Re: [css-ui] Styling Form Controls

On Fri, Jan 30, 2015 at 1:25 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 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

I think Florian means that devs will likely test their styles on only
a few inputs, with the potential for messing up the display of other
inputs, particularly when different OSes use the same styles in
different ways.  Even if an author tests all the widgets on a
particular OS, it's still possible for some widgets on other OSes to
get messed up.

(This is a general problem for all form-styling things, of course, and
needs to be accounted for explicitly in the design.)

>> 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.

The one on the right has two "scrolley-wheels". You can flick up or
down to have the numbers cycle; the numbers in the middle (between the
two cyan bars) are the current values.

> 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.

That's fine.  Text vs background, the most important distinction, is
captured in the set of names I gave, so you could do that.  It might
not match your design exactly (the input might select the "light"
variant of your magenta rather than "normal", for example), but it'll
be close, and probably okay.

> 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.

> 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.

Hm, okay. I could be convinced of this, with some more examples.
Let's start by taking screenshots of as many inputs in as many OSes as
possible, and collecting them somewhere.  I've started a css-forms
ideas doc in the repo, feel free to contribute more to it.

Received on Friday, 30 January 2015 23:46:29 UTC