On 22 February 2010 01:18, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 2/21/10 7:11 PM, Dean Edwards wrote: >> >> Why not just extend :empty to include <input> with no value? > > Because that's not backwards-compatible and in fact violates the current CSS > spec? > >> It reads nicely: >> >> input[required]:empty:after { >> content: "This value is required"; >> color: red; >> } > > 1) :after is not defined for replaced elements (which <input> is). > Conforming CSS2.1 user agents do a variety of things here, ranging from not > rendering such content at all to making it a sibling of the thing being > styled instead of a child.
Fair enough. Ignore the :after example. > 2) input[required]:empty is defined to match any input which has an > attribute named "required" and no kids in the DOM. It does NOT match an > input which has kids in the DOM. > > So today, input[required]:empty would match: > > <input required value="This is some value"> > > in an HTML document and would not match the perfectly doable > > <input required="required" value="This is some value"> > And some random text, too > </input> > > in an XHTML document. > > Unless this is in fact a proposal to completely redefine how :empty matching > works in some backwards-incompatible way? Is there evidence that this won't > break existing consumers? > Yes, I'm suggesting redefining how :empty works. For elements that cannot have children it could mean having no content. e.g. An <input> with no value or an <img> with no src. It gets around the need for a new :placeholder pseudo-class: input[placeholder]:empty { color: red; } There is a small chance that it could break some pages I guess. If people are using *:empty than it may start matching some <input> elements. I always wanted a pseudo-class that could match <input> with no value. Extending :empty is probably a bad idea but something like :no-value would be useful. -dean