HTML & CSS
Article

A Look at Ecmarkup: The ECMAScript Spec’s Custom HTML

By Louis Lazaris

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:

Example of Ecmarkup's custom tags

You can see the custom <emu-clause> and <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:

Ecmarkup's validation errors

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.

Features of Ecmarkup

Almost all the custom elements in Ecmarkup begin with the emu- prefix. This has nothing to do with big funny-looking Australian birds; it’s simply an abbreviation for “Ecmarkup”. The Ecmarkup specification itself is built on Ecmarkup and so you can insert your Inception joke here.

Here are some features of the language:

  • Clauses: The <emu-clause> element is one of the most commonly-used elements. As an example of its use, the section in the spec covering the global object is wrapped in a single <emu-clause> element and has other <emu-clause> elements nested inside of it. So this element works somewhat like HTML5’s <section> and <article> elements.
  • Notes: These are indicated using <emu-note> elements and are self explanatory; they indicate side notes inside clauses. An example is found at the bottom of the section on the hasOwnProperty() method.
  • Inline Elements: In addition to block-level elements, Ecmarkup offers inline elements, including <emu-const> and <emu-val>.
  • Cross-references: These elements cross-reference other parts of the spec, using ID attributes. They might point to clauses, notes, examples, figures, tables, etc. These don’t replace regular links but are used to wrap them.
  • Algorithms and Equations: Indicated using <emu-alg> and <emu-eqn> elements, used throughout the spec.
  • Tables and Figures: These are indicated using <emu-table> and <emu-figure>, respectively. Just like cross-references, these don’t replace the regular table and figure elements; they wrap them. Here’s an example of a table and here’s a figure. If you inspect the elements on the page, you’ll see these custom elements in use in the source.

There are other elements included in the source of the spec document that are not discussed in the Ecmarkup specification (e.g. <emu-geq>). When I asked Brian Terlson, the spec’s editor, about this, he explained that some elements exist and are generated in their build process for styling purposes but aren’t expected to be used by authors.

Possible Drawbacks of Custom HTML

Technically, as Terlson confirmed via email, the ECMAScript spec’s custom HTML is not in line with the standard way to do custom elements. For example, they don’t register the elements as the spec requires. This fact alone might throw up a few red flags.

In addition, by avoiding HTML’s standard elements, accessibility benefits might be stifled. For example, most browsers expose semantics via accessibility APIs for screen readers and other assistive technology. By using unknown elements, these potential benefits are lost. Of course, custom elements, if done in a nonstandard way, will semantically be on the same level as a plain <div>, so there won’t necessarily be any loss in accessibility, just no gains.

Benefits of Custom HTML

Although HTML is a fairly rich language in terms of semantics, sometimes the available choices are not quite specific enough. Drawbacks aside, what the spec has done with these custom elements is unique and sets an interesting precedent for developers working on new projects.

Some complex apps require tons of markup. Try inspecting the source on a web app like Gmail, for example, as shown in this screenshot:

Gmail's div soup

Maybe Gmail’s developers have some kind of process to make it easier to deal with all that markup (most of it likely being generated via JavaScript), but a lot of that could be made easier to maintain with a custom set of tags like that found in Ecmarkup.

Of course, I’m not suggesting that the ECMAScript spec document is the first to do this sort of thing, but the visibility of the project certainly brings this technique into the spotlight a little bit.

I should also point out that the use of the emu- prefix is the right way to go in a case like this. This ensures that the elements won’t actually exist one day and then break in future browsers. For example, although the document uses the <code> and <var> elements (both of which are valid HTML elements), all new elements are prefixed to avoid any future conflict with the HTML spec.

Final Thoughts

I’m still hoping to understand better how Ecmarkup is used in the new ECMAScript spec, but this should suffice to give you a decent overview of what they’ve done, along with the possible benefits and drawbacks. Check out the new spec for yourself and poke around the source.

What are your thoughts? Do you think more apps could benefit from using custom elements in this way? Or are there too many problems with going outside the standards in this way?

  • http://careersreport.com mai.morrison

    This is how it is possible to get paid eighty-five bucks /h… After searching for a job that suits me for six months , I started freelancing over this website and now I possibly could not be happier. 3 months have passed since being on my new job and my income is around five-thousand $/per month -Check site check out my disqus profile for more info

  • http://careersreport.com virgie_foster2

    Here is a technique how you can earn eighty-five dollars an hour… After being unemployed for half a year , I started working over this website and now I can not be more happy. After 3 months doing this my income is around five-thousand $/month -Check internet website check out my disqus profile for more info

  • Zlatan Beogradlija

    Hi Louis,
    I am not good with JS, or programming in general. So some of this may be over my head. Can you, or someone, tell me what is the point of yet another markup-like language. It seams that now almost every programming language is developing it’s own markup version, markdown, or a templating engine. I realize they probably need it for themselves, but what does that have to do with email, or website, rendering? Shouldn’t we get vendors to better implement HTML and CSS?
    My second question, and I do realize Jade is templating language but what is a difference? I don’t fully understand the difference between that and, for example, using markdown. Neither one is renderable by any browser as far as I know.
    Also from above mentioned website, ECMAscript 2016 language specification, third paragraph on Conformance.

    “A conforming implementation of ECMAScript that provides an application
    programming interface that supports programs that need to adapt to the
    linguistic and cultural conventions used by different human languages
    and countries must implement the interface defined by the most recent
    edition of ECMA-402 that is compatible with this specification.”

    How would this be implemented and why do we need it?

    Sorry for a long post. Also, English is my second language so my questions might not make much sense.

    • LouisLazaris

      Can you, or someone, tell me what is the point of yet another markup-like language.

      In this case, this is not a markup language that’s supposed to be used by anyone except those editing the ECMAScript spec. Maybe I should have made that more clear. As you can see in the definition in the beginning of the article, it’s specifically “for writing ECMAScript specifications”.

      It seams that now almost every programming language is developing it’s own markup version, markdown, or a templating engine

      Markdown and templating engines are two completely different things. Markdown is a general language for writing documents, sometimes web content. Jade is a template language that helps to write HTML in briefer, more maintainable format. Jade and Markdown are not in competition with each other. Although they sometimes might be used for the same purpose, they are different things.

      Shouldn’t we get vendors to better implement HTML and CSS?

      Yes, but using Markdown or Jade doesn’t change that. Markdown or Jade don’t have any impact on web standards. They are just shortcuts to produce web standard code. Kind of like an API, which is an interface with shortcuts to more complex stuff being done behind the scenes.

      My second question, and I do realize Jade is templating language but what is a difference? I don’t fully understand the difference between that and, for example, using markdown. Neither one is renderable by any browser as far as I know.

      Jade is compiled prior to being rendered by the browser. The browser doesn’t see Jade, it just sees HTML, which is what Jade produces before the browser gets the page. Again, it’s just a shortcut for HTML. It’s not supposed to be understood by the browser. You don’t have to learn Jade or Markdown in order to make web pages. Those are just shortcuts that can help you produce faster documents, if you so choose.

      Also from above mentioned website, ECMAscript 2016 language specification, third paragraph on Conformance.

      I don’t think you need to worry about this at all. That’s not really a note for JavaScript programmers. I never use the ES spec for my research. It’s much too complex. I stick to resources like MDN.

      • UniqueUsernameOfSomeGuy

        Thank you for the clarification.

  • http://www.mobileapptelligence.com/ kailash mobileapptelligence

    HTML5 is cross platform and specially designed to deliver rich media contents. Today, HTML5 development is widely used with CSS3 for dynamic visual effects and compatibility on all mobile devices.

    Mobileapptelligence [dot] com, is an award winning HTML5 app development company, delivering HTML5 apps and games to global clients.

Recommended

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the latest in Front-end, once a week, for free.