Skip to content

[css-contain] Clarify style containment property scoping #2349

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

Closed
Loirooriol opened this issue Feb 22, 2018 · 3 comments
Closed

[css-contain] Clarify style containment property scoping #2349

Loirooriol opened this issue Feb 22, 2018 · 3 comments

Comments

@Loirooriol
Copy link
Contributor

CSS Contain says that style containment scopes some properties "to the element’s sub-tree". This is defined as follows:

A scoped property has its effects scoped to a particular element or subtree. It must act as if the scoping element was the root of the document for the purpose of evaluating the property’s effects: any uses of the property outside the scoping element must have no effect on the uses of the property on or in the scoping element, and vice versa.

I think it's a bit confusing that the clear and complete definition is about scoping to an element, given that style containment scopes to a subtree instead. But this other definition is only provided at the end as an addendum:

If scoped to a sub-tree, it’s the same, except the scoping element itself is counted as "outside" the tree, like the rest of the document.

Maybe consider defining subtree scopment first? Anyways, various CSS specs assume that there is a single root element, but if the scoping element is "outside" the tree, I guess its children are "roots". So you are dropping an important CSS invariant like it's nothing. For example, if the parent of these children is "outside" the tree, are they still considered to be siblings? This is important for counter inheritance.

Then the example:

For example, if counter-increment is scoped to an element, the first use of it within the subtree acts as if the named counter were set to 0 at the scoping element

If I understand properly, this should say "scoped to an element’s sub-tree". Otherwise the element is not considered to be "outside" the tree, and thus the named counter may not be 0.

It would be helpful if the quote was converted to a real example with HTML, CSS and the expected rendering. Something like

<div>
  <p>aaa</p>
  <p>bbb</p>
</div>
div {
  contain: style;
  counter-increment: c 123;
}
p::before {
  content: counter(c) '/ ';
  counter-increment: c 1;
}

Chrome renders it as

1/ aaa
1/ bbb

But in bug #1887 it was resolved that new counters should be created "at style scoping root" (I guess this refers to the contained element and not to its children which become "roots" because their parent is "outside" the tree). So I wonder if the result should be this instead?

1/ aaa
2/ bbb

@frivoal
Copy link
Collaborator

frivoal commented Apr 6, 2018

First, editorial comments:

Maybe consider defining subtree scopment first?

I did not reorder (as it seems easier to explain in that order), but I did add a clarification that the first part of the explanation is about scoping to an element specifically (so that you don't have to read until the part that talks about scoping to a sub-tree to realize that the first part wasn't talking about that.

For example, if counter-increment is scoped to an element, the first use of it within the subtree acts as if the named counter were set to 0 at the scoping element

If I understand properly, this should say "scoped to an element’s sub-tree".

Correct, I was sloppy about that. Now fixed.

@frivoal
Copy link
Collaborator

frivoal commented Apr 6, 2018

Anyways, various CSS specs assume that there is a single root element, but if the scoping element is "outside" the tree, I guess its children are "roots". So you are dropping an important CSS invariant like it's nothing. For example, if the parent of these children is "outside" the tree, are they still considered to be siblings? This is important for counter inheritance.

I suggest clarifying that when considering the effects of the property of elements inside the subtree, the element at the base of the subtree is the root. Howver, when considering the effects of the property on the element at the base of the subtree itself, then scoping has no effect and the element itself is counted as "outside" the tree, like the rest of the document.

But in bug #1887 it was resolved that new counters should be created "at style scoping root" (I guess this refers to the contained element and not to its children which become "roots" because their parent is "outside" the tree).

I agree with you, but since this differs from what chrome does, I'd like to check in with the WG before updating the spec accordingly.

@frivoal frivoal changed the title [css-contain] Clarify style containment property scopment [css-contain] Clarify style containment property scoping Apr 6, 2018
@css-meeting-bot
Copy link
Member

The Working Group just discussed Clarify style containment property scoping #2349, and agreed to the following resolutions:

  • RESOLVED: Add this clarification to the spec.
The full IRC log of that discussion <dael> Topic: Clarify style containment property scoping #2349
<dael> github: https://github.com//issues/2349
<dael> florian: Remaining item is definition to scoping to a sub tree is confusing.
<dael> florian: [reads]
<dael> florian: The confusing part is when you're scoping to a sub tree the thing that would be the root is outside the sub tree you're consiering. If you have an element with 2 descendents does it mean 2 disconnected roots? I think yo mean the element is the root for the purposes of styling.
<dael> TabAtkins: That was my intention.
<dael> florian: I think we should resolve this is our intention and we should improve the wording.
<dael> florian: [reads proposed text from issue]
<dael> TabAtkins: Yep.
<dael> Rossen: Good TabAtkins ?
<dael> TabAtkins: Yes.
<dael> Rossen: Objections to adding this clarification to the spec?
<dael> RESOLVED: Add this clarification to the spec.

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