Re: display:none and mixed SVG and HTML

On Thu, Feb 2, 2012 at 4:59 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/2/12 5:13 AM, Tab Atkins Jr. wrote:
>> For two, "<p style=display:none><img id=foo></p>" will still draw the
>> image when you reference it with the element() function from CSS.
>> (This is currently only implemented in Firefox, as I specced it after
>> they revealed an experimental implementation.)  It's not perfect quite
>> yet - for example, if the image was an animated GIF, only the first
>> frame will show in the above example (while it would be animated if
>> the image was visible).  That can be considered a bug, though.  This
>> is basically identical to the situation you're talking about, though -
>> if, instead of<img>, I had<svg><pattern /></svg>, I should be able
>> to reference it just the same.
>
> There are some significant differences.  Rendering an image does not require
> style computation, while rendering SVG does.  The requirement that replacing
> <img> there with <svg> render the SVG would require that browsers compute
> styles on display:none subtrees, no?

If and only if the elements are referenced, so this doesn't defeat the
general optimization where browsers don't create boxes for
display:none subtrees.


2012/2/2 Boris Zbarsky <bzbarsky@mit.edu>:
> On 2/2/12 7:08 AM, Alex Danilo wrote:
>>
>> The tree is the document model.
>>
>> Hence it is all available for reference regardless of any display="none"
>> on an ancestor. Rendering is orthogonal to the document model.
>
>
> Let me be more explicit, actually.  There are cases in which rendering CSS
> content that's a descendant of a display:none subtree would in fact violate
> the CSS spec (e.g. anything involving quotes or counters).
>
> So CSS absolutely requires that there be no box creation for things in
> display:none subtrees and that precludes rendering of any non-replaced
> elements in such subtrees.
>
> The question is how to reconcile that with SVG's completely different
> rendering model and requirements.  It's not that hard to just do SVG on its
> own, but problems start arising when rendering it inside CSS boxes.  That's
> what Brian's mail is about.  Now can people please just think through the
> actual implications of the disagreements between the two spec instead of
> knee-jerking?

No, CSS does *not* require that no boxes are generated in these cases.
 Strictly, it requires that counters don't set/reset/increment, quotes
don't start/end nesting, transitions don't start, and animations don't
run.  This can be accomplished by not generating boxes, but also just
by explicitly shutting those properties down.

(That said, we'll need to run animations in the subtree when it's referenced.)

~TJ

Received on Thursday, 2 February 2012 13:31:27 UTC