> -----Original Message----- > From: Jukka K. Korpela [mailto:[email protected]] > Sent: Saturday, November 05, 2011 12:30 PM > To: [email protected] > Subject: Re: Regarding HTML5 <time> > > 11/4/2011 5:10 PM, mathew wrote: > > > I'll keep this short: > > > > The <time> element was the single HTML5 feature that I saw the most > compelling need for. > > I can imagine several _possible_ ways in which <time> might turn out to be > useful if supported by relevant software. But I do not know about any > actual support, and I don't see what might possibly be a compelling reason > to use <time>. > > I have nothing specific against <time>, but I have not seen any evidence > of its being actually useful. And there are surely many other other > phrase-level constructs for which some element _could_ be defined. For > example, a sentence is a common construct, but we don't have any > <sentence> markup - even though it is possible to present several > _possibilities_ of utilizing such markup in software. > > So it might be interesting to know why <time> is there but not, for > example, <length> or <mass> or <temperature>. I guess the reason behind > <time> is that search engines are supposed to notice <time pubdate>. > Does any search engine do anything in that direction? > > Wait... I seem to have missed a recent change: > "Goodbye time, datetime, and pubdate. Hello data and value." > http://html5doctor.com/time-and-data-element/ > > So if any search engine tried anything with <time>, it was a wasted effort, > it seems. >
If nothing else, it would eliminate the issue that has kept me from using the time microformat as well as any other microformat that requires the time microformat. Current recommendations for implementing time in microformats are not accessible or misuse existing tags. Specifically, the current recommendation is to use the title attribute of the abbreviation tag, but the date-time format is not human-friendly. >From http://microformats.org/wiki/value-class-pattern#Date_and_time_values "Some microformats properties expect an ISO8601 datetime value, e.g. hCalendar dtstart and dtend or hAtom published. Authors may use the value class pattern to separately specify the date and the time, which are then combined to specify a single datetime value. <p>The weekly dinner will be on <span class="dtstart"> <abbr class="value" title="2008-06-24">this Tuesday</abbr> at <span class="value">18:30</span> </span> </p>" The 2008-06-24 date format is not friendly to humans. Not only that, screen readers would read it in place of "this Tuesday." The 18:30 part is not friendly in the United States. Availability of a time tag would alleviate this issue. Presumably a time tag would have an optional format attribute that would eliminate ambiguity between m/d/yy and d/m/yy. Hope this helps, Charles Belov SFMTA Webmaster
