-
Notifications
You must be signed in to change notification settings - Fork 707
[css-display][css-pseudo] Clearly define display: contents behaviour on pseudo-elements #6518
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
Comments
It's also worth noting behaviour is different just for ::before/::after. Firefox makes it work like display: revert; I think, and Chrome/Safari makes it work like normal elements. |
That is a known Gecko bug, fwiw, see https://searchfox.org/mozilla-central/rev/a831b7db5643a9ae7a1ce2851330ce94075093ad/servo/components/style/style_adjuster.rs#501 |
I had a discussion with @emilio, and it sounds like everything is well defined in https://drafts.csswg.org/css-pseudo/, just in obscure ways:
display does not apply. Similar to inline level boxes.
e.g. display does not apply atm.
e.g. display does not apply to ::placeholder, so display: contents does nothing.
I assume that means this should just work like it does on That being said, one thing that would be nice to clarify would be the computed values, meaning the initial values when |
Yup, we agree with Emilio - the tree-abiding pseudos that allow 'display' should already be reasonably defined in how they interact with "display:contents" (aka, like normal elements would), and anything else just doesn't allow 'display' at all, so the question is moot. The computed value of 'display' on pseudos like ::first-line should be defined by CSSOM; if it's not, we can file an issue on that spec, but it's not the Display spec's issue. ^_^ |
https://drafts.csswg.org/css-display/#box-generation
https://drafts.csswg.org/css-pseudo/
While working on
display: contents
handling for::backdrop
(which has clearly defined rules), I noticed it is not well defined for pseudo elements in general, and behaviour is inconsistent across different browsers (notably for::marker
or::file-selector-button
). Should we try and make some easy to understand rules?It would be convenient if those rules were based on spec concepts, e.g. "tree-abiding pseudo-elements", "Typographic Pseudo-elements". "highlight pseudo-elements".
The text was updated successfully, but these errors were encountered: