[go: nahoru, domu]

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][css-scoping] Define Shadow Tree in Cascade #5372

Closed
fantasai opened this issue Jul 29, 2020 · 1 comment
Closed

[css-cascade][css-scoping] Define Shadow Tree in Cascade #5372

fantasai opened this issue Jul 29, 2020 · 1 comment

Comments

@fantasai
Copy link
Collaborator

There's a section of Scoping that is amending Cascade. We should just pull it into the Cascade spec.

I suggest pulling it into Cascade 4 which atm is just the revert keyword, which is implemented; and this is also already implemented iirc.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-cascade][css-scoping] Define Shadow Tree in Cascade, and agreed to the following:

  • RESOLVED: Shift shadow dom cascade to cascade 4, remove scoping from cascade 4, move cascade 4 to WD and republish
The full IRC log of that discussion <dael> Topic: [css-cascade][css-scoping] Define Shadow Tree in Cascade
<dael> github: https://github.com//issues/5372
<myles> q+ to ask if this is entirely an editorial change
<dael> fantasai: Noticing they're defined in scoping spec. I think we should import into cascade spec
<myles> q-
<dael> fantasai: This would be normative b/c moving between specs but no effect on impl.
<dino> 🎁➕
<dael> fantasai: Assuming we do it correctly ^-^
<dael> Rossen_: Any thoughts about this?
<dael> Rossen_: Any reasons why not?
<dael> AmeliaBR: Spec statuses?
<dael> fantasai: Scoping is WD. Cascade 4 which I think is where we should put it is CR
<dael> fantasai: Might consider pulling it to WD, adding this section, removing scoping which I think no one implements. If we do that only difference from L3 is revert keyword
<dael> fantasai: Process-wise maybe that's safest way to go since seems to be where impl have landed
<dael> AmeliaBR: more shuffling than just this but end result is version of cascade 4 with impl features?
<dael> fantasai: That's my proposal. Broader thank issue scope but makes the most sense
<dael> fantasai: Assuming no one impl scoping
<dael> florian: If we remove scoping it changes style attributes. We should go back and define them in terms of specificity again.
<dael> fantasai: I think that's part of edits
<dael> fantasai: Prop: Shift shadow dom cascade to cascade 4, removing scoping from cascade 4, move cascade 4 to WD and republish
<dael> Rossen_: Sounds like fine orchestration
<dael> Rossen_: Obj?
<dael> RESOLVED: Shift shadow dom cascade to cascade 4, remove scoping from cascade 4, move cascade 4 to WD and republish
<dael> fantasai: When we have cascade 5 we'll put scoping in that. I'll leave 5 as ED with just scoping for now

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

2 participants