- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 6 Jun 2012 08:49:19 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Jonas Sicking <jonas@sicking.cc>, Rafael Weinstein <rafaelw@google.com>, Yehuda Katz <wycats@gmail.com>, Webapps WG <public-webapps@w3.org>, Scott González <scott.gonzalez@gmail.com>
On Wed, Jun 6, 2012 at 3:42 AM, Henri Sivonen <hsivonen@iki.fi> wrote: > On Fri, Jun 1, 2012 at 10:25 AM, Jonas Sicking <jonas@sicking.cc> wrote: >>> I think the SVG working group should learn to stand by its past >>> mistakes. Not standing by them in the sense of thinking the past >>> mistakes are great but in the sense of not causing further >>> disturbances by flip-flopping. >> >> For what it's worth, I've not seen any flip-floppying on this. Over >> the years that I've asked the SVG WG the detailed question on if they >> prefer to have the parsing model for <scripts> in SVG-in-HTML I've >> consistently gotten the answer that they prefer this. > > At the time when SVG parsing was being added to text/html, vocal > members of the SVG working group were adamant that parsing should work > the same as for XML so that output from existing tools that had XML > serializers could be copied and pasted into text/html in a text > editor. Suggestions went as far as insisting a full XML parser be > embedded inside the HTML parser. > > For [citation needed], see e.g. Requirement 1 in > http://lists.w3.org/Archives/Public/public-html/2009Mar/0216.html (not > the only place where the requirement was expressed but the first one I > found when searching the archives) and requirements 1 and 2 as well as > the first sentence under "Summary" in > http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html . > >> I'm also not sure how this is at all relevant here given that we >> should do what's best for authors, even when we learn over time what's >> best for authors. > > At this point, what's best for authors includes considerations of > consistent behavior across already-deployed browsers (including IE9, > soon IE10 and the Android stock browser) and future browsers. Considering compatible behavior is indeed part of what's best for authors, but we shouldn't extend that to blanket denials of the possibility of change. "Flip-flopping" is irrelevant. Only what is good for authors is. If deployed content would break as a result of a change, we either find a new way to accommodate the desired change, or drop it. But we need the compat data about that breakage before we can claim that it will occur. The SVGWG would like to make things as good for authors as possible. Past positions don't matter, except insofar as the history of their effects on the specs persists. Compat breakage is painful, but so is manifestly hard-to-use incompatibilities between HTML and SVG. Let's fix those as much as we can. ~TJ
Received on Wednesday, 6 June 2012 15:50:15 UTC