W3C home > Mailing lists > Public > www-validator@w3.org > August 2013

Re: Itemscope validation

From: Andry Rendy <master.skywalker.88@gmail.com>
Date: Mon, 19 Aug 2013 20:41:46 +0200
Message-ID: <CAGxST9k5_KL6K4+G61RKrEUxSwchywZ5nf=MZKfNfW2zQ5HTmA@mail.gmail.com>
To: "Michael[tm] Smith" <mike@w3.org>
Cc: "Jukka K. Korpela" <jkorpela@cs.tut.fi>, "www-validator@w3.org" <www-validator@w3.org>
It sounds a bit more complicated than what I read in these messages. First,
something from validation results. I used the same document of my first
message, omitting the xmlns:fb invalid namespace declaration.
Validation tests & results as follows:
---
<!DOCTYPE html>
<html itemscope itemtype="http://schema.org/WebPage">
  <head>
    <title itemprop="name" property="og:title">An Example Title</title>
    <meta name="description" itemprop="description"
property="og:description" content="Lorem ipsum dolor sit amet" />
    <meta itemprop="image" property="og:image" content="
http://www.example.com/image.jpg" />
    <link rel="canonical" itemprop="url" property="og:url" href="
http://www.example.com/permalink" />
  </head>
  <body>
    ...content...
  </body>
</html>
Here the attributes @itemprop and @property are considered invalid
alternatively, thus *itemprop="description"*, *property="og:image"*, *
itemprop="url"* are invalid attributes.
Also, it must be noted that while the conflict between @itemprop and
@property is solved in a strange manner, neither of the 2 attributes seems
to be invalid *per se*, but only if validated in combination and only on
<meta> and <link> elements. I must also notice that the @name is considered
out of place if inserted after one of the mentioned attributes.
---

---
<!DOCTYPE html>
<html itemscope itemtype="http://schema.org/WebPage">
  <head>
    <title itemprop="name" property="og:title">An Example Title</title>
    <meta name="description" property="og:description" content="Lorem ipsum
dolor sit amet" />
    <meta itemprop="image" content="http://www.example.com/image.jpg" />
    <link rel="canonical" itemprop="url" property="og:url" href="
http://www.example.com/permalink" />
  </head>
  <body>
    ...content...
  </body>
</html>
As mentioned before, after some corrections, this test indicates an error
only on <link> attribute. The error refers to @itemprop, "not allowed on
element link<http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-link-element>
at
this point". It is a matter of conflict between attributes, exactly as
before on @name. In fact, changing positions between @rel and @itemprop,
the same statement appears *referred to the @rel attribute*!
---

The validator behavior is erratical itself. Even requiring a verbose
output, the spec does not explain the nature of the error, in fact both
@itemprop and @property are never listed as allowed attributes, but
"sometimes" they are considered "valid".

Now let's talk about previous answers.

>The solution is to not use "itemprop" and  property on the same element.
But they are allowed on <title>. And on other elements. So there is a
conflict between what specs say if taken separately and what validator
allows. It is not super at all, as far as a developer doesn't know exactly
what to do.

>> That's a bit confusing, but what about <meta property=... itemprop=...>?
>> Which rule forbids it?

>The W3C HTML 5.0 spec forbids it; it doesn't allow the meta element to
have either a "property" attribute or an "itemprop" attribute.
It is now clear that, although the spec forbids it, they work elsewhere. In
addition, below the cited lines it is said that both Microdata spec and
Microdata requirements as respected by HTML specs allow the use of
@itemscope/@itemprop, while HTML+RDFa allow @property but do not define
@itemprop. Put simply, what can WE DEVELOPERS AND/OR WEB DESIGNERS do in
order to achieve a so simple thing? HTML+RDFa+Microdata or
HTML(Microdata-compliant)+RDFa spec. What is the correct iter we have to
follow? It is important, indeed, because it has to do with delicate data,
i.e. metadata, which are a problem because they go beyond what the user
strictly sees. Not only must a developer write some info at least twice,
but also it must be done for machine-readable-only pieces of information.
It sounds frustrating. But I think there can be security issues too.

>If by "dual meta tag" you mean using two separate meta elements, one with "property"
and one with "itemprop", then I don't see any harm in that either.
What if a developer writes a page that behaves differently basing on what
metadata set is accepted? Let's make an example. A popular search engine
uses Microdata to show a webpage on search results. While at the same time
a popular social network appears to prefer RDFa property attribute and it
uses <meta@property> to fetch titles, thumbnails and descriptions to show
on its own web applications. If I am forced to use different meta data I
can make errors and write different things for different platforms. I can
also think that a malicious web developer could decide to insert different
contents *deliberately*, I can imagine several billion purposes for this.
My message was extra long. I summarize:

   1. Validator.w3.org/nu doesn't really follow specs:
      - sometimes it considers @itemprop valid,
      - elsewhere it prefers @property,
      - on elements different from meta both are valid,
      - so none of them is really valid on its own. Nor invalid. Nor
      compatible with each other. Nor incompatible. So what?
   2. Is it possible to influence specs towards a more complete
   implementation of several metadata standards? How??
      - It would be easier than influencing web application to follow just
      one type of meta contents;
      - it would encourage the use of metadata and would make pages richer
      and easier to index;
      - it would discourage errors or deliberate discrepancies in meta
      data. I think that it is important stuff.

Sorry for being so talkative and thanks in advance.
Received on Monday, 19 August 2013 18:42:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:18:09 UTC