New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow non-HTML-encoded entities #404

Open
ljharb opened this Issue Feb 23, 2016 · 7 comments

Comments

Projects
None yet
4 participants
@ljharb
Member

ljharb commented Feb 23, 2016

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

@bterlson

This comment has been minimized.

Show comment
Hide comment
@bterlson

bterlson Feb 24, 2016

Member

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.

Member

bterlson commented Feb 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Feb 24, 2016

Member

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?

Member

ljharb commented Feb 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bterlson

bterlson Feb 24, 2016

Member

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

Member

bterlson commented Feb 24, 2016

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

@musgravejw

This comment has been minimized.

Show comment
Hide comment
@musgravejw

musgravejw Apr 19, 2018

Contributor

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

Contributor

musgravejw commented Apr 19, 2018

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

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Apr 19, 2018

Member

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

Member

mathiasbynens commented Apr 19, 2018

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

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Apr 19, 2018

Member

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

Member

ljharb commented Apr 19, 2018

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

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Apr 19, 2018

Member

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)

Member

mathiasbynens commented Apr 19, 2018

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment