- From: Jeff Schiller <codedread@gmail.com>
- Date: Tue, 11 Mar 2008 10:37:46 -0500
- To: "Adam van den Hoven" <adsmart@gmail.com>
- Cc: "Henri Sivonen" <hsivonen@iki.fi>, "Julian Reschke" <julian.reschke@gmx.de>, "HTMLWG Tracking WG" <public-html@w3.org>
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