-
Notifications
You must be signed in to change notification settings - Fork 23
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
Conversation
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.
There was a problem hiding this 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.
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.