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-anchor-positioning-1] [scroll-animations-1] [css-view-transitions-1] Scoping names on elements based on tree scope #10304

Closed
khushalsagar opened this issue May 9, 2024 · 7 comments

Comments

@khushalsagar
Copy link
Member

Both #10145 and #10303 are tackling how view-transition-name applies across tree scopes. But the conceptual problem seems common across other features like anchor positioning or scroll driven animations which have a similar pattern of assigning names to elements which are later used for animations/layout tied to a tree scope. Please add if I missed a feature!

Filing this issue to decide whether each feature needs to define their own behaviour when dealing with shadow DOM or do the choices we make on the VT issues make sense across all such naming properties in CSS.

@astearns.

@fantasai
Copy link
Collaborator

@khushalsagar Would you mind inventorying what we've got / decisions we've made about this so far? :)

@khushalsagar khushalsagar changed the title [css-anchor-positioning-1] [scroll-animations-1] Scoping names on elements based on tree scope [css-anchor-positioning-1] [scroll-animations-1] [css-view-transitions-1] Scoping names on elements based on tree scope Jun 25, 2024
@khushalsagar
Copy link
Member Author

@fantasai did some digging around on this and landed on https://drafts.csswg.org/css-scoping-1/#shadow-names. This is the closest thing in CSS specs which is trying to define a generic concept of how global names should be handled. This was discussed on #1995.

There's 2 relevant concepts:

  • Tree scoped name: Each time a name is defined it is assumed to be global within its tree scope. The root element hosting the stylesheet is implicitly part of the namespacing for these names.
  • Tree scoped reference: When a name is used by a CSS property (like animation-name), the root element hosting the stylesheet (which establishes it's tree scope) is again captured.

When de-referencing a tree scoped reference, we start looking in the tree scope which matches the reference and keep going higher in the tree scope hierarchy until a match is found. This essentially means that names defined in a tree scope are visible to the descendants by default (if they are not overridden) but names defined in an inner tree scope are not visible to outer tree scope. This has been highlighted as an issue for anchor positioning, see #9408.

But there's 2 issues with the above:

  • This means names in a scope are visible throughout the subtree by default which goes against @annevk's comment here that exposing names should be an opt-in.

    There's also a comment about names in inner scope going only 1 level up but that's a separate conversation since names are not exposed up in the hierarchy.

  • The implementation doesn't align with the spec. At least for @keyframe and @property the names defined in an outer tree scope can't be referenced by the inner tree scope in Chrome, Firefox and Safari. And this is actually good if we do want an opt-in for names to be visible across shadow DOM boundaries.

So adding this to the agenda to revisit the spec.

@khushalsagar
Copy link
Member Author

@flackr pointed out that @property declarations behave as per spec, i.e., declarations in the outer scope are visible in inner scope. Here is an example: https://jsbin.com/xoqebek/edit?html,output (credits to @flackr).

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>JS Bin</title>
</head>
<body>
<div id="host">
  <template shadowrootmode="open">
    <div class=outer>I'm in the shadow DOM using outer names</div>
    <div class=inner>I'm in the shadow DOM using inner names</div>
    <style>
      @property --inner-property {
        syntax: "<color>";
        inherits: false;
        initial-value: green;
      }
      @keyframes inner-anim {
        from { opacity: 1;}
        to { opacity: 0;}
      }
      .outer {
        animation: outer-anim 1s infinite;
        color: var(--outer-property);
      }
      .inner {
        animation: inner-anim 1s infinite;
        color: var(--inner-property);
      }
    </style>
  </template>
</div>
  <style>
    @keyframes outer-anim {
      from { opacity: 1;}
      to { opacity: 0;}
    }
    @property --outer-property {
      syntax: "<color>";
      inherits: false;
      initial-value: green;
    }
    #outer {
      animation: outer-anim 1s infinite;
      color: var(--outer-property);
    }
    #outer-inner {
      animation: inner-anim 1s infinite;
      --inner-property: jfaowiej; /* not a valid color so will be discarded if property registration is used. */
      color: var(--inner-property);
    }
  </style>
  <div id="outer">I'm in outer DOM using outer names</div>
  <div id="outer-inner">I'm in outer DOM using inner names</div>
</body>

@khushalsagar
Copy link
Member Author

The proposal here seems relevant to this problem: #8915 (comment).

If the idea in the existing spec makes sense then the above proposal could be the opt-in to gate exposing of names as defined in that spec (in terms of priority order). The spec misses defining how an outer tree scope can use names in inner tree scopes but I think that could be as simple as deciding based on the DOM order of the roots associated with descendant tree scopes.

@noamr
Copy link
Collaborator

noamr commented Jul 1, 2024

@flackr pointed out that @property declarations behave as per spec

Also @font-face.

@noamr
Copy link
Collaborator

noamr commented Jul 1, 2024

I'm not convinced that what's described for at-rule declarations at https://drafts.csswg.org/css-scoping-1/#shadow-names applies to peer-to-peer names like view-transition-name and view-timeline-name. IMO as a general rule those should be 100% scoped to the tree where they're defined, and there should arguably be a way to pierce through the shadow boundary for particular names (though #10303 might be enough here).

@khushalsagar
Copy link
Member Author

Closing this based on the clarification at #10325 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants