Re: validation problems with respec output

Hi Mike,

On Jul 5, 2012, at 13:10 , Michael[tm] Smith wrote:
> There are a couple problems with current respec that cause respec-generated
> specs to not conform to requirements in the HTML5 spec.

Yup. I knew that the transition to the new validator was on its way, but I didn't know it was happening right now :) So I couldn't plan for a ReSpec update to match.

> 1. <acronym> elements in parts of the generated boilerplate. For better or
> worse <acronym> is not a valid element per the HTML5 spec. So respec should
> instead be using the <abbr> element for those cases ( if the goal is to have
> output conform to the HTML5 spec).

Yes. The default pubrules boilerplate had <acronym> there and ReSpec made the decision very early not to care about that particular useless debate. I've folded the changes you made to switch to <abbr>

> 2. rel="biblioentry" in bibliography links. The HTML5 spec requires all rel
> values to either be defined in the HTML5 spec itself or to be registered as
> a valid values at http://microformats.org/wiki/existing-rel-values
> 
> "biblioentry" is listed there, but in the "dropped" section
> http://microformats.org/wiki/existing-rel-values#dropped which says "In
> general, you should not use any dropped values." And the reason biblioentry
> is listed in that section is because it was once listed in a pre-HTML4
> non-normative "Proposed Relationship Values" draft but never actually ended
> up being included in the HTML4 specification. So there is actually no
> normative specification for biblioentry anywhere.

I took biblioentry years ago because it's something that was produced by some parts of the W3C toolchain (I think it was the CSS preprocessor, at the time). But I don't think anyone relies on this (I couldn't find trace of it being used) so I've pulled it.

> If you prefer to keep the rel=biblioentry output (because there are tools
> you know of and are targeted that actually consume that rel=biblioentry
> data and do something with it) then I propose adding a user option to
> suppress it, and I'm happy to contribute a patch to do that (though lacking
> any normative spec for what it's supposed to mean, I'd really prefer to
> just see it dropped).

Nah, I can't say I care. It's easy to put it back in if it's useful. In the meantime it doesn't seem that anyone is relying on this.

All of these changes (and a few more) will ship in 3.1.13 shortly.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Friday, 6 July 2012 15:05:17 UTC