Re: Regarding HTML5 <time>

11/7/2011 10:12 PM, Belov, Charles wrote:

>> 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.

I'm not sure whether "it" was meant to refer to the last note in my text 
that you quoted, the <time> element, but I suppose it did.

If I understand you correctly, you are referring to the possibility of 
writing a time in a globalized standard format in an attribute, while 
keeping the text content localized (i.e., in some human language).

That's an important point, and probably it is behind the ideas for the 
general-purpose <data> element, too. The need for such a distinction is 
not limited to times. For example, in metadata for content that deals 
with weights and measures or sums of money, it is surely desirable to 
include the meta using standardized units and expressions (say, "USD 
42.50") while letting authors write them as localized (say, "42,50 $").

> Specifically, the current recommendation is to use the title attribute of
 > the abbreviation tag, but the date-time format is not human-friendly.

And it's rather odd to use <abbr> for something that isn't abbreviation 
at all. It is also odd to use the title attribute for machine-readable 
metadata, as you say.

There are two issues here: elements and attributes.

I don't think we need any new elements for this, but we need a new 
attribute, or attributes. New attributes provide better compatibility 
with old browsers. If you use, say, the <span> element, you can style it 
at will and you can process it in client-side scripting, without needing 
to worry about lack of support in browsers. If a new attribute is added, 
the element keeps working, and while the attribute as such does not "do" 
anything in old browsers - it just needs to be recognized by new 
software that will use it.

Introducing a new attribute to existing elements, instead of a new 
element, has the additional advantage that existing documents very often 
already have _some_ markup for the data in question. For example, the 
time, or weight, or whatever might appear as the content of a table 
cell, i.e. a <td> element. It might also be wrapped inside a <span> (or 
<div>) for styling or scripting, or inside <em> for emphasis. Then we 
just need to add an attribute to the existing tag. This may sound 
trivial, but such simplicity matters in the adoption of new features.

>  From http://microformats.org/wiki/value-class-pattern#Date_and_time_values
- -
>      <span class="dtstart">
>          <abbr class="value" title="2008-06-24">this Tuesday</abbr>
>       at <span class="value">18:30</span>
>      </span>

That's rather artificial, and in addition to the semantic question "is 
this really an abbreviation", it causes special default rendering on 
many browsers. The <span> element would be more adequate than the <abbr> 
element.

Instead of using the title attribute for something that is incompatible 
with its defined meaning and existing usage, a new attribute is needed.

The simplest approach would be to add two attributes that apply to all 
elements: one specifying the type of data, and another specifying the 
value in a standardized format. I'm sure good names can be invented, 
even though the name "type" is effectively reserved (it exists in a 
different meaning and is disturbingly polymorphic). As working names, 
I'll use "dt" (short for datatype) and "d" (for data). For example:

<span class="value" dt="date" d="2008-06-24">this Tuesday</span>
at <span class="value" dt="time" d="18:30">6:30 PM</span>

This would make <time> redundant and would make it possible to 
distinguish dates from times (of day) and from combined date and time.

As far as I can see, this would be compatible with any microlevel 
metadata approach and would not interfere with them, though they _could_ 
be enhanced to pay attention to the new attributes in addition to their 
own conventions.

> The 2008-06-24 date format is not friendly to humans.

To some humans it is. It is widely used in Japan, Poland, and Sweden and 
largely recognized in a few other countries. But this just means that in 
addition to being machine-readable standardized format, it is _also_ 
suitable localization in _some_ locales.

> The 18:30 part is not friendly in the United States.

To some people it might be, but the general point of course is that even 
time denotations may need to be localized, whereas for metadata, a 
standard format is needed.

> Availability of a time tag would alleviate this issue.

I don't think a <time> tag has much to do with the solutions. You really 
want the datetime attribute from it. But I have outlined a more general 
approach here, and approach that is suitable for a much wider range of use.

(If times are so special, we might specify that when d="..." attribute 
is specified without a dt="..." attribute, dt="datetime" is implied, 
meaning that the data value is a date, a time, or a combined date and 
time denotation in ISO 8601 format.)

> Presumably a time tag would have an optional format attribute that would
 > eliminate ambiguity between m/d/yy and d/m/yy.

The ambiguity can be resolved in metadata by using ISO 8601. In document 
content, it's a different issue and a matter of conventions used in text 
rather than markup. Markup is not crucial here. What matters is that 
people understand expressions correctly, and for this, authors should 
use notations that are unambiguous to their audience.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Monday, 7 November 2011 21:32:18 UTC