RE: Regarding HTML5 <time>

Jukka K. Korpela wrote on Monday, November 07, 2011 1:32 PM
> 
> 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.

[cbelov] 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).

[cbelov] Yes.

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

[cbelov] Indeed it is, in my opinion.

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

[cbelov] I'm not invested in time being a tag.  Your attribute recommendation 
would seem to work for screen-reading software, which I would expect to 
ignore the tags.

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

[cbelov] Interesting; thank you.
 
> 
> > 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.)

 [cbelov] I would not raise an objection to that.  


> > 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.
>
[cbelov] Understood.
 

Hope this helps,
Charles Belov
SFMTA Webmaster

Received on Tuesday, 8 November 2011 00:36:04 UTC