W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: :invalid

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 27 Sep 2010 15:32:44 -0700
Message-ID: <AANLkTi=bWPuxrRE4GaRgZxh_yu0AScx2Pkr4yPcccbKL@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Ryan Seddon <seddon.ryan@gmail.com>, Mounir Lamouri <mounir.lamouri@gmail.com>, www-style@w3.org
On Mon, Sep 27, 2010 at 11:55 AM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Fri, Sep 24, 2010 at 1:58 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> While we could try to come up with some set of selectors which can be
>> combined together to accomplish this set of rules, I think this has a
>> couple of problems. First of all it is somewhat inflexible. If we want
>> to change the above rules we might need to invent even more selectors.
>> Second, it makes it more cumbersome for authors to override the
>> default UA stylesheet since that stylesheet might be different in
>> different UAs.
> But the styling will be different as well in different UAs, right?
> Mozilla currently adds a fuzzy red border, but others might change the
> background color, add a little X icon, or any number of other things.
> So even if we had a unified :invalid-ui selector, it wouldn't let you
> override the UI of some generic unknown browser by itself -- you'd
> still have to figure out what rules the browser has by default, so as
> to specifically override them.
> In most cases, in principle, we'd want all UAs' built-in stylesheets
> to be identical, so authors can override them reliably.  Here it seems
> like we're talking about UAs applying entirely different UI in ways
> that are visible to authors.  Surely that's an intrinsic
> interoperability problem no matter what we do.  (Not that I have any
> better solution to propose.)

Yeah, what goes into the selector is certainly also a problem, though
a orthogonal one.

One solution might be to just wait and let UAs experiment with
different UIs and hope that they converge as developers come up with
UIs and borrow each others ideas.

Another solution is to tie these things to the 'binding' CSS property,
the way that HTML5 suggests for rendering of form controls and other
complex elements like <details>. That way pages could override all
styling using

input {
  binding: none;

This would drop all default rendering associated with <input>
elements. So checkboxes/radiobuttons/textfields/etc wouldn't have OS
native look-and-feel but instead be wholly controlled by CSS. Along
with that it would also drop default styling for invalid controls.

This is somewhat inflexible, but might be an ok solution.

/ Jonas
Received on Monday, 27 September 2010 22:39:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:48 UTC