W3C home > Mailing lists > Public > www-style@w3.org > March 2016

Re: [css-forms][css-ui] Styling native components, a proposal

From: Ilya Streltsyn <streltsyn111@gmail.com>
Date: Wed, 30 Mar 2016 09:58:59 +0000
Message-ID: <CADwhjA9cP1iqeK+YYU-FwAZNnXfOBobygsRWE1LfaffsygTW+Q@mail.gmail.com>
To: www-style@w3.org
What if what Amelia proposes could be possible without breaking the
existing web? What if we could change the error handling rules (applying
the rules if only one selecror in the selector list is valid) only for the
given rule/block, not for the whole CSS?

I see two following options:

1) New functional pseudo-class reusing the pattert of :matches() from CSS
Selectors 4, much like the original Lea's proposal, but generic, not just
for form controls. E.g.:

      :supports-any(::-webkit-one-selector, ::-moz-other-selector) {
         /* styles applied to any of the selectors listed, even if some of
them are invalid */

2) New @-rule block with different parsing rules inside it only, e.g.:

     @experimental-features {
         /* code here is parsed as per Amelia's proposal */

         ::-webkit-one-selector, ::-moz-other-selector {
            /* styles are applied to any of the selectors in the list, if
it's supported */

    /* code here is parsed as ususal */

I believe that such a feature, in any form, would be useful not only for
native controls and UI elements styling, but in many other scenarios, too,
and we won't need to break the compatibility with existing hacks.
Unfortunately, neither approach (as well as original Lea's proposal) will
fix our today's problem with vendor-specific selectors redundancy, but it
can help make working with non-standard features (including experimenting
with different approaches to create a universal form styling model) easier
in the future. The pseudo-class approach might be a bit easier to implement.

What about the idea of special CSS construct in which the valid parts of
invalid selector list could work without changing the general CSS rules at

Ilya Streltsyn
Received on Thursday, 31 March 2016 09:11:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC