W3C home > Mailing lists > Public > www-validator@w3.org > March 2016

Re: W3 Markup Validator - HTML5 <time> tag

From: Shane McCarron <shane@aptest.com>
Date: Tue, 1 Mar 2016 16:02:50 -0600
Message-ID: <CAOk_reHfAOM+32jL5iGUn+RWyRp3DnNbVaBQ=LEuZ3TW5x=xZA@mail.gmail.com>
To: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
Cc: testing Cakewalk Websites <testing8467@cakewalkwebsites.com>, "www-validator@w3.org" <www-validator@w3.org>
I filed a bug about this with schema.org

On Tue, Mar 1, 2016 at 8:17 AM, Jukka K. Korpela <jkorpela@cs.tut.fi> wrote:

> 29.2.2016, 19:47, testing Cakewalk Websites wrote:
>
> When correctly adding structured data for opening hours according the
>> schema.org <http://schema.org> and tested with the Google Structured
>> Data Testing Tool
>> <https://developers.google.com/structured-data/testing-tool/>: (enter
>> this URL: http://www.oldtownvethospital.com)
>> <p itemscope itemtype="http://schema.org/VeterinaryCare"><time
>> itemprop="openingHours" datetime=
>>
> > "Mo-Fr 08:30-17:30">Mon - Fri: 8:30 am - 5:30 pm</time></p>
>
>> and shows up as “All good” in “VeterinaryCare (1)”.
>>
>
> It is still invalid HTML. The use of the datetime attribute of <time> in
> the schema, https://schema.org/openingHours , conflicts with the current
> HTML specs (and, as far as I know, any version of HTML that has the <time>
> element). It uses its own syntax for a date range, and a date range is not
> a thing that you can specify as a datetime attribute value. The values, as
> described at
> https://html.spec.whatwg.org/multipage/semantics.html#attr-time-datetime
> can only represent moments of time, a time range of a specific kind such
> as a day, a month, or a year, or a duration (amount of time) – not a range
> of time specified by its start and end. If the definition will ever be
> extended to allow such ranges, it is virtually certain that it will then
> use an ISO 8601 conformant notation, which is rather different from what
> Schema.org uses.
>
> The “Nu Html Checker” shows this as an error.
>>
>
> It’s just doing its job. It checks the document against applicable HTML
> (and some other) specifications.
>
> According to W3schools
>> <http://www.w3schools.com/tags/att_time_datetime.asp>, the <time>
>> attribute cannot contain day names (Monday - Sunday).
>>
>
> Let’s ignore w3schools since it is not in any way relevant in resolving
> this issue (and, in addition to being non-authoritative, it is unreliable).
>
>  1.
>>     *Error*: Bad value |Mo-Fr 08:30-17:30| for attribute |datetime| on
>>     element |time|
>>     <
>> http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-time-element
>> >:
>>
>
> Here the error message explains the problem with the value, and it links
> to the WHATWG HTML specification (using a link to a huge document
> containing the entire spec; above, I have mentioned a more handy address,
> pointing to a multipage version of the spec).
>
>     The literal did not satisfy the time-datetime format.
>>      From line 222, column 79; to line 222, column 137
>>     |naryCare"><time itemprop="openingHours" datetime="Mo-Fr
>>     08:30-17:30">Mon - |
>>
>
> This means that "Mo-Fr 08:30-17:30" is not valid, since it does not match
> any of the allowed patterns for the attribute value. This is a purely
> syntactic statement, and the validator’s job ends here.
>
> But the point is that a date range *cannot* be represented as a datetime
> value at all. In practice, it is not a matter of making a mistake when
> trying to write a range in the correct syntax; there simply is no correct
> syntax for it in this context.
>
> Consequently, using the <time> element at all is wrong, as a matter of
> HTML rules. I suggest that you raise the issue in some suitable forum
> related to Schema.org development. If you ask me, they should simply use
> some other element and attribute names, even though it means that in “pure”
> HTML (as opposite to HTML extended with custom elements), you would need to
> use <span>.
>
> Yucca
>
>
>
>


-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
Received on Tuesday, 1 March 2016 22:03:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 22:03:25 UTC