W3C home > Mailing lists > Public > www-svg@w3.org > September 2010

Re: Embedding SVG - need help

From: Jeff Schiller <codedread@gmail.com>
Date: Tue, 14 Sep 2010 11:46:49 -0700
Message-ID: <AANLkTikfPnj0Rq4fagY4CWLEHAr06VXn5KNfa8_Bkd62@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-svg <www-svg@w3.org>

This was not necessarily directed at Mozilla.  What I really just want to
understand is the reference rendering for all cases so I see if I can help
fix WebKit's svg-as-img implementation so that it can be interoperable with
the other browsers.


On Tue, Sep 14, 2010 at 11:35 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 9/14/10 11:12 AM, Jeff Schiller wrote:
>> Argh,
>> http://codedread.com/browser-tests/svg-image/html.html
>> Sorry!
> Note that the difference between <object>/<embed>/<img>and <iframe> in the
> first row there is purposeful in Gecko: we use the specified width/height,
> if it's in pixels, for <iframe>s, because iframe intrinsic sizes do not
> depend on the size of the <svg>, unlike the other cases. So for an <iframe>
> its size is completely specified in the parent document and has nothing to
> do with the size of the contained content, which is sized independently.
> For the other three elements, the sizing works just like it would with the
> <svg> inlined into the parent document, or at least that's the goal.
> The scrollbars in the second row are just there because it's a subdocument
> with the content overflowing the bounds of its frame.  The fourth row
> doesn't have them, because in that case the <svg> doesn't overflow, and
> since it has overflow:hidden itself it keeps the circle from overflowing too
> (the <circle> overflows the <svg> in that row).
> Are you expecting the second and fourth rows to render the same way that
> the first and third ones do, by the way?  If so, why?
> -Boris
Received on Tuesday, 14 September 2010 18:47:36 UTC

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