- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 11 Dec 2007 10:14:08 +0000 (UTC)
- To: Mihai Sucan <mihai.sucan@gmail.com>
- Cc: public-html <public-html@w3.org>
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