Allow non-HTML-encoded entities

[ljharb]

Things like < would be much nicer to work with as < in spec.html - is this something ecmarkup/ecmarkdown could handle for us?

[bterlson]

Spec.html should be utf-8 encoded and html entities should only be used when needed. Eg. a < b should be fine, although I could be wrong about that. I plan on doing this work along with the big Ecmarkdown 3.0 conversion post-snapshot.

[ljharb]

awesome - we might want to set up a travis task to specifically lint for all the things we don't want included in spec.html - like html entities, or internal slots with non-uppercase code points, etc?

[bterlson]

Sure, I would love for npm test to actually do something useful ;)

[musgravejw]

Trying to follow up on this thread, would this issue require tests and/or a feature in ecmarkdown?

[mathiasbynens]

a < b works but is not valid HTML. a > b OTOH is valid.

[ljharb]

Sure, but ecmarkup input isn’t valid html already :-)

[mathiasbynens]

Right. I was pointing out that the case for which ecmarkup doesn’t have to do anything special is a > b rather than a < b. (re: @bterlson’s comment)

[bakkot]

Per editor call today, now that we have an auto-formatter, we'll have the formatter translate from HTML entity style (which some people prefer to write) to actual code points (which most people prefer to read).

So the editorial convention will be that spec.html has actual code points (except for < and &), but people won't need to remember the rules (as long as they remember to npm run format).

[michaelficarra]

Fixed by #2901.