Re: Text selector [was Re: breaking overflow]

On Jan 6, 2010, at 7:22 AM, Boris Zbarsky wrote:

> Unless you actually mean to run some algorithm quite different from the CSS whitespace collapsing algorithm but that happens to sort of look like it to a first approximation?

I was imagining some lighter-weight pre-processing of white space, making it as similar to the CSS whitespace collapsing algorithm as it could be at that stage of the game.

On Jan 6, 2010, at 7:29 AM, Boris Zbarsky wrote:

> On 1/6/10 10:22 AM, Boris Zbarsky wrote:
>> For example:
>> 
>> <p>
>> This is <span></span> text
>> </p>
>> 
>> I assume that you would want the first textnode to claim to have a
>> trailing space and the second textnode to claim to have a leading space
>> even though after CSS whitespace collapsing there is in fact only one
>> space in the example above between "is" and "text"?
> 
> And furthermore, it sounds like you'd expect the first textnode to claim to have a leading space even though after CSS whitespace collapsing in the above example there is in fact no space there?  Note that deciding that there is no space there involves information that is not present in any of the textnodes per se.
> 
> As far as that goes, how, if at all, would you expect your whitespace-collapsing thing to behave on this example:
> 
>  <div>
>    This is <div></div> text
>  </div>
> 
> Would it give the same results as with the <span> example above?  If not, why not?  If yes, what results?

I see your point about the white-space collapsing (examples always help, with me). 

In both these examples, this would matter mostly if you were trying to match text that had a leading or trailing space, such as ::text(" This") or ::text("is ") or ::text(" text") or ::text("xt "). Or some variation in which at least one white space character is required on one or both ends. Right?

As an edge case, we'd of course have to resolve what to do about that. For the uses I envisaged, this would be pretty rare, and the utility of being able to pre-collapse before testing the pattern outweighs the need to avoid dealing with that case altogether, IMO.

So let's try to see what would work best. First, in the case of the span, we have an empty inline element. Except that we don't really know that its inline, because other styles have not been resolved (and I presume we do not want to do complete style resolution twice for each element), so the DIV and SPAN really need to be treated equally. The purpose of its inclusion in the markup is unknown, but according to what I said before [1], it would divide the text in twain, and you cannot match text across it. Perhaps the author even inserted the span in order to prevent the text from matching the CSS rule.

So, given that the interrupting element is already limiting the way matching works, I don't have a problem adding further stipulations to what happens in that case. And I say, let the white space on either side of the interrupting element stay (collapsed to a single space as if the span was not empty) for the purposes of matching. That way, if an author really wanted a pseudo-box around it with something like ::text("is "), then he could get it. Then when full styling was applied, it would be to something like this:

 <div>This <text>is </text><div></div> text</div>

I would go ahead an treat the leading and trailing spaces of the main element the same way. If the author had ::text("\sThis"), then it is because he wants to include that white space at the beginning. So let him, and fully style the result:

 <div><text> This</text> is <div></div> text</div>

I think it is well and good of you to point out flaws or unresolved details in the proposal, as we all should for all proposals. But I don't think the whole thing needs to be thrown out just because all the details weren't resolved to everyone's satisfaction in the first few e-mails.


[1] http://lists.w3.org/Archives/Public/www-style/2010Jan/0027.html
Note that the points in that post are still open to debate. Perhaps it would be better to discard empty nodes and let text match on both sides?