As many of you might already know, a couple of weeks ago it was announced that the ECMAScript specification has now moved to GitHub. Previously it was available in PDF and HTML format but the actual editing process was done in a Word document – which clearly isn’t the best choice – so the switch to GitHub is great news.
Probably one of the most interesting things about the move is the fact that the document itself is now based on something called Ecmarkup, which is described as:
a number of custom elements and a toolchain suitable for formally specifying semantics for ECMAScript proposals.
In a nutshell, Ecmarkup is an extension of HTML designed specifically for use in the ECMAScript specification document. The aforementioned announcement describes it as “a custom dialect of HTML built for writing ECMAScript specifications”. You can get a glimpse of the markup by inspecting the source of the spec page. Below is a screenshot:
You can see the custom
<emu-xref> elements in use, and the
<emu-clause> element is set to
display: block in the CSS. This is the same sort of thing developers have done with old IE to get it to recognize the new HTML5 elements. Unknown elements start out with no styling, and compute to inline, as explained well by Mark Pilgrim, so these require
display: block to be added in the CSS (assuming they’re used as block elements, of course).
Naturally, if you try to validate a page like this, you’ll get tons of errors similar to the ones shown in the screenshot below:
But before getting to any possible drawbacks to using custom HTML like this, let’s look a little deeper into what’s offered in Ecmarkup.
Continue reading %A Look at Ecmarkup: The ECMAScript Spec’s Custom HTML%