RE: [whatwg] SVG cloning elements from HTML5

On  Thursday, June 26, 2014 1:40 PM

in response to

>> idiotically-authored sites.

Chris Lilley wrote

>Yes, I would like to see some links to these sites, to see what they are
depending on, and how they would change.

[...]

>Much more important than maintaining rendering of someone's "tried this and
it didn't do anything but I never took the >tags out because they were
harmless" test page from years ago.

Hi Chris, 

This is a much more pleasant phrasing than "idiotically-authored" since I'm
sure some would call some of my experiments the former, though, your
description is much preferable. 

Whenever folks talk about their willingness to break prior content, it is
important to remember
a) As our friends at Boeing remind us, much SVG content is not visible to
Google's crawlers, being behind closed doors.
b) Google's crawlers seem not to crawl the whole visible web anyhow, often,
apparently stopping three layers deep in hierarchies that may be twelve or
more hyperlinks deep. That is: much feature-usage-census-data may be
methodologically flawed. And the number of reasons for this is (by my recent
census) enormous and almost transfinite [1]. But as a simple example, MSFT's
argument (circa 2011) that there wasn't much SMIL on the web, therefore we
don't need to do it, was a chicken and egg sort of argument that not many
bought: Of course there wasn't since the most important browser at the time
didn't support SVG! 
c) Well-meaning and publically authored documents exist which attempted to
represent best practices at time X based on specs written at time X-t. Given
that the majority of the browser-maker world (including Mozilla, Apple,
Google and Microsoft) were slow to learn the importance of SVG, and given
the dearth of best practices documents for "modern SVG in HTML5.5555+",
momentum exists, as SVG's uptake increases, for more "bad practices"
consistent with former standards to be propagated. Authors tend to read
examples more than they read specs.

Curse the past or adapt to its legacy. Making modern "standards" that are
inconsistent with previous standards which people relied on, is not a best
practice in standards development, at least from the perspective of authors
who want those standards to mean something.

Cheers
David

[1] A formal definition of the term "almost transfinite" should take a long
time to produce, should it not?

Received on Friday, 27 June 2014 03:10:25 UTC