Identifying text-only nodes with CSS

Floating ideas onto the CSS working group can be a frustrating experience, possibly almost as frustrating as seeing the same questions come up every few months! I think I may have made a mistake in terms of asking about this idea, by doing so within a thread about parent selectors.

Empty vs text-only

My original question was about how to differentiate a link that contains an image and a link that contains only text.

The scenario I had come across was identifying external links with this CSS 2.1 selector:

a[href^="http"] {...}

That CSS matches external links with have an href attribute that starts with http, but not internal links that have a path to the file, e.g. /folder/file.html.

I used that to add a small background image to external links as a visual hint that the link goes to another site. You can see this example on a news item on the UK Windsurfing site.

Screen shot of two external links, one text link and one image link, both with small icons to the right.

That worked fine (in Firefox, Safari & Opera), but as you can see it is applied to image-links as well as text links. That can lead to some strange effects if the image is floated (links given a red border):

Screen shot of several links outlined in red, the floated image-link has left the icon on the left on it's own.

There are several logical ways you might think you could select links that only contain text. For example, to apply the styles when:

You can apply the style to an image within a link (e.g. a[href^="http"] img {...}), but that is the exact opposite of what I want to do, which is only apply it to text links.

Unfortunately there does not seem to be a way to differentiate links based on what they contain.

Going up the tree

An inherent limitation of CSS selectors is that they cannot go 'up' the DOM tree. It is an often asked question on the www-style list since at least 1999, the last one I noted was this parent selector thread.

One of (if not the) main reason for the parent selector to be rejected is due to it creating performance issues. I can understand that, programmatically the browser would have to know every child element before it could start styling the parent. Boris Zbarsky stated previously on this topic:

Now consider parent/predecessor selectors in all their forms (:matches, parent combinators, etc). Let's take the parent combinator as a simple to analyze example. The condition for correctness on insertion in this case is: "If a node is inserted, and any node anywhere in the document matches the sequence of simple selectors on the left of a parent combinator, style needs to be recomputed on all nodes in the document." No comment on pageload performance.

I understand that (in a vague kind of way), and trust the source (someone who fixed one of the few bugs I found in Gecko!).

Unfortunately I seem to have gotten the text-node idea caught up with this selector that would not be good to implement.

Identifying text-only nodes

I haven't been able to find any other (CSS) methods to get the styling I would like, as you cannot style text within a link, so the link is the only element that will take the styling. If you open up the DOM inspector to see what you have to work with, you can see that there are text nodes:

A screen snippet of the DOM inpsector, showin several links, one with text in, and one with an image.

The [:empty](http://www.w3.org/TR/css3-selectors/#structural-pseudos#empty-pseudo) pseudo-selector is almost what I need, but it doesn't apply when there is text within the element.

I would propose a "text-node" or "text-only" pseudo class, so that this:

a:text-only {...}

Would apply to this:

<a href="#">link</a>

But not this:

<a href="#"><img src="#" alt="text" /></a>

Or this:

<a href="#">some <strong>other</strong> text</a>

Then all you would need to add styles to a text link to another site is: a[href^="http"]:text-only

The performance issues mean that the parent selector is unlikely to be implemented any time soon, which is the generalised version of what I would like. However, I don't see the same issue with this, it is something JavaScript has access to, but not CSS.

Unfortunately no one has replied to this either time I asked (1, 2).

It is quite frustrating, I'd actually rather get shot down than just silence. For the sake of the long term members and newbies alike, I'd suggest that the W3C make a start on Eric Meyer's suggestions for Working Group Outreach, a short-term item might be a www-style FAQ of common issues.

Technorati Tags: