Regarding HTML5 <time>

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Regarding HTML5 <time>

Bugzilla from meta@pobox.com
I'll keep this short:

The <time> element was the single HTML5 feature that I saw the most compelling need for.

A <data> element would also be a good idea, but timestamps are so commonplace that they deserve their own element -- just like we give emphasis its own element rather than using <span> with a CSS style.


mathew

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Jukka K. Korpela-2
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>.

> A <data> element would also be a good idea,

Since everything in an HTML document is data, I don't see the point.

> but timestamps are so commonplace that
> they deserve their own element -- just like we give emphasis its own element rather
 > than using <span> with a CSS style.

Most people give emphasis by using <i> or <b>, or maybe <em> or
<strong>, quite often by using formatting commands in some web authoring
software. These elements have been with us longer than CSS, so there has
never been a serious temptation to use <span> with a CSS style for emphasis.

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.

I don't expect them to get excited about <data> anytime soon.

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

Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Charles Pritchard-2
On 11/5/11 12:30 PM, Jukka K. Korpela wrote:

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

There may be room to use ARIAs flexibility with the role attribute.
Such as: <span role="time definition" aria-label="2010">Last year</span>

ARIA labels are intended to be human readable and that one is.
They're also intended to be computer-audio-synthesis readable.

Apparently 2010-01-01 is not nicely read by the TTS on this laptop.
Using forward slashes instead of hyphens works better.

Example:
<span role="time definition" aria-label="2010/12/12">Last New Year's
Eve</span>

This works <span role="time definition"
aria-label="2011/11/05">today</span>.


Reply | Threaded
Open this post in threaded view
|

RE: Regarding HTML5 <time>

Belov, Charles
In reply to this post by Jukka K. Korpela-2
> -----Original Message-----
> From: Jukka K. Korpela [mailto:[hidden email]]
> Sent: Saturday, November 05, 2011 12:30 PM
> To: [hidden email]
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Gannon Dick
Reproducibility in time separates science from conjecture.  Intellectual Property is based upon reproducibility in source, roughly, some content on which to drape your conjecture.  I'm on your side, Charles, but I'm afraid we lost.

--Gannon



----- Original Message -----
From: "Belov, Charles" <[hidden email]>
To: 'Jukka K. Korpela' <[hidden email]>
Cc: [hidden email]
Sent: Monday, November 7, 2011 2:12 PM
Subject: RE: Regarding HTML5 <time>

> -----Original Message-----
> From: Jukka K. Korpela [mailto:[hidden email]]
> Sent: Saturday, November 05, 2011 12:30 PM
> To: [hidden email]
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Jukka K. Korpela-2
In reply to this post by Belov, Charles
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/

Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Arthur Clifford
In reply to this post by Gannon Dick
I think the problem is more one of figuring out what HTML is supposed to be?

Is HTML supposed to be a markup language for presentation? Is it supposed to mark up document structure semantically? Is it supposed to mark up content structure?

The answer to those questions cannot all be yes and the time vs data tag discussion is an example of why.

If HTML was just about marking up content to tell a browser how to display something then time as a tag may be irrelevant to that. The original content would likely be built in XML or obtained from a DB and transformed into some meaningful output; thus the unix timestamp in a mysql database could become a pretty formatted date or time for human consumption. But, it would lose all semantic meaning it would just be text in a document. All server-side languages worth working with have support for converting date formats so that would be a trivial operation to perform server-side. The consequence of saying that HTML is just for marking up content for display though is it runs competly counter to the industry expectation that content and its face should be separated and CSS not HTML should dictate presentation. However, the still extant <b> and <i> tags, along with table tags and other layout/formatting tags suggest that html hasn't shaken its roots as a rich text markup language. Not long ago someone ranted here about people getting ridiculously CSS happy and bloating a page with syntax. While it  is true that not everybody will do that, it is an industry trend to think it is wrong to treat html like a rich text markup language as it once was. So the ranting gentleman's views are completely warranted from the classic expectations of html.

If HTML is for marking up a document structure semantically then time as a tag is a good way to markup something semantically (at least in english). As others said it would tell readers what to do with it. The anglo-centric view of what time should represent is also short-sighted. Time is one of those complicated data structure items that have many different manifestations depending where you are in the world. A time tag done right would be able to render time in a culturo-temporal specific way. Length So that a time in UTC could be transformed to local time and local calendar and displayed in a way that is relevant to the viewer. And readers could do the same thing. If the time tag had a src format then it can be rendered however. Since the WC3 has a datetime specification its not like we're asking anybody to reinvent the wheel. However, is HTML supposed to markup data structures or is it supposed to markup layout/formatting?

If HTML is supposed to mark up content structure then it would be completely lacking if it didn't have support for a time data type as well as int, float, and other standard core types found in most programming languages. However, it would also be necessary to extend the model for complex data types people would create. If you want an extensible data structure markup language with semantic tags you probably should be using XML and using XSLT to transform that structure into HTML+CSS or whatever presentation layer format

A data tag could be used as a catch-all for core data types and doing transformations client side. Done right it would also have handlers that could call custom javascript for converting the raw data format to display format prior to rendering. Perhaps that would provide extensibility at the expense of semantic relevance. An alt like tag could always be  provided to give readers or other formats something semantic to play with.

The lack of lengh and other non-time tags is probably due to the belief that html marks up documents and time is a common field in relation to how documents are marked up and defined. For instance a document has a creation and modified/publication date. This was a weaker point I made in my original reply to Jukka. Time is just a more common need than other measurements, and a more complicated problem space than representing units of measure cross-culturally. Units of measure tend to be known and consistent internationally especially for business and trade. Time is trickier.

While I understand the virtue of XML+XSLT/CSS to keep content and its face separate. I personally feel that taking the separation of content and formatting mentality to HTML makes sense; I realize it is too late in the game for that observation, but what can I say the emperor looks naked to me ... and he ain't that pretty.

Well, this was supposed to be a shorter email, sorry it got long. If, however, it spurred any feedback from anybody who is or has been involved with the working groups to clarify or correct anything I've written here I think that would go a long way to help the public list understand decisions.

Art C


Reply | Threaded
Open this post in threaded view
|

RE: Regarding HTML5 <time>

Belov, Charles
In reply to this post by Jukka K. Korpela-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Gannon Dick
In reply to this post by Arthur Clifford
+1, a vast majority of web pages do not depend on high frequency updates and date is sufficient.  This implies datetime is just extra decimal places.  A float is just an integer with decimal point and added zeros.



----- Original Message -----
From: Arthur Clifford <[hidden email]>
To: Gannon Dick <[hidden email]>
Cc: [hidden email]
Sent: Monday, November 7, 2011 6:01 PM
Subject: Re: Regarding HTML5 <time>

I think the problem is more one of figuring out what HTML is supposed to be?

Is HTML supposed to be a markup language for presentation? Is it supposed to mark up document structure semantically? Is it supposed to mark up content structure?

The answer to those questions cannot all be yes and the time vs data tag discussion is an example of why.

If HTML was just about marking up content to tell a browser how to display something then time as a tag may be irrelevant to that. The original content would likely be built in XML or obtained from a DB and transformed into some meaningful output; thus the unix timestamp in a mysql database could become a pretty formatted date or time for human consumption. But, it would lose all semantic meaning it would just be text in a document. All server-side languages worth working with have support for converting date formats so that would be a trivial operation to perform server-side. The consequence of saying that HTML is just for marking up content for display though is it runs competly counter to the industry expectation that content and its face should be separated and CSS not HTML should dictate presentation. However, the still extant <b> and <i> tags, along with table tags and other layout/formatting tags suggest that html hasn't shaken its roots as a rich
 text markup language. Not long ago someone ranted here about people getting ridiculously CSS happy and bloating a page with syntax. While it  is true that not everybody will do that, it is an industry trend to think it is wrong to treat html like a rich text markup language as it once was. So the ranting gentleman's views are completely warranted from the classic expectations of html.

If HTML is for marking up a document structure semantically then time as a tag is a good way to markup something semantically (at least in english). As others said it would tell readers what to do with it. The anglo-centric view of what time should represent is also short-sighted. Time is one of those complicated data structure items that have many different manifestations depending where you are in the world. A time tag done right would be able to render time in a culturo-temporal specific way. Length So that a time in UTC could be transformed to local time and local calendar and displayed in a way that is relevant to the viewer. And readers could do the same thing. If the time tag had a src format then it can be rendered however. Since the WC3 has a datetime specification its not like we're asking anybody to reinvent the wheel. However, is HTML supposed to markup data structures or is it supposed to markup layout/formatting?

If HTML is supposed to mark up content structure then it would be completely lacking if it didn't have support for a time data type as well as int, float, and other standard core types found in most programming languages. However, it would also be necessary to extend the model for complex data types people would create. If you want an extensible data structure markup language with semantic tags you probably should be using XML and using XSLT to transform that structure into HTML+CSS or whatever presentation layer format

A data tag could be used as a catch-all for core data types and doing transformations client side. Done right it would also have handlers that could call custom javascript for converting the raw data format to display format prior to rendering. Perhaps that would provide extensibility at the expense of semantic relevance. An alt like tag could always be  provided to give readers or other formats something semantic to play with.

The lack of lengh and other non-time tags is probably due to the belief that html marks up documents and time is a common field in relation to how documents are marked up and defined. For instance a document has a creation and modified/publication date. This was a weaker point I made in my original reply to Jukka. Time is just a more common need than other measurements, and a more complicated problem space than representing units of measure cross-culturally. Units of measure tend to be known and consistent internationally especially for business and trade. Time is trickier.

While I understand the virtue of XML+XSLT/CSS to keep content and its face separate. I personally feel that taking the separation of content and formatting mentality to HTML makes sense; I realize it is too late in the game for that observation, but what can I say the emperor looks naked to me ... and he ain't that pretty.

Well, this was supposed to be a shorter email, sorry it got long. If, however, it spurred any feedback from anybody who is or has been involved with the working groups to clarify or correct anything I've written here I think that would go a long way to help the public list understand decisions.

Art C

Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Philip Gladstone-2
In reply to this post by Arthur Clifford
See inline

On 11/7/2011 7:01 PM, Arthur Clifford wrote:
If HTML was just about marking up content to tell a browser how to display something then time as a tag may be irrelevant to that. The original content would likely be built in XML or obtained from a DB and transformed into some meaningful output; thus the unix timestamp in a mysql database could become a pretty formatted date or time for human consumption. But, it would lose all semantic meaning it would just be text in a document. All server-side languages worth working with have support for converting date formats so that would be a trivial operation to perform server-side. The consequence of saying that HTML is just for marking up content for display though is it runs competly counter to the industry expectation that content and its face should be separated and CSS not HTML should dictate presentation. However, the still extant <b> and <i> tags, along with table tags and other layout/formatting tags suggest that html hasn't shaken its roots as a rich text mar
kup language. Not long ago someone ranted here about people getting ridiculously CSS happy and bloating a page with syntax. While it  is true that not everybody will do that, it is an industry trend to think it is wrong to treat html like a rich text markup language as it once was. So the ranting gentleman's views are completely warranted from the classic expectations of html.
The situation that I deal with is in the representation of lengths, speed, temperature etc. Who responsibility is it to get these displayed in the correct units (for some definition of the word "correct"). Having the web server generate the values according the first accept-language seems a broken approach. For example, for language 'en', should Fahrenheit or Centigrade be used? For lengths in the UK, I would expect younger people to be more familiar with metric units and older people with imperial units. I don't think we want the web server to know about the age of the user in order to generate the correct content.

This all argues for being able to tag data in such a way that it can be rendered appropriately by the browser (which presumably has more information about the user). I admit that there will be challenges in deciding which units to use for length. Is 0.001 meters to be shown as 0.1 cm, 1mm or even 0.001 meters? For metric speeds, sometimes m/s is the right unit, sometimes km/h.

I suspect that this will all be solved by some (pseudo-standard) JS library that gets access (somehow) to units preferences for various values. Maybe the only thing that needs to be standardized is that preferences API.

Philip

-- 
Philip Gladstone
[hidden email]
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Arthur Clifford
Phillip, I appreciate your problem space.

The intelligence you want to see in user agents is I think worthy of consideration. The challenges are not quite simple though as you said. I'm not sure whether such a preference setup is advisable or not. I would not want my browser assuming I want to see all values in metric or other standard units of measure. I think I would prefer the author communicate information in his/her preferred units and that if the unit of measure could be marked up so that the user agents know they are measurements that I could right click on and choose another similar unit of measure. That is, if the unit of measure is a length I shouldn't necessarily be able to select Fahrenheit.  For metric units it might be nice to also specify engineering vs scientific notation like on a scientific calculator and set the precision, and possibly set the base to use for display (i.e. 2 would show a binary number, 8 octal, 10 decimal, 16 hexadecimal) that would take care of your use case of knowing how to change from m to cm.

Somebody mentioned that a float is just a number with a decimal. Well, yes and not yes. There's the notion of maintaining full significance. If you have a float with ten significant decimal digits you may want to only display two to four of them (rounding up the last digit causing rounding errors if you were to use the value for additional math). However if it were possible to maintain the full precision and display something more readable and if the number were copied through a right-click action and the clipboard be populated with the full precision you would have the ability to transfer complete data while making it visually less complicated.

I have some background working on multimedia interfaces for scientific data. We did a lot of that, displaying less precision than we maintained. In fact if you read the documentation for Microsoft's calculator program (I know who does that, right?) you'll see that if you enter values in fraction notation that it maintains the fractional representation of the number until you explicitly perform some operation using a decimal number in order to maintain accuracy and remove floating point errors. So if you entered 1 3/4 the UI may display 1.75 but it is holding 1 3/4 but if you add .5 and it displays 2.25 it holds 2.25.

Transferring content for human consumption and transferring it for computational consumption are two different problem spaces, but HTML *could* allow both to happen ... to a degree. The option tags for instance have a label and value attribute which is precisely for this sort of scenario;  having a difference between what is displayed and actual value. But, there will be some industry with its own unit of measures or common but avoided units (I work with GIS data, I think lat/lon, geoids, and projections qualify as common but avoided units; if you don't know about them you probably don't want to) and it is not reasonable to expect users to have to set preferences to convert all lat/lon mercator units to lambert conic conformal units unless they are using mapping software in which case that isn't html's concern. I don't know where to draw the line between what units should be supported and which shouldn't and I doubt the team at W3C want to have to make that choice either. And given that I can see the logic of a data tag.

I'm not sure the W3C is the channel to try to get something like this implemented though. I think we'd need to inspire a user-agent developer to implement the desired behavior and then the W3C if it deemed ti worthy would add it to the spec. Ian has said on multiple occasions that he is trying to get a spec that the user agents will use. So, that implies new tech be developed and then standardized/specified after the fact.

Whether they should add something to the spec or not gets back to the fundamental question of what HTML is and isn't?

Do'h! another long email.

Art C


On Nov 7, 2011, at 5:43 PM, Philip Gladstone wrote:
> The situation that I deal with is in the representation of lengths, speed, temperature etc. Who responsibility is it to get these displayed in the correct units (for some definition of the word "correct"). Having the web server generate the values according the first accept-language seems a broken approach. For example, for language 'en', should Fahrenheit or Centigrade be used? For lengths in the UK, I would expect younger people to be more familiar with metric units and older people with imperial units. I don't think we want the web server to know about the age of the user in order to generate the correct content.
>
> This all argues for being able to tag data in such a way that it can be rendered appropriately by the browser (which presumably has more information about the user). I admit that there will be challenges in deciding which units to use for length. Is 0.001 meters to be shown as 0.1 cm, 1mm or even 0.001 meters? For metric speeds, sometimes m/s is the right unit, sometimes km/h.
>
> I suspect that this will all be solved by some (pseudo-standard) JS library that gets access (somehow) to units preferences for various values. Maybe the only thing that needs to be standardized is that preferences API.
>


Reply | Threaded
Open this post in threaded view
|

Re: Regarding HTML5 <time>

Charles Pritchard-2
On 11/7/11 7:53 PM, Arthur Clifford wrote:
>   I don't know where to draw the line between what units should be supported and which shouldn't and I doubt the team at W3C want to have to make that choice either. And given that I can see the logic of a data tag.
>
> I'm not sure the W3C is the channel to try to get something like this implemented though. I think we'd need to inspire a user-agent developer to implement the desired behavior and then the W3C if it deemed ti worthy would add it to the spec. Ian has said on multiple occasions that he is trying to get a spec that the user agents will use. So, that implies new tech be developed and then standardized/specified after the fact.
>
> Whether they should add something to the spec or not gets back to the fundamental question of what HTML is and isn't?

I was impressed by the problem space that InkML attempted to solve in
their specification.

It has sufficient units for scientific precision of time, force and
sample rate, a basic interoperation section for MathML and both an
archive and streaming modes.

If you're looking for sheer accessibility, tables are not fun to work
with, but aria-activedescendant, Semantic HTML and other standard
techniques should work fine.

Earlier in the thread I commented about switching to an ARIA hack
role="time definition" -- I call it a hack because "time" does not exist
in ARIA and so "definition" is the standard role. That hack works today
in ARIA aware software, it is easily identified by spiders and scrapers
and it doesn't require any particular consent from any editor, user
agent or consortium.

For passive tagging of events, ARIA and HTML (metadata or not) are
sufficient for expressing time.
If you're looking at something more advanced, like high precision
metrics, it makes sense to branch out into other W3C specs.

FWIW: I'm not against <time>, the tag is still present on schema.org,
and I'm a big SQL fan, where timestamptz (timestamp with timezone) lives
in a real-way.

HTML5 has one single editor, I suggest using other means, such as ARIA
roles with fallback or the itemprop attributes, at least in those areas,
you won't be blocked by the decisions of one person.


-Charles