Until now, I have completely ignored the :empty pseudo-element. A quick glance at the spec tells me that this might be a fairly handy feature for someone who has to populate a table with some dynamically-generated (tabular, of course) data, and wishes to highlight empty cells for whatever reason.

So I did a quick-and-dirty experiment. (Granted, the contents aren’t dynamically generated, but for this experiment, it matters little.)

Firefox 2.0.0.6/Mac handled this one with ease, albeit with a couple of minor rendering glitches; Safari 2.0.4 (419.3) blew it to pieces, styling every td as empty instead of just the empty ones. And the value of the very last cell, the number 12, is not within a p tag like the rest of the cells…

Veddy intrestink.

Here’s the selector string I’m using (with jQuery)

$("[@value='']:input:visible:enabled:first")

I agree that using on [@value=''] or [@src=''] makes more sense then the common-sense approach to :empty, although initially I was also a little thrown.

As for ‘img’ and ‘input’, it seems to me that an attribute selector checking their ‘src’ and ‘value’ properties respectively would suffice when you wanted to see if they were truly ‘empty’.

This pseudo-class seems primarily targeted at paragraphs and divs without text, as I see little in the way of other practical uses for it (perhaps anchors?).

<p></p>
and
<p> [spaces] </p>

are supposed to be equivalent, it seems to me that the browser could legitimately collapse the distinction b/t the two in the DOM model before applying the CSS styling. …Or I could be wrong on that – perhaps the spec says that one space is the same as twenty spaces, but any number of spaces is different then zero spaces…

head:empty

I agree that logic should rule what is affected and not.
Meaning that elements that render content on the page are NOT :empty, such as images and :s.

:empty elements are what the validator warns you about, I.E. elements that, possibly, contains only white-space nodes, comments or PI.
Not what is referred to as EMPTY elements in the spec.

As for allowing us to style replaced elements, I’m ambivalent, for many and sundry reasons.

This leads me to another issue: should we be grateful with browser vendors that they give us some little freedom there (with replaced elements)? I mean, do you think this is positive at all? —If you ask me, I think it is, I tend to alter the border and background of input‘s, for instance. What’s your opinion?

I think you are missing something, Nils. In the first part of the post, I’m talking about the body being inappropriately selected, as documented in the Bugzilla entry. In the second part, I’m talking about selection of empty elements that are DOM-empty but not render-empty, like images and inputs and such. I didn’t say anything about that appearance of the top-most tiny box on the test page, which is indeed the link element and (given that we accept HTML-empty elements are selected by :empty) should be seen, given the rest of the styles.

<object …></object> is matched.
<object …><param name=”foo” value=”bar”/></object> is not.

I also tend to agree with Ralph that the attributes wouldn’t be considered, therefore img elements would always be selected, as they have no child nodes.

Perhaps a new pseudo-class is needed for the situation you bring up where an img element’s data successfully loads or not. Something like nocontent? I guess there would be some overlap between empty and something like that, though.

This is a problem of context. The :empty statement applies to empty elements. As far as I know it doesn’t take into consideration their attributes, and frankly I see no reason to do so, even more since you can reference them directly with [attribute].