- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Aug 2020 16:45:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Allow specifying the "accent color" of a form control element`, and agreed to the following: * `RESOLVED: The group wants to add accent-color and discussion on details will continue` <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<br> <dael> astearns: Discussed last week, bringing it up first this week. I'm guessing to give masonfreed a chance to give an update<br> <masonfreed> https://github.com/mfreed7/accent-color/blob/master/proposal.md<br> <dael> masonfreed: I heard a few action items. Main was people wanted examples of existing form controls across browser/platform/time perioeds<br> <dael> masonfreed: Added to proposal doc ^<br> <dael> masonfreed: You can see 5 different form controls<br> <dael> masonfreed: There were several questions discussed on thread<br> <dael> masonfreed: One was radio button. Question was on Chrome latest there's a large center blue dot on white, rest are white on blue. Q is doesn't that argue for single color and allow platform to decide.<br> <dael> masonfreed: My view is no if color is spec we should follow<br> <dael> masonfreed: Similar for gradients, what does accent color do.<br> <dael> masonfreed: My view that is up to impl but try and respect accent color. Replace graident with flat fill or integrate into gradient into whatever way makes sense.<br> <dael> masonfreed: Only other open was back to the amount of power to open w/ API. Single color or more specified with multiple colors.<br> <dael> masonfreed: That's all I heard on the thread. Can open for discussion.<br> <astearns> ack fantasai<br> <dael> fantasai: Based on what I've seen starting with one color makes sense since not much evidence of multiple. Figuring out how 2 colors would work together is complicated.<br> <gregwhitworth> q?<br> <gregwhitworth> q+<br> <hober> +1 to fantasai's points<br> <dael> fantasai: In terms of handling gradients if you set parent none everything is flat. If none is not set try and match platform convention. We can encourage use of accent color but I don't think that should disable platform styling<br> <dael> masonfreed: single vs 2 color there are a number of controls in proposal. Even the radio button there are at least 2 colors. If you only open one I would say you have to specify which part you control which leaves other uncontroled. Devs want both controls on the thread<br> <dael> masonfreed: appearance:none is a big hammer. It turns off all styling. Radio becomes an empty div. That is a complaint that brought us to this proposal. radio and checkbox you do appearance:none and have to rebuild everything. This proposal was to give some control without having to rebuild.<br> <astearns> ack gregwhitworth<br> <dael> gregwhitworth: I was initially going to +1 to fantasai in regards to spirit but heard masonfreed on complexity. Maybe have multi color but don't play into gradients. Where we leverage primary|contrast proposal we provide one color and allow UA to do what's best to keep spirit of spec<br> <dael> masonfreed: You mean take current proposal and chop of contrasting color but keep spec as to where first color should apply?<br> <dael> gregwhitworth: No, this started on handling of gradients, correct?<br> <dael> masonfreed: And radio.<br> <dael> gregwhitworth: Was thinking same accent color applied within mac on focus. That's where I was using as use case to have gradients in future. Didn't want to discount that.<br> <dael> gregwhitworth: Contrasting and primary I would keep. Too many scenarios where need to exist.<br> <dael> gregwhitworth: Goes into try to follow this and we don't make this normative. So Safari says bg is primary stay true to author expectation is what you recommend.<br> <dael> gregwhitworth: Radio, I could see Safari say primary is contrast in Chrome. To that end I don't know how you coalesce without lopping them off and hinder feature or get much more prescriptive.<br> <dael> gregwhitworth: Basically, I don't know<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to talk about primary/contrasting<br> <dael> fantasai: Thing with primary vs contrast the way accent color is used varies a lot. Sometimes fg sometimes bg.<br> <Rossen_> q<br> <Rossen_> q+<br> <dael> fantasai: They are sometimes both. Back to aqua there was a solid color highlight with bg color text b/c it's a dark color. vs gradient and lighter gradient is fg on top<br> <dael> fantasai: If intention is set accent colors UA should auto generate variations on color and match against fg or bg as appropriate.<br> <dael> fantasai: If you are creating variations on the color the pair of colors may no longer contrast.<br> <dael> fantasai: I don't know how you would use the contrasting color in a situation like that<br> <dael> masonfreed: I see that point.<br> <dael> masonfreed: I did include some lang that UA doens't have to use exact color. That's one of the cases where you take it as input to the algo but don't have to use exactly that if it doesn't make sense to the gradient.<br> <astearns> ack Rossen_<br> <dael> Rossen_: I'm hearing strong dev need that has been sampled over long time. And a good example of document that motivates and explains why we need and how to go about it. I hope all features have this level of detail and consideration when we bring them<br> <hober> q+<br> <dael> Rossen_: Question is where do we go from here. Discussed over a few weeks. I do see pushback for various reasons. Continuing forward I'm trying to tease out obsticle here. What's the obsticle or are we pushing back just for sake of pushing back<br> <astearns> ack hober<br> <dael> hober: Trying to answer. For me I generally like being able to spec accent color. Very important we preserve browser ability to adopt different designs in future and to deploy on different platforms and meet conventions.<br> <florian> q+<br> <dael> hober: Pushing back to preserve impl flexibility to match platform conventions. Platforms have color conventions and want to be able to use those.<br> <gregwhitworth> q+<br> <florian> q-<br> <florian> q+<br> <dael> Rossen_: How is this different than what we do with appearance today? The cat is out of bag when introduced webkit-appearance:none. Agree in principle to preserve browser innovation but I'm not sure taking away this flexibility is warrented here. Can you expand?<br> <dael> hober: Don't udnerstand your question<br> <dael> masonfreed: I understand what you asked hober but what do you think in proposal is constraining the future developments?<br> <dael> hober: Basic, like what if browser wants to use accent for checkmark, not background of checkbox<br> <dael> masonfreed: That's why I kept it non-normative. It's guidance but not a constraint. If that makes more sense with a new design there's a good reason so go ahead.<br> <dael> hober: Okay, gregwhitworth had said earlier if you didn't want to use accent in where it's spec you shouldn't use at all. Maybe previous call. That's different?<br> <dael> masonfreed: Current lang is accent colors are spec, guidance for what supposed to mean, but tried to thread needle between constrained and open. That's the intention. Open to clarify language<br> <fantasai> "However, the<br> <fantasai> intention is that if the same or similar accent parts exist on a given form<br> <fantasai> element, it should be associated with the "primary" or "contrasting" colors in the<br> <fantasai> same way across user agents."<br> <dael> fantasai: We need to clarify if that's intent. Text says should be same across all browsers<br> <dael> astearns: Acceptable to put intent behind text in spec. Be explicit about attempt and then put normative text so people can interpret.<br> <dael> fantasai: Disagree accent color should be on same pieces across browsers. Intent is use as appropriate, not find and accent color and try and match web os convention.<br> <dael> masonfreed: That sounds like a core disagreement we should discuss.<br> <hober> +1 again to fantasai :)<br> <myles> yep<br> <fantasai> s/find and/use/<br> <dael> masonfreed: What I was going for is if there's a very good reason, like a brand new checkbox with a completely new thing and no way to apply prior history you shouldn't be constrained. But if we're all building a box with a check we should try and be the same so dev can expect similar across browsers<br> <dael> masonfreed: In document all checkboxes are widely the same so we should hope impl uniformly<br> <myles> q+<br> <astearns> ack florian<br> <dael> florian: I think there's a tension in requirements. Desire if some platform has check blue and another box blue and you say make a thing pink and we can do that. But if you don't know if it goes to fg or bg it's hard to know it would lookr ight against everything else on the page.<br> <Rossen_> hober, re: "Don't understand your question" - How is webkit-appearance:none different in terms of overriding UA native controls compared to this proposal? (besides the fact that we won't force authors to rebuild the entire kitchen around the sink)<br> <dael> florian: Current you know if it's fg or bg so you can pick other colors but at the expense of forcing the accent on a specific part. Not sure how to satisfy both parts.<br> <astearns> ack gregwhitworth<br> <dael> gregwhitworth: florian hit nail on head<br> <hober> Rossen_: appearance: none is an escape hatch<br> <dael> gregwhitworth: To circle back in the proposal to masonfreed i put if it computes to auto it's the webdev saying I want OS.<br> <Rossen_> hober: yes, and if your position is to keep anyone from escaping this hatch is a much worse optino<br> <dael> gregwhitworth: No one disagrees with hober about forward innovation. But the second someone finds interop differences it will get replaced. THat's what we see. I get it and I agree but I don't htink it's pragmatic for use.<br> <hober> Rossen_: sorry, i'm not trying to be dumb, but i don't understand what you're getting at.<br> <dael> gregwhitworth: If we say this is limited styling and you have outside of broder have accent color the outline becomes blue and my bg is blue and I won't like it. We can go that route but people will find a barrier. The second we hit that people willr eplace it<br> <dael> gregwhitworth: Worried by making this so loose people will just replace it. We can say you can spec accent color and UA will do best and hope experience is great. We can spec that and say we recommend using these<br> <astearns> ack myles<br> <Rossen_> hober: your pushback was about keeping the ability to ship UAs that can continue comply with the native platform right?<br> <dael> myles: Partially responding I don't htink that nec a bad thing. There are different classes of desire. If web author wants form control same everywhere they have tools for that. Modifying native form controls will be different on every OS. Has to have flexibility<br> <Rossen_> q<br> <hober> Rossen_: my pushback is about making sure that browsers can change their form control designs in the future, and use the author-provided accent color(s) in ways appropriate to their new form control designs.<br> <dael> florian: Design as is has flexibility, but nudges you in a specific direction. If you say accent color blue and you expect a blue check you'd see that and it's fine, but the background is blue on another and you can't see it against your blue bg then you can't see it.<br> <Rossen_> q<br> <dael> florian: Having a nudge to say it's this part it gives you more interop to match with the rest of the page. I would be tempted to say spec as proposed probably gets the bias right<br> <dael> fantasai: I agree with myles and hober. I think if youre appearance:auto goal should be match platform. One thing we can consider is to handle contrast levels instead of spec 2 colors say this if contrast with fb and this if contrast with bg. Most of time not using sep for contrast, you're matching fg or bg.<br> <dael> florian: You means spec both with expectationbrowser uses one?<br> <dael> fantasai: Yes<br> <Rossen_> q+<br> <dael> fantasai: And if you give 1 you give permission to browser to modify along brightness however it thinks appropriate. If you give 2 you can be more precise, but you don't get to say which part is used.<br> <dael> fantasai: If you want to do that more manually I think we need to make checkboxes more stylable generally. I don't think accent color is place to do that<br> <chrishtr> q+<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <dael> masonfreed: Can we use example from dev in thread which is the time control with glyph and bg behind the glyph? Author wanted to control the glyph and bg behind to match control. How would they achieve that with your proposal?<br> <hober> q+<br> <dael> fantasai: I think that get's into...if there's a time icon on my control there's different ways to impl. glyph could be on tex tinput bg or on a button-looking thing. I don't know approach. They are all reasonable for platform. If author want sto control that specifically we need a model for that form control. I don't htink accent color is way to control b/c browser may not be using accent color for that icon<br> <dael> masonfreed: I see that but way it is says there might or might not be a glyph. If a glyph may not have backplace. If both use contrast for glyph and accent for backplate. If we impl that author would be happy. Leaves image of glyph to UA but controls colors.<br> <gregwhitworth> +1 to what fantasai said as it sounds like we need a master switch which appearance is. We should tie the two in some meaningful way and if appearance isn't adjusted we can achieve what hober myles was saying<br> <hober> I don't think it's helpful to talk about this in isolation; there are other efforts (e.g. Open UI) that will help add form control customization knobs, so the whole "if accent-color is too loose, people will use appearance: none" is a false dichotomy.<br> <dael> fantasai: But if button-like accent color is buttony part so convention would be bg of icon is accent color. Trying to say something different wouldn't work<br> <gregwhitworth> +1 to masonfreed point, but there in lies the problem :)<br> <dael> masonfreed: That's what text says. if buttony the bg should be accent. And that's why you need contrast color to control the stuff on the button. Lacking the contrast color the dev would be lost and have to replace the control.<br> <astearns> ack Rossen_<br> <dael> Rossen_: To hober point earlier I agree browsers and UA should be able to differentiate or go to native conventions. Question is given that we have webkit-appearance as an escape which forces devs to complain for years b/c tired of having to use that and re-impl everything. My question is how is this better. Is this best way can do as a presentation platform?<br> <dael> Rossen_: Best we can do is make it apperance:none? Seems like should be better answer and middle ground to allow and expose these parts.<br> <dael> hober: I feel like false dicotomy. Talking about this is isolation and not in context of other prop and features. If we think about all together we can see this question is moot. I'm not saying that the only options are appearance:none or accent color.<br> <fantasai> hober++<br> <dael> hober: Hoping openUI will increase customizability in a number of ways which willenable people to use more and not use escape hatch<br> <fantasai> s/willenable/will enable/<br> <dael> hober: I don't see accent color as alternative but as a complement to those efforts. Platforms with accent color use somewhat similar and somewhat different.<br> <dael> hober: Accent color on the spectrum of control is advice to the browser. OpenUI exposing specific parts is more at the full toolbox where we do what dev says.<br> <gregwhitworth> that last point that hober made is what I think we should explore at breakout. florian had noted he thought about this. I'll start whipping up a doc that explores this with concrete examples<br> <dael> hober: If dev wants it on a specific part of a control I'm saying use what openUI exposes for that control. Accent color is a more general feature that should be more of a hint to the UA to do the right thing. You should have the extra control which is why openUI is exciting<br> <AmeliaBR> +1 to hober's multi-level model. accent-color as a hint for modifying native styling, other options for more direct piece-by-piece control.<br> <dael> hober: I think at root question misses the point. If accent color only possible option there's a point. In a world where we'll have other tools like openUI it doens't hold water<br> <astearns> ack chrishtr<br> <dael> chrishtr: Summary on what I see where we can maybe make progress today. We all agree UAs shoudl have ability to create new UI types over time<br> <dael> chrishtr: I think any accent color we agree should be when possible interop in ways it applies so there isn't first mover advantage.<br> <Rossen_> hober: thank you for elaborating - that was the answer I was hoping and looking for :)<br> <dael> chrishtr: I think spelling out non-normative text to do so will also help inmaking sure corner cases with contrast and darkmode are taken care of<br> <dael> chrishtr: accent color is good to add, make sure text does n't prevent future design, we could encourage interop, and have text that can work the corner cases<br> <dael> chrishtr: Is that a reasonable thing to resolve?<br> <dael> astearns: I think it's more than we can currently agree on in part because recommend interop isn't agreed on definition<br> <fantasai> I think that UAs should have ability not just ot create new UI types over time, but to alter the design of existing UI types over time and across devices and platforms<br> <jensimmons> q+<br> <dael> astearns: Have consensus this is good to add but details of what's normative and not is good to work out<br> <hober> fantasai++<br> <dael> astearns: May be useful to break out current interop goals from future proofing. As we discuss it slides between what people want now and what people imagine in future.<br> <dael> astearns: Might be good to have explicit note that this could all change due to thing we haven't discovered. For current UA this is level of interop to achieve<br> <fantasai> Yeah, I don't agree with that either :) See above<br> <dael> masonfreed: Should I take action to futher update spec text to try and thread needle?<br> <dael> astearns: I think we should have more text to keep up and more discussion on issue. I think we could resolve this is a thing we want to add, but not other details.<br> <dael> chrishtr: Could we resolve on other two points?<br> <dael> astearns: We've already spent 45 minutes on this<br> <dael> jensimmons: Briefly I think there's a lot of reason for optimism. Desire is to make sure this will be complex enough for future rather than drag into past. I'm personally very interested in and haven't been able to be as involved as I want.<br> <dael> jensimmons: We can get somewhere great and this is hard b/c it's hard not b/c desire to not do it.<br> <fantasai> So far no disagreement that we should have accent-color<br> <dael> astearns: Can we resolve this is something we want to add?<br> <fantasai> Just disagreement on how prescriptive its definition is<br> <dael> astearns: Objections to continue to work on this?<br> <dael> RESOLVED: The group wants to add accent-color and discussion on details will continue<br> <dael> astearns: Helpful to break items into separate issues. masonfreed as you update text and look at particular items in contention if you can raise separate issue for each so we can have scoped discussion and resolution on pieces as we good may be good way to make progress.<br> <dael> masonfreed: Will do and thank you all<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-680996476 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 August 2020 16:46:04 UTC