-
Notifications
You must be signed in to change notification settings - Fork 465
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
mixin inside at-root not working correctly #2006
Comments
This PR add specs for sass/libsass#2006
This PR add specs for sass/libsass#2006
This PR add specs for sass/libsass#2006
This PR add specs for sass/libsass#2006
I'm pretty close on this. Should have something this weekend. |
I thought this may be fixed a side effect of correcting our cssizg'ing of at-root in #2089 but that wasn't the case. |
I've compared our at-root implementation against Ruby Sass. Our implementation is correct in this case. This is the AST when entering CSSize.
|
This is required to prevent some instances of parentizing when we shouldn't like sass#2006. This isn't a complete fix because we incorrectly add parent refs during parsing which also needs to be addressed.
This is required to prevent some instances of parentizing when we shouldn't like sass#2006. This isn't a complete fix because we incorrectly add parent refs during parsing which also needs to be addressed.
This is required to prevent some instances of parentizing when we shouldn't like sass#2006. This isn't a complete fix because we incorrectly add parent refs during parsing which also needs to be addressed.
This is required to prevent some instances of parentizing when we shouldn't like sass#2006. This isn't a complete fix because we incorrectly add parent refs during parsing which also needs to be addressed.
This PR activates specs for sass/libsass#2006
LibSass fully parses selectors during the parsing stage. This is different from Ruby Sass which parse selectors and string during the parsing stage, and lazily eval'ing when required. This difference causes some pathological selector issues. Our eager parsing of selectors has resulted in us hacking in fake `Parent_Selector` into `Sequence_Selector` during parsing. These fake `Parent_Selector` play havoc with `resolve_parent_refs` when within `@at-root` blocks. I spent a couple weeks going down the rabbit whole of refactoring our selector parsing to be lazy before bailing. Explicitly marking which `Parent_Selector` are fake during parsing allows us faithfully implement the `implicit_parent` flag in `resolve_parent_refs`. Fixes sass#2006 Fixes sass#2198 Spec sass/sass-spec#936
LibSass fully parses selectors during the parsing stage. This is different from Ruby Sass which parse selectors and string during the parsing stage, and lazily eval'ing when required. This difference causes some pathological selector issues. Our eager parsing of selectors has resulted in us hacking in fake `Parent_Selector` into `Sequence_Selector` during parsing. These fake `Parent_Selector` play havoc with `resolve_parent_refs` when within `@at-root` blocks. I spent a couple weeks going down the rabbit whole of refactoring our selector parsing to be lazy before bailing. Explicitly marking which `Parent_Selector` are fake during parsing allows us faithfully implement the `implicit_parent` flag in `resolve_parent_refs`. Fixes sass#2006 Fixes sass#2198 Spec sass/sass-spec#936
This code was recently added to foundation.
Ruby Sass
LibSass
I've done some digging and looks like this has never worked. The issue appears to be due to parentize not respecting at-root.
Spec added sass/sass-spec#769
The text was updated successfully, but these errors were encountered: