Text selector [was Re: breaking overflow]

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

>
>>> Don't line breaks get normalized to spaces during the
>>> whitespace-collapsing step?
>>> In that case this code still wouldn't
>>> work, as it'd miss those linebreaks.
>>
>> That sounds like like you just refuted your own argument. If a line  
>> break is
>> turned into a space in the DOM, and that space is selected with the
>> pseudo-element and not displayed, then what's the problem?
>
> Whitespace isn't collapsed in the DOM, it's collapsed as a display
> effect only.  (CRLFs get normalized during parsing, but that's it.)

OK, I wasn't aware of 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).

>
>>> Something like ::text certainly has some
>>> uses I can think of,
>>
>> I find myself often wishing for it, especially when styling HTML  
>> that I
>> can't edit myself.
>
> Indeed, I have many cases where it would be useful, where I'm
> currently just adding completely meaningless spans around arbitrary
> groups of text because of how I want it to display.  For example, the
> heading at http://webportal.igofigure.com/webportal has four pretty
> unnecessary inline elements to generate the desired effect for the
> text.
>
>>> but I'd rather solve the issue of whitespace
>>> handling more directly.
>>
>> Well, sure, I'd like both too. But if I were to choose which I  
>> wanted more,
>> it'd be the more powerful thing that fulfill do both roles if need  
>> be.
>
> It can't fulfill both roles, though - it's not capable of duplicating
> the other values for white-space-collapse.

Just the two values of that which I care about most.

>  I'd rather not decide
> which one I want more - I want them all.  ^_^

OK; I vote for both too. So now we just need a CSS4 Selectors module,  
and some implementations of that and CSS3 Text.

Received on Sunday, 3 January 2010 17:17:24 UTC