Re: Text selector [was Re: breaking overflow]

On Jan 6, 2010, at 9:49 PM, Tab Atkins Jr. wrote:

> On Wed, Jan 6, 2010 at 9:38 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Jan 6, 2010, at 4:01 PM, Tab Atkins Jr. wrote:
>>>> I don't think it is any more confusing than most other CSS specs, where a clear understanding of the spec helps one understand what happens with edge cases.
>>> 
>>> Very few people have a clear understanding of the spec, and the
>>> details of how implied elements nest and break each other is
>>> non-trivial to understand.
>> 
>> Right. I didn't mean the entire CSS spec as a whole. I meant, pick almost any module, and there will be some things that are less intuitive, that give rise to blog entries, tutorials, etc.
>> 
>> I think that what I am imagining is pretty intuitive (inside my head anyway). If it could be explained well and precisely, and the finer details worked out, I think it would be mostly intuitive, and there would just be some uncommon edge cases that might require explaining. Such as the white-space stuff that Robert O' brought up. I want the edge cases to be as intuitive as possible, but even more I want the more general cases to be intuitive and easy to use. I don't think we are that far off from these goals.
> 
> Right, so one of the major problems is the misnested boxes that can
> occur.  We want to allow nested ::text matches, but misnested matches
> are a problem.  Dealing with them naively results in the unintuitive
> and undesirable behavior I pointed out before.  How does my suggestion
> for most-powerful-matched-first sound for fixing this, and making
> previously matched ::text pseudos count as element boundaries just
> like a real element when matching later/less powerful ::text pseudos?

I have to read it again in the morning with fresher eyes. My initial reaction to the first part was good, but then I started getting lost, mostly due to my attention span at this time of day. But, how about this for a simple way of saying what I think we both intuit to be write in the example:

Follow normal cascading rules for each matched character, as though you were creating individual pseudo-boxes for each character, but adjacent character boxes that have the same pseudo-boxes because of the same rule get merged together into one box after all the text of the element has been otherwise resolved.

I'll re-read your details again in the morning to see if this made more sense of it or less, or if I am still missing something, but I wanted to throw it out there this way while I was still awake.