Slightly ajar

Sounds like a good idea. Makes sense, too, when considering that CSS2 already deals with "word" sections with the "word-spacing" property.

Any reason why this could not still be added to CSS3 selectors? The spec appears to still be a "Working Draft"...or would additions just delay things even further?

Peter Gasston writes:

I'd like to see a parent selector;



div < .child {}



It would be really useful to style elements based on their children.

A parent selector, as suggested above, is the one thing I'm really missing in terms of selectors.

Parent selectors have been discussed and rejected several times on the CSS WG mailing list. I'd love to be able to link to a specific site that details the reasoning for its rejection, but currently I don't know of one...either way, I doesn't look like it's going to happen any time soon.

Peter Gasston writes:

The reason seems to be that browsers apply styles as they render, so they implement each element, followed by its children; a parent selector depends on the state of the child being known first, so it would be out of the normal render order.



I can see the logic in this argument, but Javascript applies styles after the initial render, and I wonder if it wouldn't be a huge imposition for browsers to do that too.



Sorry for the huge gaps in my comment above, BTW!

Brian LePore writes:

While the word selector would be useful, I don't know if I agree with your specific example.



With support for it, in one manner or another, in every major browser, save Firefox, shouldn't we assume that browsers will have support for downloadable fonts? Your h1 could be styled with that font, and then set a word spacing between the two words to be the width of the image, and then set a background image on the h1 in the appropriate place?



Then again, that would fail once decided to rename the blog to include a third word...



What would a nth-word selected word do to the word-spacing attribute? Ignore it? Apply it to both sides?

Olly writes:

You're right, there's no reason why a CSS4 module couldn't be started now, but I think efforts would be better spent getting some more of the CSS3 (let alone 2.1) modules out the door.

@Peter: Yeah, I would think your JS example proves that it shouldn't be too big a deal...

@Brian: I would think nth-word would just be like putting opening and closing tags directly around the specified word(s). Thus the word spacing would still exist around that tag.

Also, I hope someone at my.opera.com is looking into this weird excessive line break bug. It's pretty annoying.

Peter Gasston writes:

What we need is for a browser maker to look into the mechanics of a parent selector and perhaps implement it on a trial basis; does anybody here know how to get in touch with someone who works for a browser maker?

first-word would be nice. Maybe first-sentence, but definition of it would be fuzzy.

I don't see use for nth-word though. It would get unpredictable in dynamic text. If you want something really cutting edge (and CPU heavy) go straight for regular expressions

p/foo(bar)/ {color:red;}
==
<p>foo<span >bar</span></p>

I agree that there's a lot of desire (and use cases) for parent selector. Implementation is going to be tricky — it requires completely reversed approach to selector matching, but that sounds just about right for some distant-future CSS spec

Another sort-of related issue that keeps coming to www-style list is browser-bug selector.

has-bug(float-double-margin) p.floated {margin:50px;}

or a bit more generic:

http://ben-ward.co.uk/journal/css3_required_properties/
(not quite selector, but closely related)

@Peter

Actually, since Opera already supports :only and :only-of-type, it already has to go back to apply a style. See this test I made. It first displays the span with a red background, then loads many many paragraphs, then changes the span to green when it discovers it's the only element of that type. So doesn't that mean it has to go against the render order already?

Edit: Admittedly that's still within the same parent element, so perhaps that's what makes it less of an issue.

I really only miss parent selector. That's it.

Anonymous writes:

Word/letter selectors and parent selectors are nice ideas.

Trouble with word/letter selectors (I'll refer to them as just word selectors) is that words would likely have to become elements at some point, otherwise if the word styles are stored somewhere else we'll need something other than the DOM. This would cost in terms of memory and time, though not greatly.

If we keep the DOM, what would they do to add the styles? Wrap spans around words? What properties would these spans take? If the content changes they must be adjusted - how does the browser know which spans were added and which existed already? It would have to keep track of what it changed. What if you are using techniques like switching style sheets? The whole thing starts to get messy and I believe modifying the DOM like this should be avoided for now, because style and content would no longer be completely separated.

But, let's say these problems were solved, then from an algorithmic point of view, if word selectors were implemented, they might be better as a new selector class, as the logic would probably end up quite different to other selectors.

I'm not saying it's not possible or worthwhile, but it would sure take a lot of effort.

If you really want effects like this you don't have to wait for w3c or the browser makers. Using a decent javascript toolkit like mootools, jQuery, prototype or yui would do it fairly easily and buy you a lot more besides.

I'd like to see the selectors generally extended to use regular expressions.
i.e. search for class, id, attributes by regular expression. My reasoning is that anyone who can understand selector syntax should be able to understand regular expressions, and for example attribute selectors are a bit limited.

Lee Jordan writes:

Parent selectors would allow us to build functional navigational elements without Javascript. Why is that a good thing?

Accessibility compliance for one, but we have a situation here with CSS that it can do half the job, but to do the full job on expanding nav lists, it needs a second language to complete the task. CSS can hide nav items, but without :hover or a nasty little class="active" and thus a page reload or DOM hack, we can't open up the menus without JS or without forsaking HTML structure with unneeded DIV's to to get the effect working.

JeromeLapointe writes:

I'd like to see... to the very least, something like ":novalue", something that would be to the "input type=text" the equivalent to the ":checked" to the "input type=checkbox".

Not something that checks the attribute named value... something that is actually aware of the value at all time... even after someone types something in the field... that that to the very minimum lets you know if it is empty.