Re: Styling composite elements

We should be addressing all of these.

I understand that OS controls are those the user is most likely to understand, and the most accessible since they are exposed lower level. Without allowing the authors to style these properly, and consistently, we force them to fake the same result with JS and markup, and then everyone loses.

I agree with Henrick 100%. This is a CSS problem.

Difficulty should not be a reason to avoid getting something standardised and written into a spec.

On 20 Feb 2013, at 18:08, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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 21:31:05 UTC