Re: [csswg-drafts] Allow specifying the "accent color" of a form control element (#5187)

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>
&lt;dael> Topic: Allow specifying the "accent color" of a form control element<br>
&lt;dael> github:<br>
&lt;dael> masonfreed: Prop^<br>
&lt;dael> masonfreed: Last time discussed we talked about general prop. Concern we needed to be more specific to avoid ambig or first mover problems<br>
&lt;dael> masonfreed: Sketched out the proposal<br>
&lt;dael> masonfreed: Basics are single prop with multiple values. First spec is primary, second is contrasting.<br>
&lt;dael> masonfreed: Went through each form control and layed out which are primary, which are contrast. Some cases of 3rd color<br>
&lt;dael> masonfreed: General idea is should be able to spec each color of all accent parts. Multiple colors in some cases so proposing bother are controllable.<br>
&lt;dael> masonfreed: Auto value which in any position allows UA to select a color with appropriate contrast<br>
&lt;dael> masonfreed: Biggest debate after that is which are primary and which contrast<br>
&lt;dael> masonfreed: Question for WG is will this be acceptable way to move vforawrd in general<br>
&lt;dael> masonfreed: If yes, work through each control and get agreement on which is primary and which contrast<br>
&lt;hober> q+<br>
&lt;florian> q+<br>
&lt;dael> masonfreed: I think it's important in this spec we list all controls and offer guidance on each control so dev can expect same across UI. If they want glyph of time control to be a color they know which position to use.<br>
&lt;AmeliaBR> q+<br>
&lt;Rossen_> ack hober<br>
&lt;dael> hober: Questions. 1) On some platforms at some points in past accents have been gradients. Wondering how that fits. 2) On which part should get accent it varies wildly between existing browser version and platforms<br>
&lt;tantek> +1 hober, this is 100% true. Just look at iOS versions from 1 to the present. Massive changes in accents / visuals in form controls.<br>
&lt;dael> hober: Example, blink form control refresh some pieces that weren't accented now are. Concerned answer to second question would change over time based on product decisions.<br>
&lt;gregwhitworth> q+ to respond to hober<br>
&lt;fantasai> hober++<br>
&lt;dael> hober: Whatever answer we come to should not depend on contingencies what 2020 browsers look like but instead be forward looking and allow browsers to change view<br>
&lt;dael> masonfreed: Gradient question- excellent question. I'd love specific examples so I can explore<br>
&lt;tantek> gradient, um MacOSX "Aqua" from 2000?<br>
&lt;dael> masonfreed: In terms of parts of controls i think you're right there is a variety of looks and feels and many did just change. The form control refresh drove this. We change checkboxes where it used to be gray, now it's blue, hundreds of people wanted to change it back.<br>
&lt;dael> masonfreed: Specific about which parts my sense is there are a number of ways to define, fg/bg, primary/contrast are all fine. I tried to lay out a way of thinking about accent colors so if browser wants to change they can interpret in the contraxt of the defined elements so it's forward looking.<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack florian<br>
&lt;dael> florian: For reasons realted to what hober said I'm not certain accent color thing can work. But I think there's a chance it can and approach being taken will tell us. Single property with a bunch of values and then going through a bunch of controls and saying how it applies is a good idea<br>
&lt;gregwhitworth> ack gregwhitworth<br>
&lt;Zakim> gregwhitworth, you wanted to respond to hober<br>
&lt;gregwhitworth> q+<br>
&lt;dael> florian: Based on current prop I would suggest not just one style for each control but include several. Maybe current, and MacOS aqua and maybe a somewhat out there which gives us diversity and see if it all holds up.<br>
&lt;gregwhitworth> me gregwhitworth oooh - cool<br>
&lt;Rossen_> q?<br>
&lt;dael> fantasai: I think intent is it's abstract and we'll find the answer. Looking at a variety of controls will tell us if it works<br>
&lt;fantasai> s/fantasai/florian/<br>
&lt;dael> AmeliaBR: One clarification for masonfreed. At some point prop allow arbitrary number of colors. Is that still part of proposal?<br>
&lt;Rossen_> ack AmeliaBR<br>
&lt;dael> masonfreed: In current up to 3 colors. First 2 are in almost any control. 3rd is only in range<br>
&lt;dael> AmeliaBR: Okay, that helps. Concern about too many colors is it multiplies ways things can be used and concerns about contrast<br>
&lt;dael> AmeliaBR: Related, question of what is auto? We've got examples about auto meaning use system-wide accent and auto meaning use the local colors and don't accent so use currentColor on transparent bg.<br>
&lt;bradk> For many gradients, you could have a solid, author chosen background color, overlaid with a transparent to semi-opaque white (or black) gradient. That would work for gradients that are just shades of the main color.<br>
&lt;dael> AmeliaBR: As far as web compat and testability for an author not sure if we need additional keywords to distinguish between if you want additional accent colors or keep as simple as possible<br>
&lt;dael> masonfreed: Spec written is vague. auto provided for any color position selects something appropriate for contrast when paired with given colors. So you said blue and left off the glyph so pick something for me<br>
&lt;dael> AmeliaBR: Browser has to make sure contrast is decent not browser has a standard value and do what you normally do. There needs to be smarts<br>
&lt;dael> masonfreed: Correct. I htink need to be smarts to get good contrast<br>
&lt;dael> AmeliaBR: Tying to that and hober comment on gradients we've got examples about native mac where accent modfies to lighter/darker. Same with windows accent colors. Shows as different lightness on different interface parts.<br>
&lt;dael> AmeliaBR: Do we want to explicitly acknowledge that browser may tweak to preserve contrast?<br>
&lt;dael> masonfreed: I did call thatout. If you selected auto and OS provides a color user is encouraged to respoect. UA may us similar colot to enhance a11y and contrast<br>
&lt;Rossen_> ack fantasai<br>
&lt;dholbert> q+<br>
&lt;dael> fantasai: I wanted to agree with hober. Look at specific example. Checkboxes. Some use accent, some done, son use it on border of checkbox, etc.<br>
&lt;dael> fantasai: Don't want to limit going forward and require same. Controls we know about have changed. Need to make sure spec can accomodate that. It sounds like the direction it's trying to take.<br>
&lt;dael> masonfreed: Other questions have been about how, this sounds like question of should we impl accent color<br>
&lt;florian> q+ to respond to fantasai<br>
&lt;dael> masonfreed: Understand concerns but I have done a wide survery. Examples are appriciated but in my tour of browers this scheme will allow you to control all of them. There are checkbox variety, but it has a bg and glyph on top of all impl<br>
&lt;tantek> checkbox are "simple"? like animated toggle switches which completely change color when you flip the switch?<br>
&lt;Rossen_> q?<br>
&lt;fantasai> s/trying to take/trying to take is defining exactly where the colors are used/<br>
&lt;dael> masonfreed: Trying to keep spec open for future but trying to provide guidance. florian said include explicit examples I'm happy to do it if there's appetite and helps discussion.<br>
&lt;Rossen_> ack florian<br>
&lt;Zakim> florian, you wanted to respond to fantasai<br>
&lt;dael> florian: from fantasai point, spec doesn't say you have to put accept in fg or bg. It says you have a list of accent colors and if accent is on bg part you pick from first color. If accent is on glyph you pick from second in list.<br>
&lt;Rossen_> q++ to tell everyone that q++ works<br>
&lt;Rossen_> :))<br>
&lt;dael> florian: If you have no accent color you don't pick it. It doesn't force browsers to pick. Depending on which part you accent you pick from here in list. I think not over constraining.<br>
&lt;dael> florian: I would like to see it explored for a bunch of controls to make sure<br>
&lt;Rossen_> ack +<br>
&lt;Zakim> +, you wanted to tell everyone that q++ works<br>
&lt;Rossen_> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to respond to florian<br>
&lt;dael> fantasai: Accent color for some systems, like macOS aqua, color is lighter and intended to be used with normal text color. Whereas highlight color which is selected item is darker blue and inteded to be used with white.<br>
&lt;dael> fantasai: In that case fg abd bg would be different blues not intended for same time. Maybe you only provide one color and UA modulates. I don't know, either accent is giving 2 meant to work together or 2 variations that could be used with fg or bg<br>
&lt;dael> florian: It's the former. BG and fg supposed to work together<br>
&lt;dael> fantasai: Then you have to pick both together.<br>
&lt;dael> florian: Depends on the control.<br>
&lt;fantasai> s/together/together, you can't just pick one or the other as you said/<br>
&lt;dael> Rossen_: I think these are great examples to be brought for masonfreed if he has to investigate more behaviors.<br>
&lt;Rossen_> ack gregwhitworth<br>
&lt;dael> gregwhitworth: I feel we should based on numerious desicussions I think we should do a meta on control styling. As I tried to outline in it masonfreed hits on in order for this to have value there needs to be interop<br>
&lt;dael> gregwhitworth: Only way to ensure is to normatively define<br>
&lt;AmeliaBR> q?<br>
&lt;dholbert> q-<br>
&lt;dael> gregwhitworth: But I agree with hober we don't want to limit UAs from future or innovations<br>
&lt;Rossen_> q?<br>
&lt;AmeliaBR> q+<br>
&lt;dael> gregwhitworth: I had prop that if values compute to auto author is saying UA do what you will at which point it's irrelevent you adhear to the requirement. But if it's not auto we'll agree these parts exist and it's applied as this color<br>
&lt;dael> gregwhitworth: b/c author opts in it hints to UA they want control. To have interop we need to have agreement. Or this becomes not valuable to impl<br>
&lt;dael> gregwhitworth: Naming is worth looking into.<br>
&lt;dael> gregwhitworth: atgn in github brought up use case to have accent color as a short hand. To point of contrast might be desire to have author include all, but worth considering<br>
&lt;Rossen_> ack AmeliaBR<br>
&lt;dael> AmeliaBR: Follow up from gregwhitworth comments. I think it's still true we need a more complex way of accessing and styling all parts of complicated form controls. Shouldn't stop persuing that.<br>
&lt;dael> AmeliaBR: Still value in simple way of saying use the default form controls but tweak to my colors<br>
&lt;chrishtr> q+<br>
&lt;dael> AmeliaBR: Strong value in this prop while having potential of a more fine grained control in future<br>
&lt;dael> AmeliaBR: Also option of doing appearance:none and recreating<br>
&lt;dael> gregwhitworth: That's not what I meant. Mearly saying only way to ensure interop you have to define the parts and where accent color will be defined.<br>
&lt;dael> AmeliaBR: So introp you expect authors to say this must look some everywhere and if we end up with just this color somewhere...<br>
&lt;dael> gregwhitworth: Opens up prblems like forced colors, how do you get good contrast? And spec is whisy washy and if design principles don't allow you don't have to do. If it doesn't ahear to what brand wants they throw it away.<br>
&lt;dael> gregwhitworth: I like your form control but my brand is green and I just want green. But when they open a browser and it doesn't use it and they'll say it's important and they build their own checkbox<br>
&lt;Rossen_> q?<br>
&lt;dael> gregwhitworth: I personally foresee this being nice to have and due to market share perhaps having to follow a browser. I think this will happen at UA layer if we don't do at spec layer.<br>
&lt;dael> chrishtr: I wanted to respond to points AmeliaBR and gregwhitworth raised about defining parts and how accent color fits in with interop<br>
&lt;hober> q+<br>
&lt;dael> chrishtr: I think we should try and persue the larger project of defining anatomy but htat's a big thing. Value in having easy to use thing to define use cases from authors. I think masonfreed draft is close to enough to spec that if form controls on UA have certain concepts they should use accent color to adjust<br>
&lt;dael> chrishtr: If they don't have the concept of form control has UX that's incompat then UI should ignore accent color. I think that's intent of spec prose<br>
&lt;dael> chrishtr: Allows innovation bc later point. I think it's explicit acknowledgment where we want dev to be able to style form controls we know about but not locking in 2020 style or UX conventions<br>
&lt;Rossen_> ack chrishtr<br>
&lt;Rossen_> ack hober<br>
&lt;bradk> +1 @chrishtr<br>
&lt;dael> hober: I wanted to echo something from earlier. I'm enthusastic about authors supply accent color. What I'd like as an author is to say my accent should be purple. Things that get an accent color should be purpose and that might be different on different platforms.<br>
&lt;Rossen_> q?<br>
&lt;dael> hober: In particular I think 2018 blink and 2020 blink should both be conforming b/c different things are colored. If the colored thing changes I think it meets the use case which allows the control to fit the branding author is trying to achieve while maintaining coherence.<br>
&lt;dael> hober: Websites don't need to look the same in every browser and that's okay. Trying to lock down to point where has to be bg of checkbox would be a mistake.<br>
&lt;Rossen_> Zakim, close queue<br>
&lt;Zakim> ok, Rossen_, the speaker queue is closed<br>
&lt;dael> hober: escape hatch from chrishtr where you have to ignore if you want different is disservice to author. Browsers with different UI aren't supposed to use purple at all? That would be unfortunate<br>
&lt;tantek> +1 hober again<br>
&lt;fantasai> +1 to hober<br>
&lt;dael> masonfreed: To clarify, if there is a peice of the control that does not exist you should ignore htat part. A time control has no glyphs on many platforms. If accent is meant to apply to glyph you can ignore<br>
&lt;dael> masonfreed: If there are new parts no one has imagined it says you should look through and match in spirit what is there so there is forward compat<br>
&lt;dael> Rossen_: Nearly at time. fantasai is on queue. Want to make sure we haev a path forward for masonfreed and those working on proposal.<br>
&lt;dael> Rossen_: fantasai go ahead and then we'll wrap<br>
&lt;dael> fantasai: Reading spec I don't have problem with most. Have general agreement you should be able to spec accent color and UA should do something with it. Contention here is a number of us are saying it shouldn't be dictated what part of the control that is<br>
&lt;dael> fantasai: I think it's important for us to explore various areas accent colors used and make sure spec allows for that variety and then provide guidance. I don't htink we should lock down each form control<br>
&lt;dael> fantasai: Spec text is fine until get to part where we should have interop on where accent color is applied. I think it's clear having ability to spec the accent color is a good idea.<br>
&lt;dael> Rossen_: masonfreed and co I think you've got a good bit of feedback. I prop we bring this as first topic next week and we'll see if there's more to bring closer to resolution.<br>
&lt;masonfreed> Thanks! Very helpful discussion.<br>
&lt;dael> Rossen_: Hopefully what you've heard was valuable and you can address some of the concerns in the meantime<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 19 August 2020 17:02:48 UTC