Styling composite elements

CSS is a wonderful and powerful language. But there is one thing it does
not currently address: styling elements that are composited of
subcomponents.

By subcomponents I do not mean child elements, but rather complicated
elements that has clearly identifiable subparts in common renderings.
Many, but not all of the examples are interactive.

Here is a list of the features in HTML (that I could find) that can be
assumed to have composite elements:
* Scrollbars, both the main viewport ones, overflow caused ones and the
ones belonging to frames
* The audio and video elements, when set to show playback controls
* Date and time input elements
* File upload elements
* The progress element
* The meter element
* The details element
* The drop down menu of size one select elements

I believe that it may be a good idea to allow CSS to define how these
components should be rendered. However, many of the listed examples may
be platform specific.

I will now elaborate on the subcomponents in the given examples:

Scrollbars

Always composited of two buttons at the end, a scroll track and a
variable size scroll bar. Per axis that is. Some scrollbars allow for 2D
scrolling. Some applications (Such as word processors) also add
additional elements, such as page up and down buttons.

Audio/video playback controls

May contain playlist navigation buttons (prev, next, etc...), media
controll buttons (play, pause, play/pause, stop, step frame, etc...), a
seekbar (possibly with several layered bars to status like show media
buffering and playback progress as well as traditionally having a
dragable seek head), a volume control (popularly a triangle that masks a
bar that indicates loudness by how long the masked bar is) + mute
button, fullscreen toggle button, closed caption controls as well as
additional controls.

Date and time input elements

Commonly shows a calendar. Sometimes the calendar is hidden beneath a
dropdown menu. The calendar commonly has a header that allows for month
and year selection.

File upload elements

Commonly implemented as a textfield for a local file path with a browse
button afterwards.

Progress element

A HTML 5 addition that draws a bar in a box that indicates how far a
process has progressed. The bar is normally anchored to the left edge of
the box.

It may sometimes show an indication that progress is being made, but it
is indeterminable how far the task has progressed. The indicator is
commonly either a diagonal stripe fill of the entire bar or a bouncing,
non anchored small bar.

Meter element

Another HTML 5 addition. It lacks a common control on most platforms, so
browser vendors may get creative here.

One possible rendering would be a bar in a box, but with marked zones in
the box corresponding to the set high, low, min, max and optimum values.

A more elaborate rendering could be to do it in the style of a
circularly bent bar, possibly with a needle. Like in car display panels.

Details element

Yet another HTML 5 addition. This element allows content to be
selectively collapsed (think display: none) with a small summary displayed.

Most of the content here is real child elements. But the actual matter
of how the user indicates to open or close the details view is left
unspecified. The example illustration shows that a clickable arrow could
be used as a toggle button.

Drop down menus

A textfield style control that shows a list of options, a normal box
model box that is hidden unless the user "opens" the drop down, usually
by clicking on the closed control. Selecting an option typically closes
the list.

The control shows the selected value in the textfield when the list is
closed. The control traditionally includes an arrow button aligned to
the right edge of the label of the selected value, this to indicate that
it is not a normal text field control.


CSS could potentially handle a lot of these cases by adding additional
pseudo elements to represent the various subcomponents. Some of these
elements may use pseudo classes, like active, disabled and so on.

The progress and meter elements are prime candidates for the attr()
syntax, since they could read the attribute values and compute
appropriate style values.

However, an issue that I do not know the answer to is how to let authors
work with what currently has been platform and/or application specific
parts of the rendering.

To refer to my examples, the set of possible controls for a media player
is huge and existing players have a big variation in which ones they
use, sometimes the same player might even select them based on the context!

How can CSS be enhanced to do to these cases to ensure consistent
rendering? And what of that should CSS do?

Received on Wednesday, 20 February 2013 14:02:00 UTC