Skip to content
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

[css-cascade] Cascade priority of presentation hints vs. tree scopes #6659

Closed
xiaochengh opened this issue Sep 22, 2021 · 7 comments
Closed

Comments

@xiaochengh
Copy link
Contributor

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:

<div id=host>
  <img width=100 height=100 style="background-color: green">
  <template shadowroot=open>
    <slot></slot>
    <style>
      ::slotted(img) {
        width: 200px;
    }
    </style>
  </template>
</div>

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.

@mirisuzanne
Copy link
Contributor

This makes sense to me. Adding agenda+ to get a resolution on this.

@emilio
Copy link
Collaborator

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

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Cascade priority of presentation hints vs. tree scopes, and agreed to the following:

  • RESOLVED: Presentation hints into their own origin between user and author in cascade
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

@xiaochengh
Copy link
Contributor Author

xiaochengh commented Oct 7, 2021

The resolution has a side effect that a revert in author style would revert to presentational hints. Do we care about that?

Edit: Chrome puts internal presentational hints on table elements (code). So the resolution breaks revert on these elements.

@tabatkins
Copy link
Member

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.

@fantasai
Copy link
Collaborator

Edits committed, @xiaochengh @tabatkins if it looks good please close out the issue. ^_^

@xiaochengh
Copy link
Contributor Author

LGTM

@mirisuzanne mirisuzanne moved this from To Resolve to To Draft in Cascade 5 (Layers) Nov 9, 2021
@mirisuzanne mirisuzanne moved this from To Draft to Complete in Cascade 5 (Layers) Nov 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

6 participants