- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 6 Jan 2010 23:49:58 -0600
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: "robert@ocallahan.org O'Callahan" <robert@ocallahan.org>, Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
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? ~TJ
Received on Thursday, 7 January 2010 05:50:34 UTC