- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Sep 2023 17:00:10 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain] Style containment for counters`, and agreed to the following: * `RESOLVED: fix the example and re-affirm the one-way containment of counters` * `RESOLVED: Add a clarifying note about the coutner function and review the WPT tests` <details><summary>The full IRC log of that discussion</summary> <emeyer> astearns: I assume the resolution we want here is “yes”?<br> <emeyer> ntim: Right now, I found style container behavior for counters to be quite unintuitive<br> <emeyer> …Spec says you should scope counter-increement to the subtree that is contained<br> <florian> q?<br> <emeyer> …Further effects are unclear<br> <emeyer> fantasai: At a higher level, it brings up the question of what style containers are useful for<br> <emeyer> …There’s two ways to look at it<br> <florian> q+<br> <oriol> q+<br> <emeyer> …One is that style containment prevents stuff inside a subtree from affecting stuff outside it<br> <emeyer> …Another is that the protection goes both ways, so that also stuff outside can’t affect things inside the subtree<br> <emeyer> …I think the two-way is a little easier for authors to understand<br> <vmpstr> q+<br> <emeyer> …I’m not sure if there were good reasons to have one-way containment or not<br> <astearns> ack oriol<br> <emeyer> oriol: This was discussed in 2018 in Berlin; then the idea was that we should allow content inside containment shoudl not read values from the outside<br> <emeyer> …I think this is reasonable; with things like size containment, we prevent the size of the element from depending on (missed)<br> <emeyer> …Having containment work both ways doesn’t seem needed for container queries<br> <emeyer> …I guess it’s reasonable for an author to use a counter in the headers of different sections, and maybe they want a section to be a container query<br> <emeyer> …I think it would be strange to no longer be able to use those as counters<br> <emeyer> …I think the current way this is specified may be better<br> <emeyer> …If people want to have the containment work both ways, that’s also a posisbility, but maybe too restrictive<br> <emeyer> TabAtkins: I don’t have a strong opinion, but Oriol’s summary of my reasoning is correct<br> <miriam> +1 I don't like making cq-required containment *more invasive* than necessary<br> <ntim> q+<br> <astearns> ack florian<br> <emeyer> florian: Containment in general is meant to be one way<br> <emeyer> …So, not designed to deliberately isolate parts of the document<br> <emeyer> …Updating a subtree shouldn’t update the whole page, was the goal<br> <astearns> ack vmpstr<br> <emeyer> …As Oriol said, if you aren’t using counters, it makes sense for them to update into the subtree<br> <emeyer> vmpstr: Content-visibilty: auto allows to skip styling and rendering updates if not needed<br> <emeyer> …I would like this to remain a one-way barrier<br> <astearns> ack ntim<br> <emeyer> ntim: I could go either way, but the one-way containment is harder to implement than two-way<br> <florian> s/ shouldn’t update the whole page/ shouldn’t dirty the whole page<br> <emeyer> …What’s important is use cases: if we were to expand style containment beyond making container queries work, if we were to use for names of anchor position, which behavior would make more sense?<br> <emeyer> astearns: Oriol, you mentioned if we go with one-way containment, the spec would need changes to make that more clear?<br> <emeyer> oriol: Yes, right now when counters are modified, they create a new instance of the counter<br> <bramus> present-<br> <emeyer> …The question is where the counter get instantiated<br> <emeyer> …Browsers make the new instance in the element that tries to modify the counter, which I agree with<br> <emeyer> …In complex cases, browsers have several bugs, but in simple cases they all agree that new instances are created<br> <emeyer> TabAtkins: The example I wrote is just wrong<br> <argyle> 🧠💨<br> <emeyer> astearns: I hear a slight preference for one-way containment<br> <emeyer> fantasai: I think Oriol was fairly convincing<br> <florian> my pref is rather strong…<br> <emeyer> astearns: Tim, would you be okay despite the implementation difficulty?<br> <dbaron> (I suppose the other option is that the inside of the container essentially operates on a clone of the counter state as of its start.)<br> <emeyer> ntim: I guess it’s okay<br> <fantasai> dbaron, I think that would be more confusing<br> <emeyer> astearns: So this is a “no change to spec, fix example” situation; are there tests that need to be updated?<br> <chrishtr> I think one-way is better for authors<br> <emeyer> TabAtkins: I need to check them either way and update if necessary<br> <emeyer> ntim: I would want the spec to be more clear<br> <emeyer> …Right now it says the scoped property is as if scoped to its own document<br> <emeyer> …It’s unclear the extent of the effects of the property<br> <emeyer> …If it’s like you isolate the counters in their own document, they would all be zero<br> <sakhapov_> q+<br> <emeyer> TabAtkins: The counter-* properties are scoped, but the counter() function is not scoped<br> <emeyer> …Using the counter() function does not interact with style scoping in any way<br> <emeyer> …So it should not be zeroed just because an ancestor was style-scoped<br> <emeyer> astearns: Explicitly saying in normative text that counter() is not affected, then<br> <emeyer> florian: The spec says what’s affected, and counter() is not on the list<br> <emeyer> astearns: Fair<br> <astearns> ack sakhapov_<br> <emeyer> sakhapov_: I think the problem is counter-increment acts as if the named counter is set to zero<br> <emeyer> TabAtkins: Yeah, the example is wrong and I need to fix that<br> <emeyer> sakhapov_: But the HTML code is correct, so maybe move this<br> <astearns> ack dbaron<br> <emeyer> dbaron: I want to mention a slightly different model for one-way containment, which is essentially you could do the containment by acting as though the counter state gets cloned into the contained subtree<br> <emeyer> …That way, an increment inside the subtree would happen in ways that wouldn’t leak back out<br> <astearns> ack fantasai<br> <emeyer> fantasai: I thought that was the original proposal and it’s terribly confusing, let’s not do that<br> <emeyer> …I like the suggestion that you instantiate a new counter, so inside the subtree you can do your own thing<br> <emeyer> astearns: Let’s resolve to fix the example and re-affirm the one-way containment of counters<br> <emeyer> …Objections?<br> <emeyer> (silence)<br> <ntim> florian, TabAtkins: "the effects of the property on that element" is confusing, because counter-increment does affect what's read from the counter() function<br> <emeyer> RESOLVED: fix the example and re-affirm the one-way containment of counters<br> <ntim> Hoping the wording can be clarified a bit for that.<br> <emeyer> astearns: Are we taking David’s suggestion?<br> <fantasai> s/counters/counters by instantiation of new counters/<br> <astearns> q?<br> <emeyer> sakhapov_: I don’t see how different from the current behavior that would be<br> <emeyer> dbaron: Counter resets would act the same, but incrememnts would be different<br> <emeyer> …If you were using the counters() function, and you incremented both outside and inside the subtree, the difference is that one would give you 3.1 and the other would give you 4<br> <emeyer> sakhapov_: Each counter reset creates a new counter?<br> <emeyer> dbaron: The idea is that the clone operation wouldn’t be deep, you’d only need to clone the most-nested counter<br> <emeyer> sakhapov_: Do you inherit the reset?<br> <emeyer> dbaron: Either way, the counters() function would look all the way up?<br> <emeyer> TabAtkins: David’s proposal means things inside the subtree won’t modify counters outside the subtree<br> <emeyer> florian: This is maybe more convenient and less confusing<br> <emeyer> …David’s proposal leads to people asking why counters seem to reset<br> <emeyer> fantasai: I agree it’s confusing and we shouldn’t do it<br> <emeyer> astearns: I’m slightly against the cloning proposal from an authoring perspective<br> <emeyer> …David, if you want to pursue further, you could open an issue<br> <emeyer> fantasai: I object to going that direction<br> <emeyer> florian: If we were to consider it, we need to assess compatibility baggage<br> <emeyer> astearns: We should resolve on whether we need to add a note, and update the WPT<br> <emeyer> RESOLVED: Add a clarifying note about the coutner function and review the WPT tests<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9212#issuecomment-1737769717 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 September 2023 17:00:12 UTC