Source Positions

This minor release adds a new parse option includePositions. This is an opt-in feature that when set to true will cause himalaya.parse to emit nodes with a position field, containing start and end points. These points contain the zero-indexed index, line, and column numbers.

See this feature in the README example, the new spec section, and the updated demo page.

See the PR #90 and issue #89 for more information. Currently the position data is limited to only nodes so attributes and tag names do not have associated information, but this may be added later.

Note: this change did uncover some bugs that were fixed as well.

Thanks to @lazarljubenovic for making the issue for this idea. I'm excited to see what it enables, and am very happy to see it implemented so easily and incorporated into tests so well.

Be kind; rewind

This release is a bug fix for issue #84 / PR #86.

There was a problem with unnecessary closing tags causing the parser to exit early, leaving later tags unparsed. For example, </i>x would return []. This is fixed, and tests added to prevent regression.

Thanks to @orballo for reporting this bug.

One Point Oh

This major release includes a lot of changes (re-iterated from the PR):

• Dropping the Version 0 spec. In v0.2 Himalaya underwent huge internal changes in order to support multiple specification simultaneously with a shared parser powering these different formats. In v0.3 we introduced the v1 specification which co-existed alongside v0. While definitely good for v0.x users who won't upgrade, supporting both specs is quite tedious and from an ecosystem standpoint extremely difficult to build around as you have to support every spec in your independent packages. Going forward in v1, we will only support the single spec. The capability for coexisting specs is still there but Himalaya will not advertise or advocate multiple specifications. Refer to the v1 spec for details of the new spec.

• Dropping the CLI tool. Back in 2015, every utility had a CLI tool packaged with it. Himalaya followed suit with a tool of its own that was just enough to say we had one. Even in 2017 the CLI never was treated as a first-class citizen and to its final day had zero tests. A Himalaya CLI tool is not a bad idea, but should be its own package as to not be neglected by the core and also not thrash core's history as the CLI is improved in its own various ways.

• Removing translate. The himalaya/translate module had always been a bit odd. I always wanted it in its own package but it was so frequently needed and so closely tied to the spec I didn't want to break it out. The dream was that it would be the rosetta stone of HTML, bridging the gap between HTML, Jade/Pug, HAML, and what not using Himalaya has the shared AST. That dream is still possible but will have to live in other packages. A nice by-product of this change is that Himalaya now has zero external dependencies, making the package as a whole smaller.

• Adding stringify. To replace the most common use case of the translate module I have increased the core API's method count from 1 to 2. The new method stringify is the toHTML of v1. The naming aligns nicely with JSON.parse/JSON.stringify.

Overall I think that Himalaya v1 is a huge leap forward, if only because its scope is much more limited. There will be bugs, but now that the specification is doing a lot less, I don't plan to be adding new features. Maybe expect a v2 when HTML6 comes out and removes < or whatever.

Version 1 - Prerelease 1

See #74 for the details.

Try this version with:

npm install himalaya@next

Alphanumeric Tags

This patch release aligns Himalaya closer with the spec for HTML5 tag names in regards to valid tag names. Up until now, any characters following an < could be considered a tag name by the parser. Now that < must be immediately followed by an alphanumeric character.

Note: The HTML5 spec only allows purely alphanumeric tag names, but Himalaya will accept any tag name starting with an alphanumeric character. This looseness is for web component folks who get crazy with naming using dashes and whatnot.

See issue #71 / PR #73 for more details; thanks to @figueiredo-lucas for the issue.

The Way of the Future

This minor release introduces the upcoming version 1 specification which will be the default in Himalaya v1.

This minor release does not break existing APIs. This release includes the option to use the version 1 for those interested in getting a head start to the future, use the features of version 1 that are not possible in version 0, and allow us to get feedback on the specification and find potential bugs before the version 0 specification is completely removed in v1.

The high-level benefits of the new specification:

• Faster. The spec does less work as far as processing and formatting.
• Better. The v0 spec was lossy: we lose information about the source material when we process data-*, classes, style, etc, and those "niceties" have been removed.
• Stronger. The attributes is now an array, which is easier to iterate and maintain its ordering.

Please give this new specification a try. There is documentation in the updated README on how to do so.

Thanks to @pahan40, @longjiarun, @themaxsandelin, @armoucar, and others for opening issues on the version 0 specification and offering suggestions that drove the design of the version 1 spec. I'm sorry it took so long.

Colons in CSS values

This patch release fixes CSS values which contain :. Previously, only the bar in foo: bar:baz would be parsed. Now the fully value is added to attributes. This was fixed in PR #62, and reported by @longjiarun in issue #60.

Tabled Tables 2

Continuing the fix from 0.2.11, td and tr also support nested tables.

Tabled Tables

This patch release fixes the behavior of auto-closing tags tbody, thead, and tfoot which should not auto-close if a table is nested inside any of them. (Issue #57 / PR #58)

Thanks to @bhreinb for reporting this bug.

Whitest Space

Himalaya now parses whitespace correctly. Previously only spaces " " were recognized as whitespace by the lexer. Now anything deemed whitespace by the RegExp metacharacter \s is considered whitespace.

The issue with this was opened in #42.