W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: Styling composite elements

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 20 Feb 2013 10:08:33 -0800
Message-ID: <CAAWBYDASQ8WDBa92=SU0zPwHbr-1TVOFnm3h4-J33JdJPJNvPQ@mail.gmail.com>
To: Henrik Andersson <henke@henke37.cjb.net>
Cc: www-style list <www-style@w3.org>
On Mon, Feb 18, 2013 at 6:57 PM, Henrik Andersson <henke@henke37.cjb.net> wrote:
> 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
[snip]
> 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?

You hit on the basic problem, and why this hasn't been addressed for
so many years - different browsers, on different platforms, can render
the same controls substantially differently.  In particular, mobile
browsers often have very different renderings for certain types of
input controls, such as <select>, date inputs, etc., which are
optimized for their small touch-based interface.  It's not obvious
what part of these should be exposed for styling, and how.  Somebody
needs to, at some point, work out these details, but the difficulty of
doing so (and coordinating with multiple desktop and mobile
implementations) has meant that nobody has wanted to do so yet. :/

Some of them, though, are fairly easy.  <details>, for example, is
standardizing on using a list marker to display the open/closed
indicator, and it appears that the actual show/hide behavior will be
implemented via Shadow DOM (to introduce an invisible wrapper around
the contents that can receive a display:none property).  <progress>
and <meter> are probably reasonably easy to expose, because there's no
interaction, just display.

~TJ
Received on Wednesday, 20 February 2013 18:09:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT