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] Probably css-cascade shouldn't say that there's a specified value for every property and element. #2562

Closed
emilio opened this issue Apr 13, 2018 · 4 comments

Comments

@emilio
Copy link
Collaborator

emilio commented Apr 13, 2018

https://drafts.csswg.org/css-cascade/#specified says:

guaranteeing that a specified value exists for every property on every element.

Similarly, https://drafts.csswg.org/css-cascade/#intro says:

The cascading and defaulting process takes a set of declarations as input, and outputs a specified value for each property on each element.

Those two paragraphs, and probably a couple more, should mention "for each element of the flat tree", or something like that, probably, to be in accordance with the resolutions in #1964 and #1548.

@tabatkins tabatkins changed the title [css-cascade] Probably css-cascade shouldn't say that there's a declared value for every property and element. [css-cascade] Probably css-cascade shouldn't say that there's a specified value for every property and element. Jun 21, 2018
@tabatkins tabatkins added css-cascade-4 Current Work and removed css-cascade-3 labels Jun 21, 2018
@fantasai
Copy link
Collaborator

Fundamentally, CSS has an abstract concept of a document tree which is given as input to CSS. Shadow DOM has decided to compose the flat tree and give it to CSS for presentation. You can give it other kinds of trees, it doesn't have to be a DOM tree.

Where and how best to define the interaction of CSS and Shadow DOM--the fact that DOM hands over the flat tree, and not some other construct, for CSS to style--isn't entirely clear to me... In a sense, it's the DOM's semantics that says "this is what should be presented to the user", so I could make a pretty good argument that the DOM should be the one defining that we use the flat tree. (If we used a different tree technology, there wouldn't be a “flat tree” definition to use, but if DOM was presented with some other style sheet technology, it would still need to define that it's the flat tree that gets presented.) But in any case, we'll probably want to gather all of these issues and solve them together, as clearly the current situation is a bit incoherent.

@tabatkins
Copy link
Member

Scoping defines how the DOM-including-shadows works in selectors, and how it's flattened to work with the rest of CSS.

I have an action hanging around somewhere to put all the tree transformations in one place (likely Display) so you don't have to search around in Scoping, Selectors, and Display to figure out what tree is used where.

But yeah, in general we don't mention the flat tree; Scoping just feeds CSS a flattened tree, and then we work with an abstract element tree.

@tabatkins tabatkins added topic: shadow and removed css-cascade-4 Current Work labels Aug 30, 2018
@fantasai fantasai added the css-cascade-4 Current Work label Mar 17, 2021
@fantasai
Copy link
Collaborator

@emilio https://drafts.csswg.org/css-cascade-4/#value-stages has the following text:

Elements that are not connected or are not part of the document’s flattened element tree do not participate in CSS value processing, and do not have declared, cascaded, specified, computed, used, or actual values, even if they potentially have style declarations assigned to them (for example, by a style attribute).

I think that should cover it?

@fantasai
Copy link
Collaborator

This was added in 8804865 two months ago. I think that closes this issue. :)

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

3 participants