W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Detailed review of 3.12.10. The time element

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Sat, 04 Aug 2007 20:55:05 +0300
To: public-html <public-html@w3.org>
Message-ID: <op.twjqp3dhmcpsjgr0b0dp@localhost.localdomain>

Hello!

I have reviewed the 3.12.10. "The time element" section [1]. I have the  
following comments to make:

1. "The dateTime DOM attribute must reflect *the datetime content  
attribute*."

I noticed this is a common error in the spec (if others agree it's an  
actual error).

My experience in English tells me that's wrong, knowing what the phrase is  
supposed to mean. The datetime content attribute, sounds like the datetime  
attribute is of content - which is not logical, and confusing.

I would suggest the following correction:

"The dateTime DOM attribute must reflect the datetime attribute content."


2. Another common error in the spec:

"User agents, to obtain the date, time, and timezone represented by a time  
element, must *follow the following* steps:"

"follow the following" is not really the best wording.

I would suggest the following correction:

"To obtain the date, time, and timezone represented by a time element,  
user agents must follow the steps provided below:"


3. The provided steps for obtaining the date, time and timezone *might*  
have an additional error.

Quoting the first two items:

"1. If the datetime attribute is present, then parse it according to the  
rules for parsing *date or time strings in content*, and let the result be  
result.
2. Otherwise, parse the element's textContent according to the rules for  
parsing *date or time strings in content*, and let the result be result."

The emphasized text is linked to 3.2.4.2. "Vaguer moments in time" [2].  
 From where I quote:

"This section defines date or time strings. There are two kinds, *date or  
time strings in content*, and *date or time strings in attributes*. The  
only difference is in the handling of whitespace characters."

In "Vaguer moments in time" the parsing algorithm handles whitespace  
differently for attributes, compared to string in content.

However, in "the time element" section the datetime attribute is defined  
to be parsed as in content, just like the textContent of the <time>  
element. I think that's a wrong duplication.

Here's a suggested correction for the steps:

"1. If the datetime attribute is present, then parse it according to the  
rules for parsing date or time strings in attributes, and let the result  
be result.
2. Otherwise, parse the element's textContent according to the rules for  
parsing date or time strings in content, and let the result be result."


4. The provided API is not clear about the format of the .date and .time  
DOM attributes.

Looking at the parsing algorithm for date or time strings, found in the  
"Vaguer moments in time" section, one expects the result just takes the  
date, time and timezone as they are, no changes to other timezones, to  
other formats, nothing.

The TIME element section does not really tell the format of the .date and  
.time DOM attributes. The DOMTimeStamp interface is not linked anywhere,  
it's undefined.

The examples at the bottom just say the time in miliseconds. Obviously,  
that's not in the DOM.

I believe the DOM API is OK, if:

a) The .date DOM attribute is defined as an ISO date of the format  
YYYYMMDD. Today that would be 20070804.

b) The .time DOM attribute is defined as HHMMSS.ms. Where HH is the hours  
in 24-hours format. If the seconds and miliseconds are undefined, then  
they are considered as 0. Therefore, the time is now 204300.0.

c) A new .unixTimeStamp DOM attribute is defined as representing the date  
(and time, if defined) in the well known UNIX timestamp format. If .date  
is null, then .unixTimeStamp is also null. If .time is null, but .date is  
defined, then the .unixTimeStamp DOM attribute tells the date and time as  
if .time would be the midnight of the day defined by date.

d) Add new DOM attributes .month, .mday, .yweek (Nth week of the year),  
mname (the month name, local string?), .dname (the day name, local  
string?), .hour, and .minute. These are often used when working with  
calendars.


That's about all.



[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#time0
[2]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-common1.html#date-or1


-- 
http://www.robodesign.ro
Received on Saturday, 4 August 2007 17:55:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:03 GMT