Re: Text selector [was Re: breaking overflow]

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.  If the order of the rules were reversed, we'd
end up with "foo" being red, "bar" being blue, and "baz" being green,
right?

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.

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

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.

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

> 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

Received on Sunday, 3 January 2010 17:53:51 UTC