Re: [css-ui] Styling Form Controls

> On 31 Jan 2015, at 08:45, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Fri, Jan 30, 2015 at 1:25 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
>> You're also not giving the UA any information on spacing, on
>> border thickness and radius, etc. Which in the OSX controls,
>> they might not use (and just focus on colors and fonts), but
>> in the Android case they might want to apply.
> 
> I actually highly doubt they'd want to.  Android is currently on a
> Material Design kick, which specifies a bunch of that stuff pretty
> precisely.  Integrating a page's color into it is pretty easy, but
> changing other aspects of the design probably wouldn't fly.

I have a hard time seeing how you could supply spacing information
when you don't know how things are going to be combined together.

Colors and fonts are important to match the design of the page, but
spacing needs to be based on (or at least take into account) the
design of the control itself, so I don't see why/how an author would
specify them.

If you're trying to match the look and feel of your page this
precisely, it doesn't sound like you're trying to have your controls
look native anymore, and you should probably be starting to look into
web components or similar, and building your form control yourself.

>> E.g. the Android UA could take the border color and thickness
>> from the button style, but apply it as collapsed borders across
>> the top/middle in the Cancel / Set pair and ignore the border
>> radius. Or apply the button's border radius to the dialog box
>> and not the buttons themselves.
>> 
>> The point is, we're giving the UA's theme designer a prototype
>> of an input field and a button and a selected item, and their
>> job is to extrapolate the rest of the controls to match that
>> scheme, in whatever way makes sense. We might need one or two
>> more prototypes, but controls are not endlessly variant: they
>> are designed to look as a set, so the characteristics of one
>> control are ported to the rest.
>> 
>> Basically, to implement this, a UA chrome designer would need
>> to get handed a bunch of different settings and figure out how
>> they would extrapolate if s/he were to design the full set of
>> controls from that starting point. And then work with the
>> implementers to generalize those rules, using whatever info
>> was deemed extrapolatable and ignoring the rest.

The types of controls are not infinitely variant, but the ways
they can be combined is. Depending on how things are composed,
the background color of a button might want to match the
background color of text fields, or the foreground color, or
be some other color altogether. And the answer might be different
for several buttons in the same control, as they serve different roles.

Yes, the UA will have to extrapolate from the inputs the authors
are giving, but this seems significantly easier to do correctly
if we provide it with a semantic palette, rather than a structural
one.

 - Florian

Received on Saturday, 7 February 2015 22:53:21 UTC