RE: SVG cloning elements from HTML5

I'd remind to keep in mind that there may well be SVG documents that are NOT on the publicly available internet that one needs to also consider when making a standard.  Just because you cannot access the svg file via a public URL doesn’t mean it has no merit.

Thomas Smailus, Ph.D.  P.E.
Boeing Information Technology
-----Original Message-----
From: Tab Atkins Jr. [] 
Sent: Thursday, June 19, 2014 10:22
To: Dr. Olaf Hoffmann
Cc: www-svg
Subject: Re: SVG cloning elements from HTML5

On Thu, Jun 19, 2014 at 10:08 AM, Dr. Olaf Hoffmann <> wrote:
> Tab Atkins Jr.:
>> I said "browsers", not "viewers".  I don't care very much about the 
>> community of viewers, as their userbase is infinitesimal compared to 
>> the userbase of browsers.  This is a pretty standard treatment; for 
>> example, non-browser implementations of CSS have very little 
>> influence on CSS specifications.  (Not zero, but very small.)
> What do you call a browser and what a viewer - what is the difference 
> for you, if both provide a visual presentation of a document like SVG 
> or (X)HTML?

For the purpose of my definitions, a "browser" is any web-viewing program with sufficient users that the features they implement are plausibly depended on by a significant percentage of websites.  The browsers are Firefox, IE, Safari, Chrome, and Opera. (For most purposes, Opera and Chrome are the same thing, as they share their Blink core.)  There are other web browsing programs, but their userbase is small enough that whatever arbitrary things they do are almost certainly not being relied on by the web.  (Pre-Blink Opera is in this category.)

> This seems to be more a compatibility problem of the HTML5 drafts, 
> that reinvented the wheel once more here. audio and video in SVG are 
> mainly reused from SMIL - unfortunately this was incomplete for the 
> audio element, but this could be fixed in SVG 2.
> Basically the 'deunification' happened in HTML5, not in SVG tiny 1.2.
> I think, when this came up, the SMIL/SYMM WG offered help to the HTML5 
> working group to get it right, but unfortunately this was somehow 
> ignored and no we have these HTML5 drafts with an incompatible model, 
> problematic for SVG. But because
> HTML5 is still only a draft, no official recommendation, anybody 
> should already use for official, serious publications, it should be no 
> problem to fix this inconvenient issue right now in the HTML5 drafts 
> without problems and suffer for authors, before some HTML5 draft comes 
> close to something like a recommendation, as SMIL 1/2/3 and SVG tiny 
> 1.2 already are ;o)

Timing and standards-body status are irrelevant; adoption by pages is.
HTML's definitions are thus canonical, and it's SVG Tiny that has the weird non-standard definitions.

(It's possible for multiple definitions to be "correct" via this metric, which just means we've got a terrible compat problem on our hands.  Luckily that's not the case here; the number of pages that rely on SVG Tiny's definitions round off to zero.)


Received on Thursday, 19 June 2014 17:52:54 UTC