W3C home > Mailing lists > Public > www-style@w3.org > January 2010

Re: Text selector [was Re: breaking overflow]

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 5 Jan 2010 10:51:14 -0800
Cc: Boris Zbarsky <bzbarsky@mit.edu>, robert@ocallahan.org, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-Id: <65DD4AA4-6249-4244-8CD2-48A5F86D3E2B@gmail.com>
To: Bobby Jack <bobbykjack@yahoo.co.uk>

On Jan 5, 2010, at 2:09 AM, Bobby Jack wrote:

> --- On Tue, 1/5/10, Robert O'Callahan <robert@ocallahan.org> wrote:
>> For one thing, it makes style dependent on details of the content in
>> a way that seems rather fragile (e.g., "I just fixed a
>> typo, why did my styles go away?").
> 
> Agree. It also makes translation a pain (i.e. stylesheets need to be translated in addition to content)

The same could be said of the "content" property. The way I see it, if you are including more than 3 or 4 words in the matching pattern, you are probably abusing it, and deserve what you get. The places I would find it most useful would typically be just one or a few words, or would be regular expressions that are not necessarily tied to exact words.

> and, I fear, could lead to situations in which it's very difficult to determine which styles are applied. 

Welcome to the world of Cascading Style Sheets. Nothing new there. But with free and easily available tools, it is child's play to determine from a browser (using Web Inspector in Safari, Firebug in Firefox, and Developer Tools (I think it's called) in IE) what styles are applied and where they are coming from.

>> It's going to be hard to spec, hard to
>> implement, and potentially confusing to use.
> 
> And, given that,

I do not think that is a given. 

Hard to spec? We've given some samples that show it can be unambiguous. 

Hard to implement? It should be much simpler to implement than '::first-line', because we aren't crossing element boundaries to any extent beyond what any other element does. For the regular expressions, UAs should be able to use the regexp engines already built in for JavaScript/EcmaScript.

Confusing to use? I don't think so. Most of the discussion so far has been about nodes, but from an HTML author's point of view, it basically boils down to "you can now put a pseudo-element around any pattern of text that does not have a tag in it (other than a comment tag, in my version)." That pattern can be a simple text literal, or can be something fancier for those more familiar with grep/regexp patterns. Where two patterns overlap in a run of text, normal specificity and precedence rules take place on the overlapping pieces.

> I think we need to ensure there are some strong use cases before considering this any further. The common use case seems to be, for example, a heading consisting of several words, each of which needs to be styled independently.

That was only one use case, but is hardly "the common use case". I find places where I want to use something like this in virtually every major project I work on.

> As suggested, this can currently be achieved using additional span elements, although this is certainly not ideal - how would one plan for this at the structural level?

A CSS author should not have to (and often cannot) add HTML markup for purely presentational effect.

> Having said that, I think this particular use case can be handled with a more structural, less content-dependent selector such as ::word(n) (which I don't think exists anywhere).

I don't think that would help that case that much, and would make it even more brittle.

> 
> Are there any other use cases?

Sure, tons.

Here is something that could put a box around the entire text node within a paragraph (almost like ::inside that has been proposed before):

p::text(".*") { border: 1px solid black; }

Here was something I showed earlier:

::text("Example \d: *\n") {
  display: block;
  padding: .5em;
  margin: 1 em 0;
  border: 1px solid #999;
  background-color: #eee;
}

Here is a way to highlight the company name whenever it appears in a paragraph or list item:

p::text("ACME"), li::text("ACME") { background-color: yellow; }

Here is a way to use a mono-spaced font for numbers:

p::text("\d+") { font-family: "Courier New", Courier, monospace; }

Here is a way to turn a greater-than glyph into a picture of a hand pointing right:

::text(">") {
    height:20px; width:40px; 
    background-image:url(right-pointing-hand.png); 
    display:inline-block; 
    color: transparent;
}

Here is a way to quickly strike out your old phone number throughout the site, until you've had a chance to update it, or in case you suspect that it is still on some of the hundreds of pages you don't control but provide CSS files for:

::text("\(555\) 555-5555") { text-decoration: line-through; }

I could go on and on, but use your imagination.



Received on Tuesday, 5 January 2010 18:51:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:23 GMT