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

Re: Styling composite elements

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Wed, 20 Feb 2013 14:58:02 -0800
Message-ID: <CALRQH78+UU7yZR3yn9YUTCON_wG1+veyr5cx2-9F9a9UcE39Pg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Antony Kennedy <antony@silversquid.com>, www-style list <www-style@w3.org>
On Wed, Feb 20, 2013 at 1:50 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Feb 20, 2013 at 1:46 PM, Antony Kennedy <antony@silversquid.com> wrote:

>> If the standardised version of the select box had specific elements and behaviours, all written down in a specification then authors could predict those behaviours, and the pseudo-elements Henrick described would be predictably available. If the standardised version were enabled via CSS, then that is a lot less difficult to cope with? If it weren't enabled, the browser could do whatever it wanted.
> Have you seen what <select> elements do on mobile browsers, like
> Chrome on Android or the iOS browser?  It would be a terrible
> experience for the user if you could opt into a "normal" <select>.

It is true that different platforms render input elements differently.
But it is also true that all platforms are tend to represent them in
principle the same manner.
All UI platforms that are worth mentioning in this discussion have for
example <select> structured this way:
<select type=dropdown-list>

So we can expose this structure at least in form of pseudo-elements:

select::caption {....}
select::button {....}

-or something more generic/universal -

select {  style-set: my-select;  }

@set my-select {
   caption {...}
   button {...}

It is up to the platform to use these hints or not but they should be there.

This applies to all input elements. There are not that many of them actually.

Andrew Fedoniouk.

Received on Wednesday, 20 February 2013 22:58:34 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:24 UTC