The last few weeks there has substantive discussion on the HTML WG mailing list (public-html) and the Math WG public dicussion mailing list (www-math) regarding embedding non-HTML languages in the text/html serialization of HTML focusing mostly on MathML and SVG. (Sidenote: the number of e-mails totalled over the yearly average of the www-math list.)
I wrote about SVG and text/html before and what the complexities of introducing it would be. What wasn’t mentioned back then was having HTML or MathML inside your SVG, having HTML or SVG in your MathML, et cetera. What’s currently in the HTML5 draft addresses all these scenarios. A few details on the parsing side have yet to be worked out and the authoring side needs a whole lot of introductory text to make it more understandable, but the basic concept clear.
The <math> and <svg> start tags act as namespace scopes for MathML elements and SVG elements respectively. They represent the doors to the foreign lands, where:
/> is no longer a token of faith and pops the start tag from the stack of open elements immediately.
xmlns “attributes” have no effect, but will be allowed so that tool output is by default compatible. They might even end up in the correct namespace, http://www.w3.org/2000/xmlns/.
: and other entities representing “ASCII” characters…) (For what it’s worth, these entities will work outside the foreign lands too.)
p start tag in <math><p> will take you right back home safe turning that fragment into <math/><p>. (I expect p to be in that list.)
mi, mo, mn, ms, and mtext and the SVG elements foreignObject, desc, and title provide bridges so that the aforementioned magic list of HTML element names can be nested safely inside SVG and MathML (in the HTML namespace, too). They also allow for SVG in MathML and vice versa.
Not everybody likes this approach, Tim Berners-Lee said: The idea of using SVG without XML is horrifying.
(I guess that statement does not necessarily apply to using the DOM instead of any specific serialization which is how libraries are currently using SVG.)
However, solving the generic extensibility problem for HTML is hard and it’s not that clear what the best approach would be. Also, mathematics and graphics are very basic utilities that everybody in the world should have easy access to. And just as with HTML, there should be no need for complex tools to publish mathematics and graphics (though admittedly MathML and SVG are not as simple as HTML as they are solving somewhat more complex problems). Given that both MathML and SVG started gaining traction in user agents and that the vast majority of authoring software is catered for text/html special casing these two vocabularies makes sense. When implemented it enables a very wide audience to share information in a more accessible way than now (mathematics is often hidden in a bitmap image). Just imagine how much more rich Wikipedia could become.
I'm glad that someone summarized all of those emails, I lost which thread had what solution a long time ago, but I'm incredibly disappointed at the result.
This isn't the way to create a syntax that takes us into the future. We've created the black board with the words, "And a miracle happens here", when it comes to future vocabularies. Heck, probably with SVG and MathML, too, if it comes to that.
And don't say if I don't like it participate on the email list or shut up. From what I can see, my participation would not have made even the smallest difference.
I cannot believe that people who are so astute at markup and issues related to markup would see this as a "solution". If so, then I guess my own admittedly limited knowledge is completely flawed, because my only thought on seeing this is, 'ware, there be dragons here.
The future vocabularies are an unsolved problem, as I said in my post. It remains unclear whether that will be solved in HTML5 for text/html or maybe in a future version of HTML.
I personally think the solution as described above is good for MathML and SVG. All the namespace complexity is taken away and the syntax is reasonably compatible with what HTML authors are used to. I think having more complex authoring for MathML and SVG because it suits architecture astronauts better would be a missed opportunity. (Also, it is not clear that such a generic solution is an actual possibility.)
By the way, I don't think this is very fair: [I]f [you] don't like it participate on the email list or shut up.
We’re doing the best we can to get feedback from wherever possible and take it into account. Implying the aforementioned line would be our normal response is just not nice, nor true.
The idea of using SVG without XML is horrifying.
I really hope the XML people learn from the HTML 5.0 error handling concept, and see it's value, and make XML 2.0 the same way... and it would be cool if they'd allow XML languages to be in either syntax....for easier inclusion into X/HTML. I really think the HTML 5.0 error handling is a far better way to deal with things, and syntax is minor issue. You wouldn't have caught me saying that at one time, but I've seen the light!
I'm inclined to agree with timbl.
MathML, I can kinda understand, but SVG? Who actually writes SVG except outside of test cases? That's right—nobody. It's all generated automagically, which means it'll either be in (X)HTML documents controlled by the generator, or it'll be referenced in separate files and the whole issue is moot.
About the only reason I can see for doing this is as a backhanded way of persuading Microsoft to support SVG without forcing them down the XHTML path.
Sorry if I wasn't nice, Anne. My lack of niceness is a reflection of past experience. OK then, I'll write my concerns here and elsewhere without worrying that someone will tell me that unless I participate directly in the email list, I should shut-up. And if someone does, I'll point them to your comment.
What I'm seeing is that we're bending over backwards so far to avoid the 'error handling in XML' that we're creating an implementation of SVG and MathML in HTML that is based on hard coded entitles, which means then that we're faced with some serious conflicts in the future if SVG and/or MathML change. Frankly, wouldn't the draconian error handling be preferable?
I can't believe in this day in age with everything being open that we're creating a future web page markup that's based on closed vocabularies.
I liked what I saw of your XML5, which is keep the openness of XML but lets work on providing better error handling. That is a fairly correct understanding of your XML5, isn't it? Now, though, I don't know what we have. Well, yes I do:
A fundamental break as regards namespaces between HTML5 and IE.
A fixed, rigid set of SVG entities in HTML5. Ditto, MathML.
Two serializations of supposedly the same thing, XHTML5 and HTML5, each of which has SVG and/or MathML which cannot help but eventually end up with different document object models, because one is based on open vocabularies, while the other is based on closed, fixed vocabularies.
I am not a markup person so I will be the first to admit that my understanding is potentially flawed. But am I wrong on the issues just listed?
Sorry, mixed up entities and elements.
Actually, only the cross-language entry points are hardcoded and they have to be for better or worse. Apart from that no elements are hardcoded. (There was another proposal that did propose hardcoding all the SVG and MathML elements and that didn’t make it.)
Sorry, Anne. My misunderstanding about the fixed set of elements. I thought that was the last consensus in the list, but obviously I misread the list. Or followed the wrong thread. Or both.
Sorry for being dense, but how is xlink being handled in the new approach?
What happens if I take an Inkscape generated SVG document and try to embed it into an HTML5 document. Here's an example. With this new approach you've outlined, what would I need to do to the SVG to make it usable in HTML5?
What happens with a script element, or style in the new approach? Would these be defined as cross-over elements? If a prefix is used, is it just ignored? Or will these generate errors?
Is this all documented somewhere? I saw the wiki, but it's a little...sparse.
Finally, though I'm indifferent to whether IE8 chokes on HTML5, wouldn't this approach lead to IE8 choking on HTML5? I'm just trying to figure out the differences between what you're saying here, and what MS has said in its white paper.
"However, solving the generic eXtensibility problem for HTML is hard and it’s not that clear what the best approach would be."
Sorry to be flippant, but extensible markup is a solved problem. Only the optimisations for legacy/liberal support in text/html+html5 are in conflict with those of open extensibility (which inherently explodes the number of possible markup combinations that have to be considered).
Personally I don't see the creation of a hobbled form of SVG etc. as a particularly convincing step.
Possibly the only sane approach would be to leave that version without extensibility, and encourage anyone that needs it to use XHTML5. Horses are a perfectly good means of transport, but you can't really bolt wings to them and expect them to fly.
I can't believe in this day in age with everything being open that we're creating a future web page markup that's based on closed vocabularies.
I think making the parser generic is the wrong optimization.
"Possibly the only sane approach would be to leave that version without extensibility, and encourage anyone that needs it to use XHTML5."
I agree with this. I wouldn't care about the HTML version of the spec except for one thing: agents that only generate or consume one serialization over another. Since the two are not "alike", those of us who want SVG, or MathML, or FutureVocab incorporated into our page won't have an option. Particularly since agents will, most likely, be encouraged to support the "friendly" HTML serialization over the nasty, evil, draconian XML-based serialization.
But the nasty, evil, draconian XML-based serialization is so wonderfully open. Henri, you pointed out one of your email thread postings, about above DOM versus below and putting optimization into the appropriate context. However, I want to copy what you wrote in an earlier post:
"And, yet, XML is consistently failing on the Web. XML is succeeding in enterprise system integration. But the moment people try to produce XHTML or RSS, it is revealed that XML is too hard for the kind of mass authoring that text/html works for."
One could say HTML is failing on the web, or otherwise, why would there be an HTML5 effort?
In five years, if we discount the unicorn/rainbow stuck in forever amber sites, probably ninety-nine percent of the markup on the web will be generated by tools. I say markup, because I believe CSS will always have significant manual input. I don't think I'm being overly optimistic in making this guess, considering the developments of the last five years.
If I'm right, then why is our entire focus on making something that should be managed by tools that are developed by people who are supposedly capable of reading a spec (though goodness knows, this isn't always true), into something that can be hand tweaked by Joe Bob and Gertrude, for their "How to make Possum stew" web page?
If I could count on the HTML5 spec having one important sentence in it, I would say have fun with the HTML serialization, or more appropriately, have a drink because you'll need it with this latest. That sentence is: conforming agents must support both forms of serializations, HTML5 and XHTML5.
We've been told, however, that we won't get this sentence. Conforming agents can support one, the other, or both. If this is true, all we're left with is trying to wrap our minds around how to shove a round peg into a square hole. Evidently, the trick is to use a big hammer.
Using " and the em element to mark up a quote. Let me tell you, the Semantic Web will totally rock.
One could say HTML is failing on the web, or otherwise, why would there be an HTML5 effort?
So HTTP 1.0 was a failure too? And DOM Level 1? And CSS1? And the first season of Buffy? And the first Feynman lecture? And the first act of Macbeth? Maybe this paragraph is a failure too, since it's followed by more paragraphs. :-)
Ten years ago, people were predicting that five years ago, 99% of sites would be written by tools. We still have to cater to the hand authors. Heck, Tim himself said he never imagined HTML would ever be hand-written, yet here we are. (I'll probably elaborate on this in the e-mail I'm writing about these namespacing changes.)
The spec can't require XML support, because user agents don't do what the spec requires unless they agree with it. If we make requirements that just get ignored, they are pointless. Specs are about guiding implementors to converge on particular behaviour in the areas that they agree need to exist. They can't actually compel vendors to write code they don't want to write.
Ignoring reality in favour of what we would like to be true doesn't actually work. This simple axiom probably underlies almost everything the WHATWG has done so far, and it has so far served us well. I don't see a reason to change course now.
Oh, also:
Since the two are not "alike", those of us who want SVG, or MathML, or FutureVocab incorporated into our page won't have an option.
Those of us who want SVG or MathML in text/html pages now do have an option. Those of you who want an as yet unproven standard that not everyone supports (FutureVocab) incorporated into your pages will not have the option. That's a good thing. It means that we don't end up with pages containing proprietary markup or markup that the end user has no hope of processing correctly. Sending only well-known, well-defined vocabularies over the wire is how we achieve wide interoperability, accessibility, and independence from vendor lock-in.
Shelley, that example would work as far as I can tell. I don’t think it will validate. script element handling is an open issue. xlink:href as attribute will map to the right namespaced attribute. The specification and wiki contains all the details I have used in this post, but as I mentioned, some things have yet to be worked out in more detail.
Anne: Using " and the em element to mark up a quote. Let me tell you, the Semantic Web will totally rock.
Hmm. What was that about being nice, Anne?
I appreciate you glancing at the example. I was curious as to what happens with all the namespaced elements in that example. Perhaps the wiki will have more detail over time.
Ian: Those of you who want an as yet unproven standard that not everyone supports (FutureVocab) incorporated into your pages will not have the option. That's a good thing.
No, it is not a good thing because that FutureVocab will be a new specification coming out of the W3C, which now has to go through all of this negotiation in order to ensure that it's incorporated into HTML 5.898486934589. And counting.
HTMl5 will have defined a box and shoved us into it, Ian. All hail the closed web.
Just joking, although there might be some truth to it, dunno. As for the namespaces, I thought that was clear. As for HTML5 closing the Web, that seems dramatizing things too much. text/html was never open ended in the way you desire it to be. That doesn’t stop people from doing stuff on top of it though, see microformats and RDFa. Also, this move isn’t closing any door, as I already explained. It’s just optimizing for MathML and SVG.
The very first time I saw XML namespaces, I thought, "Awesome! An infinitely scaleable approach to extensibility!" As such, I'm generally in favor of the namespaces approach, but I'm not going to argue for it here.
which now has to go through all of this negotiation in order to ensure that it's incorporated into HTML 5.898486934589. And counting.
While this is indeed a possibility, especially since incorporating MathML and SVG means adding "dependencies" to other languages, in my experience language specifications evolve slowly enough that it shouldn't get to this point. If you were really worried about it, you could add a versioning mechanism to the svn or math tags (I wouldn't do it until you actually needed it).
It’s just optimizing for MathML and SVG.
Anne, I think this pretty much sums things up. My question, however, is whether or not it's worth it to optimize for MathML and SVG. You state, quite optimistically:
However, solving the generic extensibility problem for HTML is hard and it’s not that clear what the best approach would be. Also, mathematics and graphics are very basic utilities that everybody in the world should have easy access to. And just as with HTML, there should be no need for complex tools to publish mathematics and graphics (though admittedly MathML and SVG are not as simple as HTML as they are solving somewhat more complex problems)
MathML was specifically designed such that in all but the simplest cases, authors will use equation editors, conversion programs, and other specialized software tools to generate MathML. A quick comparison between the Quadratic Formula written in MathML versus LaTeX will easily attest to that.
As for SVG, Sam Ruby's the only person I know who handwrites it, and I'd hate to see him attempt more complicated pictures.
And yes, I hand-write all of my XHTML.
It means that we don't end up with pages containing proprietary markup or markup that the end user has no hope of processing correctly.
Or, it means browsers will implement proprietary markup in an ad hoc manner without standards. At least with namespaces, you can set up interdicting software to translate the "proprietary" (but standardized) markup into something the end-user can read.
Heck, Tim himself said he never imagined HTML would ever be hand-written, yet here we are.
I suspect this is because raw HTML closely resembles its output.
we're faced with some serious conflicts in the future if SVG and/or MathML change.
If SVG and MathML change in a backwards-incompatible way, we're still left with serious conflicts with or without HTML5.
What you describe as a problem (requiring coordination to add new vocabularies) seems to me to be the desirable outcome. It's not like adding a new vocabulary is hard -- adding SVG and MathML took two weeks, including determining that we wanted to do it, when I finally got around to looking at the problem. Adding new vocabularies, when HTML maintenance is just that -- maintenance, as opposed to defining the language from scratch to deal with the vagueness that came before it, as we are now -- will be a trivial matter technically. The political side to this is a good one. Putting barriers in place so that people don't willy nilly extend the Web's core language is a good thing.
Honestly. Adding a new vocabulary requires tons of work determining what problem you're solving, specifying the language to solve it, defining its its behaviour, its error handling, how it interacts with all the other languages, how you script it, not to mention actually implementing it, writing tutorials, etc. The syntax part can be done in a matter of days, the rest will take years. Worrying about the syntax part shows a pretty fundamental misunderstanding as to the relative costs of adding a new vocabulary to the Web. It looks like a desire to solve the easy part of the problem, while ignoring the hard parts. It also smacks very much of a great thinker seeing a pattern.
I'm looking through the WHATWG mailing list, and I'm not seeing many cries for features like this. And I don't see nearly enough rationale or explanations. This is huge, and I want to know more than, "oh hey look what we did".
Why was a closed solution chosen over a general solution? (e.g. supporting the xmlns attribute so stuff like <svg xmlns="...">...</svg> would work) You act like that wouldn't work, but I can't find an explanation as to why.
Why was it decided that drastically changing HTML like this would be better than asking developers to use XML?
Who did the research to find that this would be an easier switch to make than just switching to XML? Do people really think Internet Explorer will support this before they support XHTML?
If we're going to make such drastic changes to markup languages, why not change XML to have error recovery and a default HTML namespace when identified as HTML (e.g. through the MIME type or file extension)? Lots of people are asking for a general purpose error-friendly XML, but I haven't seen much clamor for a version of HTML that can include specific types of XML.
Is it not possible to create an HTML markup language that is backwards compatible with current web browsers, but also able to encoded XML documents as generically as XML?
How are these elements going to be treated in XHTML5 documents? The way it's currently worded, it sounds like all SVG and MathML elements have been added to the HTML namespace. Should SVG and MathML elements work when in the HTML namespace in XML documents?
What do the MathML and SVG developers think about this?
Why are these elements already included in the spec when there is so little information on how they should work? Wouldn't it be better to wait until the details are worked out a bit more before adding them to the HTML5 spec?
I have so many questions, and I'm not finding a lot of answers. This makes HTML5 development feel very closed. I'm not seeing much open discussion on this.
Why wouldn't you want to do namespaces? Atom uses namespaces, why wouldn't HTML?
James: I'm writing the e-mail responding to the 620 (!) e-mails on the subject as we speak, it'll be sent in a few days when I'm done rereading all the e-mails and replying to each one in turn. It'll contain detailed information on all that kind of stuff.
That's a good thing. It means that we don't end up with pages containing proprietary markup or markup that the end user has no hope of processing correctly. Sending only well-known, well-defined vocabularies over the wire is how we achieve wide interoperability, accessibility, and independence from vendor lock-in.
Ah, a true master of sublime comedy. :-)
Indeed, eschewing open extensibility is certainly going to stop Microsoft from making IE10 parse Silverlight-in-HTML or some such. Extensibility: for big boys and girls only.
@Ian Hickson:
Okay, awesome. Thanks for working to keep WHATWG so open.
Can we get OOXML in HTML5 too? They seem to be very similar in their approaches to standardisation.
*blech*
Aristotle makes a very good point, in fact part of Ian's comment was almost diametrically opposite the reality:It means that we don't end up with pages containing proprietary markup or markup that the end user has no hope of processing correctly.
Nothing in the HTML5 spec can prevent the introduction of proprietary markup in the wild. What's more the only way an agent can process an arbitrary FutureVocab correctly is if there is an systematic extension mechanism that allows discovery of information about FutureVocab (such as the use of URI-based namespaces). If you can come up with, say, a tractable equivalent to XML+namespaces without draconian error handling, great. I've no doubt this is a hard problem. But I really don't think OneBigVocab (which is what in effect HTML+SVG+MathML would be) is a viable alternative - especially when we start seeing Silverlight etc jammed into it.
One thing that irritates me a little in these discussions is the implication that HTML5 is not introducing anything new. While XHTML 1.x is not deployed to the extent some of us would like, of the two, HTML5 is the unproven standard. Liberal interpretation of SVG & MathML is a major novelty.
btw Anne, sorry if my markup in the comment above offended, I'm not that experienced in the finer points. I did consider alternatives, but the thing is I was distorting your words so it wasn't really a quote. I guess that subtlety could have been made clear with a bit of RDFa :-)
Finally, may I hereby declare the Law of Spolsky (aka the reductio ad Spolskyum fallacy) : As a Web standards discussion grows longer, the probability of a reference to Architecture Astronauts approaches one."
What's more the only way an agent can process an arbitrary FutureVocab correctly is if there is an systematic extension mechanism that allows discovery of information about FutureVocab (such as the use of URI-based namespaces).
Please show me an XML user agent that does not have native SVG or MathML support but uses URI-based extensibility to discover how to process them and, as a result, renders strechy integrals and filtered filled and stroked Porter–Duff-composited Bézier paths. Cuz that would be totally awesome.
If you can come up with, say, a tractable equivalent to XML+namespaces without draconian error handling, great. I've no doubt this is a hard problem.
That would be Anne’s XML5. It is not suitable for text/html, though. Unfortunately.
Somehow, Danny’s unescaped single ampersand from his above comment made it into the comment feed literally.
Seems to be some bug somewhere in my PHP spaghetti (or in PHP itself).
It seems like the biggest argument I've heard against the 'general extensibility using XML islands' proposal is that people don't want XML in their HTML5... is that right? In other words, they don't want to mix XML draconian error handling with HTML5 error recovery.
Has anyone played with how IE8 wil allow mixing XML vocabularies inline with HTML? I would be curious if leaving out an /svg end tag would destroy the rest of the HTML page.
Is the WHATWG/HTMLWG working with Microsoft on their plans to allow well-known XML vocabularies into HTML? Obviously their approach is to allow inline XAML with HTML and you won't deter them away from that. If Microsoft's approach gains popularity, it will inevitably result in other user agents reverse-engineering their approach...
Henri, logical fallacy m'fraid - I didn't say that URI-based extensibility automatically enabled complex graphics processing (that would be awesome!), just that without some way of discovering unknown specs, correct processing of arbitrary markup is impossible.
But your example isn't entirely out of the question - say your agent already had a well-known rendering engine, and the namespace doc for SVG provided information on how to map from SVG to whatever that engine consumed. I've not heard about such a technique being used for graphics, but something quite similar is already spec'd out and implemented for RDF - GRDDL.
Henri, logical fallacy m'fraid - I didn't say that URI-based extensibility automatically enabled complex graphics processing (that would be awesome!), just that without some way of discovering unknown specs, correct processing of arbitrary markup is impossible.
Humans can discover unknown specs by pasting unfamiliar-looking bits into Google.
But your example isn't entirely out of the question - say your agent already had a well-known rendering engine, and the namespace doc for SVG provided information on how to map from SVG to whatever that engine consumed. I've not heard about such a technique being used for graphics, but something quite similar is already spec'd out and implemented for RDF - GRDDL.
And before GRDDL there was XSLT. But once you tell the browser how to transform stuff into HTML (unconditionally!), you might as well send HTML in the first place. Likewise, you could turn FooML graphics into SVG on the server side. Also, these transformations don’t really work with dynamic DOM scripting scenarios.
Nothing in the HTML5 spec can prevent the introduction of proprietary markup in the wild.
Sure. But there's a big gap between making it hard and clearly non-conforming to add new vocabularies, and making it easy, conforming, and encouraged.
I completely agree with TimBL's comment. I think this solution is horrific. The HTML5 WG should come up with at least a subset of namespaces that will enable SVG, MathML and any other language to be embeddable. The once and future HTML WG should not be the gatekeeper to adding features into browsers. As an example, facebook should be able to add their markup in a decentralized way and ensure there aren't name clashes.
Because the supposedly "open" process is actually so closed, it's impossible to find out how many people actually support or oppose this horrible solution.
We exist. I am not worthy to be included with Sam Ruby, but I am honored. I hand code SVG as seen in my map of our ethnobotanical garden. I hand code MathMl as can be seen on a math practice entrance test. I mix both on one page. And I am already looking ahead to MathMl in SVG for my physical science pages. I hand code for the same reason I hand code HTML and XHTML: cleaner, tighter, easier to maintain and reuse code. Plus we send pages over narrowband satellite links out here in the Pacific.
One piece that is often missing for me is HSL support, both in CSS in XHTML and in SVG.
At least for me, a teacher of ethnobotany, physical science, and statistics, MathMl and SVG are uniquely useful. I am indebted to the hard and excellent work of Anne, Hixie, and the many many other people who are making my work possible! Thanks!
The once and future HTML WG should not be the gatekeeper to adding features into browsers.
SVG and MathML in their XML form were added to browsers without the HTML WG’s gatekeeping. Calling the HTML WG a gatekeeper here reveals a tacit assumption that text/html is the gateway to success—not XML. ☺
As an example, facebook should be able to add their markup in a decentralized way and ensure there aren't name clashes.
Serving proprietary markup to a proprietary platform is different from serving openly specified markup to browsers from multiple vendors. Facebook’s use case would be better served by XML5 as Facebook doesn’t need to ingest legacy Web content. (Also, I find it interesting that people are so eager to enable the exploitation of HTML as an ingredient to proprietary languages.)
The MathML elements mi, mo, mn, ms, and mtext and the SVG elements foreignObject, desc, and title provide bridges so that the aforementioned magic list of HTML element names can be nested safely inside SVG and MathML (in the HTML namespace, too). They also allow for SVG in MathML and vice versa.
The currently "correct" method for including foreign namespaced content in MathML (the annotation-xml element) is not going to be such a bridge? That strikes me as problematic. My understanding is that MathPlayer will choke on (say) SVG content in an mo element. But it does just fine, ignoring that same content, wrapped in annotation-xml. Arguably, the current MathPlayer ignores content served as text/html, so we would not actually be causing that UA to break. However, it will come as a nasty surprise if the same MathML content caused MathPlayer to break, if switched from an HTML 5 to XHTML 5 context.
Jacques, sorry that I omitted the part about annotation-xml. It is slightly more complex and therefore I thought not worth mentioning, though I should’ve realized who’s reading this blog. SVG nested in annotation-xml will work perfectly fine. HTML, however, cannot be nested. The reason is that we want to keep the namespace scope intact for content MathML so we do not have to hardcode one hundred and fifty element names (and counting supposedly with MathML 3, 4, …). To cater for SVG the svg element name does provide an escape mechanism there.
I'm a _big_ HTML 5 supporter, and I appreciate that you guys did some creativity to figure out how to get SVG and MathML working inside of HTML, which is a great goal, but this _is_ horrifying. There's got to be a better solution. This will be a nightmare moving forward.
How about something like XML Data Islands? http://ajaxpatterns.org/XML_Data_Island
What of RDF/XML inside svg:meta? Say I wanted to include a dc:description in XHTML?
Why are we adding SVG and MathML to HTML5 anyway? If people wanted to use MathML and SVG they could just use XHTML5 and embed them with namespaces. It's a non-issue. Instead, we're creating random controversy and changing some of the ways those languages work?
I just don't get it.
Re Navarr's #42, the issue with xhtml+mathml is lack of support by IE. Some people can't afford to tell 70% of their users to go away because their browser doesn't support xhtml. This forces people to serve up different versions of a page depending on the browser -- or to avoid implementing mathml completely, as is the case, for example, with Wikipedia.
Re Navarr's #42, the issue with xhtml+mathml is lack of support by IE.
I beg to differ. IE supports MathML via a plugin. Safari, Opera, Google Chrome, .... don't support MathML, plugin or no plugin.
This is one instance where IE is (and long has been) ahead of more "Standards-compliant" browsers.
