- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Mar 2024 16:29:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Data type for types in script APIs`, and agreed to the following: * `RESOLVED: Use FrozenArray for CSS OM. VT typeset which is setlike for types attribute. Keep sequence of strings for svt as is.` * `RESOLVED: dont deduplicate values in reflections` * `RESOLVED: dont drop invalid values in reflections` <details><summary>The full IRC log of that discussion</summary> <keithamus> astearns: first data type in script APIs for typed.<br> <keithamus> noamr: we reflect types we discussed in JS. We want to finish up exactly which data types we expose.<br> <keithamus> noamr: there are 3 of those.<br> <keithamus> noamr: 1. One that goes in the view transition object, VT types. Exposed as SetLike - viewtransitionstateset.<br> <keithamus> noamr: Basically exactly like CustomStateSet, a set of strings. It has side effect of changes types of VT.<br> <keithamus> noamr: Decide on reflecting only valid events, removes none etc. Or reflects everything like a set of strings<br> <keithamus> noamr: 2. CSS OM - readonlysetlike or frozenarray.<br> <keithamus> noamr: No strong preference. Precedence for readonlysetlike like gpu capabilities, which is readonlysetlike<string><br> <keithamus> noamr: maybe css om can be simpler like a frozenarray<br> <keithamus> noamr: 3. What we pass to start view transition, its a sequence. We maybe don't need at all?<br> <emilio> q+<br> <astearns> ack emilio<br> <keithamus> emilio: when you specify duplicate names into cssrule theres deduplication? We don't generally do that. If at parse time I dont care if array or set. If we dont do parse time deduplication - I don't think we do - I think there was precedent but we undid it? If none then we should go with frozenarray. It's also simpler.<br> <keithamus> emilio: the rest sounds fine<br> <keithamus> noamr: we can decide if theres duplication or not<br> <khush> q+<br> <keithamus> noamr: deduplication is most convenient and performant to do first thing but its not... we can make a judgement call on frozenarray and do dedupe during VT rather than css parse<br> <keithamus> emilio: that sounds maybe more consistent, like color-scheme, but no strong opinion. If people are fine... classname is the same it doesn't get deduped during parse time<br> <keithamus> noamr: they're deduped in classList right?<br> <keithamus> emilio: only if you mutate, not the attribute value<br> <keithamus> emilio: either way is fine though, no objections<br> <astearns> ack khush<br> <keithamus> khush: invalid values? No question there that invalid items in the list are dropped at parse time?<br> <keithamus> noamr: right. The question is should we remove invalid values added with JS to the set? Should we throw? or discard? Or add to set but never match?<br> <keithamus> noamr: initial impl is a copy of customstateset, its a set of strings. Invalid strings wouldn't match because they don't get into css<br> <vmpstr> q+<br> <keithamus> noamr: last thing is - do we need types parameter in startviewtransition, or regular and mutate later?<br> <keithamus> fantasai: conceptually when you set up transition you set up types. Mutate later while running seems weird<br> <keithamus> noamr: call viewtransition then settypes? Some convenience inside start.<br> <astearns> ack vmpstr<br> <keithamus> vladhanter: Mild preference for keeping param in startviewtransition<br> <keithamus> khush: can be a sequence of strings<br> <keithamus> noamr: yep<br> <vmpstr> s/vladhanter/vmptr/<br> <keithamus> emilio: seems fine<br> <vmpstr> s/vladhanter/vmpstr/<br> <keithamus> noamr: frozenarray if duplicated would reflect back as string value, look like what you put in there.<br> <keithamus> khush: CSS OM is readonly right? Cant mutate?<br> <keithamus> noamr: right but would it dedupe? `foo foo`. One or both?<br> <keithamus> khush: if in css? Are both going to show up or single value.<br> <keithamus> noamr: yes. Also array style like includes or setstyle like has?<br> <keithamus> khush: ...<br> <keithamus> emilio: no you get both as string<br> <keithamus> emilio: we could also go for string. How font-face descriptors work if you specify lists.<br> <keithamus> noamr: also selectors are strings.<br> <keithamus> emilio: exposing new interface for that attribute might be overkill, you need for setlike. FrozenArray and strings, I don't care either way too much<br> <keithamus> noamr: string would be most CSSOM like.<br> <keithamus> noamr: a bit less useful<br> <keithamus> emilio: in practice you can split<br> <keithamus> astearns: if precedent for frozenarray, with better dev ergonomics, happy go with that. We dont need to follow string precedent<br> <keithamus> noamr: preference for frozenarray from this discussion<br> <keithamus> emilio: not sure if it has precedence in CSS OM but selectors nowadays would not be plain string, same for other apis<br> <keithamus> astearns: specify frozenarray, from impl experience if that is entirely new thing for cssom. Or push back to string if not.<br> <keithamus> emilio: even if completely new I think it's fine<br> <keithamus> noamr: in chromium not a problem<br> <keithamus> emilio: css om has observable arrays for mutable stuff so for ro frozen makes sense<br> <keithamus> astearns: resolution then?<br> <keithamus> PROPOSED RESOLUTION: Use FrozenArray for CSS OM. VT typeset which is setlike for types attribute. Keep sequence of strings for svt as is.<br> <keithamus> khush: one more thing is we dont dedupe<br> <keithamus> noamr: also dont check for invalid<br> <keithamus> RESOLVED: Use FrozenArray for CSS OM. VT typeset which is setlike for types attribute. Keep sequence of strings for svt as is.<br> <keithamus> PROPOSED RESOLUTION: dont deduplicate values in reflections<br> <keithamus> RESOLVED: dont deduplicate values in reflections<br> <keithamus> PROPOSED RESOLUTION: dont drop invalid values in reflections<br> <keithamus> RESOLVED: dont drop invalid values in reflections<br> <keithamus> emilio: just that we're not consistent with customstateset but...<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 March 2024 16:29:57 UTC