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

Re: Exploring new vocabularies for HTML

From: Erik Dahlström <ed@opera.com>
Date: Tue, 25 Mar 2008 10:16:08 +0100
To: "Ian Hickson" <ian@hixie.ch>, whatwg@whatwg.org, public-html@w3.org
Message-ID: <op.t8keo6rlgqiacl@gnorps>

On Tue, 25 Mar 2008 07:29:07 +0100, 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]
>   3. Writing a document by hand, with inline diagrams imported from a
>      graphics package.
>      Priorities:
>       * Compatibility with existing graphics packages

Reading that sounds to me like that should cover the inclusion of  
namespaces, since many/most svg editors put data in custom namespaces in  
the svg files, and that data should not be lost when parsed (doctype and  
XML PI:s to be excluded). Also for things like <svg:metadata> I'd say that  
it's pretty much a requirement that data inside it isn't lost when it's  
parsed to DOM. Furthermore it's not that uncommon that people want to put  
custom data in namespaced attributes in svg, and I would expect that to  
continue to work even if used inline in HTML.

If you wish, let me reformulate that into requirements/use-cases:

* Use-case: ability to add custom (non-svg) data on svg elements so that  
this data can be processed e.g with scripts or by XSLT, and without  
risking name collisions with svg currently and/or future extensions of the  
svg language.
   Use-case: enable new svg/mathml features as they become available, so  
that people can use them even if inline in HTML.
   Requirement: make the definitions for how to parse other languages  
inline in HTML forwards-compatible, so that when new elements and  
attributes are added to SVG/MathML they still work when included inline in  

* Use-case: copy-paste of svg fragments between HTML and XHTML documents  
should work,
   Use-case: ability to access custom (namespaced) data specified in e.g.  
   Requirement#1: no data loss when parsing.
   Requirement#2: a self-contained svg fragment containing a script that  
operates on the DOM tree using *NS methods should still work the same when  
included inline in HTML.
   Expectation/Requirement#3: When an svg fragment inside HTML is parsed  
the output DOM tree should be equivalent to the same fragment when parsed  
inside of an XHTML document.

> 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.

Please address the use-cases above.


Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 25 March 2008 09:16:59 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:27 UTC