Re: [csswg-drafts] [css-view-transitions] 'type' argument that takes an array of types is very weird naming (#10070)

The CSS Working Group just discussed `[css-view-transitions] 'type' argument that takes an array of types is very weird naming`, and agreed to the following:

* `RESOLVED: Switch to using "types" in all the locations.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> vmpstr: We have an attribute called 'type' in the opt-in block<br>
&lt;fantasai> vmpstr: the corresponding argument is 'type', which takes an array<br>
&lt;fantasai> vmpstr: issue raised that 'type' refers to an array of items<br>
&lt;fantasai> vmpstr: so bikeshedding issue to figure out what to call these<br>
&lt;fantasai> vmpstr: proposals include 'types' everywhere or using 'typeList'<br>
&lt;fantasai> vmpstr: interested in opinions<br>
&lt;khush_> q+<br>
&lt;ntim> q-<br>
&lt;astearns> ack khush_<br>
&lt;fantasai> khush_: I was suggesting to just use 'type-list'<br>
&lt;fantasai> khush_: in a different place we resolved on this for CSS transition rule<br>
&lt;bramus> q+<br>
&lt;fantasai> khush_: several places where this is provided, should be consistent<br>
&lt;astearns> ack bramus<br>
&lt;fantasai> khush_: since we said 'typeList' for CSSViewTransitionRule, let's use 'typeList' everywhere<br>
&lt;fantasai> 'type-list'/'typeList'<br>
&lt;fantasai> bramus: it was inspired by being a DOMTokenList, but no longer a DOMTokenList<br>
&lt;ntim> +1 to bramus<br>
&lt;fantasai> bramus: I'm a fan of using 'types', it works in both CSS and JS<br>
&lt;vmpstr> q+<br>
&lt;astearns> ack vmpstr<br>
&lt;fantasai> vmpstr: Wrt DOMTokenList, it wouldn't be in CSS object but in DOM it might be<br>
&lt;fantasai> vmpstr: OK with renaming, but wanted to clarify<br>
&lt;bramus> scribe+<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I'm also a fan of consistency<br>
&lt;TabAtkins> fantasai: I unfortuantely don't have much familiarity with the OM in general<br>
&lt;TabAtkins> fantasai: But I remember going with typeList for consistency with classList, but it's not a list in HTML, it's a space-separated list of classes<br>
&lt;TabAtkins> fantasai: I think consistnecy acorss objects is important, but it shoudl be clear that if something is an Array it's an Array, not a string<br>
&lt;TabAtkins> fantasai: We don't use much plurals in CSS syntax, it's unusual<br>
&lt;TabAtkins> bramus: There's some precedent in descriptors<br>
&lt;TabAtkins> bramus: override-colors, and symbols<br>
&lt;TabAtkins> fantasai: For those you're expected to give multiple values, you really wouldn't give just one<br>
&lt;TabAtkins> fantasai: While for this, in many cases it's a single value<br>
&lt;khush_> https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1997836510<br>
&lt;TabAtkins> fantasai: So what are the options?<br>
&lt;TabAtkins> fantasai: CSSViewTransition at-rule descriptor<br>
&lt;TabAtkins> fantasai: and the corresponding CSSViewTransitionRule object<br>
&lt;astearns> (this is in the comment khush_ linked above)<br>
&lt;khush_> There is a summary here: https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-1997836510<br>
&lt;TabAtkins> vmpstr: startViewTransition() parameter<br>
&lt;TabAtkins> vmpstr: And last is ViewTransition object returned by that<br>
&lt;TabAtkins> fantasai: I have a question, for CSSViewTransitionRule<br>
&lt;TabAtkins> fantasai: We have something that represetns the types as an array<br>
&lt;TabAtkins> fantasai: Do we also have that as a string? Or just as an array<br>
&lt;TabAtkins> vmpstr: We only ahve an array<br>
&lt;TabAtkins> (we don't have a consistent pattern in the OM for this)<br>
&lt;TabAtkins> fantasai: Is that normal for OM representations of a rule?<br>
&lt;TabAtkins> TabAtkins: It's not unusual.<br>
&lt;TabAtkins> khush_: the other question is, for CSSVTRule, what type should that have? Currently DOMTokenList, but could be a string or an array of strings<br>
&lt;TabAtkins> vmpstr: And one limitation, the OM one can't be called "type", becuase that already exists. And I think that's all the restrictions.<br>
&lt;TabAtkins> vmpstr: I propose just "types" everywhere, we can revisit if someone doesn't like it<br>
&lt;TabAtkins> +1 to this, personally<br>
&lt;bramus> +1<br>
&lt;ntim> I like types everywhere<br>
&lt;khush_> +1<br>
&lt;ntim> There's className too if you look at class :D<br>
&lt;TabAtkins> astearns: proposed to use "types" everywhere. Concerns?<br>
&lt;TabAtkins> RESOLVED: Switch to using "types" in all the locations.<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/issues/10101<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 20 March 2024 16:22:30 UTC