W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] SVG extensions to <canvas>

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Mon, 4 May 2009 16:26:55 +0200
Message-ID: <65307430905040726j39750f30ke57affaf66c2a846@mail.gmail.com>
2009/5/4 Oliver Hunt <oliver at apple.com>:
>
> On May 4, 2009, at 6:38 AM, Anne van Kesteren wrote:
>
>> On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>> As far as I can tell this doesn't require any changes to HTML5, since the
>>> same applies here as applies to a regular <img>, right?
>>
>> Maybe you misunderstood, but the request was not about <img> referencing
>> SVG, but passing an SVGSVGElement object directly to drawImage() and
>> friends.
>
> I had certainly misunderstood :D
>
> I'm not sure this is a great idea, as like all other elements the size of an
> SVGSVGElement may be influenced by where it is in the DOM, which makes it
> unclear how drawImage(SVGSVGElement) should work, eg. should it use the
> "natural" size of the element, the size of the element according to its
> current location in the dom (and what happens if it's not in the dom?), or
> what?

If HTMLImgElement uses the natural size, then SVGSVGElement should as
well. The CSS properties set on <img> at its natural position in the
DOM don't matter, so it is not really an issue.

> I believe drawImage should be left as it currently is (basically taking
> objects that are intrinsically bitmap-ish), and if we were to add an ability
> to draw an svg element into the canvas it should really be an simple
> drawElement(Element) method instead, after all, why restrict it it just to
> SVG elements?

<svg> has an intrinsic size (like <video>,<img>, and
<embed>/<object>), the other have not.

> --Oliver
>

Giovanni
Received on Monday, 4 May 2009 07:26:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:48 UTC