Re: Text selector [was Re: breaking overflow]

On 1/3/10 8:42 PM, Brad Kemper wrote:
>> p::text("f") { color: blue; }
>> and the text contains the word "fluoride" in a font with an "fl"
>> ligature. In that case there are two characters, one glyph. Are you
>> saying that glyph should be either all blue or all not blue? Which one?
> Good question, which I don't know the answer to. I would think "not all
> blue". What do you suggest? Stick to character level, not glyph level?

Probably, yes.  That's what Gecko does for selections that only cover 
part of a ligature...

I'm not sure there's a perfect solution here.

>> What if "bar" is split over two adjacent textnodes in the DOM?
> Forgive my ignorance, but when does that happen?

Simple example #1:

<!DOCTYPE html>

Simple example #2:

<!DOCTYPE html>
   ba<!--comment, so the textnodes aren't even quite
   adjacent in the DOM-->r

Simple example #3:
<!DOCTYPE html>

(again, not even adjacent in the DOM; user-perceived as one word.

Simple example #4, equivalent to the above:

<!DOCTYPE html>

Example #5, that might depend on the exact parser algorithm used and 
might not ever lead to multiple textnodes in an HTML5 parser but I think 
does in some cases in existing parsers:

<!DOCTYPE html>

with an HTTP packet boundary between the 'a' and the 'r'.

Example #6, which depends on exact behavior still being hammered out in 
the HTML5 spec:

<!DOCTYPE html>
   document.write("ba"); document.write("r");

Example #7: editable content (designMode/contentEditable) can probably 
lead to random textnode boundaries as text is inserted, then removed, 
then edited, wrapped in tags, unwrapped from the tags, etc.  I don't 
think there's anything that specifies what the resulting DOM should look 
like on the individual textnode level yet.

> Can they be treated as one?

Probably yes.  The issue is deciding what cases to treat as one, in some 


Received on Monday, 4 January 2010 05:02:51 UTC