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

Tab Atkins Jr. wrote:
>> 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.

You're assuming the error message is shown in the website content area 
to start with.  That doesn't seem like an assumption we want to be making.

>>  What's the use case?
> 
> For content, or in general?

For content.

> 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.

Which leads to immediate internationalization issues, right?

> 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.

What if the error messages are not in the page?

>  Unlike form elements, where control of the UI can actually be a
> security issue, this should be perfectly safe to expose.

I haven't looked at the set of errors HTML5 defines to see whether this 
is the case.  That said, with the exception of file inputs there are no 
security issue for form controls.  There _are_ issues involving the 
native look of the controls, the fact that CSS can't describe their 
rendering very well, etc.

Note that there _might_ in fact be security issues with putting active 
content (rather implied by your XBL2 mentions) in the error messages. 
Again, I haven't looked into the details of the error messages yet, but 
letting websites inject scripted browser UI is a red flag for me.

> 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.

Sure; clicking on the error message flashes the input.  Much like the 
Inspect feature in Firebug, say.

> 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.

I don't see why not.

> At the bare minimum the ::error pseudoelement is needed so that
> authors can display:none it and use scripting to display their own
> messages.

Suppressing display of the error message altogether seems like something 
the HTML spec should be defining, no?

> 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.

Yes; hence my supposition that some browsers might opt to not put this 
UI within the page.  However you proposal would require them to do so.

-Boris

Received on Tuesday, 25 August 2009 19:53:09 UTC