Incorrectly generated css
johno opened this issue · comments
Firstly, thanks for your work on this plugin!
I seem to be encountering a bit of an issue when trying to use it with a ruleset that includes float and _display properties:
Input
.fl { float: left; _display: inline; }
.fr { float: right; _display: inline; }
.fn { float: none; }Output
.fl { _display: inline; }
[dir=ltr] .fl { _float: left; }
[dir=rtl] .fl { _float: right; }
.fr { _display: inline; }
[dir=ltr] .fr { _float: right; }
[dir=rtl] .fr { _float: left; }
[dir] .fn { float: none; }Not sure what's going on yet, but I will try and at least open up a pr with a failing test case shortly.
In my opinion, this output:
.test { _display: inline; }
[dir=ltr] .test { _float: left; }
[dir=rtl] .test { _float: right; }
is better than this output:
[dir=ltr] .test { float: left; _display: inline }
[dir=rtl] .test { float: right; _display: inline }
Because it has the same effect yet:
- Avoids duplication
- Avoids increase of selector specificity score
The _display property is not direction-specific so there is no need to put it in a [dir=...] declaration.
Just saying.
I'm not sure about the normal behavior for this module - I haven't delved too deep into it.
Breaking out the display: inline; definitely makes sense. My issue is with the float property ending up with the underscore prefix: _float: left. I'm guessing it has something to do with the parsing, causing the float to take on the display property's prefix browser hack.
OK, sorry, I missed that. I was reading PostCSS documentation yesterday, and came across a mention that non-standard prefixes (such as *, _, etc.) are stored in declaration.raws.before (or such), which you would normally expect to contain only whitespace.
So maybe this gets duplicated for some reason and inadvertently applied to the wrong declarations.
I add passing test for this case. Looks like PostCSS fix it in latest releases.
Sorry for late answer and thanks for report and PR!
No worries, thank you!