- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 29 Jan 2015 11:11:21 -0800
- To: Florian Rivoal <florian@rivoal.net>
- Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Thu, Jan 29, 2015 at 3:25 AM, Florian Rivoal <florian@rivoal.net> wrote: > 2 + 3 could probably be worked around by having the UA workout your color palette from the various controls you've styled, and derive the full list of colors it needs from that. But in that case, why not provide that directly? > > @controls { > saturated-light-color: <color>+; > saturated-dark-color: <color>+; > neutral-light-color: <color>+; > neutral-dark-color: <color>+; > preferred-scheme: light-on-dark | dark-on-light; > } > > Or something along these lines. I am not a designer, so I am not sure what's the best way to label the components of a palette, but you get the idea. The UA could pick from the list for the relevant aspects of its controls, and generate additional or intermediate colors as needed from there. > > When it comes to fonts, by a similar logic, rather than giving the fonts based on building blocks, you could give them by intent: title-font, text-body-font... Yes, I think this is a better approach for this kind of thing. It lets UAs continue to innovate in form control UI, while letting anything imaginable integrate into the page. It's basically a set of UA-defined variables, just using a syntax that doesn't clash with custom properties. ~TJ
Received on Thursday, 29 January 2015 19:12:15 UTC