Bugzilla – Bug 964
<link> element inside <body> should be reported as error
Last modified: 2013-04-16 06:32:12 CEST
Minimal demo: <!doctype html> <title>Test</title> <body> <link rel="stylesheet" href="foo.css"> This passes, but shouldn't, since <body> allowed content is flow content, and <link> is not flow content.
(In reply to comment #0) > Minimal demo: > > <!doctype html> > <title>Test</title> > <body> > <link rel="stylesheet" href="foo.css"> > > This passes, but shouldn't, since <body> allowed content is flow content, and > <link> is not flow content. We have the HTML+RDFa spec to thank for that misfeature. http://www.w3.org/TR/rdfa-in-html/#extensions-to-the-html5-syntax "If any RDFa attribute is present on the link or meta elements, they must be considered flow and phrasing content if used outside of the head of the document." The RDFa specs claim the rel attribute as an "RDFa attribute". Both validator.nu and validator.w3.org/nu include RDFa checking by default. (Not because we like it but mainly just because there are a lot of pages using the Facebook <meta property="og:title" content="foo"> etc., stuff. So it's better to allow that then to have people keep filing bugs asking why they're getting an error for it. And to allow that we have to allow all of RDFa too). If you don't what the RDFa checking you have to manually choose one of the presets that lack it.
I understand the explanation, but this still means that the validator reports a document as valid when it does not satisfy the syntactic requirements of HTML5 CR. The W3C validator even shouts “This document was successfully checked as HTML5!” Validator.nu doesn’t technically say that, but few people will understand what it means when it says, in its response, “Info: Using the schema for HTML5 + SVG 1.1 + MathML 3.0 + RDFa Lite 1.1.” I think authors have the right to expect that to a validator, `<!doctype html>` implies, in absence of explicit selections requesting otherwise, that conformance to HTML5 CR is to be checked. Although `link` inside `body` might not be serious per se, it typically reflects unintentional confusion in document structure and should be reported. Thus, it would be more adequate to have inclusion of RDFa as selectable option rather than the implied default.
> We have the HTML+RDFa spec to thank for that misfeature. No, actually you have the Microdata spec to thank for this misfeature, which took the link element from this: http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-link-element to this: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element This is perfectly valid in Microdata, which would cause the same sort of issue: <link rel="stylesheet" itemprop="narf" href="foo.css"> We followed suit with the RDFa spec because people were complaining that they couldn't do exactly the same sort of information hiding that Microdata does with the LINK element. It's a bad feature, but it didn't originate in RDFa. We never allowed LINK outside of Metadata content until Microdata forced the issue. In any case, the validator could deterministically catch this sort of error in HTML5 since 'stylesheet' isn't a pre-defined term in the HTML+RDFa 1.1 initial context. The markup, while technically legal, does not generate any triples and the validator could generate a warning because of this. Here's the logic for the check: if element == LINK and element in BODY and rel is not a CURIE or ABSOLUTE_URL then "Warning: You should not use the LINK element with a rel value of XXX outside of the HEAD of a document."
(In reply to comment #3) > > We have the HTML+RDFa spec to thank for that misfeature. > > No, actually you have the Microdata spec to thank for this misfeature, which > took the link element from this: > > http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-link-element > > to this: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element > > This is perfectly valid in Microdata, which would cause the same sort of issue: > > <link rel="stylesheet" itemprop="narf" href="foo.css"> It's not the same issue at all, because nobody is likely to ever actually do that. Whereas it's much more likely that somebody would accidentally put a <link rel="stylesheet" href="foo.css"> inside the body of a document. And that's not valid in Microdata. Microdata requires the itemprop attribute if the link element is used inside the body of a document. > We followed suit with the RDFa spec because people were complaining that they > couldn't do exactly the same sort of information hiding that Microdata does > with the LINK element. It's a bad feature, but it didn't originate in RDFa. Like I said, it's not the same. The way it's specced in Microdata makes sense, because it requires the itemprop attribute. That's a sane way to distinguish an intentional use of the link element for Microdata use from an accidental misplacement of a link element that the author actually meant to put in the head. > We never allowed LINK outside of Metadata content until Microdata forced the > issue. > > In any case, the validator could deterministically catch this sort of error in > HTML5 since 'stylesheet' isn't a pre-defined term in the HTML+RDFa 1.1 initial > context. > The markup, while technically legal, Is there any actual normative conformance requirement defined in any of the RDFa specs which states that a term must be pre-defined? > does not generate any triples and > the validator could generate a warning because of this. > > Here's the logic for the check: > > if element == LINK and > element in BODY and > rel is not a CURIE or ABSOLUTE_URL then > "Warning: You should not use the LINK element with a rel value of XXX > outside of the HEAD of a document." But what if the rel value is instead a "pre-defined term in the HTML+RDFa 1.1 initial context"? Are there actually any such terms? That error message is not something the schema backend could generate on its own. No grammar-based schema mechanism could. To implement that I would basically need to write a new datatype checker (in Java, as part of the HTML5 datatype library) solely for the RDFa rel attribute. I don't need to do that for Microdata because the design of Microdata provides a simple way for distinguishing between the two cases. A way that it's possible to express and check solely using a grammar-based schema.
From the most recent RDFa WG telecon: RESOLVED: Restrict the link and meta elements in HTML5+RDFa 1.1 when used in the body to require the usage of @property to be valid. http://www.w3.org/2010/02/rdfa/meetings/2013-02-28#Mike_Smith__28_tm__29___27_s_Complaint I believe this will help resolve this issue solely via the use of a grammar-based schema. Mike, please let me know if we need to do anything further.
(In reply to comment #5) > From the most recent RDFa WG telecon: > > RESOLVED: Restrict the link and meta elements in HTML5+RDFa 1.1 when used in > the body to require the usage of @property to be valid. > > http://www.w3.org/2010/02/rdfa/meetings/2013-02-28#Mike_Smith__28_tm__29___27_s_Complaint Cool :) Thanks much, Manu > I believe this will help resolve this issue solely via the use of a > grammar-based schema. Mike, please let me know if we need to do anything > further. This looks like exactly what we need. I've not looked at it in detail because I'm on vacation for the next week or so. So for now, just replying to say thanks
https://bitbucket.org/validator/syntax/commits/b8c495f29775fe0b0ce6730a2051c74d77de2770 ...and pushed out to the W3C validator.