W3C home > Mailing lists > Public > public-html-comments@w3.org > November 2011

Re: Regarding HTML5 <time>

From: Gannon Dick <gannon_dick@yahoo.com>
Date: Mon, 7 Nov 2011 17:22:26 -0800 (PST)
Message-ID: <1320715346.42559.YahooMailNeo@web112602.mail.gq1.yahoo.com>
To: Arthur Clifford <art@artspad.net>
Cc: "public-html-comments@w3.org" <public-html-comments@w3.org>
+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 <art@artspad.net>
To: Gannon Dick <gannon_dick@yahoo.com>
Cc: public-html-comments@w3.org
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
Received on Tuesday, 8 November 2011 01:22:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 November 2011 01:22:58 GMT