- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Sep 2020 16:52:54 +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: Continue working on standardizing these 3 pseudos`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: [css-pseudo-4] Standardizing input[type="range"] styling<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/4410<br>
<dael> gregwhitworth: I can try and take if it the person isn't on the call<br>
<dael> emilio: These people rpoposed standardizing a model similar to Gecko. Subtle differences. Added to get feedback. Modal is fairly simple. Could go one way or other. Would like to hear from WK and Blink if it's interesting to using more Gecko-like model and if there's interest in standardizing.<br>
<gregwhitworth> q+<br>
<astearns> ack gregwhitworth<br>
<fantasai> Proposal:<br>
<fantasai> ::range-thumb { /* Styles the thumb of the input*/ }<br>
<fantasai> ::range-track { /* Styles the track of the input*/ }<br>
<fantasai> ::range-progress { /* Styles the progress/fill below the thumb of the input*/ }<br>
<dael> gregwhitworth: To get more specific the proposal is 3 different items. Range-thumb, range-check, and reange-progress. Concrete is missing<br>
<dael> gregwhitworth: did a decent amount of research b/c I was hesitant we'd design into a corner. These 3 are unanimous. I'm in favor of standardizing. Would need concrete what can/can't they do analysis.<br>
<dael> iank_: From blink, I don't know if mason is on. Quick look this is interesting. Would welcome improvement. I don't think we have concept of progress element, but could be wrong. Agree with gregwhitworth and analysis of what properties would/wouldn't be respected would pave way for easier implementation<br>
<dael> gregwhitworth: I will note WK you have a concept of tracking. I don't know if you have an element.<br>
<dael> iank_: I don't believe we have an element.<br>
<dael> gregwhitworth: Okay, okay<br>
<dael> iank_: Just purely a paint effect I believe<br>
<smfr> q+<br>
<jensimmons> q+<br>
<dael> gregwhitworth: I had requested the research. We can action me and I'll reping the person to know what's interop so we cna get a concrete proposal<br>
<dael> iank_: Sounds great<br>
<astearns> ack smfr<br>
<dael> smfr: WK has html progress which is pre-fork. Certainly interested in participating in standardizing<br>
<jensimmons> q-<br>
<dael> smfr: the range pseudo elements<br>
<dael> astearns: Sounds like we have consensus to work in this area<br>
<dael> ACTION gregwhitworth respond to commentor on #4410 to see if they can do the research<br>
<dael> gregwhitworth: Yep. smfr if you can see what you limit that would be great. I'll compare with Maz in Chromium<br>
<jensimmons> q+<br>
<dael> iank_: We recently did a bit of work to simplify in this area so may be pretty different to WK<br>
<florian> I wonder if we're painting ourselves into a corner, and excluding alternative designs (dial like, or other things)<br>
<dael> gregwhitworth: Got it. I'll definitely test<br>
<astearns> ack jensimmons<br>
<gregwhitworth> q+<br>
<emilio> q+<br>
<dael> jensimmons: I want to advocate for a holistic way to get at these problems. Similar space to other conversations. Jumping to we should make pseudo elements. We should look at the whole system, not just this one control. gregwhitworth I think said this in the thread. Terrific we're doing this, but should look at whole thing and not just design separately<br>
<dael> leaverou: Agree with jensimmons. We standardize pseudo elements on a piece by peice basis. There was proposal for parts to standardize. What happened to it? Why create different pseudo elements when can make one for all form controls.<br>
<astearns> ack gregwhitworth<br>
<tantek> +1 jensimmons, take a look at the whole system<br>
<una> +1 jensimmons and leaverou as well -- forms need wholistic review<br>
<dael> gregwhitworth: I really do think and maybe there's an OpenUI joint meeting that makes sense, I don't want to paint into a corner. OpenUI is holistic appraoch. There's 3 or 4 topics where we talk in meta and go in circles while we do ad hocs. But I don't disagree with accent color and these where it technicallye xists<br>
<dael> gregwhitworth: We should do the holistic thing but web is the web today. There are valid use cases not supported in UAs that should be documented.<br>
<dael> gregwhitworth: I'll throw together and ad hoc agenda for joint meeting with OpenUI. There's 3 or 4 topics we could cover. There's enough overlap between the groups. I'm in favor of resolving on these 3 elements but it won't allow you to go to the extent of content swapping<br>
<dael> gregwhitworth: Also point to explainer that Google, Edge, and Salesforce did which is put together a model definition. I think that's worth exploring in joint meeting. Get opinions on that model because does allow part access instead of one offs<br>
<astearns> ack emilio<br>
<dael> emilio: I think gregwhitworth had good points. I agree to finding a holistic solution is useful and needs to pursue. This is standardizing reality. The prefixed pseudo elements won't go away. Allowing authors to not write same style in 3 selector lists is good<br>
<dael> astearns: Agree we should consider holistically and happy to see peoplelike gregwhitworth and Mason are doing the research.<br>
<dael> astearns: It seems like we are doing the holisitic consideration. If there are gaps in the analysis it would be great to raise those in the issues<br>
<florian> Doesn't seem that these pseudos would let you do this sort range controls (or style a UA that had them): https://cdn.shopify.com/s/files/1/0017/2972/products/PX5-chromcapsprodcutpage_580x387.jpg?v=1596119507<br>
<dael> astearns: For this issue we have the next step of figure out what things could be used on these pseudos.<br>
<dael> astearns: Should resolve we do want to make progress on the proposed range pseudos<br>
<dael> astearns: Prop: Continue working on standardizing these 3 pseudos<br>
<dael> astearns: Objections?<br>
<dael> RESOLVED: Continue working on standardizing these 3 pseudos<br>
<dael> astearns: Where it goes, I'm assuming pseudo spec?<br>
<dael> fantasai: Yes or do we want a spec of form controls and their pseudo elements?<br>
<dael> astearns: Yes, does make some sense to have form control pseudos by themselves<br>
<dael> gregwhitworth: We could add that for discussion at joint meeting. I would love to not duplicate. If they're just pseudo elements they go in pseudo. If we spin up a form control spec it goes same patch as OpenUI.<br>
<dael> astearns: That okay fantasai ?<br>
<dael> fantasai: Okay. If we end up adding lots that's specific to a form control at that point it should move to its own spec. Currently mostly specific to page<br>
<dael> gregwhitworth: That's what I was trying to take away from is that overlap. Pseudo elements are a part but ultimately define an anatomy. If we go that route do we spin a new spec for parts? This can be in holistic discussion about where things live. this is part of Open UI anatomy discussion<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-689688371 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 September 2020 16:52:55 UTC