- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 2 Feb 2012 07:02:05 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-svg@w3.org
On Thu, Feb 2, 2012 at 6:28 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 2/2/12 9:24 AM, Tab Atkins Jr. wrote: >> This is not hard, actually. The counter-* properties, for example, >> actually just need to not affect any counters started outside the >> display:none subtree. This means that a display:none subtree should >> probably form an isolation boundary for counters, so counter-increment >> can't affect a counter from outside. > > There is no such concept of isolation boundary in CSS right now, right? So > it would need to be created and added. Yes, but it's simple. Right now, whenever an element has counter-increment, you consult some data structure holding all the current counter scopes you can see (or walk the tree upwards, which is equivalent). display:none will wipe these scopes in the element and subtree (alternately, abort the walk). counter-reset needs a tiny bit more effort, as doing a reset *on* a display:none element must only have effects within the element and its subtree, and must not disturb a same-name scope originating from a previous sibling. Quotes are similar - in a display:none subtree, just reset the nesting level to 0. The following sibling (assuming it's not display:none as well) gets the normal nesting level, unaffected by the display:none subtree. Both of these could be done either on *every* display:none element, or you could track whether or not a display:none subtree is created, and only trigger them when you move from outside to inside (so, further uses of display:none inside the subtree don't do anything). >> I agree that changes are likely required, but they're fairly trivial. > > I don't think they will be trivial to spec, and they will be even less > trivial to implement. > > And that wouldn't address the other issues with animations/transitions, or > with other future things the CSSWG adds while thinking that there is an > invariant that display:none things don't affect CSS rendering. > > At some point you may want to step back and think about how much complexity > you really want to add to support what's fundamentally an edge case and > whether a simpler solution in spec terms might be better. The other alternative that's still CSS friendly is to define some property that makes elements ignore display:none somehow and continue to generate boxes and have rendering effects. This property would be set appropriately on svg|* in the UA stylesheet. Such elements would continue to not be displayed, but would act normally with respect to counters, quotes, animations, etc. ~TJ
Received on Thursday, 2 February 2012 15:10:30 UTC