- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 May 2024 16:34:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-syntax][css-nesting] Design of `@nest` rule``, and agreed to the following: * `RESOLVED: 1. Introduce a CSSNestedDeclarations object inheriting from CSSRule and having a .style accessor, and use that to represent the declaration lists in a CSSStyleRule. It serializes as a raw declaration list. 2. Extend .insertRule() to parse declarations (or, if Web-compat requires, add .insertDeclarations()) into a CSSNestedDeclarations Object. 3. Open a new issue wrt the first declarations block.` <details><summary>The full IRC log of that discussion</summary> <keithamus> emilio: Leah added this, I can introduce it a bit<br> <keithamus> ... there still seems to be some disagreement on best path forward<br> <astearns> could we resolve on @some-long-weird-name?<br> <Rossen4> s/Leah/Lea/<br> <keithamus> lea: the gist is another issue we resolved to stop hosting decls coming after nested rules, with decls inside a rule coming after get hoisted to the top which results in strange conflict resolution<br> <keithamus> lea: Tab proposed the @ rule which avoid this. There was push back as it only exists in the OM and has no purpose for authors, only exists to make spec editors lives easier<br> <fantasai> s/in the OM/for the purpose of the OM/<br> <Rossen4> q<br> <keithamus> ... there are some challenges to not introducing. One proposal to have the @nest rule but not serialize, so you only get plain decls.<br> <keithamus> ... Tabs opposition is that CSSOM isn't used that much so whats the point<br> <keithamus> ... another proposal to make a new object to represent the interleaved decls.<br> <keithamus> ... Blink is strongly opposing not having the rule<br> <keithamus> ... On the grounds that CSSOM is not used frequently<br> <keithamus> ... also that syntax is pointless from author perspective<br> <keithamus> ... what if we call it @group then extend it later with functionality? What if we can give this rule a purpose?<br> <TabAtkins> q+<br> <kizu> +1 to "<@astearns> could we resolve on @some-long-weird-name?"<br> <keithamus> ... my position is that I tend to agree with webkit. Against priority of constituencies. People will find some weird ways to use it<br> <keithamus> ... I disagree with Tab's assertion that CSSOM is infrequently used.<br> <keithamus> ... We do plan to eventually add nesting & author styles - extremely author facing.<br> <emilio> q+<br> <keithamus> ... many devs modify css properties on the fly, indirectly or not. It's extremely author facing<br> <keithamus> ... I worry if we can't reach consensus we're stuck with status quo - the hoisting behavior, which is worse than any solutions proposed<br> <keithamus> ... I'd be happier with @nest vs hoisting<br> <keithamus> ... even though I'm opposed<br> <miriam> +1 current behavior is worse than any of the proposals<br> <keithamus> Rossen4: we can bikeshed later on naming. Prefer path forward suggested by Alan with @some-long-weird-name and bikeshed later<br> <Rossen4> ack fantasai<br> <keithamus> fantasai: webkit is opposed to new @ rule for the purpose of making it easier to specify CSSOM. Only reason this rule is being proposed. We don't think that's good for authors<br> <keithamus> ... flexible to what form the OM does take.<br> <keithamus> ... we posted one that we think gives some useful interfaces for authors. If people don't like it we're flexible<br> <keithamus> ... but one thing we're opposed to is this thing that gets parsed out<br> <Rossen4> ack TabAtkins<br> <keithamus> TabAtkins: lea's characterization of my position is incomplete. Creating things in the OM is vary rarely used. Crawling via .style or other - there's no meaningful difference. Creating an OM from scratch is only where you'd see the difference. That's incredibly rare to do. Only CSS tooling does it<br> <keithamus> ... the set of authors we're effecting positively or negatively is minuscule, and these authors are advances. We don't want to give them bad stuff just because, but we trust them to navigate this<br> <keithamus> ... webkit proposal give us genuinely worse tradeoffs. When you serialize you get something useful but insert rule or manip gets magical in a bad way, where insertrule might merge or insert before or after. Deleting rules has odd behavior as well<br> <keithamus> ... two decls next to eachother need to be resolved.<br> <keithamus> ... unexpected tree structure munging is difficult to work with as a user of the API<br> <keithamus> ... bikeshed represents HTML structure of the doc with a well used XML library but it sucks for HTML. APIs are hard to predict and has inconsistent behavior with text nodes as you're moving around element nodes<br> <keithamus> ... I used to have bugs in bikeshed due to this. I reimplemented the DOM and used the DOM wrapper just because DOM treats text and other nodes the same, a predictable behavior.<br> <keithamus> ... similar using an @ rule of some kind means we don't do any weird magic with OM manip.<br> <keithamus> ... We have consistent behavior, nothing weird needs to happen with add/remove. No cleanup<br> <keithamus> ... simplifies impl and specs. Importantly it makes manipulation predictable for the author which is far more important to maintain<br> <keithamus> ... if necessary we're fine with having a serialization rule which most of the time omits @ nest. Anything you parse in can always serialize back out without showing the rule. It just relies on adding one serialization quirk, which you'll never notice unless you're creating rules which couldn't be produced by the parser.<br> <keithamus> ... in all other cases it'll be invisible. This is acceptable to us<br> <keithamus> ... I think it's a bad idea to complicate the data model with magic.<br> <Rossen4> ack emilio<br> <keithamus> emilio: I wanted to say similar. What lea said implied the model consistent only helps browser/spec editors, I don't think that's true. Let's not overcomplicate the solution.<br> <lea> q?<br> <keithamus> ... having extra @ rule vs having to invent weird stuff... the trade-off is clear for me.<br> <Rossen4> ack fantasai<br> <Zakim> fantasai, you wanted to clarify that a bunch of what Tab objects to is not something we're requiring and to clarify that most of what Tab objects to is not something we're<br> <Zakim> ... requiring<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/10234<br> <keithamus> fantasai: Tab is referring to this<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2116380146<br> <keithamus> fantasai: which is one proposal which we suggested as a possibility. We clearly said we're flexible how it's represented in the CSSOM<br> <TabAtkins> q+<br> <emilio> q+<br> <keithamus> ... so the long spiel about merging, that's objectionable, we can drop it<br> <keithamus> ... what we were proposing is that we introducing a CSS Nested Declaration object inherit from CSSStyleRule, it has accessors... when you use insertrule, and there happens to be an adjacent rule, you'd merge the declarations into that.<br> <keithamus> ... if that's a problem we don't have to do that.<br> <keithamus> ... the only thing we're stating is that it serializes without an at-rule. Consequence is not merging in CSSOM when you serailize and parse it back in 2 objects get merged together.<br> <keithamus> ... we think this is acceptable vs a new at-rule to avoid it.<br> <fantasai> "We would also be OK with alternative solutions that don't introduce an at-rule"<br> <fantasai> idk how to get more explicit than that<br> <keithamus> TabAtkins: if that's the constraint it would be good to express it. It seemed like it was requiring more magic. Serialization & reparsing.. I don't care too much about that, as long as tree manip doesn't do unpredictable magic<br> <Rossen4> ack TabAtkins<br> <keithamus> ... changing behavior of insert rule to allow declaration lists... currently it throws but the OM API is old. It's always unpredictable if things like this are compat issues.<br> <keithamus> ... if it's purely a matter of producing some sort of object, call is CSSDeclarationList, and it serializes declarations, and you're ok with it changing structure when you roundtrip, I'm okay with that<br> <Rossen4> ack emilio<br> <keithamus> ... but all the magic proposed in thread was what I was objecting to<br> <keithamus> emilio: I still prefer avoiding rounttripping. Apples proposal without the extra magic is basically @nest without saying @nest.<br> <TabAtkins> Note again that "just doing an at-rule" also always serializes as bare declarations *as long as you haven't used OM manipulation to do something funky*.<br> <keithamus> ... that's not amazing but that seems way better than the original tree-monkeying stuff<br> <Rossen4> ack dbaron<br> <TabAtkins> Or network packet delays can cause separate text nodes, I think, directly from the parser.<br> <keithamus> dbaron: Wanted to point out the idea you get a different OM when you serialize and reparse is something we already have with HTML: emtpy text nodes or adjacent text nodes. DOM has an API to normalize these.<br> <Rossen4> q?<br> <dbaron> https://developer.mozilla.org/en-US/docs/Web/API/Node/normalize<br> <keithamus> Rossen4: are we getting close? The original proposal in IRC seems to be landing okay?<br> <Rossen4> ack fantasai<br> <fantasai> PROPOSAL:<br> <fantasai> 1. Introduce a CSSNestedDeclarations object inheriting from CSSRule and having a .style accessor, and use that to represent all the declaration lists in a CSSStyleRule. It serializes as a raw declaration list.<br> <fantasai> 2. Extend .insertRule() to parse declarations (or, if Web-compat requires it, add .insertDeclarations())<br> <fantasai> 3. Open question about the first declaration block.<br> <keithamus> fantasai: we should handle 3 as a follow up<br> <emilio> q+<br> <keithamus> emilio: to be honest I still prefer a regular rule than bare decls, but this is a fine compromise if people are unwilling<br> <Rossen4> ack emilio<br> <fantasai> s/())/()) into a CSSNestedDeclarations object/<br> <keithamus> TabAtkins: I don't think first decl block is an open question. We still have weird magic behavior. The first block of stuff is definitely put in a stylerules.style not reflected in child rules<br> <keithamus> fantasai: 100%. I think theres a question about if its also represented in CSS rules.<br> <keithamus> emilio: I don't think putting it in 2 places is great<br> <keithamus> TabAtkins: I don't think we can. If you delete the first block you'll be invoking magic behaviour<br> <keithamus> ... we'll have to re-create at some point. Exactly the magical behavior I want to avoid<br> <keithamus> emilio: that's true.. calling delete rule would be weird<br> <keithamus> fantasai: if we do this authors can have a single consistent API for all of the contents of the style rule<br> <keithamus> TabAtkins: If we were designing these from scratch I'd agree<br> <keithamus> ... but with history, the only way to maintain it safely would be additional magic with delete rule. I want to avoid the tree magic as much as possible<br> <keithamus> fantasai: can we open that conversation separately?<br> <keithamus> TabAtkins: I can guarantee my position but the others, mild objections, but this is acceptable<br> <keithamus> Rossen4: Can we summarise the compromise?<br> <keithamus> TabAtkins: In the proposal<br> <keithamus> Rossen4: all 3?<br> <keithamus> fantasai: 3rd isn't really a thing<br> <keithamus> Rossen4: any additional points or objections>?<br> <keithamus> s/>?/?<br> <fantasai> 1. Introduce a CSSNestedDeclarations object inheriting from CSSRule and having a .style accessor, and use that to represent all the declaration lists in a CSSStyleRule. It serializes as a raw declaration list.<br> <keithamus> lea: can someone restate the proposal?<br> <fantasai> 2. Extend .insertRule() to parse declarations (or, if Web-compat requires it, add .insertDeclarations())<br> <fantasai> s/())/()) into a CSSNestedDeclarations object/<br> <keithamus> lea: that seems great<br> <keithamus> Rossen4: I'll call this resolved<br> <fantasai> RESOLVED: 1. Introduce a CSSNestedDeclarations object inheriting from CSSRule and having a .style accessor, and use that to represent the declaration lists in a CSSStyleRule. It serializes as a raw declaration list. 2. Extend .insertRule() to parse declarations (or, if Web-compat requires, add .insertDeclarations()) into a CSSNestedDeclarations Object. 3. Open a new issue wrt the first declarations block.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2137832089 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 May 2024 16:34:35 UTC