Re: [css3-ui]? Proposal for ::error pseudoelement

On Tue, Aug 25, 2009 at 1:58 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote:
> Tab Atkins Jr. wrote:
>> There's currently no way to change the display of the the error
>> message, but Lachlan reported yesterday that they have received a lot
>> of feedback that authors want to control this.  The display of the
>> Opera error messages is pretty simple - it's just a text string in a
>> box - so this should be fairly easy to spec up.
>>
>> I propose adding an ::error pseudoelement to the CSS3 UI spec.  You
>> can style the error message for a specific element by attaching it to
>> that element, like "input[type=email]::error {}".
>
> How would this work if the error message is NOT "just a text string in a
> box"?

The hope is that the browser exposes it as just a text string in a box
for now, and any further elaborations can instead be done through
shadow methods like XBL2, when that gets supported.

It's also possible that browsers can provide more elaborate displays,
and once an appropriate mechanism exists to allow authors to specify
the same, the default display would just be a default value for that.

If the above sentence was difficult to parse, I mean something like
the browser just using a default XBL2 binding, which can be overridden
by the author.

>> With one exception, the ::error pseudoelement is treated exactly like
>> an abspos box inserted into the markup via scripting.  It accepts all
>> CSS properties.
>
> Including "content"?

Yes.

> What's the use case?

For content, or in general?

For content, paired with a more elaborate :invalid() syntax like I
proposed a few hours ago on the list, you could write your own
validity messages by targeting particular input/error combinations.
Like this:

input[type=number]:invalid(range-underflow)::error {
  content: "Further embiggening is required.";
}

In general, the use-case is that authors want to be able to style the
display of the error messages to match the general spirit of the page.
 Unlike form elements, where control of the UI can actually be a
security issue, this should be perfectly safe to expose.

> In any case, this seems needlessly constraining in terms of the UI a browser
> can present (e.g. what you just described would prevent a single
> notification bar that one can then use to look at all the errors).

Indeed, it would prevent that.  I don't think that the browser has
enough information to actually present that sort of error display,
though.  If you have the error messages physically disconnected from
the input, you need a way to unambiguously connect the message to the
input.  Libraries like the jQuery validate plugin can do this because
they can use a completely custom error message, but as a
browser-default that wouldn't be possible.

> Given that this is fundamentally browser UI, I don't think we should be
> specifying it in that level of detail.

At the bare minimum the ::error pseudoelement is needed so that
authors can display:none it and use scripting to display their own
messages.  I believe that the browser UI can be usefully constrained
sufficiently to allow full control to the page author, however.
Browser-generated UI within a page should really be limited as much as
possible - it always makes us authors unhappy.

~TJ

Received on Tuesday, 25 August 2009 19:19:02 UTC