Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@extend loops output selectors in the wrong order #1392

Closed
xzyfer opened this issue Jul 27, 2015 · 11 comments
Closed

@extend loops output selectors in the wrong order #1392

xzyfer opened this issue Jul 27, 2015 · 11 comments

Comments

@xzyfer
Copy link
Contributor

xzyfer commented Jul 27, 2015

.foo {a: b; @extend .bar}
.bar {c: d; @extend .baz}
.baz {e: f; @extend .foo}

Ruby Sass

.foo, .baz, .bar { a: b; }
.bar, .foo, .baz { c: d; }
.baz, .bar, .foo { e: f; }

LibSass

.baz, .bar, .foo { a: b; }
.foo, .baz, .bar { c: d; }
.bar, .foo, .baz { e: f; }

Spec https://github.com/sass/sass-spec/tree/master/spec/libsass-todo-tests/180_test_basic_extend_loop
Spec https://github.com/sass/sass-spec/tree/master/spec/libsass-todo-tests/181_test_three_level_extend_loop

@mgreter
Copy link
Contributor

mgreter commented Aug 23, 2015

Have seen this one already, IMO it only happens with circular extends ...

@xzyfer
Copy link
Contributor Author

xzyfer commented Sep 6, 2015

As pointed out by @andybenedict in #1539 this can actually cause broken code when attribute selectors are involved.

.foo{
  &[disabled]{
    display: none;
  }
}

.bar {
  @extend .foo;
}

Libsass

.foo[disabled], [disabled].bar {
  display: none;
}

@mgreter
Copy link
Contributor

mgreter commented Jan 9, 2016

@chriseppstein maybe you have any pointers as to how the ordering works?

@mgreter
Copy link
Contributor

mgreter commented Apr 27, 2016

This is another interestingly similar issue:

.thing[disabled] {
    @extend .thing;
    background: blue;
}

ruby sass:

.thing[disabled] {
  background: blue; }

libsass:

[disabled].thing {
  background: blue; }

@chriseppstein
Copy link
Contributor

I'd really like to make sass-spec agnostic of non-semantic differences like this. The order doesn't matter and I don't think libsass should work very hard to achieve that level of consistency when there are bigger fish to fry.

@xzyfer xzyfer modified the milestones: 3.4, 3.4.1 May 20, 2016
@xzyfer xzyfer modified the milestone: 3.4.1 Sep 8, 2016
@mgreter
Copy link
Contributor

mgreter commented Sep 9, 2016

@xzyfer you pointed out that "by @andybenedict in #1539 this can actually cause broken code when attribute selectors are involved." Can you provide an example of this? I agree with @chriseppstein that it should not make any difference!?

@xzyfer
Copy link
Contributor Author

xzyfer commented Sep 9, 2016

You're both correct. I realised my mistake but hadn't removed the comment. This is why I removed the milestone as per #2174

@mgreter
Copy link
Contributor

mgreter commented Sep 9, 2016

Thanks for the clarification, so it's basically a whitespace issue ...

@xzyfer
Copy link
Contributor Author

xzyfer commented Sep 9, 2016

Correct.

@xzyfer
Copy link
Contributor Author

xzyfer commented Sep 9, 2016

Once we have semantic equivalence in sass spec, as opposed to exact matching, this will be "fixed".

@mgreter
Copy link
Contributor

mgreter commented Nov 12, 2017

Closing as dart-sass also exhibits inconsistent order with extend and doesn't seem to care.

@mgreter mgreter closed this as completed Nov 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants