- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 11 Jul 2010 10:27:47 -0700
- To: Eduard Pascual <herenvardo@gmail.com>
- Cc: Andrés Sanhueza <peroyomaslists@gmail.com>, www-style@w3.org
On Sun, Jul 11, 2010 at 4:23 AM, Eduard Pascual <herenvardo@gmail.com> wrote: > On Sun, Jul 11, 2010 at 6:27 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> [...] >> The problem is dealing with overlaps. For example, given this code: >> >> <b>foo</b><i>bar</i><b>baz</b><i>qux</i> >> >> And these selectors: >> >> ::wrap(b,b) { color: blue; } >> ::wrap(i,i) { color: red; } >> >> What color is each word? > > If my understanding of your ::wrap() idea is correct, then 'foo' and > 'qux' should be blue, 'bar' and 'baz' should be red. The reasoning > behind this is rather simple: CSS already has a well-defined mechanism > to handle property "conflicts" (ie: multiple declarations setting the > same property of the same object to incompatible values): most > specific wins, and then last declaration wins among specificity tied > declarations. > > Both selectors have the same specificity, so last declaration wins. That doesn't actually address the overlap problem. Yes, *after* you've somehow resolved how to treat overlaps, then specificity and the cascade work like normal. This is how the HTML will look after creating the pseudo-elements in the naive way: <::wrap(b,b)><b>foo</b><::wrap(i,i)><i>bar</i></::wrap(b,b)><::wrap(b,b)><b>baz</b></::wrap(i,i)><::wrap(i,i)><i>qux</::wrap(i,i)></::wrap(b,b)> The pseudoelements are misnested! Now it's unclear which tag is innermost in the overlap areas. Is the <::wrap(i,i)> element started before the <i>bar</i> implicitly closed and reopened around the </::wrap(b,b)> tag? That might mean that <::wrap(i,i)> is the innermost pseudo for <i>bar</i>, but the outermost for <b>baz</b>, which would create a different rendering than what you described (the elements would alternate blue and red). Or are the <::wrap(b,b)> pseudos created first, and then the later <::wrap(i,i)> pseudos "steal" the relevant elements from them, so that each element is only wrapped by a single <::wrap()> pseudo at a time? That also produces a different rendering than what you described (only "foo" would be blue, the rest would be red). These choices also affect how the next case is handled. >> I haven't yet solved this problem in a way that makes me happy, unfortunately. > > What does it take to make you happy? Personally, I have quite enough > with things being well-defined and predictable (nearly an utopia in > the web world), and that's what CSS Cascade gives. So, CSS Cascade > makes me happy :P > > Sure, there will be cases where the result of applying Cascade won't > be what the author intended. But then the author has several tools at > his/her disposal, such as swapping the order of selectors, adding > redundant stuff to the selector that increases the specificity, using > more fine-grained selectors to match more specific stuff, etc. As I've hopefully outlined above, the problem is precisely that it's *not* well-defined right now, nor is it predictable. There are multiple possible ways to handle overlaps, and it all gets resolved at a level above the cascade. >> Further problems to ponder: >> >> <b>foo</b><i>bar</i><b>baz</b> >> ::wrap(b,b) { color: blue; } >> ::wrap(i,b) { color: red; } > > 'foo' and 'baz' => blue; 'bar' => red. That one makes sense, since the <::wrap(i,b)> can correctly nest inside the <::wrap(b,b)> pseudo. But would your answer change if the order of the rules were reversed? A "nesting" approach to assigning these would say no, but a "stealing" approach would. >> <b>foo<i>bar</i>baz</b> >> ::wrap(b) { color: blue; } >> ::wrap(i) { color: red; } > > 'foo' => blue; 'bar' and 'baz' => red. I believe this one is the least ambiguous, but it's still affected by the choices you make to handle the previous cases. I don't think ::wraps at a higher level in the tree should have any affect on ::wraps affecting a lower level - they should only interact when the pseudos are conflicting as siblings. > In all these examples, I don't think we can unambiguosly determine > what an author might be attempting, but we can easily determine how > would the cascade apply. > > Is it worth to break the cascading rules to deal with corner cases > where we won't even be sure to be addressing correctly? Again, resolving the issues I'm talking about takes place at a level higher than the cascade. *First* you figure out how the pseudos get applied to the element-tree, *then* you cascade based on that modified structure. ~TJ
Received on Sunday, 11 July 2010 17:28:40 UTC