W3C home > Mailing lists > Public > public-html@w3.org > March 2008

Re: [whatwg] Exploring new vocabularies for HTML

From: Doug Schepers <schepers@w3.org>
Date: Sat, 29 Mar 2008 14:49:50 -0400
Message-ID: <47EE8F4E.1000907@w3.org>
To: public-html@w3.org

Hi, Ian-

David Carlisle's most recent email reminded me that the opinions stated 
in my own email were, of course, merely my personal opinion, not an 
official stance of the SVG WG.  I believe that it is fairly 
representative of the individual opinions of the SVG WG participants, 
and of the SVG community in general, but I'm not claiming to speak for 
them.

I should also note that when I say that any changes to the SVG language 
should be done in coordination with the SVG WG, I do mean just that: 
that the SVG WG does want this to be a cooperative enterprise, and will 
attempt judge all information presented fairly and with an open mind.  I 
anticipate that the HTML WG will operate on the same principles.

Thanks-
-Doug

Doug Schepers wrote (on 3/29/08 11:33 AM):
> 
> Hi, Ian-
> 
> You talk about including graphics and diagrams in a very generic way, 
> without specifically mentioning vector graphics in general, or SVG in 
> particular.  I believe most people on this thread have assumed that you 
> are talking about SVG.  However, it's not clear from your public 
> statements that that's your intent.
> 
> For example, you stated in an earlier thread [1]:
> 
> [[
> "* Add vector graphics markup and related APIs to text/html.
>     - Ensure all the graphics standards are open.
>     - Allow copy/paste from vector graphics programs today."
> ...
> "... [this] requirement could be handled by a careful listing
> of some SVG elements and how to handle them, with custom
> error handling to handle common problems. It could also be
> handled by a careful study of the output from widespread
> vector graphics programs to make the parser handle the syntax
> that they require us to support. Maybe we can even solve it
> without using SVG at all, but by supporting the output of some
> common graphics program directly, after specifying it."
> ...
> "As a general rule I recommend avoiding referring to specific technologies
> in such use cases."
> ]]
> 
> You've also replied on this very thread that you are considering MathML 
> as only one of several options for including equations inline, and asked 
> to subset it.
> 
> On IRC, you've also said that you do not intend to allow SVG in 
> text/html; I don't know that you were serious, but it does give me 
> reason for concern.
> 
> By insisting that all feature requests be couched in the form of 
> minimalist requirements, and by eschewing mention of specific 
> technologies, you seem to be giving yourself considerable leeway in how 
> you interpret use cases and requirements.  This could have the result of:
> 
> 1) using another vector graphics language than SVG; or
> 
> 2) subsetting SVG with limited supported set of features that cannot be 
> expanded by future SVG specifications; or
> 
> 3) redefining SVG in an manner incompatible with existing specifications 
> and implementations.
> 
> All of these risks  would be deleterious to the Web, and the first 
> possibility is a clear example of reinventing the wheel, which goes 
> against the Design Principles of this WG.  It would be an egregious 
> misuse of time and resources to specify a custom vector graphics language.
> 
> I'd like to avoid these possibilities, and to reinforce that the use of 
> SVG, specifically, should be the primary requirement for any vector 
> graphics, just as Canvas is the primary requirement for dynamic raster 
> graphics.  Further, any changes to the language should be done in 
> coordination with the SVG WG.  I believe that this is the expectation of 
> this Working Group as a whole (if anyone disagrees, feel free to speak 
> up with counterarguments).
> 
> I don't think I need to restate the reasons for this requirement, as 
> this has been discussed many times, but if necessary, I think we could 
> reiterate and make the case again. (The short list: widespread 
> deployment, native support in most browsers, known royalty-free patent 
> policy, commonly used and understood format, growing test suite, broad 
> free and commercial toolchain support, market momentum).  But I would 
> like you to allay my concerns and acknowledge that this is in fact a 
> primary requirement.
> 
> Perhaps the Chairs could put together a poll, or the TAG or AC could be 
> consulted?
> 
> [1] http://lists.w3.org/Archives/Public/public-html/2008Mar/0094.html
> 
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, CDF, and WebAPI
Received on Saturday, 29 March 2008 18:50:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:53 UTC