Re: [csswg-drafts] [css-contain] Scoping of the content property unclear.

The Working Group just discussed `Scoping of the content property unclear`, and agreed to the following resolutions:

* `RESOLVED: no change to spec, but add examples and improve wording to clarify desired behavior.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Scoping of the content property unclear<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2483<br>
&lt;dael> Loirooriol: If you have type containment and then it says that the content property goes to the sub tree<br>
&lt;dbaron> s/type containment/style containment/<br>
&lt;dael> Loirooriol: It says for the purpose of open quotes etc. it's not clear what that means. You can use counter function to read counters without defining it. I'ts not completely scoped. The element behaves at the root of the tree, but if you can read contents from elsewhere it's not cler what happens.<br>
&lt;dael> dbaron: I would have thought you create ne counter scopes.<br>
&lt;dael> Loirooriol: In another issue it was resolved that the counter are maintained.<br>
&lt;dael> florian: WE said it's a new counter, but not a new counter scope.<br>
&lt;dael> Loirooriol: Counter is created, for example, but you cant link all the counters with a name from outside the tree.<br>
&lt;dael> dbaron: What does the spec say reason for style cotnainment are.<br>
&lt;dael> TabAtkins: Whenever properties change the dom tree is dirty. When you increment a counter it's not going to effect counters<br>
&lt;TabAtkins> s/the dom tree is dirty/the style outside of the containing element is unchanged and doesn't need to be recalculated/<br>
&lt;dael> florian: So satisfied if you make a new counter scope but you don't need to go that far. Chorme ignores what's going on in the parent, but I don't believe that's what we resolved. WE coulld clarify the previous resolution a bit more.<br>
&lt;dael> Rossen: What would hte clarification be?<br>
&lt;dael> florian: I proposed to replace 'etc' with details of the effects of the content properties list with the depth of the nesting in the tree starts at 0. Wait...we're missing something. COunter set and counter incremeent must be scope to the elements of the tree is last itme. For open and close quote we're not clear what we do.<br>
&lt;dael> florian: Detailing this, [reads text from the issue]<br>
&lt;dael> florian: That's not the point Loirooriol raised. It was also what does the counter inside the property do. That's the other issue we have left.<br>
&lt;dael> TabAtkins: When you use counter and there isn't one of that name it creates a new counter. What happens when it does exsit outside the style scope. Style containment doesn't prevent flowing into, but not flowing out. You should still see the outside world's counter. You should see that name.<br>
&lt;dael> TabAtkins: Counter set have special behavior beacause they would alter the value outside the tree. BUt the read doesn't cause alteration so it hsould work as normal.<br>
&lt;dael> florian: This bug and #2349 are both covering this topic.<br>
&lt;dael> florian: If we go piece by piece...for counters do we stick with the idea that counter set and incement do. But what' you're saying TabAtkins isn't what chrome does.<br>
&lt;dael> TabAtkins: Given the example in #2483 Chrome beahvior seems fine. What behavior to you expect.<br>
&lt;dael> florian: 1 and 1.2 because the counter outside exists.<br>
&lt;dael> TabAtkins: The only counter is n on the div.<br>
&lt;dael> florian: But style containment is scope to element sub tree.<br>
&lt;dael> TabAtkins: True, correct. Yes. Chrome is wrong.<br>
&lt;dael> Rossen: File a bug and leave the spec?<br>
&lt;dael> TabAtkins: I should be 1 and 1.2 So the before sees a single counter and the after sees two counters. Yes. 1 and 1.2 is the correct rendering<br>
&lt;dael> florian: If chrome is okay to align we should calrify the spec but not change behavior.<br>
&lt;dael> TabAtkins: Yes.<br>
&lt;dael> florian: So resolve no change to spec, but add examples and improve wording to clarify desired behavior.<br>
&lt;dael> Rossen: Obj?<br>
&lt;dael> koji: How do others browsers do it.<br>
&lt;dael> florian: Others don't impl.<br>
&lt;dael> RESOLVED: no change to spec, but add examples and improve wording to clarify desired behavior.<br>
&lt;dael> Rossen: Please file browsers bug for everyone that impl this.<br>
&lt;dael> florian: While we clarify I'm suggesting we clarify the exact effect on open and closed quotes.<br>
&lt;dael> TabAtkins: Why resetting nesting depth?<br>
&lt;dael> florian: That seemed simplier.<br>
&lt;dael> TabAtkins: Nesting depth stays what you inherit from outside.<br>
&lt;dael> florian: Okay, so not what I wrote.<br>
&lt;dael> florian: Changes from must be scoped to sub tree to it starts at waht it was but changes to the depth of nesting and do not effect outside the subtree.<br>
&lt;dael> Rossen: This is clarification part?<br>
&lt;dael> florian: I don't know if you want to resolve separately?<br>
&lt;dael> Rossen: We can resolve on this, but the resolution says we need to clarify.<br>
&lt;dael> Rossen: Resolution covers it<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2483#issuecomment-380360855 using your GitHub account

Received on Wednesday, 11 April 2018 07:50:09 UTC