Re: Detailed review of 3.12.10. The time element

On Sat, 4 Aug 2007, Mihai Sucan wrote:
> 
> 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."

As noted in other feedback, the term "content attribute" is one that I 
settled on some time ago to mean an attribute of the content, as opposed 
to an attribute of the DOM object. Unless an especially compelling better 
name is proposed, I don't suggest changing this term at this point.


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

This has been largely fixed now.


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

The first was a typo. The hyperlinks actually went to different things, 
but the first link's text was incorrect. Fixed. Good catch!


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

DOMTimeStamp is defined in DOM3 Core to be a JS Date object. Does that 
define things adequately? I've added cross-references.


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

Hopefully the Date object's API handles these needs adequately.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 11 December 2007 10:14:16 UTC