W3C home > Mailing lists > Public > www-svg@w3.org > March 2013

Re: SVGSVGElement.toDataURL()

From: Jeremie Patonnier <jeremie.patonnier@gmail.com>
Date: Tue, 12 Mar 2013 16:57:20 +0100
Message-ID: <CAEi838mDxp5h=nmMGhHVMp-Au1XH3=12gsG4umqh_SDYLnWiAg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-svg <www-svg@w3.org>
Hi


2013/3/12 Boris Zbarsky <bzbarsky@mit.edu>

> On 3/12/13 8:59 AM, Rick wrote:
>
>> On Mon, Mar 11, 2013 at 3:27 PM, Boris Zbarsky <bzbarsky@mit.edu
>> <mailto:bzbarsky@mit.edu>> wrote:
>>     It seems to me like the right way to handle SVG and HTML wanting to
>>     share some DOM bits that really don't belong on Element for whatever
>>     reason is to factor out all those bits onto an separate interface
>>     that both HTMLElement and SVGElement implement...
>>
>> If this can be done, it seems the best solution.
>>
>
> It can certainly be done.  It just requires identifying what that shared
> subset should be.
>

As an author, beyond DOM stuff (innerHTML, outerHTML, etc.) that deserve to
live in Element, I would love to see the following HTMLElement properties
to be shared between HTML and SVG:

   - title
   - lang
   - style (it seams to be already the case \o/)
   - hidden
   - dataset (which implied support for data-* attributes on SVG content)
   - draggable
   - dropzone
   - contextmenu (wich implied to support the menu element in the SVG
   namesapce as well as in the HTML namespace... I could understand that this
   would be possible only for SVG-in-HTML)

I doubt className can be harmonized but because classList is part of DOM4
on Element this will make thing smoother for authors (please, dont mess
with classList on animated class attribute)

Cheers
-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>
Received on Tuesday, 12 March 2013 15:58:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:41 UTC