- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Sep 2020 17:02:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[accent-color] Should interoperability be a goal for the `accent-color` spec?``.
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: [accent-color] Should interoperability be a goal for the `accent-color` spec?<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/5480<br>
<masonfreed> https://github.com/mfreed7/accent-color/blob/master/proposal.md#motivation-and-intent<br>
<dael> masonfreed: Heard 2 things from last time. One is ^ to add motivation and intent to help interpret written spec. I wrote that.<br>
<dael> masonfreed: tl;dr is it's to provide a compromise between interop and not constraining browser impl.<br>
<dael> masonfreed: Today is interop question. Are we going for interop? It's fundamental. Depending on your answer the spec changes. Should it be same across or hint to browsers?<br>
<dael> masonfreed: My opinion is useful either way but lose a lot if don't strive for interop.<br>
<dael> masonfreed: 2 reasons. 1 is not easily usable by devs without browser sniffing. Could also cause a11y and contrast issues if different expectation as to where the color goes. blue background, white accent for checkbox and you assume that's the background. If browser colors the check white you have contrast problems.<br>
<dael> masonfreed: I started this with the idea of a single color and went through how it works for each control. Realized it's hard to use without language on how it's used for all controls. Helpful to look at examples section<br>
<dael> masonfreed: Question today is should accent color be interoperable.<br>
<dael> myles: Background concern is being able to match platform form controls is valuable. Some browsers system framework needs to fit in. Don't want to have 2 sets of form controls for web content vs rest of OS<br>
<emilio> q+<br>
<dael> masonfreed: I think if you as a dev want to make form controls match platform it's easy, don't spec anything for fonm controls and it matches. If you spec colors you're trying to change away.<br>
<astearns> ack emilio<br>
<jensimmons> q+<br>
<TabAtkins> q+<br>
<dael> emilio: I feel a bit the same as myles. If we try and spec form controls...dev may spec accent color b/c chrome handles it and they don't look native but look better if you change accent color. I'm not sure your argument applies that some browsers will honor colors and others won't.<br>
<myles> q+<br>
<myles> q-<br>
<dael> emilio: For some platforms like Windows and MacOS (I think) we don't have much control over which colors are native and which are for form controls. Alternatives are remove native but you don't want to do same as appearance:none, right?<br>
<dael> masonfreed: Right. Idea here is make basic style of color easier for developers.<br>
<myles> q+<br>
<dael> masonfreed: The intention of proposal is that it's open to not do anything. It's explicit you can disregard a color. It says if you are going to respect it you should try and use it same way as everybody else. If you don't want to control colors of native form controls you can do that. But if you use accent color you should do it same as everyone else<br>
<dael> emilio: But if Gecko and Wk want to keep native appearance we have to impl form controls twice if we want to honor it sometimes.<br>
<dael> myles: Another way to say this, this is a world where some browsers impl intentionally and some done. Some browsers use own native design and others use non-native custom design. That doesn't sound like consistency. That world answers the question, it isn't consistent.<br>
<dael> masonfreed: Agree form controls are all different. Is that what we want is the question. If we're adding something new should we point it toward interop?<br>
<una> q+<br>
<astearns> ack jensimmons<br>
<dael> jensimmons: I think there's 2 ways to look at this. One is what we're discussing from impl. From author PoV is the other.<br>
<myles> q-<br>
<dael> jensimmons: I think some of what you're asking masonfreed gets at the root of the idea where coming up with accent color as the property...another way to do is pseudo class for checkmark and another for checkbox....having something more vague implies the idea we're not giving you a bunch of hooks<br>
<dael> jensimmons: If I expect to say my checkbox bg is blue I expect that everywhere. But when it comes to saying accentColor: blue it's impled by the property and the name that hey author welcome to the wide world of chaos and there is not consistency even in the same browser what's happening<br>
<dael> jensimmons: I thought the idea is hey we know it's chaotic so we're going to give authors something that's more generic and we'll give authors a way to say my accent color is blue and it's not interop in a way that pixel perfect designs would imagine<br>
<dael> masonfreed: I appriciate and understand that. That is still my intent. Range looks different across everything. I think the realization I made going through each control is there are in a lot of cases 2 places where accent color comes in. There's background-y and foreground-y thing. I think we're still trying to spec something vague but add a bit more information and provide more of a hint what the dev is trying to do.<br>
<gregwhitworth> q+<br>
<dael> masonfreed: Providing 2 colors and some guidance feels to me helpful even to devs. Definitely helpful to devs. If building a checkbox and looks like other checkboxes it's helpful to me.<br>
<jfkthame> q+<br>
<dael> masonfreed: I hear we're not going pseudo classes for everything. Maybe that's down the road. This is low hanging fruit that solves a bunch of dev problems that want to make the controls the right color for their site.<br>
<dael> masonfreed: I feel you need some level of intent about doing the same thing if you're going to do it.<br>
<dael> jensimmons: Makes sense to put something in spec so impl aren't just making it up and everyone gets to a different idea. Say in general we think accent is here and other color is here so impl can have some guidance and not make it up from scratch or look at other browsers. But maybe just a gentle suggestion<br>
<dael> jensimmons: You're asking should we try and get everyone to be definitely the same way and I don't know that we can say yes<br>
<dael> masonfreed: Adding one more thing. Way we got here is there was concern about first mover problems. If one browser impl accent color then other browsers would be stuck matching. Work I did to go through each control was in response to this call saying let's discuss first up front.<br>
<astearns> ack TabAtkins<br>
<emilio> q+<br>
<dael> TabAtkins: Two things. 1 to talk to myles and emilio about browsers wanting native on particulr platforms. I think that should be fine. Goal of form elements being stylable will continue to be impossible. Native form controls are weird. Spec allowing browsers to stick with native and ignore accent color is necessary and doesn't make us any worse.<br>
<dael> TabAtkins: When talking interop, saying we need interop is nonsense. We need interop to make this a property. We need at min if it's a fg or bg color. Required to ensure element looks good against parent. This will be complex b/c things liek Chrome redesign from where checkign a checkbox swaps the bg and fg colors<br>
<dael> TabAtkins: This means chrome cannot be using blue as fg accent and use that to draw bg. Needs to set in UA that when checkbox is checked it uses flipped. It's a work around. If we're clear that if you give 2 colors one wis fg and one is bg I think we're okay. Given there's no control what so ever right now that bit of requirements should insure enough interop even if there's a first move<br>
<dael> TabAtkins: Means we'd have to be careful about how we spec<br>
<astearns> ack una<br>
<jfkthame> q-<br>
<TabAtkins> like, `input { accent-color: blue white; } input:checked { accent-color: white blue; }` needs to be in the Chrome UA stylesheet<br>
<dael> una: I want to speak to intent of prop. Give authors more control over form styling. Problem for 20 years. If we're giving authors more control the authros that would case want consistency across brands and OSs. My worry is it seems to be about consistency. If there's not consistency about how colors applied it doesn't solvet he issues the property tries to solve.<br>
<dael> una: Even with having BG color it's different in Safari where there's a gradient. Solving those issues is key to making this something authors adopt. If we say here's the color and good luck and it's different across browser and OS it takes away the power of the property<br>
<astearns> ack gregwhitworth<br>
<dael> una: Want to argue to authori ntention in wanting consistency. If we're introducing new properties and options it should be top of mind<br>
<dael> gregwhitworth: I would like to 100% agree with TabAtkins and una. This was something we were hoping to tackle at joint meeting and it's b/c masonfreed hit nail on head. Need to resolve if we agree this is a problem we're solving<br>
<jensimmons> q+<br>
<dael> gregwhitworth: There's a reason author is putting this in there. They're saying I need to change this for a meaningful reason. Way we start to address is recognizing there's potential buckets, potential capabilities we can unlock these things. We're going after the extreme far end to unlock everything. This property is more like intent<br>
<dael> gregwhitworth: There is a spirit and an intent to say I'm coke and I want checkboxes to be coke-red. I love your checkbox but it's blue and it feels Chrome not Coke. I'm proving you a brand hint, please apply to your control in a meaningful way. That's the way it's spec.<br>
<dael> gregwhitworth: Trying to thread the needle of allowing author to have limited control, but some control, while not biting entire problem. Feel it's a good first step.<br>
<bradk> +1 to CocaCola example<br>
<dael> gregwhitworth: I agree with TabAtkins that if they're using the property you should leverage it. I guar everyone has primary, secondary, etc. colors. We should be able to commit to if they're native render or not it's not un-implable.<br>
<astearns> ack emilio<br>
<dael> gregwhitworth: jensimmons and una hit on it. Author problem and if we feel our controls are superior to the problem author is trying to solve. Agree with TabAtkins about we should lock down. Appriciate masonfreed trying to have the spirit<br>
<fantasai> +1 to gregwhitworth "please use this color in a meaningful way"; -1 to defining what "use in a meaningful way" means in terms of which parts get which color<br>
<dael> emilio: Agree with sentiment<br>
<TabAtkins> Important bit here is that the role of the colors *cannot* be semantic like "primary, secondary, tertiary". They *must* be functional like "foreground, background, shadow". Otherwise a page using "black white" for a checkbox, expecting a white box with a black check, and putting it against a black background, would look bad on Chrome where the bg is the "primary" color when checked.<br>
<gregwhitworth> q?<br>
<gregwhitworth> q+<br>
<fantasai> +1 TabAtkins<br>
<fantasai> need to ensure contrast<br>
<dael> emilio: Concern is implementablity. We can do the work to make it work. If WK commit they can add coco APIs for Mac but no control over windows. Only alternative is re-write form controls. We may end up doing that. I don't know. If you force engines to apply it then you prevent using native form controls<br>
<gregwhitworth> q?<br>
<dael> emilio: If you don't it's not all that useful to authors b/c they can't customize<br>
<gregwhitworth> TabAtkins: yeah, my point was that everyone does have colors in their control that will be able to map to the property value set<br>
<dael> astearns: Compromise is for a browser using native controls without any capability of changing the browser could say they do not support on that platform. lets author know styles won't work as intended.<br>
<dael> emilio: It's an option but pages could rely on colors to work<br>
<bradk> I disagree that it should say backwards vs. foreground. If one native control has a border and another doesn’t, saying the background should be white would be much worse on the one with no border.<br>
<fantasai> wrt accent-color, I don't think making a list of "primary/tertiary/etc" makes sense. But listing colors, against which the browser will use a "pick color with most contrast against [color/bgcolor as needed for this particular use of accent coloring]", could be a good way to do this<br>
<astearns> ack jensimmons<br>
<TabAtkins> gregwhitworth: Yeah, I was just countering your use of "primary" in your description. ^_^<br>
<dael> astearns: There will always be browsers that won't support.<br>
<TabAtkins> agree with jensimmons; this has been circling for twenty minutes when it's actually just a debate over the existence of the feature itself<br>
<emilio> q+<br>
<dael> jensimmons: I'm just confused as to where disagreement is. Feels like a high level debate about if we should use must/may/should in every part of the spec. Maybe some of spec should say must, some should be may, some should.<br>
<dael> masonfreed: For me the debate is the way prop is written is the interop version. Alternative is strip away most of that to just say accent color looks like this and browsers us as they say fit. Debate is spec as written vs another spec that reads that accent color is a hint, use as you'd like<br>
<gregwhitworth> q-<br>
<dael> astearns: Put another way we dsicussed and asked masonfreed to make non-normative suggestions. masonfreed is coming back for validation. I think we should say yes this is what we want or no, dial back on interop<br>
<astearns> ack emilio<br>
<gregwhitworth> my main point here was that we can pick up this discussion at the Open UI + CSSWG meeting<br>
<gregwhitworth> I have this as an agenda item<br>
<gregwhitworth> as it's paramount to land on aspects of interop<br>
<gregwhitworth> whether we do or do not<br>
<astearns> ack fantasai<br>
<dael> emilio: Assuming we spec this feature I think it should be sufficiently well spec so browsers and impl can do something consistent.<br>
<TabAtkins> masonfreed: I'll make it easy: if the spec says "here's some colors, do what you want with them", I'll formally object to it. ^_^<br>
<bradk> Seems like dark-color, secondary-dark-color, light-color, secondary-light-color would work better<br>
<dael> fantasai: I think I would go with saying spec shouldn't mandate use of color and instead say it's a hint. If we're switching to a mode of form control with a lot of author controls we can mandate. There is a desire for authors to influence without changing render at a fundemental level.<br>
<TabAtkins> bradk: That doesn't work for Chrome's checkboxes vs everyone else's checkboxes.<br>
<TabAtkins> bradk: That's what I meant by "cannot use semantic roles, must use functional roles"<br>
<gregwhitworth> q+<br>
<dael> fantasai: Main concern should be how do we get enough contrast. Some checkmarks use fg and some bg. Need to make sure we can get enough contrast. Having examples which are here's how it's used in some browsers is good, but you're using native controls and accent color should be a hint that says I'd like to use this accent color and please use it meaningfully. But shouldn't define meaningful<br>
<dael> astearns: So you think dial back on non-normative text of what you should do with accent color<br>
<gregwhitworth> q-<br>
<dael> fantasai: I don't think we should have should or must requirement<br>
<dael> astearns: It's all non-normative. So you're okay with spec as-is?<br>
<dael> fantasai: I'm fine with it being examples<br>
<dael> masonfreed: All non-normative examples<br>
<dael> myles: WE said difference is today with non-normative vs deleting the examples. What's the functional difference between the two<br>
<astearns> https://github.com/mfreed7/accent-color/blob/master/proposal.md#per-control-guidance<br>
<dael> masonfreed: Functionally means every impl can do own thing and may be completely different. Chrome will impl the way they want. If we delete all the text. It will just be a rough desc and no guidance as to how to use it.<br>
<TabAtkins> And I"ll strongly object to a version fo the spec without guidance on using the colors<br>
<iank_> Unrelated to current topic - I've added a comment to the overflow model issue: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-697691447<br>
<dael> astearns: Back to original issue, should interop be a goal? non-normative examples will likely get better interop. Removing is more likely for non-interop<br>
<TabAtkins> No guidance = browser-specific, so this is a prefixed property, not a real property.<br>
<emilio> TabAtkins++<br>
<gregwhitworth> emilio: you're confusing me bud<br>
<gregwhitworth> TabAtkins: agreed<br>
<dael> fantasai: I think the section labeled non-normative is written with normative language. It needs to say this is how it could be done but it could be done in a different way.<br>
<emilio> gregwhitworth: if we specify the property, we should specify what it does<br>
<emilio> gregwhitworth: (that's what I said when I last spoke)<br>
<TabAtkins> If someone doesn't want the property *at all*, say that; trying to water down the requirements by removing guidance doesn't do the job.<br>
<dael> astearns: My way of thought is here's an example where if form control looks like this here's what it should do. If it looks different do what you want. But if you have something liket his should is appropriate<br>
<emilio> gregwhitworth: That is regardless of my concerns about implementability in Gecko / WebKit<br>
<dael> fantasai: In this case might want 2 examples. If it looks like this here's what changes and if it looks like that here's what else would change. So you can say your form control doesn't have to look exactly like that<br>
<emilio> gregwhitworth: But I think we decided a bit ago that debating implementability was specifically a non-goal of this issues<br>
<dael> astearns: Can we resolve to say this non-normative section is way we want to proceed?<br>
<emilio> this issue*<br>
<dael> astearns: Would anyone object to keep with advice on impl?<br>
<dael> fantasai: Don't want as is, but fine with a bunch of examples<br>
<dael> myles: Need resolutions for non-normative text?<br>
<emilio> gregwhitworth: So I think I'm not contradicting myself, but maybe I'm wrong :))<br>
<dael> masonfreed: Looking for next steps<br>
<dael> fantasai: Happy to give more specific feedback. We can resolve on the normative<br>
<dael> astearns: This issue is about non-normative<br>
<dael> astearns: myles do you object to keeping non-normative? Want more time?<br>
<TabAtkins> I would like this to wait for the OpenUI talk; this 40min discussion did very little. :(<br>
<dael> myles: We're kind of out of time<br>
<dael> masonfreed: Can I get more specific feedback on the issue?<br>
<TabAtkins> Let's not talk about this again until there's a focused topic on it<br>
<masonfreed> Thanks!<br>
<dael> astearns: Anyone with specific concerns please put them in the issue and we'll do this first thing 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/5480#issuecomment-697703725 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 September 2020 17:02:54 UTC