- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jul 2020 16:59:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Allow specifying the "accent color" of a form control element`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Allow specifying the "accent color" of a form control element<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-656913918<br> <dael> Mason: Proposal is add ability to spec accent color for form control elements.<br> <masonfreed_> https://docs.google.com/document/d/1yHQUshdC3hKrDRG-xDtUPYVIcc_JNUglK0KMVoqRyCo/edit#heading=h.p0f1fs5x6ado<br> <dael> Mason: These are the ones that can't be styled, particularly color. Looked at most form control elements. Put together a study<br> <dael> masonfreed_: Conclusion I came to is it seems we would need foreground and background color. Many form controls accent have 2 colors. Absent that we would need magic to ensure contrast<br> <dael> masonfreed_: In many cases it seemed like magic that would get in the way for devs.<br> <dael> masonfreed_: Motivation for us is Chrome recently changed from gray to blue and that caused a lot of problems for devs that had a theme on their site.<br> <dael> masonfreed_: Not full styling but this seems to eliminate a lot of problems<br> <TabAtkins> q+<br> <astearns> q+<br> <dael> masonfreed_: I did propose some spec language. accent-color-background and -foreground. It's nec. vauge because impelmentation varies across browsers. Even if impl is different across browsers there's still value in being able to say here is what I would prefer.<br> <astearns> ack TabAtkins<br> <dael> TabAtkins: Overall I like the idea. Similar to explorations a few years ago where we suspected we could boil down color choices<br> <dael> TabAtkins: On studies, checkmarks you have background as background behind glyph. Screenshot has white checkmark and blue background, but I think usual is dark glyph on light background. Might be fine.<br> <myles> q+<br> <dael> TabAtkins: More important is range inputs. Color of progress bar and range input sounds like something to put under control of page. But that's not being colors by either you provide. YOu give reasons, particularly for range inputs, but it does worry me that's a missing thing<br> <dael> TabAtkins: I think it's really the only missing thing<br> <dael> masonfreed_: On checkbox and radio. It was modern chrome. Impl differ quite a bit and across platforms on same browser. That was a more motivating case for both.<br> <emilio> q+<br> <dael> masonfreed_: On range control, it's a general question. this isn't exhastive list. Can't tackle all. Range control has prefixed pseudo-elements. Though controlling turns off default.<br> <dael> TabAtkins: My concern is if we add these range inputs won't be sufficently styleable. That's my only concern<br> <dael> masonfreed_: I don't disagree. Perhaps that future improvement<br> <dael> TabAtkins: I'm happy with this and works for other control. I support pursuing and see if we can solve range<br> <dael> astearns: I wanted to voice concern that these are vauge in application where UAs decide how to apply them. Understand form controls are impl differently. May not be initially ways of making this interop apply<br> <jensimmons> q+<br> <dael> astearns: Do you think that's set in stone or is making these colors available and seeing differences sparking further interop in form controls?<br> <astearns> ack astearns<br> <dael> masonfreed_: This isn't a fix for complete interop. It's a good project which is being persued. I see this as currently form controls are not interop at all. Causes many problems. Adding this mandate (since it's not well spec)....currently colors are out of control of authors. It moves us in direction of interop since there is more dev guidance in the impl.<br> <dael> astearns: Yeah. Wanted to make sure not painting into a corner. This isn't perm bandaid and allows things to heal underneath<br> <astearns> ack myles<br> <dael> masonfreed_: Completely agree.<br> <dael> myles: A few minutes ago they said chrome switch from gray to blue caused problems. Surprising that a browser made a change which caused problems and fix is adding css properties. Some thought to maybe that change to all websites in browser needs work<br> <dael> masonfreed_: I think this points to a current interop problem. Most of the complaints were around a color change to blue which existed in other browsers, incl chrome on Mac. To me what that means is they weren't testing on other platforms or browsers since it was already blue. Making this exposed would hopefully eliminate interop problems<br> <astearns> ack dbaron<br> <dael> dbaron: I do share some of astearns concerns. What I wanted to raise is when TabAtkins went through list of controls, esp range and progress. My understanding of desc is what is nominally foreground and background would we set to same for range. I think this pic shows they're the same blue.<br> <gregwhitworth> q+<br> <dael> dbaron: Risky in that one of the things we try and do in css is push that foreground and background should have contrast. We should avoid situation where we want them not to contrast. I'm worried about defining range in a way that fg and bg used but not contrasting<br> <florian> q+<br> <dael> masonfreed_: Two comments. In document I call out thumb being fg and filled in as bg. The screenshot there is chrome current impl which has no contrast. THat is very different across browsers. I think it calls out you want 2 colors so dev can choose different or identical. Spec 1 color and an algo to choose contrast precludes dev not wanting contrast<br> <dael> dbaron: In this case 3 colors on range. Question is which 2 can devs spec with fg and bg<br> <dael> masonfreed_: Agree. Ambig. That's the TabAtkins point range may need additional work. I don't think try and spec exactly which piece is fg and which bg. Point of study is what do these typically look like in order to have guidance. I don't thinkw e should spec all pieces now<br> <dael> dbaron: I think if you don't spec whatever first impl does everyone has to copy. I think better to spec and discuss.<br> <Rossen_> q?<br> <astearns> +1 to spec where we can rather than leaving ambiguities<br> <astearns> ack emilio<br> <dael> masonfreed_: I see point but I point to current form control which have been different for decades. I see point, it is possible. Long term is expand and spec all parts and allow complete style. I go back to this is a bandaid between now and when that's real<br> <dael> emilio: Point out dbaron point where this cannot be left out to whatever. We will have to copy 1st impl.<br> <dael> emilio: If I understand this is for native form controls, like appearance:auto. Right?<br> <dael> masonfreed_: Yes<br> <fantasai> Would like to note that locking down the exact UI of every form control on every device forever just because authors want to style them pixel perfectly on the devices they care about is not good for users.<br> <dael> emilio: Browsers don't always have control over those colors. Ex range on linux and mac for FF the control os drawn by the OS so this is not really impl right now. Want to move to a place where we may not have native styling, but right now couldn't impl<br> <dael> masonfreed_: Take your point. Until recently on Chrome checkboxes on mac not styled. That's more about why this should be guidance for impl<br> <dael> emilio: But then not useful to authors. What authors could do is say if browser supports I'll use it if not appearance:none. Not sure to what point authors would bother.<br> <dael> masonfreed_: Valid point.<br> <astearns> ack jensimmons<br> <Rossen_> Trying to align styling of form controls is not a new thing... certainly not new in terms of resolving against it, see https://lists.w3.org/Archives/Public/www-style/2019Jul/0002.html<br> <dael> jensimmons: I want to say thank you for going and doing more research<br> <dael> jensimmons: I like seeing you figured out we need 2 properties. That's great,t hat's what we need.<br> <dael> jensimmons: As a front end dev the idea of these properties existing is super appealing. I can just universally or dark-mode/lightmode I can quickly change accent colors.<br> <dael> jensimmons: I think we believe there needs to be interop on this. I understand desire to do something quickly and not have to do deeper dive. Given reality of how tricky forms are in browsers it's a rats nest.<br> <dael> jensimmons: One of the things about how modern css is spec we learned the hard way what happens when underspec. form controls re bad b/c they were underspec a while ago. We can't repeat same mistake if we want to get out from under.<br> <dael> jensimmons: Feels like if these properties went to world without spec as to what part gets colors we wouldn't get same from all browsers and situation could get worse. THis shouldn't try and fix everything and I appiciate desire to do something quicker than openUI project.<br> <chrishtr> q+<br> <dael> jensimmons: I think right depth in technical debt is go through each thing and define exactly what is fg and bg. I don't know how to proceed without that. Doesn't have to be worst thing every, but make it clear that checkmark is fg and behind is bg. If browsers aren't same it's not useful<br> <dael> jensimmons: Whatever browser ships first defines it is what happened with css1 and 2 and then we end up stuck with things we can't ever change.<br> <dael> astearns: If we do run into scenario where people have to copy 1st impl it goes into spec, jsut too late.<br> <astearns> ack gregwhitworth<br> <dael> gregwhitworth: I wanted to say I feel like people are alluding. We left style out of openUI charter b/c we didn't think anyone would want to talk about interop styling. I think people overe there would be happy to say what gets fg and what's bg. We can take masonfreed_ work as an intial stab.<br> <dael> gregwhitworth: I went and looked at browsers and saw overlap...someone mentioned contrast...most component libraries do magic.<br> <dael> gregwhitworth: I'd like to involve openUI in standardizing. In addition we should provide that magic. Css1 we prevented all magic. We went the other way where we have no magic. I propose language where if you provide one browser does math to get contrast min so we get browsers able to do contrast<br> <TabAtkins> light/dark mode is a lot different from "here's two precise colors i need you to use"<br> <dael> gregwhitworth: Other argument where I'd like other browsers to weigh in on route we didn't nec do this for all browsers. We didn't go through all controls where if we're in dark this button gets a dark border. I'm getting some conflicts but happy to peel onion. I would love for us to be consistent if possible<br> <astearns> ack florian<br> <dael> florian: Conflicted. On one hand I agree with jensimmons and example where range sometimes they contrast and sometimes not and we should be deliberate and design. However, I don't believe we can. OSs not only have different colors but different structures. If you look at scrollbars they have differnet parts from now and 5 years ago. If form control looks completely different between browsers I don't see how we crack this. All while agreeing with jensimmons<br> <astearns> ack chrishtr<br> <dael> chrishtr: I don't think this would result in a disaster. Form controls being very different is a big problem. Id on't think this adds to problem but subtracts.<br> <dael> chrishtr: Addresses main problem that color scheme doesn't match.<br> <TabAtkins> I think the properties currently hit a good mix of specific and generic that'll be useful *and* future-safe. dbaron's concern about range fg/bg is the only one I'm really concerned about.<br> <dael> chrishtr: I think not a good idea to wait on complete solution b/c will take long time. Could be reasonable to try and approach where we write more specific suggestions in spec that state things like on checkbox rec that fg is the glyph.<br> <TabAtkins> (I think we might be able to address it by instead saying that Chrome *just* uses the fg color.)<br> <Rossen_> q-<br> <dael> chrishtr: Then bring it to the group and see if it's reasonable se of defaults for most browsers. Avoid problem of one browsers chooses and make it more collaborative.<br> <jensimmons> q?<br> <dael> astearns: Sounds like a good next step.<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to talk about variance of form control styling across OSes, e.g. drop-down boxes<br> <jensimmons> q+<br> <masonfreed_> I'm happy to take an action item to recommend the added spec recommendations suggested by chrishtr<br> <dael> fantasai: Same concerns as florian. I udnerstand problem we want to solve. Concern about idea that goal is make form controls unified for now and in future. Lots of improvements to form controls over time. I think it would be a little bit inappropriate to say now is the best form of UI. I don't want to lock into where we spec exactly what form controls look like and in 5 years someone makes s new select box style that's not compat. That's my concern. No[CUT]<br> <TabAtkins> That's also my concern, fwiw, and I think this proposal specifically does *not* run into that.<br> <astearns> ack jensimmons<br> <masonfreed_> q+<br> <dael> jensimmons: I think we have a lot of agreement. We don't want to overcontrol form controls b/c it needs to be possible to invent new display. We know defaults are different for very good reasons. There's a happy medium. What chrishtr said is right taht limit to what we can spec, but we should go down the road. Use lots of may<br> <dael> jensimmons: As we add accent-color-fg and -bg I can see not spec the defaults. There's threading hte needle. I think everyone is saying thigns that are true. We want to keep this scoped and tight so it doesn't take forever but not create bigger problems.<br> <fantasai> For the minutes, the proposal gdoc is archived at https://lists.w3.org/Archives/Public/www-archive/2020Jul/att-0000/Accent_Color_for_Form_Controls.pdf<br> <astearns> ack masonfreed_<br> <dael> masonfreed_: Echoing. This will be hard to spec crisply, but want to avoid 1st impl wins. I like chrishtr suggestion for more guidance we can agree on before it's implemented. Happy tot ake that action and propose new text.<br> <dael> astearns: Thank you and thanks for the work.<br> <dael> astearns: Out of time. Everything we didn't get to goes on the agenda next week<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-662570409 using your GitHub account
Received on Wednesday, 22 July 2020 16:59:41 UTC