- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 08:22:37 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo-4] Standardizing input[type="range"] styling`, and agreed to the following: * `RESOLVED: Add ::slider-thumb, ::slider-track` * `RESOLVED: Define these pseudosas siblings of each other` * `RESOLVED: Apply them to <input type=range>, switch, <progress>, and <meter>` * `RESOLVED: Add ::slider-fill when relevant` * `RESOLVED: track, fill, thumb are in the same tree order as their usual painting order` * `RESOLVED: acknowledge at least thebabydino` * `ACTION hober: Add people who contributed to GH discussion to Acks` <details><summary>The full IRC log of that discussion</summary> <fremy> hober: We have had this issue about range styling for a long time<br> <fremy> hober: I put it on the agenda because 20 years ago when it was added, we punted the styling<br> <fremy> hober: mainly because expected appearance to make everything great by default<br> <fremy> hober: but, every browser implemented their own custom way to style the input, but in different ways<br> <fremy> hober: both in terms of shadow dom structure, and in terms of what is stylable<br> <fremy> hober: so, I acknowledge there is a great range of complexity, I don't want to touch all of that<br> <fremy> hober: people have been digging up how to style them in a cross-browser way<br> <fremy> hober: it's on emilio to write some spec texts for this, I trust him to do a great job<br> <fremy> hober: and I'm willing to help with that<br> <fremy> hober: the reason why I bring this up, because HTML want to add a switch checkbox<br> <fremy> hober: because it has become very popular on touch UIs<br> <fremy> hober: and has slightly different semantics<br> <dbaron> https://github.com/whatwg/html/issues/4180<br> <fremy> hober: however, one bit is blocking this progressing in HTML<br> <fremy> hober: the stylability of the control<br> <fremy> hober: and I noticed switch and range are similar<br> <fremy> hober: switch is a subset of range, so we can maybe move ahead with the shared part?<br> <fremy> hober: so, I would love to resolve on making progress on these shared bits first, without blocking this on the differences<br> <emilio> q+<br> <TabAtkins> ack TabAtkins<br> <fremy> hober: the subset of the proposal is ::range-progress, ::range-thumb, ::range-track<br> <TabAtkins> Also prefer prefixed names, ::slider-* sounds reasonable<br> <fremy> hober: I guess I would maybe like to unprefix them with "range"<br> <fremy> hober: so they become more generically applicable<br> <fremy> hober: all engines implement these pseudos in some way, so that sounds good<br> <fremy> hober: we could maybe arrange to just alias them?<br> <fremy> hober: however, this is not as easy, because the structure is different<br> <fremy> hober: should they be siblings or nested in each other, for instance<br> <dbaron> hober: In Gecko thumb and track are siblings but in WebKit they have parent-child relationship<br> <fremy> hober: (webkit nests, other browsers don't)<br> <fremy> hober: so I thought about this, how to move forward fast?<br> <fremy> hober: and it seems the flat gecko structure is easier<br> <fremy> hober: so, I propose we just do that, from the Apple side<br> <dbaron> hober: for achieving a bunch of the styling use cases<br> <fremy> hober: and I think that is the only thing we need to do<br> <fremy> hober: for compat reasons in webkit, there are some concerns, but we are happy to handle it<br> <miriam> q?<br> <astearns> q+<br> <fremy> hober: Apple engineers are willing to sign up to do this work<br> <miriam> ack emilio<br> <fremy> hober: for what styles to apply, I trust the judgment of Emilio<br> <fremy> emilio: A lot of the replaced behaviors are removed if we accept content, for instance<br> <fremy> emilio: but we can probably define the same behavior with some custom styles<br> <florian> q+<br> <fremy> emilio: I'm willing to look into it, I will need to figure those details<br> <fremy> hober: yes, my goal here is not to solve everything here<br> <fremy> hober: I hope to solve enough questions for progress to be made<br> <fremy> hober: we already a resolution I recall to add this pseudos<br> <fremy> hober: so, my question, if I make a PR for this, would that be agreable to everyone?<br> <emilio> q+<br> <fremy> miriam: there is a queue, but can you paste the links to what you showed?<br> <hober> https://github.com/whatwg/html/issues/4180<br> <hober> https://github.com/whatwg/html/pull/9546<br> <fremy> hober: I just paste the html issue<br> <fremy> and the pull request that is currently blocked<br> <hober> https://tess.oconnor.cx/2023/08/tracks-and-thumbs<br> <fremy> and the blog post<br> <fremy> astearns: is that blog post the explainer fantasai was referring to earlier?<br> <miriam> ack astearns<br> <fremy> hober: yes, though now I rephrased a bit better<br> <miriam> ack florian<br> <fremy> astearns: so, Blink inherited the webkit structure, right?<br> <fremy> hober: yes<br> <fremy> astearns: so Blink engineers probably need to agree as well<br> <fremy> florian: one thing I wanted to say, is that appearance:none should remove some things, but not what is semantic<br> <astearns> s/probably need to agree as well/will get the benefit of Webkit figuring out the compat issues/<br> <fremy> florian: and that should be clarified as well<br> <fremy> hober: I think if you set it, the pseudos disappear as well, no?<br> <fremy> emilio: no, they are still stylable, (?) they just have different styles by default (?)<br> <fremy> florian: that sounds like what appearance would want<br> <fremy> hober: I'm in favor of speccing what implementations do as much as possible, so we can move fast<br> <fremy> florian: maybe some are decorative and should go away?<br> <miriam> ack emilio<br> <fantasai> Mozilla definitely keeps the pseudos for appearance: none;<br> <fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%0A%3Cstyle%3E%0A%3A%3A-moz-range-track%20%7B%20background%3A%20blue%3B%20%7D%0A%3A%3A-moz-range-thumb%20%7B%20background%3A%20fuchsia%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cinput%20type%3Drange%20style%3D%22appearance%3A%20none%22%3E<br> <fremy> hober: I think they are all semantic<br> <fremy> emilio: they need to be there, otherwise you cannot restyle them yourselves<br> <fremy> hober: but you can use pseudo-classes, right?<br> <fremy> emilio: right<br> <fremy> hober: for switch, I would like to behave like range<br> <fremy> emilio: in general, I'm supportive of this<br> <florian> q+<br> <miriam> ack fantasai<br> <fremy> emilio: wrt the bikeshedding aspect, I also agree with the broader naming for reuse<br> <fremy> fantasai: I also heard a proposal for "slider"<br> <fremy> fantasai: also, what spec does this go into?<br> <miriam> ack florian<br> <fremy> hober: I have an opinion on this, but I'm a bit afraid to open a can of worm<br> <bramus> FYI: “thebabydino” is Ana Tudor<br> <fantasai> s/I also heard a proposal for "slider"/I agree with TabAtkins and jensimmons that the names should be prefixed with e.g. ::slider-/<br> <fantasai> i/fantasai: also/fantasai: Also, whoever drafts this spec should put thebabydino into the Acknowledgements section/<br> <fremy> florian: there is a holding place somewhere (?) for form-control specific things<br> <ntim> (I think that's css-ui)<br> <fremy> hober: I have other plans for the long term, but in the short term that sounds good to me<br> <fremy> florian: for everything or just a subset?<br> <florian> s/somewhere (?)/in css-ui-4<br> <fremy> hober: the whole thing<br> <miriam> ack dbaron<br> <fantasai> -> https://www.w3.org/TR/css-ui-4/#control-specific-rules<br> <fremy> dbaron: I think there are a few interesting things about how much details we need to specify, and how interoperable we need to be<br> <fremy> dbaron: (1) how the shadow dom is defined<br> <fremy> dbaron: (2) how the user agent set styles in that shadow dom<br> <fremy> dbaron: like the position of the range etc...<br> <fremy> dbaron: this interarcts with the author styles, so we need to say how<br> <fremy> hober: personally, I would rather not specify the details too much, like what the shadow dom is<br> <fremy> hober: this is an implementation detail to me<br> <fremy> hober: if we can't, ok, we should go in this rabbit hole<br> <fremy> hober: but I would rather not<br> <fantasai> i/hober: if we/hober: but we can talk about the pseudo-elements and their relationships/<br> <fremy> hober: for instance, we use the system framework for some things by default<br> <fremy> hober: and they can be styled a bit<br> <emilio> q+<br> <fremy> hober: but probably not everything<br> <fremy> hober: but I would like to keep that option open for us<br> <fremy> dbaron: I think you will find it difficult to spec order of things etc in this way in an interoperable way<br> <miriam> ack emilio<br> <fremy> emilio: I think the default appearance is not relevant here<br> <fremy> emilio: because the pseudos only work if you style from a known base<br> <fantasai> s/default appearance/inheritance/<br> <fantasai> s/pseudos only work if you style from a known base/pseudos inherit from their originating element, even in shadow DOM/<br> <fremy> emilio: unless we start allowing ::before/::after, we can probably skip defining the shadow dom<br> <miriam> ack fantasai<br> <fremy> emilio: but I agree with media controls, this might be tricker to achieve<br> <fremy> fantasai: I think one pseudo we also need is the filled part<br> <TabAtkins> I think that is also minimal set<br> <dbaron> for what it's worth, emilio, I think we're probably going to want cases where pseudo-elements inherit from each other or from something else in the shadow structure (though not necessarily here)<br> <fremy> hober: I agree, but this is not required for switch<br> <fremy> emilio: you can use the pseudo class for switch<br> <TabAtkins> Not desirable, *required* for range<br> <fremy> hober: and I'm here to unblock switch<br> <fremy> fantasai: the other thing we should do is apply the same model to progress and (?) leader<br> <astearns> s/(?) leader/meter/<br> <fremy> fantasai: you can style the boundaries differently if you want<br> <fremy> hober: I'm ok either way<br> <fantasai> s/if you want/if you want with ::thumb, but default not visible/<br> <fremy> hober: I want to resolve on adding the pseudo<br> <TabAtkins> q+<br> <fremy> hober: and that they apply them to switch, range, etc...<br> <fremy> hober: I'm looking for a quick consensus<br> <fremy> hober: can we resolve on them being siblings too?<br> <fremy> florian: if we have agreement, we might as well resolve?<br> <miriam> ack. TabAtkins<br> <miriam> ack TabAtkins<br> <fremy> TabAtkins: my only comment is that I agree with fantasai that every other element requires the filled part to be stylable<br> <fremy> TabAtkins: so, I think I want the set of three is required to be truly generic<br> <florian> q?<br> <fremy> hober: if we can resolve on that today, I'm fine with it<br> <fremy> TabAtkins: if we don't do the third one, then we should resolve only about switch<br> <fremy> florian: what are the challenges for the filled part?<br> <TabAtkins> s/we should resolve/we are only resolving/<br> <fremy> hober: I don't remember<br> <fremy> hober: but EdgeHTML had a few other pseudos<br> <fremy> hober: but maybe EdgeHTML is not necessary today<br> <TabAtkins> I'm happy with a "let's handle it ASAP"<br> <fremy> hober: but which one of the two sides should be stylable etc... I don't know<br> <fantasai> * Add ::slider-thumb, ::slider-track<br> <fantasai> * Define them as siblings of each other<br> <fantasai> * Apply them to <input type=range>, switch, <progress>, and <meter><br> <fantasai> * Also add ::slider-fill<br> <fremy> hober: this might need more research<br> <fantasai> * Add thebabydino to the Acknowledgements section of whatever spec this goes into<br> <fremy> emilio: (missed)<br> <fremy> hober: right now webkit does not have a pseudo for the filled part, but that should be easy to add<br> <fremy> florian: are they immediate siblings?<br> <fremy> emilio: not sure if that matters<br> <fremy> florian: for selector matching<br> <fremy> fantasai: you cannot see that as an author<br> <miriam> q?<br> <TabAtkins> Correct, pseudos don't have an observable relative order.<br> <fremy> fantasai: with ::marker etc<br> <fantasai> s/author/author, like ::marker + ::before is not a thing/<br> <fremy> miriam: fantasai proposed a few resolutions<br> <fremy> miriam: any opposition to the first one?<br> <fremy> RESOLVED: Add ::slider-thumb, ::slider-track<br> <fremy> miriam: the second proposed resolution is to make these elements are sibling of each other<br> <fremy> miriam: any objection?<br> <fremy> RESOLVED: Define these pseudosas siblings of each other<br> <fremy> miriam: third proposal was to apply them to <input type=range>, switch, <progress>, and <meter><br> <fremy> emilio: I agree with this one, with an action to investigate the interaction<br> <fremy> hober: yes, we should<br> <fremy> miriam: any objection to this?<br> <fremy> RESOLVED: Apply them to <input type=range>, switch, <progress>, and <meter><br> <fremy> miriam: final resolution, we want ::slider-fill<br> <fremy> miriam: any objection?<br> <fremy> oriol: counters?<br> <fremy> hober: in the case of switch, inside the track, there is some text<br> <fremy> hober: like "on" / "off"<br> <fremy> hober: so I would like "content" to apply on them<br> <fremy> emilio: I can read for this, but I don't think there is precedent for this<br> <fremy> emilio: if we allow counters in the content, order is observable<br> <fremy> emilio: so the order would be track, fill, thumb from bottom to top<br> <drott> I'll be right back, but fwiw chris' proposed resolution on #9281 sgtm<br> <fremy> s/emilio/hober/ for the last sentence<br> <fremy> fantasai: can we go back to slider-fill and resolve on it?<br> <fremy> emilio: sounds fine by me<br> <fremy> RESOLVED: Add ::slider-fill when relevant<br> <fremy> miriam: and it sounds like we want one more resolution for the ordering of pseudos<br> <TabAtkins> default paint order, yeah<br> <fantasai> s/from bottom to top/from bottom to top, not saying anything about tree structure/<br> <fremy> hober: should we talk about the tree order, or just paining order<br> <fremy> emilio: let's do tree order<br> <fremy> miriam: any objection?<br> <fremy> RESOLVED: track, fill, thumb are in the same tree order as their usual painting order<br> <fremy> hober: happy to take an action to coordinate<br> <fremy> hober: if you look at this issue, the extensive research convinced me<br> <fremy> hober: so we should acknowledge them<br> <astearns> RESOLVED: acknowledge at least thebabydino<br> <fantasai> ACTION hober: Add people who contributed to GH discussion to Acks<br> <chris> q+<br> <fremy> hober: I will make sure this is the case<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1720875895 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 08:22:40 UTC