- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Apr 2023 16:21:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting-1] Consider using ObservableArray<CSSRule> instead of CSSRuleList`, and agreed to the following: * `RESOLVED: Redefine CSSRuleList as ObservableArray` <details><summary>The full IRC log of that discussion</summary> <fantasai> TabAtkins: Domenic raised the fact that CSSStyleRule has a new ??<br> <fantasai> ... it's the weird legacy CSSRuleList<br> <fantasai> ... which is a weird old DOM interface that pretends to be a list, but very awkwardly<br> <fantasai> ... suggested to use ObservableArray, which can reproduce behavior<br> <fantasai> ... and we can subclass it stuff<br> <fantasai> TabAtkins: I would like to be good, but I would like to be consistent<br> <fantasai> ... so if we do this, we should do it by creating a subclass that adds all the legacy interfaces<br> <fantasai> ... and do it throughout the CSSOM<br> <fantasai> astearns: So on other places where we use CSSRuleList, that would result in some extra things that you currently can't do with those objects?<br> <fantasai> ... so we would need tests for all this<br> <fantasai> TabAtkins: Yes, all of the array methods, which don't exist on CSSRuleList, would start showing up there<br> <fantasai> ... need tests that we're not doing the weird things<br> <fremy> q+<br> <fantasai> astearns: [missed]<br> <emeyer> fantasai: Are you oing to redefine CSS rule list or something else?<br> <fantasai> TabAtkins: redefining CSSRuleLIst<br> <emeyer> s/oing/going/<br> <fantasai> ... I will make it a subclass of ObservableArray<br> <fantasai> sgtm<br> <emilio> q+<br> <astearns> ack fantasai<br> <astearns> ack fremy<br> <fantasai> fremy: Mainly had a question about CSSRuleLIst, right now can you modify it?<br> <fantasai> ... I thought it was a readonly array<br> <fantasai> ... ObservableArray is read-write<br> <fantasai> TabAtkins: That's something that we can define<br> <fantasai> ... make sure that the readonly bits throw on the setting they're deleting<br> <fantasai> fremy: Why Observable if it's readonly?<br> <fantasai> TabAtkins: ObservableArray is how we should do arrays generally<br> <fantasai> ... plain array supposed to be static, not invisibly modified by the browser<br> <fantasai> ... ObservableArray allows modification underneath<br> <fantasai> fremy: ah, ok<br> <fantasai> TabAtkins: browser doing Observing, which can go both ways<br> <plinss> q+<br> <fantasai> heycam: this might be first one where API would allow script to modify it<br> <fantasai> TabAtkins: possibly? But that would be by luck<br> <fantasai> ... a script-modifiable ObservableArray is reason we defined ObservableArray rather than frozen list<br> <fantasai> heycam: Does that have methods that can modify the array?<br> <fantasai> TabAtkins: ?? is that array<br> <fantasai> ... it is an Array exotic object, so looks like an array to author script code<br> <fantasai> heycam: so you can splice it etc?<br> <astearns> ack emilio<br> <fantasai> emilio: Plan is to make it readonly?<br> <fantasai> TabAtkins: keep the current readonly-ness<br> <fantasai> ... except now it will get the array modern methods<br> <fantasai> ... but it will continue to be readonly<br> <fantasai> emilio: so Something.cssRules.push would throw?<br> <fantasai> TabAtkins: yes. WebIDL has you specify the array modification behavior using a set/delete algorithm<br> <fantasai> ... and that gets called by all the mutation methods underneath<br> <fantasai> ... so if you try to modify, it'll throw<br> <fantasai> emilio: then I'm not opposed, but, it feels weird to expose all the mutating methods if you can't mutate it?<br> <fantasai> ... if you feel it's better, sure. Just want to make sure we're not making the OM more mutable<br> <matthieudubet> q+<br> <fantasai> TabAtkins: don't intend to change mutability, just expose more modern interfaces<br> <astearns> ack fantasai<br> <emeyer> fantasai: Why isn’t there an equivalent observable array that’s designed to be read-only?<br> <fantasai> TabAtkins: behavior to make readonly is trivial, just define set/delete to throw<br> <fantasai> TabAtkins: This is an intended use case<br> <fantasai> emilio: I think it will confuse authors<br> <fantasai> ... but we'll see<br> <fantasai> ... not like you can construct CSSRuleList, so maybe not too weird<br> <astearns> ack plinss<br> <fantasai> plinss: I'm in favor, just two things to confirm<br> <fantasai> ... we get iterators etc?<br> <fantasai> TabAtkins: yes<br> <fantasai> plinss: perfect<br> <fantasai> plinss: my other question, are there other places in the CSSOM where we're doing weird array-like things, and if so can we swap them all at the same time?<br> <fantasai> TabAtkins: I believe that's it for CSSOM, have a pending edit for TypedOM<br> <fantasai> ... which currently uses a better version of fake arrays<br> <fantasai> ... but I think in CSSOM CSSRuleList is the only actual list we have<br> <fantasai> ... everything else is individual rules<br> <fantasai> plinss: Would be good to do a quick pass over everything else, do them all<br> <fantasai> TabAtkins: been looking over OM, and everything seems to use CSSRuleList, and Declaration doesn't expose anything like that<br> <fantasai> ... theoretically we could also make CSSStyleDeclaration an ObservableArray, since it has indexed getting/setting<br> <fantasai> ... happy to look into it<br> <fantasai> plinss: or making it something maplike or whatever, but in any case modernize anything that should be modernize it<br> <fantasai> TabAtkins: should raise as a separate issue<br> <fremy> I believe CSSStyleDeclaration should not be made an ObservableArray<br> <fantasai> ... only other one that fits in this area, I think<br> <astearns> ack matthieudubet<br> <fremy> Otherwise, there can be conflicts between CSS property names and Array methods<br> <fantasai> matthieudubet: CSSGroupingRule and now CSSStyleRule are really similar implementation-wise<br> <fantasai> ... insertRule/deleteRule are exactly the same<br> <fantasai> ... should we expose those as (??)<br> <fantasai> ... or share code only in the implementation<br> <fantasai> TabAtkins: those all have .cssRules, and then they have legacy insertRule/deleteRule<br> <fantasai> ... if we wanted we could pull those two methods out into a mixin, but that wouldn't be a behavior change<br> <fantasai> ... just better organized specification<br> <emeyer> fantasai: I was following up on emilio’s concern that we define stuff that doesn’t do anything.<br> <fantasai> s/stuff/methods/<br> <fantasai> TabAtkins: just don't call them<br> <fantasai> TabAtkins: having something be a real array is valuable, and having it behave like an array but not have all the methods is hard and unnatural in JS<br> <fantasai> astearns: Proposed resolution is redefine CSSRuleList as ObservableArray, with all of the readonly bits defined<br> <fantasai> ... particularly carefully since this is the first time we're defining such a readonly ObservableArray<br> <fantasai> RESOLVED: Redefine CSSRuleList as ObservableArray<br> <fantasai> astearns: and also follow-up issue about CSSStyleDeclaration?<br> <fantasai> ACTION: TabAtkins to file issue about CSSStyleDeclaration's array upgrade<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8350#issuecomment-1497776457 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 April 2023 16:22:01 UTC