-
Notifications
You must be signed in to change notification settings - Fork 711
[css-cascade] Cascade priority of presentation hints vs. tree scopes #6659
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
This makes sense to me. Adding agenda+ to get a resolution on this. |
In Gecko presentational hints are collected after user rules, but before all other author rules, effectively in their own cascade level: https://searchfox.org/mozilla-central/rev/1dab956095020c53aa66cbee8845eb1fa925b75c/servo/components/style/rule_collector.rs#474-492 |
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: Cascade priority of presentation hints vs. tree scopes<dael> github: https://github.com//issues/6659 <dael> miriam: Problem noted here is that as specced presentational hints do sometimes override author styles. I think not the intent <dael> miriam: Request is fix spec so presentational hints always overwritten by author styles. Likely moving up in cascade so immediatly after origins <astearns> ack fantasai <dael> fantasai: I would make it it's own origin. Simpliest fix <dael> TabAtkins: I think so too <dael> astearns: Make it its own origin and spec where it fits? <dael> fantasai: Yeah. Answer to that is obvious. Don't want to change behavior <dael> miriam: Between user and author? <dael> fantasai: Yep <dael> astearns: Concerns? <dael> florian: Why is this not in UA origin? <dael> TabAtkins: Presentational hints come from author doing things. Interp as author intent, jsut weaker <dael> astearns: prop: Presentation hints into their own origin between user and author in cascade <dael> astearns: Obj? <dael> RESOLVED: Presentation hints into their own origin between user and author in cascade |
The resolution has a side effect that a Edit: Chrome puts internal presentational hints on table elements (code). So the resolution breaks |
Good catch; no we don't. We probably want to have an explicit statement in revert that if triggered from the author origin, it skips past presentational hints as well. |
Edits committed, @xiaochengh @tabatkins if it looks good please close out the issue. ^_^ |
LGTM |
This issue affects CSS Cascade Level 4 and 5, both of which have defined the cascade priority comparison between tree scopes, but are not clear which tree scope presentational hints belong to (when UA treats them as author style).
Level 4 says presentational hints are treated as "with a specificity of zero placed at the start of the author style sheet", and Level 5 says they are "in their own cascade layer placed as the lowest layer in the author origin".
Neither says anything about tree scopes, so I'll assume they belong to the same tree scope as the element itself.
As a result, when comparing presentational hints vs.
:host
or::slotted
rules from a shadow tree, presentational hints win because they are in an outer tree scope (see example below). This seems wrong, as the intention of the spec seems to be that any author rule can beat presentational hints.To fix it, I'm proposing adding presentational hints as an independent sorting criterion into Cascade Sorting Order that is lower than origin and importance and higher than context, so that when comparing presentation hints with other rules, presentational hints never win.
Example:
If we treat presentational hints as author style in the same tree scope as the element, then the result
width
of the image should be 100px because the presentational hint beats the::slotted
rule. Fortunately, I haven't seen any browser implement this behavior (tested Chrome, Firefox and Safari), so this is probably just a spec bug fix.The text was updated successfully, but these errors were encountered: