Re: Text selector [was Re: breaking overflow]

On Jan 5, 2010, at 12:10 PM, "Robert O'Callahan"  
<robert@ocallahan.org> wrote:

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

Sure. Doesn't mean it has to be more difficult to spec than anything  
else.

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

More or less like this:

var paragraphs = document.getElementsByTagName("p");
for(var p=0; p<paragraphs.length; p++){
	i= paragraphs[p].innerHTML
	paragraphs[p].innerHTML = i.replace(/(ABAB)/g,"<span style='font-size: 
150%'>$1<"+"/span>")
	
}

Except it wouldn't be spans, it'd be pseudo-boxes. (For simplicity, I  
left out the part that would only have it work on tagless runs of  
text, since your example was just text inside the P.)

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

Tab and I resolved this to our own general satisfacion, I thought, in  
the earlier part of the thread. "AB" would be red and "CDEF" would be  
blue.

> 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

...which don't seem all that problematic...

> , also because you want to have all properties work with it, up to  
> and including 'display'.

I still don't see any reason why the box(es) created by the ::text()  
pseudo-element should behave any different from the box created by,  
say, a SPAN. Both could have a 'display' value applied to them, and  
both could interact with other pseudo-elements (e.g. ::first-line) in  
exactly the same way.

> But first-line itself is already not one of the easier CSS features  
> to implement.

Granted. That's why I am trying to avoid those extra complications.

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

I could live with that, if it's as fast as JavaScript regexp  
processing. Simple regexp and literals run pretty fast, don't they?  
And dynamic element changes also require rematching. I don't think I'd  
want it to run the matching every second as I typed into editable  
HTML. It still seems pretty managable.

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

It should be a factor that guides our decisions to some extent. I am  
far from convinced that the proposal is unreachable in this case.

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

As I said, that is but a single use case out of many.

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

No way. Talk about idealistic goals that cant be reached! I should  
have the content/markup author tell the UA where all the numbers are,  
just because I want to style them differently? I should insist on a  
separate class for every phone number that matches a particular one  
that I might be interested in styling? What HTML tag do I use for a  
">" that represents another level of breadcrumbs? These are all things  
that I cannot reasonably expect to be in the markup, but that I may  
want to style. There are already many places where authors are adding  
extra spans in the HTML just to get a presentational effect, and I  
think we should provide ways to alleviate that where we can.