Comments (7)
@khushalsagar Would you mind inventorying what we've got / decisions we've made about this so far? :)
from csswg-drafts.
@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.
from csswg-drafts.
@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>
from csswg-drafts.
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.
from csswg-drafts.
@flackr pointed out that
@property
declarations behave as per spec
Also @font-face
.
from csswg-drafts.
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).
from csswg-drafts.
Closing this based on the clarification at #10325 (comment).
from csswg-drafts.
Related Issues (20)
- [selectors] Parameterized selectors HOT 16
- [css-view-transitions-2] (feature) access view-transition snapshot as an image/ImageData HOT 9
- [scroll-animations] Allow smooth animation from lvh to svh
- [web-animations] how to make animate() method work with CSSKeyframesRule object? HOT 4
- [css-color-5]: Relative Colors doesn’t work with `calc(l + 10%)` HOT 1
- [css-color-5]: light-dark() doesn’t work with Relative Colors HOT 2
- Two "variants" of `color-mix()` ?? HOT 4
- [css-animations-2][web-animations-2] (proposal) Add pointer driven animations
- [css-values-5] Should `interpolate-size` be a new value to animation/transition-behavior? HOT 8
- CSS Color; light-dark() should be applicable on more properties. HOT 12
- [css-color-4] Evaluate static gamut mapping algorithms for oklab/oklch spaces HOT 3
- [css-easing-2] Linear easing function requires at least two points? HOT 3
- [scroll-animations-1] Consider adding a timeline range that takes ink overflow into account
- [scroll-animations-1][css-animations-1] A non-animated "Is in viewport" HOT 4
- [css-ui-4] Add `outline-offset-(inline|block)[-(start|end)]`
- [css-view-transitions-2] Capture modes HOT 1
- [css-view-transitions-1] Consider a wider margin from viewport than 0 for offscreen elements
- [css-tables] block size distribution to table sections not interoperable
- [css-tables] Distribution of block size to table sections not interoperable. HOT 4
- [css-scrollbars] Scrollbar Hover/Interaction Colors HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csswg-drafts.