The ecmascript from bterlson

ecmascript's Introduction

ECMAScript 6 in HTML

Just give me the spec

Clone the repository, and open spec/index.html in a modern browser.

You may need to start a local http server instead of opening off the file system. If you need an http server, npm install -g http-server works great.

Introduction

The document format for the specification uses Custom Elements and Imports. The custom elements give semantic meaning to ECMAScript constructs and keep markup terse. Imports enable breaking the specification up into many files while avoiding a build step. Everything is plaintext and can be edited with any tool.

The html files were generated from html produced by Jason Orendorf's es-spec tool. The script tasks/parse.js parses the html input and builds the output html under the spec directory. Currently this process introduces some bugs but once the document format is deemed stable the parser can be jettisoned and one-off markup issues fixed manually.

ecmascript's People

Contributors

Stargazers

Watchers

Forkers

arv

ecmascript's Issues

Add page titles

Use the gh-pages branch

Creating a branch called gh-pages allows you to access all the repo’s content via https://bterlson.github.io/ecmascript. You can also rename the current master branch to that and set it as the default branch.

Feature flags

I would like to have infrastructure so that new features can be added to the spec once they have reached a somewhat stable point, while still being tracked as separate features.

New features would be added to the spec surrounded by feature flags, and build infrastructure would allow us to include or exclude specific features when building the specification.

Benefits:

More gradual integration instead of a "big bang" integration once Stage 4 is reached. This will help people working on features see the impact of their changes on other in-progress work.
Ability to generate "canary" or "nightly" builds that include all in-progress work. This will help people see whether things are hanging together.
Ability to generate "Stage 3" ("beta"?) builds that include features that are actively being implemented by multiple browsers and considered stable, but not yet "locked".
A similar structure in test262 would have similar benefits there and provide symmetry across the development of a feature.

Just to be clear, I am not suggesting that features migrate into the main spec once they are accepted as straw men. I am suggesting that once implementors have started to implement a feature, there is value in incorporating it into the shared work that we are all doing. I think a good time for this is Stage 2, but it could make sense to do it earlier if there is active implementor interest.

I don't think this will have the effect of confusing people about the stability of given features. On the contrary, the ability to have very clear stability marking at the spec level will make it clear how far along things are. Using similar tactics and stability marking as shipping browsers will further help us explain what is going on.

Recommend Projects