Re: [csswg-drafts] [cssom-view] checkVisibility options have inconsistent naming schemes (#9487)

The CSS Working Group just discussed `[cssom-view] checkVisibility options have inconsistent naming schemes`, and agreed to the following:

* `RESOLVED: don’t rename but define pattern for arguments and add aliases`

<details><summary>The full IRC log of that discussion</summary>
&lt;bramus> Rossen_: who can take this?<br>
&lt;bramus> fantasai: is ntim here?<br>
&lt;bramus> fantasai: 3 open Qs<br>
&lt;bramus> … what are we gonna call the checkContentVisibility option?<br>
&lt;bramus> … name for various options pretty inconsistent<br>
&lt;bramus> … last one was brought up by smfr<br>
&lt;vmpstr> q+<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/9487#issuecomment-1769013122<br>
&lt;bramus> … maybe  method on window, mirroring getComputedStyle<br>
&lt;TabAtkins> q+<br>
&lt;bramus> … tim’s suggestion was to go with “…VisibilityProperty”<br>
&lt;bramus> … and “…VisibilityAuto“<br>
&lt;Rossen_> ack vmpstr<br>
&lt;emilio> q+<br>
&lt;bramus> vmpstr: this is shipping both chrome and firefox, so bar to change should be a bit higher<br>
&lt;bramus> … for the names, we have quite a long discussion with various people and we ended with checkVisibility which isnt the greatest name<br>
&lt;bramus> TabAtkins: the fn name and location cant be changed at this point<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;bramus> … its been stable for a while now<br>
&lt;bramus> … could alias the option names<br>
&lt;bramus> … for consistenty, but cant remove existing ones<br>
&lt;Rossen_> ack emilio<br>
&lt;bramus> emilio: we could add usecounters to track usage<br>
&lt;bramus> … changing from Element.checkVisibility to something else feels like a bit too much<br>
&lt;bramus> … separate function could query psuedoEls<br>
&lt;bramus> … bu we can add that option to E.checkVisibility<br>
&lt;bramus> … unless someone objects, we should resolve on not changing<br>
&lt;bramus> … we are not restricted to booleans<br>
&lt;bramus> … could pass in “auto” as a string<br>
&lt;Rossen_> q?<br>
&lt;bramus> fantasai: would be good to set up some consistent way to deal with the option<br>
&lt;bramus> … we could do passing in the name of the prop and the interested value<br>
&lt;bramus> … is a bit weird to have camelCase names of props and values<br>
&lt;bramus> … we could not have that if we wanted, e.g. 'content-visibility'<br>
&lt;bramus> emilio: web animations does that a lot<br>
&lt;bramus> … could take a look at that<br>
&lt;fantasai> s/values/values in strings/<br>
&lt;bramus> flackr: confirming<br>
&lt;bramus> emilio: only unfortunate thing is visiblity being in the function name and also property name<br>
&lt;bramus> … we could probably say that as long as you opt in to one of both … define what happens when you specifiy both<br>
&lt;TabAtkins> yeah, just ORing the aliases together seems reasonable imo<br>
&lt;vmpstr> q+<br>
&lt;flackr> web-animations-1 spec refers to https://drafts.csswg.org/cssom/#css-property-to-idl-attribute to convert the names<br>
&lt;Rossen_> ack vmpstr<br>
&lt;TabAtkins> I propose we take this back to the issue to figure out a proposal for a new set of values, and we can discuss it there. We should reject renaming/moving the function itself.<br>
&lt;bramus> vmpstr: if we add more props and alias existing ones, then is the plan to deprecate the existing props and unship? or do we ship both sets of props so devs can mix and match?<br>
&lt;bramus> emilio: we could try to unship, but its not a lot of effort to check two bools instead of one<br>
&lt;TabAtkins> q+<br>
&lt;bramus> TabAtkins: my proposal is that we reject the rename and return to the issue<br>
&lt;bramus> … and see if we can come up with a consistent set of readable names<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;bramus> … to then look at, and adopt as aliases<br>
&lt;fantasai> fooProperty / fooPropertyValue<br>
&lt;bramus> fantasai: one proposal in the issue is to follow fooProperty / fooPropertyValue system<br>
&lt;bramus> Rossen_: going back to TabAtkins’ proposal, is there sth to resolve on?<br>
&lt;emilio> fooProperty / fooPropertyValue seems ok to me fwiw<br>
&lt;bramus> … we can do it next week when Tim et al are here<br>
&lt;bramus> fantasai: I suspect its OK to resolve, they can reopen<br>
&lt;bramus> Rossen_: SGTM<br>
&lt;bramus> PROPOSED RESOLUTION: reject rename<br>
&lt;bramus> fantasai: don’t rename but define pattern for ?? arguments and add aliases<br>
&lt;fantasai> s/aliases/aliases that combine with OR/<br>
&lt;bramus> TabAtkins: when we come up with reasonable set of names, then we can talk about it … and alias them if we add new names<br>
&lt;bramus> Rossen_: Objections?<br>
&lt;fantasai> s/rename/rename method/<br>
&lt;bramus> PROPOSED RESOLUTION: don’t rename but define pattern for arguments and add aliases<br>
&lt;bramus> RESOLVED: don’t rename but define pattern for arguments and add aliases<br>
&lt;bramus> Rossen_: tim can always reopen<br>
&lt;bramus> fantasai: comments on the proposed pattern in the issue?<br>
&lt;bramus> … cause there is a pattern in the issue<br>
&lt;bramus> TabAtkins: havent thought about it yet. will look at it in the issue<br>
</details>


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


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

Received on Wednesday, 25 October 2023 16:41:39 UTC