W3C home > Mailing lists > Public > www-svg@w3.org > February 2012

Re: display:none and mixed SVG and HTML

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 2 Feb 2012 07:02:05 -0800
Message-ID: <CAAWBYDDUaMmhsKQSfdKCBHC2_6gRcoTWxWVtmNf9zbJ0EWSfQw@mail.gmail.com>
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

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.

Received on Thursday, 2 February 2012 15:10:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:27 UTC