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

Re: Text selector [was Re: breaking overflow]

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 3 Jan 2010 11:53:19 -0600
Message-ID: <dd0fbad1001030953h7d899ab5u1086a86188284407@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: www-style list <www-style@w3.org>
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,

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

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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:32 UTC