- From: Sam Ruby <rubys@us.ibm.com>
- Date: Wed, 2 Apr 2008 12:25:05 -0400
- To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
- Cc: public-html@w3.org, public-html-request@w3.org
- Message-ID: <OF854B21AF.06958285-ON8525741F.00599D41-8525741F.005A3040@us.ibm.com>
Dr. Olaf Hoffmann wrote on 04/02/2008 11:51:21 AM: > > Simon Pieters: > > >Until I see actual pages that contain non-MathML in <math> or non-SVG in > ><svg>, I'm not convinced that Henri's scoped parsing proposal[1] doesn't > >work. Do you perhaps have such data at hand so I can take a look and be > >convinced? :-) > > The SVG recommendations expicitly note, that in the elements 'title', 'desc' > and especially 'metadata' may contain elements from other namespaces. > Especially RDF in 'metadata' might be really used currently. Because > SVG does not provide any content for metadata itself, if it is used, it > will typically contain elements from other namespaces to provide for > example some copyright or license information related to the graphics. > (X)HTML in 'desc' might be very useful to provide some description > with some structure (for an alternative display), but because > accessibility features and alternative text presentation is currently not > widely implemented for SVG, there are maybe not very much examples > for this (I have some). For example Amaya and partly Squiggle > interprete 'desc' somehow. To help illustrate this, here is an example produced by inkscape: http://en.wikipedia.org/wiki/Image_talk:Bart-logo.svg As a minimum, it is important that none of the elements and attributes which are *not* in the svg namespace do not detract from the ability to process the parts that *are* in the svg namespace. It may also be worth noting that this document also contains empty elements. Ideally, these also would not detract from the ability to process the remainder of the document. In particular, the <g> node needs to be an immediate child of the <svg> node in the DOM. - Sam Ruby
Received on Wednesday, 2 April 2008 16:26:04 UTC