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

Re: Text selector [was Re: breaking overflow]

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 6 Jan 2010 09:10:26 +1300
Message-ID: <11e306601001051210q7a868c09u4fffbe5fc0d8af88@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Bobby Jack <bobbykjack@yahoo.co.uk>, Boris Zbarsky <bzbarsky@mit.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On Wed, Jan 6, 2010 at 7:51 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

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

Of course *some* examples can be handled unambiguously. Ambiguity is always
about the edge cases.

How does your proposed spec handle
p::text('ABAB') { font-size:150%; }
<p>ABABABAB</p>

or
p::text('ABCD') { color:red; }
p::text('CDEF') { color:blue; }
<p>ABCDEF</p>

?

Hard to implement? It should be much simpler to implement than
> '::first-line', because we aren't crossng 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.
>

It's potentially more complicated than first-line, partly because of the
problems above, also because you want to have all properties work with it,
up to and including 'display'. But first-line itself is already not one of
the easier CSS features to implement.

There will also be significant performance penalties for using ::text. Apart
from regexp matching costs, dynamic text changes will require rematching.

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

That's a nice goal but I don't think we should expect to always reach it.


> > 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.
>

I think a good way to address your use case would be to extend the "content"
property as applied to elements, so we can replace the contents of an
element with children with different styles. Right now CSS3 supports, for
example,
h1 { content: url(welcome.png) " to my " url(page.png); font:...; }
With creative use of :before and :after you can have
h1:before { content: "Welcome"; font:...; }
h1 { content: " to my "; font:...; }
h1:after { content: "Page"; font:...; }
We could extend this to support an unlimited number of different child
pseudo-elements.

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.
>

I think all these examples deserve semantic markup.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
Received on Tuesday, 5 January 2010 20:10:59 GMT

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