Please define meta@property conformance requirements precisely

RDFa Working Group, please handle this as a formal comment on the spec
"HTML+RDFa 1.1" at http://www.w3.org/TR/2013/PR-html-rdfa-20130625/

Comment:
In the "HTML+RDFa 1.1" spec, please add precise and unambiguous document-
conformance requirements for the case of a <meta> element that has a
"property" attribute.

Here's some proposed language:

  A <meta> element that specifies the "property" attribute can be used in
  an HTML document where the HTML specification states that metadata
  content is expected and where the HTML specification states that phrasing
  content is expected. The element must specify the "content" attribute but
  must not specify the "http-equiv" or "charset" attributes. If the element
  appears where metadata content is expected, it may specify the "name"
  attribute, but if the element appears where phrasing content is expected,
  it must not specify the "name" attribute.

Context:
I've implemented support for validating RDFa in HTML in the W3C validator
and found that the spec is unclear about which (if any) of the following
cases are meant to be conforming.

  A. meta@name in head of a document with "property" attribute
     <head><meta name="author" property="foo" content="Mike Smith"></head>

  B. meta@name in body of a document with "property" attribute
     <div><meta name="author" property="foo" content="Mike Smith"></div>

  C. meta@http-equiv in head with "property" attribute
     <head><meta http-equiv="refresh" property="foo" content="300"></head>

  D. meta@http-equiv in body with "property" attribute
     <div><meta http-equiv="Refresh" property="foo" content="300"></div>

  E. meta@charset in body with "property" attribute
     <div><meta charset="utf-8" property="foo"></div>

  F. meta@charset in head with a "property" attribute
     <head><meta charset="utf-8" property="foo"></head>

  G. meta with "name", "http-equiv", "charset", and "property" attributes
     <meta name="author" http-equiv="Refresh" charset="utf-8" content="300" property="foo">

The current spec doesn't clearly prohibit any of the above.

None of B-G make any sense at all and should be clearly prohibited by the spec.

I'd prefer that A be prohibited as well, but I know of instances where
people do it for some reason and expect it to be valid, so I would not
argue strongly against making it valid if the WG prefers it that way.

Below is the full text of what the "HTML+RDFa 1.1" spec currently says about
<meta>, along with my specific comments on what's problematic about each part.

1. "If the @property RDFa attribute is present on the link or meta
elements, they must be viewed as conforming if used in the body of the
document."

  That language makes meta@http-equiv and meta@charset and meta@name
  allowed in the body of a document, as long as the "property" attribute is
  present. I'd guess that the editors of the spec did not actually intend
  for meta@http-equiv and meta@charset and meta@name to be allowed in the
  body of a document, so some further language needs to be added to
  explicitly disallow them in the body.

  Also, the above language allows <meta> elements anywhere within the body
  of a document, including cases like these:

  <ul><meta property="..." content="..."><li>
  <table><meta property="..." content="..."><tbody>

  And "must be viewed as conforming" is not precise language for document
  conformance and not consistent with the language that the HTML spec uses.

2. "More specifically, when link or meta elements contain the RDFa @property
attribute and are used in the body of an HTML5 document, they must be
considered flow content."

  If the intent here is only to allow meta@property in specific places, not
  just anywhere in the body, then please completely remove the "conforming
  if used in the body of the document" language and use only the language
  that precisely states where meta@@property is actually allowed.

  Also "must be considered [something]" is not precise language for
  document conformance, and not consistent with the language that the HTML
  spec uses.

  And I'd think the HTML+RDFa 1.1 spec should actually allow <meta> and
  <link> where *phrasing* content is expected, not just where flow content
  is expected.

  Phrasing content can appear in more places than flow content can, and I
  don't see a good reason why you'd want to restrict meta@property to being
  allowed only where flow content is expected -- especially since authors
  are likely to end up using it in places where flow content is not
  expected, and as far as I understand the RDFa processing model, it'll get
  processed just the same regardless of where it appears.

3. "If the RDFa @property attribute is present on the meta element, neither
the @name, @http-equiv, nor @charset attributes are required and the
@content attribute must be specified."

  That language seems to be intended to alter the HTML spec restriction
  that "exactly one of the name, http-equiv, charset attributes must be
  specified" to allow for the meta@property. But what the overall language
  for meta@property is doing is, it's completely removing the HTML spec's
  restriction that "exactly one of the name, http-equiv, charset attributes
  must be specified", and replacing it with ambiguity.
  
  I'm sure you don't mean to allow all of them to be specified at the same
  time, or even to allow other combinations of them. But if the requirement
  is no longer that "exactly one of the name, http-equiv, charset
  attributes must be specified", then what exactly is allowed instead?

  I think instead you'd want to say that the "http-equiv" and "charset"
  attributes must not be specified, and that the "name" attribute must not
  be specified if the meta element appears where phrasing content is expected
  (or where flow content is allowed, if for some reason you actually don't
  want it to be allowed in all places where phrasing content is expected).

Due the problems noted above, I'd suggest taking out all the current
language in the HTML+RDFa 1.1 spec about the <meta> element, and replacing
it with something like the proposed language in my comment at the beginning
of this message.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike

Received on Friday, 12 July 2013 10:52:34 UTC