Re: SVGSVGElement.toDataURL()

HI


2013/3/11 Robin Berjon <robin@w3.org>

> On 11/03/2013 15:23 , Jeremie Patonnier wrote:
>
>> 2013/3/11 Robin Berjon <robin@w3.org <mailto:robin@w3.org>>
>>
>>     Or conversely, SVGElement could inherit from HTMLElement.
>>
>> Mmmh... I'm not sure about this for two reason :
>>
>>   * Whatever people said, SVG is not HTML, and SVG can be used
>>     standalone, wich mean having a requirement to implement part of HTML
>>     to support SVG is not necessarily a good idea for some people (I
>>     think about people writing Vector Drawing Software that could allow
>>     to use and manipulate the output DOM for example)
>>
>
> It's just an interface. Just because it has "HTML" in the name doesn't
> mean that it involves implementing part of HTML.
>

Ah right... that's where you see I'm not an implementor but a silly author
;) However, this naming could be confusing in many ways. Maybe it would be
wise to just define what is part of a common ground between technologie
involved in a browser and have a common interface that does not refere to
any specific language. Let's say WebElement or BrowserElement for instance?


>
>    * Having innerHTML inside "Element.idl" allow to imagine using it on
>>
>>     any XML content (MathML for instance) which will empowered users in
>>     many ways.
>>
>
> Two things:
>
>   • Other languages can inherit from HTMLElement too.
>   • Consistency empowers users.
>
> If you move innerHTML to Element, what happens to all the other useful
> things such as outerHTML, insertAdjacentHTML, dataset, hidden, style... ?
> HTMLElement is the basic unit that I'd expect all elements in a browser
> context to support.
>

Maybe HTMLElement is irrelevant and all of this should be pushed to
Element? (remember, silly author here :P)


> Conversely, placing it on Element means that it becomes available in
> contexts in which people don't normally see it, such as regular server DOM
> stuff. That strikes me as weird, and possibly problematic.
>

I agree that some part of HTMLElement are not relevant outside a browser
contexte, but FWIW, I think every API that make the DOM easier to
manipulate should be pushed to Element or at least to the DOM specification.


> I'm not saying that SVG is HTML, but at the very least in a browser
> context, even when standalone, it really should script in the same way.


In that case, that mean that there is a common ground between HTML and SVG
(and maybe other specs). So in that case, this common ground should be
specified outside both HTML and SVG spec. My humble opinion is that it is
at least the DOM spec but maybe there is a need for something in between.


> Libraries should Just Work. Developers shouldn't be surprised. Ideally SVG
> should inherit as much as possible, and only focus on defining the things
> that make it special.


I desperatly agreed on that (the author here, again :). However, it is not
because HTML DOM is the most known API that it means that that common
ground should be specified inside the HTML spec ;) Okay... maybe we can
postpone this to HTML 6 and SVG 3 :P

Is there a joined group or a task force for SVG and HTML as well as for CSS
and SVG with the FXTF? Maybe the Markup Task Force ?

-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>