Re: Text selector [was Re: breaking overflow]

On Jan 3, 2010, at 9:53 AM, Tab Atkins Jr. wrote:

> On Sun, Jan 3, 2010 at 11:16 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Jan 3, 2010, at 6:58 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>> On Sun, Jan 3, 2010 at 1:49 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>>> 
>>>> Well that's why I suggested that it be limited to individual text nodes,
>>>> not
>>>> to text that crossed into (or were broken by) other elements. Even with
>>>> that
>>>> limitation, it would still be powerful and very useful (especially if you
>>>> could use regular expressions).
>>> 
>>> Ah, okay.  That makes it relatively simple to deal with, then.
>>> There's still some cases you have to handle, though - how would the
>>> following display?
>>> 
>>> <p>foo bar baz</p>
>>> p { color: black; }
>>> p::text("foo") { color: red; }
>>> p::text("foo bar") { color: blue; }
>>> p::text("bar baz") { color: green; }
>>> 
>>> That's one simple nesting, and one non-trivial overlap.
>> 
>> Yeah, interesting. I would expect a granular overriding, later rules
>> replacing ranges of earlier rules, if you get my drift. Somewhat like if it
>> was broken up like this:
>> 
>> <p><text string="foo">foo</text><text string=" "> </text><text
>> string="bar">bar</text><text string=" baz"> baz</text></p>
>> 
>> So the first rule would turn the "foo" text red. The second rule would turn
>> that "foo", it's following space, and the "bar" blue. The third rule would
>> turn the "bar" and the " baz" green. So you end up with:
>> 
>> "foo": blue
>> "bar baz": green
> 
> That's also what I would expect - that it essentially cascades on
> individual characters.  

Right. Individual glyphs.

> If the order of the rules were reversed, we'd
> end up with "foo" being red, "bar" being blue, and "baz" being green,
> right?

Yes.

> And I assume that this still follows normal cascading rules, so that,
> frex, ".class::text('foo') { color: red; } p::text('foo') { color:
> blue; }" would end up with red "foo" strings, since the class selector
> is higher precedence than the element selector, even though the
> element-selector-using rule comes later.

Yes.

> I also assume that it operates on all descendant text nodes (though
> still not crossing element boundaries), so that the following two are
> both matched by p::text('bar'):
> 
> <p>foo bar baz</p>
> <p>foo <i>bar</i> baz</p>
> 
> But this isn't:
> 
> <p>foo b<i>ar b</i>az</p>
> 
> Because there are no text nodes containing "bar".

Right. That is how I was imagining it. 

> I also assume that it doesn't care about implementation details of
> text nodes, such as the fact that in HTML5 right now I believe that
> continuous runs of text can sometimes be placed in separate text
> nodes.

You lost me there. I am not familiar with the HTML5 feature you describe. But your assumptions sounds reasonable on its face. 

I think HTML entities should probably be converted to Unicode before comparing, but I don't feel strongly about that.

>>> If ::text() operates on the DOM, it will miss the linebreaks, which
>>> will subsequently get turned into spaces for display.  To make this
>>> work you'd need a full regexp so you can select all whitespace.
>> 
>> That would be pretty basic regexp, and yes, please. But even without it you
>> _could_ still select an escaped linebreak (though I agree it would be
>> yucky).
> 
> Yeah, a whitespace regexp is just /\s/, super simple.

\s, yes. In vbscript (or when using the RegExp constructor in JavaScript) you can just type "\s", which I think would be better for this CSS selector. An occasional escaped quote is easier to read than lots of forward- and back-slashes. Escaped backslashes would be pretty ugly still ("\\\\"), but those are less likely to commonly appear in prose.

> 
>> OK; I vote for both too. So now we just need a CSS4 Selectors module, and
>> some implementations of that and CSS3 Text.
> 
> Sounds good to me.
> 
> ~TJ