Re: Text selector [was Re: breaking overflow]

On Mon, Jan 4, 2010 at 6:15 AM, James Hopkins <james@idreamincode.co.uk> wrote:
> In conclusion, it makes sense to me that all adjacent textnodes are treated
> as separate entities; that is ::text() is excluded from crossing adjacent
> textnode boundaries in order to match a single word. In contrast, the
> selector _should_ be able to cross one side of an element's boundary
> (start-tag or end-tag), so as to match an element's sibling textnode with
> any descendant textnodes (with no whitespace inbetween) of that element
> which appear in the document source (which successfully excludes example
> #4).

I really don't see how these two statements are consistent.  How is it
okay to treat adjacent text nodes as separate, but a text node
followed by an element containing a text node as together?

I also don't like basing anything on document source.  It's much
better to pay attention to the DOM.  I don't think CSS even has access
to the document source - it's a separate layer in applications, given
to the parser which then produces a DOM for other things to access.

As well, the example #5 makes *no* sense to treat as separate.  It's
together in the source, it's together in the display, it's only the
DOM that might have them separate, due to the vagaries of packets.
Making exceptions for these situations is no good.

Overall, we need to be *consistent*.  Having rules based sometimes on
source, sometimes on the DOM, sometimes treating adjacent nodes as
separate, and sometimes treating them as together, will just be
ridiculously confusing for authors, not to mention likely bug-ridden
in implementations.  The simplest rule that covers reasonable cases is
that it matches on the DOM, and adjacent text nodes are treated as
being together for the purpose of matching.  I still don't support
matching across element boundaries, as it will work in a non-intuitive
manner.  For example, the following code:

<p>foo <i>bar</i> baz</p>
p::text("foo b") { display: block; }

Would result in the following display:

foo
b
ar baz

Because the text pseudoelement would have to be broken up into two,
essentially producing a structure like this:

<p><text match="foo b">foo </text><i><text match="foo b">b</text>ar</i> baz</p>

(Alternatively the <text> could break the <i>, instead of being broken
by it.  That's even more non-intuitive, I think, and will cause the
exact same problems if the <i> was display:block instead.  You'd have
::text rules interacting non-locally with rules appearing elsewhere in
the document, in a manner that will be *supremely* confusing.)

Rather than deal with this sort of confusion, I think it's better to
just say that you can't cross element boundaries at all.  This will
still result in confusion sometimes (particularly when the text has an
otherwise-invisible <span> in it or the like), but it will be lesser,
and easier to understand.  (I think explaining the way pseudoelements
get broken up into multiple pieces and how that effects some
properties is much more difficult than explaining "all the text has to
be together in the element to match".)

This means that for Boris's examples, 1, 5, and 6 would match, 3 and 4
would not.  I'm not sure what I feel is best for 2 - I could go either
way, whichever seems more consistent.  7 is difficult, but it's going
to be difficult no matter what.  I guess I'm fine with just
recommending not applying ::text to a contentEditable piece, or
accepting that the results will be non-intuitive.  The main thing I'm
afraid of is text being wrapped in tags, then all the text being
deleted, but the tags still sticking around with no textual content.
That'd break a ::text selector without the user knowing what's wrong.
On the other hand, deleting that segment of text and retyping it would
fix it.  Shrug.

> As an aside, I believe it would also be beneficial to have the ability to
> include multiple strings in the same selector, something like ::text("foo
> bar", "test text").

Yeah, I can see the use for that.  I'd consider it necessary, in fact,
now that you mention it.

~TJ

Received on Monday, 4 January 2010 14:32:39 UTC