[css-scoping] Handling global name-defining constructs in shadow trees #1995

tabatkins · 2017-11-17T22:23:49Z

Since the introduction of Shadow DOM, we've been struggling with what to do with name-defining things, like @font-face, which define global names for other things to reference.

Can @font-face be used in shadow trees?
Does it still define a global name? What's our plan to deal with collisions between non-communicating components?
Does it define a scoped name? What's our plan to deal with collisions between an outer and inner @font-face name, when the font-family property inherits across a boundary?

Right now the answer is a collective shrug. I think I have an answer, however:

Every name-defining thing (such as @font-face) is valid inside of shadow trees, and is scoped to the TreeScope that its defining stylesheet is in. Nested shadows can use name-defining things defined in higher trees (see below), but can't directly refer to them.
Every reference to a defined name (such as a font-family font name) is implicitly a tuple of (name, defining scope), where the defining scope is the TreeScope the reference's stylesheet is in. (In other words, it's always a reference to the local thing defining the name, not something further up the scope tree.)
Applying a style from a stylesheet in one TreeScope to an element in a different TreeScope (such as via ::part()) thus resolves the name against the stylesheet's TreeScope, even if the element's TreeScope has that name redefined to something else. (So an outer page setting an ::part(foo) { animation: foo 1s; } uses the @keyframes foo {...} from the outer page, not anything from inside the shadow tree that that "foo" part is in.)
The value/scope tuple is inherited normally thru TreeScopes, meaning that a particular reference refers to the same name-defining construct no matter how deeply it gets inherited.
This does not affect how the value serializes - the reference continues to serialize as just a keyword, with no tree scope mentioned. So setting a property on an element to its own computed value is not always a no-op when shadow DOM is involved; the new value will be referring to the element's tree scope, which may not have that name defined or have it defined to something else.
This does affect how the value reifies in TypedOM - keywords will gain a nullable .scope attribute or something, which points to the tree scope the keyword is being resolved against.

This has some implications. Since the defining scope is implicitly captured by a reference, it doesn't change as the value inherits. Thus, in this situation:

<style>
@font-face { font-family: foo; ... }
body { font-family: foo; }
x-component::part(my-p) { font-family: foo; }
</style>
<body>
 <p>ONE
 <my-component>
  <::shadow>
    <style>
    @font-face { font-family: foo; ... }
    p.foo { font-family: foo; }
    </style>
    <p>TWO
    <p class=foo>THREE
    <p part=my-p>FOUR
  </>
 </>
</>

ONE is rendered in the outer "foo" font (standard behavior)
TWO is rendered in the outer page's "foo" font (via inheritance, since the outer scope was captured at definition time)
THREE is rendered in the shadow's "foo" font (specified via a style in the shadow tree, thus implicitly capturing the shadow as its scope)
FOUR is rendered in the outer page's "foo" font (specified via a style in the outer page, thus implicitly capturing the outer page as its scope)

Scripting is a slightly thornier problem here. When setting styles, we can use the rules I've already laid out - you're always setting the style in some stylesheet (perhaps the implicit one attached to an element and accessed via el.style), so there's a consistent notion of an associated TreeScope. (This may not always be obvious, but it's clear - a script that pokes around inside of the shadows of its components and sets styles needs to be aware of what scope the stylesheet is in and what scope the name-defining thing it's trying to reference is in.)

(Edited to take into account the compromise to drop the scoped() syntax and only allow implicit references via the string-based API.)

The text was updated successfully, but these errors were encountered:

tabatkins · 2017-11-17T23:18:55Z

Ojan privately points out that it's very likely the integer is over-engineering, and virtually every case will just be wanting the nearest-local or the global version of a name. You still need the ability for a value to refer to an arbitrary scope for inheritance to work properly, but you don't actually need to be able to specify that reference - in other words, we don't really need syntax for such a thing.

This simplifies it considerably. We can just define that the keyword always refers to the globally-defined name, and have scoped(foo) refer to the local name (name tbd, of course). Internally, the value will still be stored as a (name, scope) tuple, but in some cases, from some stylesheets, you won't be able to write down a value that actually refers to the specified name. The TypedOM will be completely correct, however - it can still have a CSSScopedKeywordValue with a .scope property that refers to a particular TreeScope, and you can construct that explicitly if you need to refer to a particular scope's name. You just won't be able to, in some cases, reproduce the effects of a style via an explicit property set in a stylesheet or the string-OM.

tabatkins · 2017-11-17T23:51:25Z

Alternate argument in favor of the integer: it means the value is locally interpretable at all times. If we make the bare keyword (like font-family: foo;) always refer to the global scope, and require using scoped() to refer to a local one, then we can just have a special inheritance rule, where when a scoped() value inherits past a shadow boundary, its integer automatically increments. This maintains the "el.style.foo = getComputedStyle(el).foo is a no-op" invariant, and means we don't necessarily have to track a JS object in the internal value, just an integer.

Common usage will still be limited to just foo and scoped(foo), and we can even warn authors to not use scoped(foo, N) as it's fragile, but it would be supported for back-end reasons.

ruphin · 2018-02-20T21:53:13Z

I would argue that the expected behaviour is for the bare reference (font-family: foo) to always refer to the local scope by default. My argument is that I feel CSS behaviour should be the same in a scoped environment and a global environment; it would be weird that it takes a different syntax to define a font and use it depending on the scope it is defined in. Under the proposal by @tabatkins the following code would have a different meaning depending on if it was defined in the global scope or inside a ShadowRoot:

@font-face { font-family: foo; ... }
p { font-family: foo; }

The expectation from a developer standpoint is that when using the normal syntax, styles within a ShadowRoot behave like they are in their own global scope, and do not interact with outside styles. There are some cases where alternative syntax is needed to resolve scoping issues (like the ::slotted() syntax), but the default syntax should always have the expected behaviour of treating the local scope as if it was the global one. (i.e. p { ... } should apply to <p> elements in the ShadowRoot, not elements slotted through <slot>)

I am suggesting this behaviour:

The bare reference font-family: foo always refers to the local scope.
If that reference is not available in the local scope, the lookup cascades to higher scopes until it finds a matching reference
There is a separate syntax to refer to the global scope, or a specific scope, font-family: scoped(foo, <integer> | global)

The difference between @tabatkins' suggested behaviour is that the bare reference font-family: foo is a shorthand for font-family: scoped(foo, 0) (instead of defaulting to global)

tabatkins · 2018-02-20T22:32:46Z

I chose the current behavior for bare keywords to match what I thought I remembered browser behavior was, or at least Chrome's. Per #715, tho, it looks like Safari does the opposite, and treats @Keyframes as local and references to it as referring to the local definition?

If we have to swap the bare keyword to be the local version, that's fine.

tabatkins · 2018-02-20T22:36:09Z

(I do think, tho, that the "bare keyword means global" behavior is slightly better aesthetically, as it means that the common case from today doesn't have to invoke the magical "rewrite yourself to refer to the parent scope" behavior; you only get that if you explicitly use scoped().)

ruphin · 2018-02-21T00:30:07Z

I think we are actually seeing a different issue here. All browsers with Web Component support use local definitions by default (including Chrome), at least for @Keyframes definitions (I will check @font-face behaviours and report back) but there is an inconsistency in how slotted elements are treated.

Chrome uses local definition in the scope where the DOM node the animation is targeting is defined, as per this example:

<my-component>
  <div id="one"></div>
  <::shadow>
    <style>
      @keyframes some-animation { ... };
      div {
       animation-name: some-animation;
      }
      ::slotted(div) {
        animation-name: some-animation;
      }
    </style>
    <div id="two"></div>
    <slot></slot>
  </>
</>

In this case, div#one is attached inside the lightdom (outside my-component shadow tree), so Chrome will look for a definition in that scope, fail to find, and do nothing. div#two is attached inside the shadow tree of my-component so Chrome will look there for some-animation and apply the animation correctly.

Safari will apply the animation correctly in both cases, because it uses the scope of the CSS reference (the animation-name: some-animation).

I feel like the correct scope to use should be the scope where the CSS reference is made, and not the scope where the affected node is attached to the DOM.

A more complete reproduction with comments can be found here: https://codepen.io/ruphin/pen/zPQvXw

Both browsers are in agreement on the scoping rules of @Keyframes definitions except for the case of slotted elements styled from within the shadowroot. Chrome renders a red and two green squares, and Safari renders a blue and two green squares.

Nadya678 · 2018-02-21T14:48:14Z

@ruphin: Anonymous tags </> are lagal in HTML? looks like self-disclosed tag without name?

ruphin · 2018-02-21T15:05:48Z

It's a pseudo-code example like in the original post. A working example with valid syntax can be found in the codepen.

tabatkins · 2018-02-21T19:05:47Z

@ruphin Ah, cool, thanks for the compat research. I agree then that we should match Safari's behavior and let the bare keyword refer to the local definition. I'll update the OP.

emilio · 2018-05-01T08:13:45Z

Current chrome behavior is somewhat broken, leaking @keyframe names from inside the shadow root, fwiw. The following test-case fails on Chrome, for example, showing red:

<!doctype html>
<style>
#host {
  width: 100px;
  height: 100px;
  background: green;
  animation: myanim 10s infinite;
}
</style>
<div id="host"></div>
<script>
  host.attachShadow({ mode: "open" }).innerHTML = `
    <style>
      @keyframes myanim {
        from { background: red; }
        to { background: red; }
      }
    </style>
  `;
</script>

What WebKit does makes sense (it keeps track of the scope the rule that ended up in the declaration). But that feels somewhat like a layering violation, having to propagate the cascade order down so much.

emilio · 2018-05-01T09:28:39Z

Hmm, the problem with what WebKit does is that it doesn't work if you explicitly inherit the name from an scope you don't have access to, because suddenly it's from an scope you don't have access to. Or worse, it's from a different scope.

I'm having a hard time deciding what to implement in Firefox here. :(

emilio · 2018-05-01T09:44:50Z

Ugh, apparently Blink's behavior is pretty intentional judging their document lookup:

https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/resolver/style_resolver.cc?l=1267&rcl=90f9f8680ebb4a87d177f3b0833372ae4e0c88d8

Blink doesn't make animations in ::slotted selectors work (:host works basically by chance), but for now I'm interested in not making Firefox's implementation prone to compat problems, so given it's simpler, I'll do what Blink does.

ruphin · 2018-05-01T11:52:29Z

I consider the Blink implementation to be broken, and I would urge you to reconsider your position and follow the Safari implementation instead.

From a developer point of view, the Blink implementation breaks the Web Components contract of code encapsulation. With their implementation, it is impossible to style a slotted component without breaking the encapsulation of the component and injecting style into the global document.

ruphin · 2018-05-01T11:57:27Z

With that I mean that in specific cases, as a Web Component author, with the Blink implementation, you must literally inject a <style> node outside your component in order style elements inside your component with the CSS ::slotted() spec. I consider this a strong violation of the core principles of Web Components.

emilio · 2018-05-01T13:33:47Z

Oh, fwiw I totally agree.

I have WIP patches to switch to WebKit's approach here: https://bugzilla.mozilla.org/show_bug.cgi?id=1458192, with tests at https://bugzilla.mozilla.org/show_bug.cgi?id=1458189.

Note that WebKit breaks when inheriting across components. Getting that right is a bit more complex. That's why for now I landed a Blink-like approach. As soon as the spec authors confirm that the intention of the spec is to do what WebKit does, or at least confirm that what Blink does is not the intent of the spec, I can put them up for review and land them in Firefox. But until then I don't think it's worth complicating the code if the spec is going to change substantively.

ruphin · 2018-05-02T00:58:40Z

That sounds like a good approach. Who would be spec authors for this case? We have a comment from @tabatkins up in this thread.

Can you provide an example of component inheritance that breaks in the WebKit implementation? I am not aware of any issues

emilio · 2018-05-02T01:55:47Z

If you use animation-name: inherit across shadow boundaries it copies the m_styleScopeOrdinal member, even though it means a different thing. Simplest test-case would be something like:

<!doctype html>
<style>
#host {
  animation: myanim 10s infinite;
}
</style>
<div id="host"></div>
<script>
  host.attachShadow({ mode: "open" }).innerHTML = `
    <style>
      @keyframes myanim {
        from { background: red; }
        to { background: red; }
      }
      #inner {
        width: 100px;
        height: 100px;
        background: green;
        animation: inherit;
      }
    </style>
    <div id="inner"></div>
  `;
</script>

Which shows red. In this case it doesn't seem like a big deal because we're using just the shadow tree rules, but I think I can come up with more confusing test-cases involving nested slots.

emilio · 2018-05-02T01:57:14Z

Basically, putting Shadow-related information in the computed style, even if not exposed, looks like a bit of a layering violation, causing issues like that.

tabatkins · 2018-05-02T17:32:16Z

You don't just have a "comment" from me, I started the thread and have an active proposal for how to handle these things. ^_^

Yes, Blink's behavior is bad. I'm not sure of the exact details of WebKit's implementation, but I'm pretty certain it's also still not what we finally want. Thus my proposal up top: name-defining things should scope their names to the TreeScope their stylesheet appears in; name-referencing things default to only referring to the top-level definition; scoped(ident) can be used to refer to the definition from the local (to the stylesheet) TreeScope (or explicitly from an ancestor TreeScope anywhere between your local and the top level); inheritance across TreeScopes auto-increments the integer argument in scoped(), so it maintains its correct reference.

rniwa · 2018-11-16T04:04:33Z

Apple's WebKit team's feedback for the proposal will be that:

Bare name reference by font-family, keyframes, etc... should first look up its name in the current scope, and then fallback to its parent scope, its grandparent scope, etc... Also see the compatibility analysis in [css-scoping] Handling global name-defining constructs in shadow trees #1995 (comment)
We're highly skeptical that scoped(indent) would be a useful feature given (1). We propose we get rid of that feature.

Basically our preferred approach here is to adopt WebKit's current approach, add the "inheritance" of names from the parent tree, then fix the inheritance issue since inheritance leaking the existence of shadow tree is a generic problem tracked by whatwg/html#3748.

ruphin · 2018-11-16T16:23:01Z

I concur that the current implementation in WebKit is the most sensible approach to this problem. If it is extended with fallbacks to ancestor scopes, that would be more than sufficient for almost all purposes.

I also do not see a strong use for the scoped() feature if the above is implemented.

tabatkins · 2018-11-16T18:42:57Z

Apple's WebKit team's feedback for the proposal will be that: [...snipped...]

No, recursive search does not work.

If the outer page has a @font-face declaring a "foo" family, and sets body { font-family: foo; }, then a component declares its own "foo" @font-face but doesn't immediately use it, inheritance will still carry the font-family: foo declaration into the shadow.

With recursive search, as this declaration crosses the shadow boundary, it will suddenly start referencing the inner "foo" @font-face, which is completely unexpected. It means that shadows aren't encapsulated from the outer page; if they declare a font-family that happens to have the same name as one the outer page uses, it'll suddenly break the display of the component. The same applies to every other inheritable reference; it means an inherited fill: url(#foo) will break if the shadow happens to have an element with the same ID, etc.

With my proposal (all referencing things are implicitly a (scope, reference) pair), all of this works as expected. The outer page's font-family declaration inherits correctly, maintaining its reference to the outer @font-face, regardless of what has been declared inside the shadow. If you ask for the computed style on one of the shadow elements, it'll serialize as font-family: scoped(foo, 1) instead, but the underlying value (the scope/name pair) is unchanged.

Also see the compatibility analysis in #1995 (comment)

Chrome's behavior is definitely broken in that example; the two styles should act identically, either both seeing the shadow's @Keyframes or neither seeing it (depending on how the resolution rules work out).

Compat's thornier than that tho, isn't it? In Chrome, @font-face simple doesn't work in shadows at all, and all font-family declarations implicitly reference the global definition. I can't easily test Safari at the moment, so I'm not sure what y'all do. My point, tho, is that compat is a complete mess around this subject right now, and whatever we do to make things consistent and reasonable will cause some amount of problems for some number of people.

bicknellr · 2021-05-14T22:17:46Z

True, there's at least precedence for this behavior in CSS custom properties which have to handle almost exactly the same problem. I think I would have preferred both to have been more strictly scoped but, given how similar they are and that one is certainly set in stone, having the scoping behavior be consistent is probably more important.

tabatkins · 2021-05-14T22:57:00Z

@rniwa I want to make sure that y'all have the correct "inheritance" behavior, because I know we've discussed this in the past and you described your behavior as always looking up the tree for the nearest defining construct, even if the value is inherited. That is, in Example 5, according to what I understood from your previous descriptions all three elements in the shadow (.inner-default, .inner-styled, and .part-styled) would use the "inner.woff" font, rather than .inner-default and .part-styled using "outer.woff" as the spec requires.

I can't easily test Safari right now; is that still y'all's behavior? Or do you match the spec here?

(The behavior I described is broken, because it violates encapsulation in an important way - if the inner component ever defines a @font-face or similar construct with the same name as one in the outer page, it'll break any property that inherits in completely by accident, with no way for the component author to predict that this'll happen ahead of time, or fix it. The only way around it is to always author your components to use UUIDs for their @font-face and similar constructs, to guarantee that a 'font-family' inheriting in won't accidentally change meaning to suddenly refer to your @font-face. I'm not willing to spec that behavior, as it's just broken from an authoring point of view.)

lilles · 2021-05-26T16:32:11Z

@font-face rules in WebKit seem like being global - exposing @font-face into and out of the shadow tree looking at this in Safari TP:

<!doctype html>
<style>
  @font-face {
    font-family: myfont;
    font-weight: bold;
    src: local(Arial);
  }
</style>
<div style="font-family: myfont; font-weight: normal">Normal - Document</div>
<div style="font-family: myfont; font-weight: bold">Bold - Document</div>
<div id="host"></div>
<script>
  let root = host.attachShadow({mode:"open"});
  root.innerHTML = `
    <style>
      @font-face {
        font-family: myfont;
        font-weight: normal;
        src: local("Times New Roman");
      }
    </style>
    <div style="font-family: myfont; font-weight: normal">Normal - Shadow</div>
    <div style="font-family: myfont; font-weight: bold">Bold - Shadow</div>
  `;
</script>

css-meeting-bot · 2021-05-26T16:50:59Z

The CSS Working Group just discussed [css-scoping] Handling global name-defining constructs in shadow trees, and agreed to the following:

RESOLVED: Tentative agreement on the spec text as in the draft. Subject to further review of current interop behavior

The full IRC log of that discussion

<dael> Topic: [css-scoping] Handling global name-defining constructs in shadow trees
<dael> github: https://github.com//issues/1995
<Rossen_> https://github.com//issues/1995#issuecomment-840895144
<dael> Rossen_: This is being brought a second time. Link to more relevant discussions ^
<Rossen_> q?
<Rossen_> ack fantasai
<dael> TabAtkins: Since into of shadow dom and we isolate chunks of html it beacme unclear how name defining contructs work. Can fontface defined in outer be in shadow dom? Defined in shadow dom in outer? If same name in both which wins?
<dael> TabAtkins: All undefined
<dael> TabAtkins: Had a prop for a long time.. Put it in scoping. Tweaked to match reality
<dael> TabAtkins: Summary of proposal for informative- Whenever you have a name defining construct the names are defined in a css context, a tree scope. Inherit into nested tree scopes. A component with shadow dom can see names in outer scope and override
<dael> TabAtkins: Same logic as inheritence. Within the shadowdom the inner defined one wins and doens't inerfere with rest of page
<dael> TabAtkins: References to that. font-family: foo on an element. It sees the font-face rule from the context it's in. If you write it int he shadow dom you see the shadow dom defined. Carries that around as it inherits. Writing font-family:foo in the outer page. Inherits into shadow dom it still referes to outer page, even if there's a font-face:foo in the shadow dom
<dael> TabAtkins: Required so you don't have to worry about collisions as you inherit.
<dael> TabAtkins: [missed example about how this can be very bad]
<dael> TabAtkins: That's the proposal. All reflected in scoping spec. To best of my knowledge the spec text is completed and well defined. Somewhat matches some browsers impl. none do everything correctly. for font-faces specifically there's a mix across browsres. I don't know what plan is to update to correct.
<astearns> missed example is you can only avoid collisions by adding a bunch of random noise to names
<Rossen_> q
<dael> TabAtkins: I htink any behavior except what's in the spec is bad for authors and users. There might be compat we have to worry about and work around b/c so many years of the wild west. Would appriciate feedback to that
<dael> TabAtkins: Need to get these on a level to where things work consistantly. Right now authors cannot use name defining contrstructs in shadow dom.
<dael> TabAtkins: I tried to go through the specs I owned to make sure it's all well defined. Want to make sure everyone invokes properly. I'll ping authors of other specs
<dael> TabAtkins: If a browser impl has objections or concerns I'd love to hear them
<Rossen_> ack fantasai
<dael> fantasai: Thanks for the overall explanation model you proposed makes a lot of sense. I think we need a WG resolution on this b/c not discussed before.
<emilio> q+
<dael> Rossen_: Other opinions or concerns about impl or from impl with respect to compat risks?
<Rossen_> ack emilio
<dael> emilio: When I impl keyframe lookups in gecko and how they work in shadow dom I recalled weird behavior from other browsers. I want to make sure we have a place where we can see current state in all browsers.
<dael> emilio: I think font-face doesn't work at all in showdow trees. Maybe in safari but prob show up in document.fonts which is wrong
<dael> emilio: Usually we have something to say current state of compat
<futhark> q+
<dael> TabAtkins: Reasonable. I can put together a wiki page and we can collect data
<tantek> regrets+
<dael> emilio: That would be great. I think only keyframes work in gecko
<dael> emilio: Other thing is do we need a shadow root prototype of fonts and how does that work. For now getting @fontface working is more important
<dael> futhark: I wanted to mention we started working on this in blink. Deprioritized. Main concern is font caching. Had a plan to do it, but how do you do font caching in tree scopes; it's a complication but not impossible. not straightforward to make it performant
<dael> Rossen_: Other opinions?
<dael> Rossen_: Sounds like TabAtkins you will start collecting the current state of interop between browsers which will be great
<bkardell_> q+
<dael> Rossen_: futhark is expressing some concern about impl complexity which is good but doesn't seem like a blocker?
<Rossen_> ack futhark
<dael> futhark: Not blocking. Explanation that this isn't trivial to impl
<dael> bkardell_: Apologies if this is just noise. Conceptually document scoped things, we have a bunch of open questions and ongoing things. not nec css. Like id ref for aria. Conceptually they're very similar.
<dael> bkardell_: Feels like they shouldn't be considered completely in isolation. Not sure if that's helpful
<dael> emilio: id ref is slightly different case. That's more about allowing to reference stuff inside shadow tree in a global way. This is eq. to shadow root get element by ID not doing anything
<dael> bkardell_: Not saying they're the same. Conceptually there's a lot of issues where there's this boundary and need cooperation mechanism. Would be great if we didn't have to have 10 of them.
<dael> bkardell_: Probably just noise but in my head feels like having a lot of convos that are spiritually related.
<dael> emilio: That is true
<Rossen_> q?
<Rossen_> ack bkardell_
<dael> Rossen_: Thank you bkardell_
<dael> Rossen_: On the issue here, other opinions?
<dael> Rossen_: If not let's see if we can resolve
<dael> TabAtkins: Prop: Tentative agreement on the spec text as in the draft. Subject to further review of current interop behavior
<dael> fantasai: Can you summerize? Binding the name per context through inheritence
<dael> TabAtkins: I don't want to try and nail down to that level of summary b/c that admits some bad behaviors. There's varients that can break. Details matter a lot and would rather point to spec
<dael> Rossen_: Objections to TabAtkins prop text?
<dael> RESOLVED: Tentative agreement on the spec text as in the draft. Subject to further review of current interop behavior
<dael> fantasai: Spec is super out of date. When repub?
<dael> TabAtkins: Fine with now if we want to resolve.
<dael> fantasai: Do you have a changes summary?
<dael> TabAtkins: Need to collect it. I'm sure a lot
<dael> fantasai: Last pub was 2014
<dael> florian: Let's republish
<dael> Rossen_: TabAtkins would you gather summary of changes and we'll resolve over email. It's just WD update, right?
<dael> florian: Why would we not republish?
<dael> fantasai: In case there's unreviewed new things
<dael> florian: Alright
<dael> Rossen_: We have a path forward. Please get the set of changes and we'll resolve over email

tabatkins · 2021-05-26T18:37:12Z

Dropped the skeleton of an interop table in https://wiki.csswg.org/spec/css-scoping. I'll fill in what I can figure out in Chrome and Firefox, but any specific details filled in by people with more direct info would be great.

emilio · 2021-05-26T20:24:43Z

I filled in the Firefox details.

Note: this test case is the same as example FOUR in w3c/csswg-drafts#1995 (comment) Bug: 1225033 Change-Id: Ic02c6c0e9c623c4eb12ac4bc152716f63f6ebd52

Note: this test case is the same as example FOUR in w3c/csswg-drafts#1995 (comment) Bug: 1225033 Change-Id: Ic02c6c0e9c623c4eb12ac4bc152716f63f6ebd52 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3025847 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org> Cr-Commit-Position: refs/heads/master@{#901552}

…ist markers via shadow DOM part, a=testonly Automatic update from web-platform-tests [counter-style] Add a test for styling list markers via shadow DOM part Note: this test case is the same as example FOUR in w3c/csswg-drafts#1995 (comment) Bug: 1225033 Change-Id: Ic02c6c0e9c623c4eb12ac4bc152716f63f6ebd52 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3025847 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org> Cr-Commit-Position: refs/heads/master@{#901552} -- wpt-commits: 0993872f0a326817e4acb9b462930517816f82c4 wpt-pr: 29662

Note: this test case is the same as example FOUR in w3c/csswg-drafts#1995 (comment) Bug: 1225033 Change-Id: Ic02c6c0e9c623c4eb12ac4bc152716f63f6ebd52 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3025847 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org> Cr-Commit-Position: refs/heads/master@{#901552} NOKEYCHECK=True GitOrigin-RevId: a5cb2f8b37a6f0127ece4a213084fb332ac5bfb4

gnat · 2023-10-06T17:42:00Z

Likely of interest to people here: https://github.com/gnat/css-scope-inline

These 16 lines scopes your animation @keyframes, and adds inline style scoping in general.

tabatkins added the css-scoping-1 Current Work label Nov 17, 2017

tabatkins mentioned this issue Nov 17, 2017

[css-shadow-parts-1] Does @keyframes rule match in ::parts()? #1516

Open

tabatkins mentioned this issue Feb 20, 2018

Undefined specification for @keyframe scope on slotted content WICG/webcomponents#715

Closed

annevk mentioned this issue Feb 21, 2018

Create "topic: shadow" label #2340

Closed

annevk added the topic: shadow label Feb 22, 2018

annevk mentioned this issue Mar 15, 2018

CSS scoping for @keyframes in ::slotted(*) WICG/webcomponents#748

Closed

tabatkins mentioned this issue Aug 2, 2018

How should various document internal references work when SVG is being used in shadow DOM WICG/webcomponents#179

Closed

rniwa mentioned this issue Nov 14, 2018

[css-values] Clarify fragment URLs resolve against the current tree, not document tree #3320

Open

css-meeting-bot removed the Agenda+ label May 26, 2021

mozilla-apprentice mentioned this issue May 26, 2021

[css-scoping] Handling global name-defining constructs in shadow trees mozilla/wg-decisions#549

Closed

chromium-wpt-export-bot mentioned this issue Jul 14, 2021

[counter-style] Add a test for styling list markers via shadow DOM part web-platform-tests/wpt#29662

Merged

xiaochengh mentioned this issue Jul 19, 2021

CSS tree-scoped at-rule names and references (for @font-face, @keyframes, etc.) mozilla/standards-positions#556

Open

xiaochengh mentioned this issue Jul 23, 2021

CSS tree-scoped at-rule names and references (for @font-face, @keyframes, etc.) w3ctag/design-reviews#659

Closed

1 task

tabatkins closed this as completed Aug 30, 2021

Westbrook mentioned this issue Oct 12, 2022

@font-face and @property constructs in Shadow Roots web-platform-tests/interop#212

Closed

badlydrawnrob mentioned this issue Dec 7, 2023

@font-face doesn't respect scope when compiling less/less.js#4251

Closed

tabatkins mentioned this issue Mar 7, 2024

update test to expect shadow trees to find document keyframes web-platform-tests/wpt#44991

Merged

astearns mentioned this issue Mar 12, 2024

[css-properties-values-api] Allow @property in shadow trees w3c/css-houdini-drafts#1085

Merged

khushalsagar mentioned this issue Jun 25, 2024

[css-anchor-positioning-1] [scroll-animations-1] [css-view-transitions-1] Scoping names on elements based on tree scope #10304

Closed

tabatkins mentioned this issue Aug 30, 2024

[css-scoping] Breaking name encapsulation #10808

Open

sorvell mentioned this issue Sep 22, 2024

Open styleable shadow tree and theming w3c/tpac2024-breakouts#27

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-scoping] Handling global name-defining constructs in shadow trees #1995

[css-scoping] Handling global name-defining constructs in shadow trees #1995

tabatkins commented Nov 17, 2017 •

edited

Loading

tabatkins commented Nov 17, 2017

tabatkins commented Nov 17, 2017

ruphin commented Feb 20, 2018

tabatkins commented Feb 20, 2018

tabatkins commented Feb 20, 2018

ruphin commented Feb 21, 2018

Nadya678 commented Feb 21, 2018 •

edited

Loading

ruphin commented Feb 21, 2018

tabatkins commented Feb 21, 2018

emilio commented May 1, 2018

emilio commented May 1, 2018

emilio commented May 1, 2018

ruphin commented May 1, 2018

ruphin commented May 1, 2018

emilio commented May 1, 2018

ruphin commented May 2, 2018

emilio commented May 2, 2018

emilio commented May 2, 2018

tabatkins commented May 2, 2018

rniwa commented Nov 16, 2018

ruphin commented Nov 16, 2018

tabatkins commented Nov 16, 2018

bicknellr commented May 14, 2021 •

edited

Loading

tabatkins commented May 14, 2021 •

edited

Loading

lilles commented May 26, 2021

css-meeting-bot commented May 26, 2021

tabatkins commented May 26, 2021

emilio commented May 26, 2021

gnat commented Oct 6, 2023

[css-scoping] Handling global name-defining constructs in shadow trees #1995

[css-scoping] Handling global name-defining constructs in shadow trees #1995

Comments

tabatkins commented Nov 17, 2017 • edited Loading

tabatkins commented Nov 17, 2017

tabatkins commented Nov 17, 2017

ruphin commented Feb 20, 2018

tabatkins commented Feb 20, 2018

tabatkins commented Feb 20, 2018

ruphin commented Feb 21, 2018

Nadya678 commented Feb 21, 2018 • edited Loading

ruphin commented Feb 21, 2018

tabatkins commented Feb 21, 2018

emilio commented May 1, 2018

emilio commented May 1, 2018

emilio commented May 1, 2018

ruphin commented May 1, 2018

ruphin commented May 1, 2018

emilio commented May 1, 2018

ruphin commented May 2, 2018

emilio commented May 2, 2018

emilio commented May 2, 2018

tabatkins commented May 2, 2018

rniwa commented Nov 16, 2018

ruphin commented Nov 16, 2018

tabatkins commented Nov 16, 2018

bicknellr commented May 14, 2021 • edited Loading

tabatkins commented May 14, 2021 • edited Loading

lilles commented May 26, 2021

css-meeting-bot commented May 26, 2021

tabatkins commented May 26, 2021

emilio commented May 26, 2021

gnat commented Oct 6, 2023

tabatkins commented Nov 17, 2017 •

edited

Loading

Nadya678 commented Feb 21, 2018 •

edited

Loading

bicknellr commented May 14, 2021 •

edited

Loading

tabatkins commented May 14, 2021 •

edited

Loading