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/
