Re: SVG and MathML in text/html

The way I understand the problem is that the HTML5 parser would
require too many "special cases" to handle XML 'islands' like this.

Regards,
Jeff

On 3/11/08, Adam van den Hoven <adsmart@gmail.com> wrote:
> Hey guys,
>
>  It seems that there is no easy way to include other vocabularies into
>  text/html assuming that:
>  1) You want the resulting docs to conforming
>  2) You want the resulting docs to be testable for conformance (using
>  code, not manually)
>  3) You want to be able to support emerging technologies
>         Henri's point that we've only seen two additional element sets is not
>  entirely useful. In the broader web, I agree that new languages are
>  likely to be infrequent. However in corporate settings, where all the
>  browsers are controlled, other technologies could very well become
>  common.
>
>  In SVG, you have the foreignObject. Why not introduce something
>  similar here? Would this not provide adequate isolation to allow
>  validation code to work?
>
>  Just $0.02 from a lurker
>
> Adam
>
>
>
>  > On 11-Mar-08, at 7:59 AM, Henri Sivonen wrote:
>  > On Mar 10, 2008, at 23:06, Julian Reschke wrote:
>  >
>  >> Henri Sivonen wrote:
>  >>>> Atom, for instance, works much better.
>  >>> http://hsivonen.iki.fi/atom-xhtml/
>  >>
>  >> It does work better.
>  >>
>  >> Yes, there may be clients that are broken.
>  >
>  > And why might that be? Perhaps XML is tough.
>  >
>  >>> Putting all the element names from the Web platform languages
>  >>> (XHTML, SVG, MathML) into a single space of XML element names
>  >>> without any URI binding mechanism. That is, if HTML defined
>  >>> "table", it is taken and MathML should define "mtable".
>  >>
>  >> Doesn't scale. How do you add a new vocabulary? Don't say you don't
>  >> need to in the future.
>  >
>  > In the past decade, the vocabulary of the Web platform has been
>  > extended by a whopping two additional element sets: SVG and MathML.
>  > Next XBL2 may join the platform.
>  >
>  > Given that this is the actual rate of vocabulary growth we got
>  > *with* Namespaces in XML in place, it seems clear to me that as far
>  > as the Web platform goes, Namespaces in XML is premised on a totally
>  > wrong projection of the rate of growth and, thus, solves a problem
>  > we'd not really be having.
>  >
>  > In the case of MathML, the convention of starting element names with
>  > "m" would already be sufficient for avoiding collisions with HTML.
>  > As far as MathML goes, Namespaces in XML is just a superfluous
>  > complication.
>  >
>  > In the case of SVG, the element name overlap with HTML is small and
>  > mostly about duplicating the elements. Had Namespaces in XML been
>  > absent, SVG could easily have been designed not to clash with HTML
>  > in a bad way.
>  >
>  >>>>>> Maybe it's because I'm used to writing SVG, but I really don't
>  >>>>>> have a problem with the concept of mixed namespace content.
>  >>>>> I have a problem with namespace URIs every single time I need to
>  >>>>> deal with XHTML, SVG, etc. I always have to waste time looking
>  >>>>> up and URI to copy and paste because trying to go by memory and
>  >>>>> getting it wrong (which year? trailing slash?) would waste even
>  >>>>> more time.
>  >>>>
>  >>>> I fail to see how this is a problem. Is copy & paste too hard?
>  >>> Yes, when the plausible alternative is not having to do that.
>  >>
>  >> Well, short names require a central registry.
>  >
>  > A central registry is a good thing in order to avoid a Babel of
>  > languages with no coherent common feature set for authors to rely on.
>  >
>  >> Doesn't scale as well as URIs. See the related microformats
>  >> discussions.
>  >
>  > http://www.w3.org/TR/ seems to scale well enough to cover HTML, SVG
>  > and MathML.
>  >
>  > --
>  > Henri Sivonen
>  > hsivonen@iki.fi
>  > http://hsivonen.iki.fi/
>  >
>  >
>  >
>  >
>

Received on Tuesday, 11 March 2008 15:38:12 UTC