Re: [css-ui] Styling Form Controls

On 01/29/2015 06:25 AM, Florian Rivoal wrote:
> On 24 Jan 2015, at 08:11, fantasai <fantasai.lists@inkedblade.net> wrote:
>>
>> There's been a lot of desire to have stronger ability to style form controls,
>> but the tricky thing here has been balancing
>>   A) the ability of authors to style the form control exactly how they want
>>   B) the ability of the UA to match OS conventions, adapt to novel devices,
>>      and improve usability over time
>>
>> I think I have an idea.
>>
>> The idea is this: we have a handful of styleable prototypes: [...]
>>
>> Most form controls, even a calendar widget or clock, are a combination of
>> these three primitives in some way. If the UA is given the styling for
>> these three primitives, and perhaps one or two more it can figure out how
>> to style the rest.
>
> 1) Authors would almost certainly be setting up things by trial and error on whatever the trendy device is these days until it looked good, but this gives no guarantee that the result would be equality good in other UAs. It could possibly even be unreadable. Say the UA you tweaked the control on has a non-changeable dark background, so you but a light foreground color that fits within your palette, but some other UA has a non changeable light background. You'd either push UAs to all imitate each-other, or to ignore the author-provided styles.

There's a limited amount of trial-and-error they can do,
because the styles are not form-control-specific, they
are page-specific. For example, the author can't change
the padding on buttons just on the calendar widget.
   * either the UA makes it unchangeable or
   * it affects all buttons for all form controls

> 2) I think you underestimate the amount of basic controls and
> custom controls that make up form inputs. If we only provide
> ways to style some of them, you'll have inconsistencies
> between the ones where you did change the color / font /whathaveyou,
> and those where you didn't.

Most of them stylistically match the basic scheme even if they're not
composed of the same basic controls.

> Here is a pair of time pickers from android:
https://cdn-images.xda-developers.com/direct/2/9/7/7/3/4/0/timepicker.png,

It's hard to tell without more context, but for the one on the right,
the clock face and the digital readout are @input colors, the highlighted
bits are the highlight color, the Done button is the button styling,
and the shaded area around the clock face is the same color as the
button background.

I need more context for the one on the right, show me an input field
in the same scheme.

> and here is one from iOS not that long ago:
>  http://i.stack.imgur.com/nu8Ts.png

The black area is the button color; a very light transparency of it
can be the glass color. The rollers are the input colors.

> The clock hand color, the clock face background color or the
> overall background color in the first android picker, the
> little bars in the second android picker, the translucent
> glass color or frame color in the iOS one, all look like
> things that wouldn't be addressed by your proposal.

They are, if you extrapolate. You are taking things too literally.

> However...
>
> 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;
> }

The problem with this is you're not describing the roles that
the colors play in the UI, you're describing what types of
colors are available. What if my color scheme is light magenta
with bright blue text and horizontal rules in dark gray? No
OS designer will come up with that, it's too extreme for an OS,
but a web page might.

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.

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.

~fantasai

Received on Friday, 30 January 2015 21:25:45 UTC