W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [css3-images] Impl feedback requested - detached elements in element()

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 28 Apr 2011 21:04:41 -0700
Message-ID: <BANLkTinGhQOtVwdAf-MoESwk+1dfC9ohuA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style list <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>
On Thu, Apr 28, 2011 at 6:42 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/28/11 9:20 PM, Tab Atkins Jr. wrote:
>>
>> Hixie was recently tweaking the HTML side of this (you need a
>> mechanism to refer to the detached elements, since Selectors can't
>> target them), and was curious why I excluded other replaced elements
>> like<iframe>.  I don't have a very good answer to this question, so I
>> wanted to see what reasoning there was in Gecko to not allow other
>> detached replaced elements to be used.
>
> In Gecko, detached iframe's can't be rendered at all.  The data structures
> that compute style data and create a box tree are only allowed to exist when
> the iframe itself has a box.

Maciej brought up the good point that an SVG <img> needs to be
processed in basically the same way as an <iframe> does.  Is there
just a special exception for this that <iframe>s don't share?


>> (The best I've got so far is that all the data necessary to display
>> img/video/canvas is present automatically, as part of the elements'
>> natures, so it's easy to present that data via element() even if the
>> element's not in the DOM.
>
> Precisely.
>
>> However, an<iframe>  needs to actually do
>> layout on its contents to be displayed; this *can* be done without a
>> surrounding document.
>
> In Gecko at the moment it cannot.

Cool, thanks.

~TJ
Received on Friday, 29 April 2011 04:05:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT