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

Re: Text selector [was Re: breaking overflow]

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 6 Jan 2010 23:06:36 -0800
Cc: "robert@ocallahan.org O'Callahan" <robert@ocallahan.org>, Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
Message-Id: <DDC705F9-72E1-47FC-A833-CF0045A3E033@gmail.com>
To: Tab Atkins Jr. <jackalmage@gmail.com>

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.
 

Received on Thursday, 7 January 2010 07:07:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:23 GMT