Are you experiencing an issue with...
shields.io
🐞 Description
The Dynamic XML badge's HTML-tolerant mode (dynamic-xml.service.js, using @xmldom/xmldom's DOMParser with contentType: 'text/html') fails to parse almost any real-world github.com page. The reason is that @xmldom/xmldom does not implement the HTML5 spec's "optional tags" rule, which allows elements like <option>, <li>, <tr>, <td>, and <p> to omit their closing tag because a following sibling implicitly closes them. See https://html.spec.whatwg.org/#optional-tags for the spec definition. This is a documented, acknowledged limitation in xmldom's own source comments (lib/conventions.js):
"xmldom does not have any logic for optional end tags cases (like li, tr and others)... will report them as a warning. Content that would go into the unopened element will instead be added as a sibling text node."
In practice this throws, or produces an opaque empty message error rendered as "invalid", on virtually every github.com page that uses a <select>/<option> dropdown. That is nearly all of them (repo pages, org profiles, login, package pages, etc.), because those dropdowns rely on implied closing of <option>. Only GitHub's separate docs style templates (e.g. github.com/site/terms) happen to avoid this and parse successfully.
This makes it impossible to use Dynamic XML badges against most real world sites, not just github.com, that use standard, spec valid HTML5 markup relying on optional end tags. This is a very common markup pattern.
🔗 Link to the badge
Failing (real GitHub pages, all valid HTML5):
Working (pages without <select>/optional-tag markup):
💡 Possible Solution
Two possible fix directions:
- Contribute HTML5 "optional end tag" inference to
@xmldom/xmldom itself. It is a finite, well defined element list per spec, so this should be a bounded change that stops the parser from mis-nesting content and throwing.
- Longer term, swap the HTML-tolerant parsing path in
dynamic-xml.service.js for a spec compliant HTML5 parser, such as parse5 (the reference implementation also used by jsdom). This correctly implements tree construction including implied tag closing. Its output tree would need a small adapter for the existing xpath npm package to query.
Related existing issue on the same code path: #10827 (lowercase <!doctype> also breaks parsing here).
Are you experiencing an issue with...
shields.io
🐞 Description
The Dynamic XML badge's HTML-tolerant mode (
dynamic-xml.service.js, using@xmldom/xmldom'sDOMParserwithcontentType: 'text/html') fails to parse almost any real-worldgithub.compage. The reason is that@xmldom/xmldomdoes not implement the HTML5 spec's "optional tags" rule, which allows elements like<option>,<li>,<tr>,<td>, and<p>to omit their closing tag because a following sibling implicitly closes them. See https://html.spec.whatwg.org/#optional-tags for the spec definition. This is a documented, acknowledged limitation in xmldom's own source comments (lib/conventions.js):In practice this throws, or produces an opaque empty message error rendered as "invalid", on virtually every
github.compage that uses a<select>/<option>dropdown. That is nearly all of them (repo pages, org profiles, login, package pages, etc.), because those dropdowns rely on implied closing of<option>. Only GitHub's separate docs style templates (e.g.github.com/site/terms) happen to avoid this and parse successfully.This makes it impossible to use Dynamic XML badges against most real world sites, not just github.com, that use standard, spec valid HTML5 markup relying on optional end tags. This is a very common markup pattern.
🔗 Link to the badge
Failing (real GitHub pages, all valid HTML5):
Working (pages without
<select>/optional-tag markup):💡 Possible Solution
Two possible fix directions:
@xmldom/xmldomitself. It is a finite, well defined element list per spec, so this should be a bounded change that stops the parser from mis-nesting content and throwing.dynamic-xml.service.jsfor a spec compliant HTML5 parser, such asparse5(the reference implementation also used byjsdom). This correctly implements tree construction including implied tag closing. Its output tree would need a small adapter for the existingxpathnpm package to query.Related existing issue on the same code path: #10827 (lowercase
<!doctype>also breaks parsing here).