W3C home > Mailing lists > Public > www-style@w3.org > January 2015

[css-ui] Styling Form Controls

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 24 Jan 2015 02:11:35 -0500
Message-ID: <54C345A7.20307@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
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.

~fantasai
Received on Saturday, 24 January 2015 07:12:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:56 UTC