Skip to content
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

Add parsing of definitions specific to HTML spec #340

Merged
merged 5 commits into from
Jun 30, 2020
Merged

Add parsing of definitions specific to HTML spec #340

merged 5 commits into from
Jun 30, 2020

Conversation

dontcallmedom
Copy link
Member

The HTML spec does not follow the markup conventions to properly type and associate definitions, so it needs special handling.

A lot is encoded in the ids of the definition elements, but not all the data (e.g. no distinction between attributes and methods), and there are many exceptions to the general conventions on id building.

Figuring out the right output requires additional knowledge that is available through the WebIDL fragments embedded in the spec, so we make use of that.

The diff of the generated definitions is large (2000+ definitions have a changed type), so a bit hard to meaningfully review. I think the result is statistically much better, so even if there are regressions hidden in the middle, that's probably still an overall improvement.

I'm separately looking into whether the said improved definitions can be upstreamed into the HTML spec.

The HTML spec does not follow the markup conventions to properly type and associate definitions, so it needs special handling.

A lot is encoded in the ids of the definition elements, but not all the data (e.g. no distinction between attributes and methods), and there are many exceptions to the general conventions on id building.

Figuring out the right output requires additional knowledge that is available through the WebIDL fragments embedded in the spec, so we make use of that.
Copy link
Member

@tidoust tidoust left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See inline for one main comment on ES modules, and a few nits.

The whole thing is rather ugly and seems easy to "break", but there is unfortunately not much that can be done about it. Good thing to have written tests, including one that checks that things won't break if the HTML spec starts following the convention used in other specs.

src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
src/browserlib/extract-dfns.js Outdated Show resolved Hide resolved
tests/extract-dfns.js Show resolved Hide resolved
src/lib/util.js Outdated Show resolved Hide resolved
@tidoust tidoust merged commit 15adb94 into master Jun 30, 2020
@tidoust tidoust deleted the html-dfns branch August 27, 2020 08:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants