Re: The cite and pubdate attributes

Hixie wrote:
> The whole point here is to be able to convert HTML to Atom without  
> having
> to annotate the document with classes everywhere, so a solution that
> relies on sprinkling classes everywhere is a non-starter. :-)

I agree. That's why I said:
> I'm not in favour of "blessing" certain uses of the class attribute  
> in the spec (I think the ad-hoc approach of microformats works just  
> fine).

I was simply pointing out the existence of hAtom as a way of solving  
this very use case *outside* the spec. I wasn't suggesting adding  
hAtom to the HTML5 spec.

Hixie wrote:
>> <article>
>>  <header>
>>    <h2><a href="blah" rel="bookmark">Accessibility of HTML5 video</ 
>> a></h2>
>>    <time datetime="2009-07-30" pubdate>Thursday 30 July 2009</time>
>>  </header>
>>  <p>Brilliantly witty, incisive prose, in a gloriously elegiac style
>>  reminiscent of <cite>Cider With Rosie</cite>.</p>
>> </article>
>
> I don't really see how that's any better. The data is still  
> duplicated,
> the data is still hidden

In what way is the data duplicated? In Bruce's example, the current  
solution (@pubdate on <article>) *requires* duplication if you want  
the publication date to be visible:

<article pubdate="2009-07-30">
   <header>
      <h2><a href="blah" rel="bookmark">Accessibility of HTML5 video</ 
a></h2>
     <time datetime="2009-07-30" >Thursday 30 July 2009</time>
    </header>
    <p>Brilliantly witty, incisive prose, in a gloriously elegiac  
style reminiscent of <cite>Cider With Rosie</cite>.</p>
</article>

If, by duplication, you mean that the date information is duplicated  
in the datetime attribute and the text node between the opening and  
closing <time> tags, that's inherent to the <time> element. If that  
kind of duplication is undesirable, then why is the <time> element in  
the spec?

Hixie wrote:
> the data is still hidden

Again, if this is a problem for @pubdate, it is also a problem for  
<time>.

Hixie wrote:
> and now we've just added even more ways to get
> the errors in the data (e.g. what if there are two conflicting <time
> pubdate> elements?).


That's certainly an issue but as Bruce wrote:
> The parsing rule could be simply that the first pubdate in any  
> section/ article context is considered to over-ride any other inside  
> the same sectiom/article.

It strikes me that the <time> element is tailor-made for exactly this  
use case: providing a machine-readable way to associate a timestamp  
with a chunk of content.

The documentation for <time> currently states[1]:
> This element is intended as a way to encode modern dates and times  
> in a machine-readable way

Great! But then the spec goes on to say:
> so that user agents can offer to add them to the user's calendar.

It seems unnecessarily restrictive to me that we would want to narrow  
the potential use cases so early on.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Received on Tuesday, 25 August 2009 09:37:32 UTC