Re: Detailed review of 3.12.10. The time element

Hello!

Thanks for your reply.


Le Tue, 11 Dec 2007 12:14:08 +0200, Ian Hickson <ian@hixie.ch> a écrit:

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

Agreed. This is my old feedback.


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

Good.


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

You are welcome. :)

I followed the instructions "how to read this specification". :)

http://www.whatwg.org/specs/web-apps/current-work/multipage/section-structure.html#how-to


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

The DOM 3 Core specification defines DOMTimeStamp very shortly:

"For Java, DOMTimeStamp is bound to the long type. For ECMAScript,  
DOMTimeStamp is bound to the Date type because the range of the integer  
type is too small."

... from http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp

If I correctly understand the definition, then the DOMTimeStamp interface  
is a Date object. This solves the issue.


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

Yes, it does.


Best regards,

-- 
Mihai Sucan
http://www.robodesign.ro

Received on Saturday, 12 January 2008 11:39:04 UTC