Re: [css-ui] Styling Form Controls

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: one for a button,
> and one for an input field, e.g.
> 
>  @control button {
>    <declaration-list>
>  }
> 
>  @control input {
>    <declaration-list>
>  }
> 
> plus the ability to style a selection, which could simply be
> 
>  input::selection {
>    <declaration-list>
>  }
> 
> You would be able to use styles for:
>  * font selection (css-fonts)
>  * text decoration (css-text-decor)
>  * text layout (css-text)
>  * backgrounds & drop-shadow (css-backgrounds)
>  * borders & padding (css-backgrounds)
>  * filters
>  * anything else we or a UA decides seems relevant
> 
> 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.
> 
> For example, a calendar widget might have the month, the year, some buttons
> to move them around, the ability to click into them and edit them directly,
> and a representation of the days of the month. The selected day is selected.
> Perhaps the buttons only show up on :hover or :focus -- the UA decides. But
> it knows that a button should be this particular shade of blue with that
> particular border-radius and drop-shadow. The calendar might be shown in the
> colors of the input field, and the selected day in the selection color, and
> in all ways it will match the way the input fields look in the rest of the
> page.
> 
> Now, the author can't decide, for example, the spacing between the year
> and the month name, or whether the button to change years has a solid
> arrow or a hollow arrow or a frilly one, and she can't decide that there
> should be a black solid half-border between the month and the day field
> below it with 5px spacing. But the calendar will look like it belongs to
> the page, and the UA can come up with a different calendar layout when it
> ships one on a wide but short smart watch where the month and year are
> better placed on the side without breaking anything.

I have several reservations about this idea.

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.

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.

3) Depending on how these building blocks are composed, they should be styled differently. But as an author, you have no knowledge about how they are composed (and it varies across platforms anyway), neither do you have a selectors-like mechanism to style different bits differently depending on how they're structured.

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, and here is one from 
iOS not that long ago: http://i.stack.imgur.com/nu8Ts.png

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.

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

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

 - Florian

Received on Thursday, 29 January 2015 11:25:46 UTC