Re: [csswg-drafts] [css-ui] Should interoperability be a goal for the `accent-color` spec? (#5480)

As far as defining a specification, option "A" takes into account what browsers are doing today and have done in the past, but we can't really account for what they will do in the future. After all, who expected Chrome to one day reverse its colors?

Another issue with this specification is that it very specifically uses the text "browsers" at the moment, and this seems to me to remove some of the power of CSS across platforms. Consider, if you will, that this specification could be used on a device with a limited color output. During device setup, the device asks a user to pick an accent color. That color is used where the device deems appropriate to maintain usability. Consider perhaps a device that meets a functional need with a 4 or 16 color display and a long shelf life. The device has the ability to interpret form elements, but no ability to set a background color -- perhaps a clear display. In the case of a checkbox, the one accent color chosen could end up being either the color of the checkbox or the color of the checkmark, but not both, so we wouldn't be able to force a foreground and background for it, or even a "primary" and "secondary" for it -- just a primary.

If we want to restrict this specification to browsers, we can, but I think that would be missing out on an opportunity. If we were to think of the specification more generically while still allowing it to give the guidance needed to provide power to authors, then we almost certainly can't use "A".

Using "B" may take away the focus on interoperability, but UAs aren't made to be completely interoperable for display anyway when using default controls. The goal of this specification seems to be to add flavor to default controls, not ensure consistency in display. And it says nothing of what to do with those form controls when I go to print the webpage. Maybe the accent color isn't something that should ever appear on paper for legibility (like a bright yellow), but makes complete sense on a monitor.

This is where "C", @fantasai 's proposal could also come in handy -- rather than specify a color and say "Do this" (A) or a color and say "Do what you will" (B), it says "This is what we'd like." (C) and allows the hinting to take place so that the UA can render for media as appropriate.

The idea at heart here I think is that we can already beat UAs into submission by specifying foreground and background colors, but then we lose styling such as gradients and shadows and shapes. An "accent color" lets the UA do what it needs to do to preserve the user experience, but gives authors control over "theme hinting" or "style hinting" rather than styling.

And that's the problem, isn't it? This is potentially an extremely powerful property:value pair that can change the entire feel of a page that has several form elements on it, and at some point it will probably get extended to more than form elements. If we allow the browser to take "C" as a hint, and then want other elements on our pages to use the color decisions that the browser has made so that the page will not clash with the form, then we'll have to add a "color: accent-color;" at some point so that the browser knows to use whatever it applied to the forms to other things on the page.

Another issue is that we are only able to limit our thinking to form elements as they exist today, but who knows which additional form elements may get added in the future? 

"A" is too limiting in how explicit it is.
"B" isn't harnessing the power that this specification can truly give.
"C" is very powerful, but the amount of additional scope that it could introduce is possibly staggering. I think it would need a bit of refinement to be truly useful, including a "should" here and there.

I think we should take "C" and run with it, change the wording to be more all-encompassing to explore UAs besides browsers, and express this spec as the intention of an author to add a hint to the existing UI rather than to take complete control of it. 

"Interoperability" in this case could mean that:
1) *An* accent color SHOULD be applied if at all possible.
2) The vendors make a pledge that the form elements will continue to be visually usable despite specification of an accent color. 
3) Elements will continue to act as they already do, so if you check a box and it reverses the colors, authors continue to see this behavior.
4) Accent colors will not affect existing "flavor styling" of a form control -- if a control has rounded corners, a slight shadow in one corner, and a gradient background, that form control will retain all of those things, with the accent color applied in such a way that the vendor sees fit to preserve their existing user experience.

"Interoperability" in this case should NOT mean that:
1) The form control looks the same on every device.
2) The accent color from the author is applied in such a way that it breaks the display of the form (no white-on-white or black-on-black).
3) Vendors disregard the user experience and author's intention in using accent-color in favor of their own styling. You know who you are. Your users know who you are and are already using your product.

-- 
GitHub Notification of comment by x-Jake-x
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-702118461 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 1 October 2020 13:01:39 UTC