Re: Exploring new vocabularies for HTML

What about compatibility with XHTML?  Right now, one can take an XHTML
document and serve it up as HTML and it (mostly) works.  If one adds MathML
or SVG, than they must have a namespace associated with them and it would be
useful if they too worked.  This means that HTML5 needs to handle namespaces
to some extent.  At a minimum, if HTML5 "ignores" them, it needs to ignore
the namespace syntax and semantics so as to preserve the XHTML meaning of
these for MathML and SVG.

The other issue that you seemed to miss is "export".  If someone copies the
SVG or MathML from a document, it should be serialized as per those specs
(including any namespace requirements) so that it can be pasted into a SVG
or MathML consuming app.  This may not change your solution in that you
might require browsers that provide a serialization that follows the specs,
but you did omit export from your use cases.

Neil Soiffer
Senior Scientist
Design Science, Inc.
neils@dessci.com
www.dessci.com
~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~


On Mon, Mar 24, 2008 at 11:29 PM, Ian Hickson <ian@hixie.ch> wrote:

>
> 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,
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>