Prism WPD plugin — Telling HTML and XML (SVG, MathML etc) apart

The problem
=============
As you might know, I’m writing a Prism [1] plugin that converts some tokens [3] into links to WPD documentation, both for our use and for developers in general, to promote WPD. A conundrum I ran into was how to do that for HTML and XML languages such as SVG and MathML. Prism currently uses the same language definition for both HTML and XML variants ("markup"), so it was hard for the plugin to decide where to link tokens found in "markup" contexts. 

Solution #1
===========
We chatted about this with Doug last week and we decided on using the WPD API to fetch a list of tags for HTML, SVG and MathML, so that Prism could use those to decide where those tokens [3] would link to. However, when I investigated this idea (thanks fr0zenice for helping with the API!), I encountered a number of issues. Since plugins hook into Prism’s main code, there is no way for a plugin to delay Prism execution (e.g. until an async request finishes). Therefore, the API requests would need to happen synchronously. This is a bad practice and could cause significant delays, making the plugin less appealing to authors. So, this solution is not feasible after all.

Note that we could always make an extended version of the plugin in the future, which makes API requests when somebody hovers over these tokens showing a tooltip or something, which would fetch the API info just-in-time instead of when the page loads.

Solution #2
===========
The idea I’m probably going with (unless somebody has something better to suggest, which is why I'm writing this email) is to defer element recognition to the browser. Every known element (with very few exceptions, which could be special cased) corresponds to a specific interface, e.g. HTMLInputElement or SVGCircleElement. There is a way to get this interface name through JavaScript [2]. Unknown elements on the other hand resolve to different interface names, such as HTMLUnknownElement or HTMLElement or Element, depending on the browser. I’ve verified this is true for both Trident (IE10), WebKit and Gecko.
The main issue I see with this solution is that elements that are not supported by the current browser would not be linked. That's unfortunate, but I don't think it's a blocker.

Hope it all makes sense, I tried to describe it in as much detail as possible. Any feedback and/or advice is welcome!

[1]: http://prismjs.com
[2]: e.g. try document.createElementNS('http://www.w3.org/2000/svg', 'circle').toString()
[3] tokens in this context are the parts of the code that get highlighted, e.g. "tag", "attribute", "property" etc.

Lea Verou
W3C developer relations
http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou