Re: [whatwg] Exploring new vocabularies for HTML

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

Ian Hickson wrote (on 3/25/08 2:29 AM):
> I've read all 367 e-mails that were sent to the WHATWG, the HTMLWG, and to 
> other forums on the topic of MathML, SVG, namespaces, etc, in HTML, 
> spanning threads from 2006 to 2008. [1]
> 
> I've tried to summarise the problems (use cases) that people want solved, 
> along with what they consider most important when faced with those 
> problems [2]:
> 
>   1. Putting an equation in a Web page.
>      Priorities:
>       * Maintainability
>       * Searchability
>       * Accessibility
>       * Typographically-sound printing
>       * Ease of authoring (are authors willing to learn new formats?)
>       * Ease of import from existing documents
>       * Ease of implementation (are UAs willing to implement new formats?)
>       * Resistance to errors (e.g. not brittle in the face of syntax errors)
> 
>   2. Migrating from LaTeX to HTML.
>      Priorities:
>       * Fidelity
> 
>   3. Writing a document by hand, with inline diagrams imported from a 
>      graphics package.
>      Priorities:
>       * Compatibility with existing graphics packages
>       * Resistance to errors (e.g. not brittle in the face of syntax errors)
>       * Scriptable (retained-mode, with DOM support, without requiring 
>         cross-frame scripting)
>       * Round-tripping (the ability to take image fragments from a Web page 
>         and edit them)
> 
>   4. Writing documents that include diagrams that include
>      typographically-correct mathematics.
> 
> Philip also wrote a detailed story, which touches on several of the points 
> above, of what we want to enable. In addition to the points above, his 
> requirements include a solution for ID clashes in multiple-document 
> transclution, and a solution for embedding custom non-visible data in an 
> HTML document for scripting purposes. [3]
> 
> 
> Now, please, if I've missed something that you want to do, please let me 
> know as soon as possible. I intend to start working on solutions to these 
> problems tomorrow, and things that aren't on the list of problems will 
> likely not be considered as constraints.
> 
> In particular, people seemed to jump to solutions that the above problems 
> don't imply. For example, nowhere in the above list of problems do 
> namespaces appear anywhere, yet the majority of the discussion revolved 
> around namespace issues. If this is because I've missed a problem that in 
> fact requires those solutions, please tell me as soon as possible.
> 
> I cannot solve problems I don't know exist!
> 
> 
> [1] http://www.whatwg.org/issues/#html-parsing-rules-namespaces-discussion
> [2] http://wiki.whatwg.org/wiki/New_Vocabularies 
> [3] http://lists.w3.org/Archives/Public/public-html/2008Mar/0156.html
> 
> Cheers,

--

Received on Saturday, 29 March 2008 15:33:45 UTC