ecmascript 规范_看看Ecmarkup：ECMAScript规范的自定义HTML-优快云博客

ecmascript 规范

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.

正如你们许多人可能已经知道，几个星期前就宣布了ECMAScript规范现在已经转移到GitHub上。以前，它以PDF和HTML格式提供，但实际的编辑过程是在Word文档中完成的-这显然不是最佳选择-因此改用GitHub是个好消息。

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:

有关此举的最有趣的事情之一可能是该文档本身现在基于称为Ecmarkup的东西，它被描述为：

a number of custom elements and a toolchain suitable for formally specifying semantics for ECMAScript proposals.

大量的自定义元素和工具链，适用于为ECMAScript建议正式指定语义。

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:

简而言之，Ecmarkup是HTML的扩展，专门用于ECMAScript规范文档中。上述公告将其描述为“为编写ECMAScript规范而构建HTML的自定义方言”。您可以通过查看规范页面的源代码来一窥标记。以下是屏幕截图：

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).

您可以看到正在使用的自定义<emu-clause>和<emu-xref>元素，并且<emu-clause>元素在CSS中设置为display: block 。这与开发人员对旧IE所做的相同，以使其能够识别新HTML5元素。正如Mark Pilgrim所解释的那样，未知元素开始时没有样式，然后进行内联计算，因此这些元素需要display: block添加到CSS中(当然，假设它们被用作块元素)。

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.

但是在了解使用此类自定义HTML可能带来的弊端之前，让我们更深入地了解Ecmarkup中提供的功能。

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.

几乎所有Ecmarkup自定义元素与开始emu-前缀。这与大而有趣的澳大利亚鸟类无关。它只是“ Ecmarkup”的缩写。 Ecmarkup规范本身基于Ecmarkup构建，因此您可以在此处插入Inception笑话。

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.
子句： <emu-clause>元素是最常用的元素之一。作为其使用的一个示例，规范中涉及全局对象的部分被包装在单个<emu-clause>元素中，并在其内部嵌套了其他<emu-clause>元素。因此，此元素的工作原理类似于HTML5的<section>和<article>元素。
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.
注意：这些是使用<emu-note>元素表示的，是自我解释；它们在子句中指示旁注。在hasOwnProperty()方法的部分底部找到一个示例。
Inline Elements: In addition to block-level elements, Ecmarkup offers inline elements, including <emu-const> and <emu-val>.
内联元素 ：除了块级元素外，Ecmarkup还提供内联元素，包括<emu-const>和<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.
交叉引用 ：这些元素使用ID属性交叉引用规范的其他部分。它们可能指向条款，注释，示例，图形，表格等。它们不会替代常规链接，而是用于包装它们。
Algorithms and Equations: Indicated using <emu-alg> and <emu-eqn> elements, used throughout the spec.
算法和方程式 ：在整个规范中使用<emu-alg>和<emu-eqn>元素表示。
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.
表格和数字 ：这些分别用<emu-table>和<emu-figure> 。就像交叉引用一样，它们不能代替常规的表和图形元素。他们把它们结语。这是一张桌子的例子，这是一张图。如果检查页面上的元素，则会在源代码中看到这些自定义元素。

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.

规范文档的源代码中包含其他未在Ecmarkup规范中讨论的元素(例如<emu-geq> )。当我向规范的编辑Brian Terlson询问时，他解释说某些元素存在并在其生成过程中生成以用于样式设计，但不希望作者使用。

自定义HTML的可能缺点 (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.

从技术上讲，正如Terlson通过电子邮件确认的那样，ECMAScript规范的自定义HTML与执行自定义元素的标准方式不符。例如，他们没有按规范要求注册元素。仅这个事实就可能引发一些危险信号。

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.

另外，通过避免使用HTML的标准元素，可以抑制可访问性带来的好处。例如，大多数浏览器都通过针对屏幕阅读器和其他辅助技术的可访问性API公开语义。通过使用未知元素，这些潜在的好处就会丧失。当然，自定义元素(如果以非标准方式完成)在语义上将与普通的<div>处于同一级别，因此可访问性不一定会有任何损失，只是没有收获。

自定义HTML的好处 (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.

尽管HTML在语义上是一种相当丰富的语言，但是有时可用的选择不够具体。撇开缺点，规范对这些自定义元素所做的工作是独特的，并为从事新项目的开发人员树立了一个有趣的先例。

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之类的Web应用程序上的源，如以下屏幕快照所示：

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.

也许Gmail的开发人员可以采用某种过程使处理所有标记变得更容易(大多数标记可能是通过JavaScript生成的)，但是通过使用一组自定义标记(例如， 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.

当然，我并不是说ECMAScript规范文档是第一个做这种事情的人，但是项目的可视性无疑使这项技术引起了人们的关注。

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.

我还应该指出，在这种情况下，使用emu-前缀是正确的方法。这样可以确保元素实际上一天不会真正存在，然后在以后的浏览器中中断。例如，尽管文档使用<code>和<var>元素(它们都是有效HTML元素)，但是所有新元素都加上了前缀，以避免将来与HTML规范发生任何冲突。

最后的想法 (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.

我仍然希望更好地了解在新的ECMAScript规范中如何使用Ecmarkup，但这足以使您对它们所做的事情有一个体面的了解，以及可能的优点和缺点。亲自检查新规范并查看源代码。

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?

你觉得呢？你有没有什么想法？您是否认为以这种方式使用自定义元素可以使更多应用受益？还是以此方式超出标准存在太多问题？