Re: SVG cloning elements from HTML5

On Thu, Jun 19, 2014 at 10:08 AM, Dr. Olaf Hoffmann
<Dr.O.Hoffmann@gmx.de> 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.)

~TJ

Received on Thursday, 19 June 2014 17:22:35 UTC