Dropped styles when using CSS nesting to form selectors of multiple classes
Categories
(Core :: DOM: CSS Object Model, defect)
Tracking
()
People
(Reporter: rchristian, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0
Steps to reproduce:
Open the attached HTML document, it sets up 4 buttons and each should have a unique background color.
Actual results:
Half of the elements (2) do not have any background colors, the styles seemingly don't apply.
Expected results:
All selectors should work.
It seems like, behind the scenes, these selectors are added to an ordered list of some sort where every other item is "dropped", or at least, that's my best explanation for it.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•2 years ago
|
|
|
||
Comment 2•2 years ago
|
||
For what it is worth, I see the same behavior on Chrome and Safari (first and third button are grey, second button is blue, fourth button is green).
|
Reporter | |
Comment 3•2 years ago
|
||
|
|
Reporter | |
Comment 4•2 years ago
|
||
Indeed, I've seen the same. However, to my knowledge, this should by syntactically valid (happy to be corrected if not).
Fiddling with the order of the four nested classes, I have seen situations in which it becomes the outer two or inner two buttons that are colored instead, it's not always every other. I don't have any good explanation for this though.
|
|
||
Comment 5•2 years ago
|
||
The severity field is not set for this bug.
:TYLin, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Comment 6•2 years ago
|
||
There are "No-Break Space" (U+00A0) between &.first and { as well as &.third and {. I think that is why the CSS parser failed to parse the first and third background color.
I attached a testcase with "No-Break Space" replaced by space. It work as expected.
|
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 7•2 years ago
|
||
Huh, didn't spot that (was copied from a real issue we were having, though simplified down).
Is there a possibility of handling no-break spaces? Obviously this is a problem that is extremely difficult to notice for users.
|
|
||
Comment 8•2 years ago
•
|
||
Is there a possibility of handling no-break spaces? Obviously this is a problem that is extremely difficult to notice for users.
I understand this can be difficult to debug. I think you propose adding "No-Break Space" (U+00A0) to CSS grammar https://www.w3.org/TR/css-syntax-3/#whitespace. The best approach for this to happen is to file an issue at CSS Working Group https://github.com/w3c/csswg-drafts, and explain why this is important with real testcases. We have to get the spec & all the other browsers to agree before we can implement this change. Otherwise, there will be an interop issue -- that means the testcase works differently in other browsers, which is also bad for web developers.
|
|
Reporter | |
Comment 9•2 years ago
|
||
Yeah, just chatted with someone a bit more familiar who told me the characters supported are rather strictly defined by the spec; this isn't just chance behavior. Probably hard to change that today.
Thank you for your time in tracking that down. I was utterly baffled by (seemingly) inconsistent do to copy/pasting the original selector, not realizing it (and therefore my reproduction cases) sometimes had it added in.
|
|
||
Comment 10•2 years ago
|
||
No worries. Thank you for reporting the bug!
Description
•