[uf-discuss] Hcalendar in bbc.co.uk/programmes

[Robert O'Rourke]

Benjamin Hawkes-Lewis wrote:
> Robert O'Rourke wrote:
>
>> I know it defeats the object semantically speaking but what are the 
>> other arguments against putting the machine-readable date/time in the 
>> class attribute and do they outweigh the gain in accessibility?
>>
>> For example, what's wrong with this:
>>
>>     <abbr class="dtstart:2007-12-12T16:03:00Z" title="3 minutes past 
>> 4pm, 12th December 2007">
>>          16:03
>>        </abbr>
>
> Leaving aside the immediate question of whether using class to hide 
> data is a good idea:

I understand that microformats are about keeping the data visible but 
2007-12-12T16:03:00Z is no good to humans. The data is still visible to 
machines and as far as I know it's there for the machine's benefit.

>
> 1. 16:03 isn't an abbreviation for 12 September 2007. That's 
> /additional/ information. So that should be a SPAN not an ABBR.

Sure I understand, it was just an example based on what was in TITLE, so 
you're saying 16:03 isn't an abbreviation for 2007-12-12T16:03:00Z 
either?. Ignoring the '12 December 2007' bit would it still be an ABBR 
do you think? Seems a bit superfluous to treat it as an abbreviation at 
all if that's the case. Taking the example of a blog post there is a 
context for date and time so if 16:03 appeared there a human could 
figure out it was on that day. A machine could work it out from the 
information in CLASS. It seems like an impossible situation to get right...

>
> 2. Information in TITLE is hard for humans to access (for example, 
> with just the keyboard, or on an iPhone). So it's best to keep 
> important information, like 12th December 2007, implicit or explicit 
> in the main content.
>
> 3. If 12th December 2007 is made implicit or explicit, then the TITLE 
> is superfluous and distracting:
>

I agree with these points, so basically ABBR is the wrong element in 
this case because the date/time in full is given or implied. Could it be 
argued then that the machine-readable date-time belongs in CLASS on a SPAN?

>> Since no solution is ideal with the current HTML flavours people use 
>> is there any work being done with regard to the new HTML specs like 
>> HTML5? A <DATE> element or data="" attribute for example?
>
> Given that the set of data types is potentially infinite, I'd like to 
> see an extensible method for hiding machine-readable data in the next 
> version of HTML.
>
> The current HTML5 draft, doesn't have an extensible method, but it 
> does include dedicated TIME and METER elements:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-time 
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-meter 
>
>
> Caveat: a flaw doomed to irritate historians, scientists, space opera 
> authors, and non-Christians everywhere is that the proposed TIME 
> element cannot represent times before 0 AD or after 9999 AD:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-common1.html#dates 
>
>
> The current XHTML2 draft doesn't have an equivalent for TIME and 
> METER, but it does have a general way of hiding machine-readable data, 
> using the content attribute:
>
> http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content

The XHTML2 method gets my vote then, unless of course that flaw is 
worked out. What a palaver...

>
> -- 
> Benjamin Hawkes-Lewis
>

Thankyou for the links and response Benjamin,

-Rob