Re: The cite and pubdate attributes

Ian Hickson On 09-08-15 13.16:

> On Mon, 10 Aug 2009, Lachlan Hunt wrote:
>> The cite and pubdate attributes now defined for the article and section 
>> elements don't seem to be very well designed.  It's not entirely clear 
>> what problem they are meant to solve, or use cases they are addressing.  
> cite="" on <section> is solving the problem that Chaals doesn't know where 
> the parts of his document come from.
> cite="" on <article> is solving the same problem as <a rel=bookmark>.
> pubdate="" on <article> is solving the problem that there's no other way 
> to associate a publication date with a blog entry in HTML, in particular 
> to allow for conversion to Atom.

[snipped your other pro section@cite/article@cite statements.]

> I've removed cite="" from <section> and <article>, since their use cases 
> are either weak or solved by other problems.

What does "solved by other problems" mean?

If it was meant "solved by other means", which means? Microdata?

> I've not removed pubdate="" 
> since I don't see how else to get an unambiguous date out for conversion 
> to Atom without annointing a class name. 

I don't know why a @class ought to be better. But a predefined 
class name solution should in principle be possible to introduce 
via the profile/versioning *concept*. (HTML 4 embeds a default 
profile, HTML 5 embeds another profile.)

> I've also not done anything with 
> <blockquote cite=""> at this time, since the arguments against them (not 
> quoted above, but mentioned in passing in the original e-mails from which 
> the above is quoted) were weak to non-existent.


> While <blockquote cite=""> 
> is hardly a commonly used attribute, its presence does not seem to have 
> done as much harm as one usually finds is caused by such features, and a 
> surprising number of people who contribute to the standards process seem 
> to like having the ability to cite their sources using that attribute.
> I would like to drop pubdate="" also, if we can do so in some manner that 
> still solves the aforementioned problem.

leif halvard silli

Received on Saturday, 15 August 2009 16:14:38 UTC