Bikeshed inserts invalid `<l>` elements in generated html, which prevents publication
svgeesus opened this issue · comments
Given this bikeshed source:
<pre class="propdef">
Name: font-family
Value: [ <<family-name>> | <<generic-family>> ]#
Initial: depends on user agent
Applies to: all elements and text
Inherited: yes
Percentages: n/a
Computed value: list, each item a string and/or <<generic-family>> keywords
Animation type: discrete
</pre>Bikeshed emits, for the family name
<pre class="prod highlight"><l><a class="production" data-link-type="type" href="#family-name-value"
id="ref-for-family-name-value④"><family-name></a></l> = <a class="production"
data-link-type="type" href="https://www.w3.org/TR/css-values-4/#string-value"
id="ref-for-string-value"><string></a> <a data-link-type="grammar"
href="https://www.w3.org/TR/css-values-4/#comb-one" id="ref-for-comb-one①">|</a>
<a class="production" data-link-type="type" href="https://www.w3.org/TR/css-values-4/#identifier-value"
id="ref-for-identifier-value"><custom-ident></a><a data-link-type="grammar"
href="https://www.w3.org/TR/css-values-4/#mult-one-plus" id="ref-for-mult-one-plus">+</a></pre>This contain an <l> element, resulting in a fatal error from the pubrules validator
[1339@31] Element “l” not allowed as child of element “pre” in this context. (Suppressing further errors from this subtree.)
HTML validator
All normative representations must validate as HTML5 with the following limitations:
Inline markup for MathML is permitted but should use a (fallback) alternative.
If the HTML5 validator issues content warnings, the publication request must include rationale why the warning is not problematic.
$ bikeshed --version
3.13.1
(I'ts not relevant for this bug, but fyi you're fairly behind on updates - 3.14.0 was released five months ago.)
Hm, I'd thought I transformed all of those elements back into spans. I'll check what's up.
Done
$ pipx upgrade bikeshed
upgraded package bikeshed from 3.13.1 to 3.14.5 (location: /home/chris/.local/pipx/venvs/bikeshed)
Still seeing the <l> elements after bikeshed upgrade to 3.14.5
I'ts not relevant for this bug
^_^
Fixed in 4.0.2, I did indeed have a few cases where I didn't clean up the <l>.
(Btw, it's line 291 of Fonts 4 that was triggering this, not line 121.)
Thanks!
Did you also deal with
<pre class="highlight"><c- k>font-family</c-><c- p>:</c-> Red/Black<c- p>,</c-> sans-serif<c- p>;</c->
<c- k>font-family</c-><c- p>:</c-> <c- s>"Lucida"</c-> Grande<c- p>,</c-> sans-serif<c- p>;</c->
<c- k>font-family</c-><c- p>:</c-> Ahem!<c- p>,</c-> sans-serif<c- p>;</c->
<c- k>font-family</c-><c- p>:</c-> test<c- n>@foo</c-><c- p>,</c-> sans-serif<c- p>;</c->
<c- k>font-family</c-><c- p>:</c-> #POUND<c- p>,</c-> sans-serif<c- p>;</c->
<c- k>font-family</c-><c- p>:</c-> Hawaii <c- m>5</c-><c- k>-</c-><c- m>0</c-><c- p>,</c-> sans-serif<c- p>;</c->
</pre>
I'm not sure what you're referring to.
The HTML5 element index does not list a <c-> element
Did aeadbad result in a new version number? pipx asserts:
bikeshed is already at latest version 3.14.5 (location: /home/chris/.local/pipx/venvs/bikeshed)
Latest is... 4.0.2
$ pipx upgrade bikeshed && bikeshed update
upgraded package bikeshed from 4.0.0 to 4.0.2 (location: /home/jsbell/.local/pipx/venvs/bikeshed)
Updating via manifest...
Gathering local manifest data...
Fetching remote manifest data...
Updating 74 files...
Done!
The HTML5 element index does not list a element
Right, because it doesn't list custom elements (for obvious reasons). <c-> is a perfectly valid custom element.