Re: <input type=datetime-local> HTML5 CR bugs [I18N-ACTION-279]

Hi Travis et al,

Apologies for the late follow-up on this but I just happened upon
these changes (and discussion) from today's HTMLWG telcon.

I have a specific and a general concern.

1. Specific concern: from reading the threads on local/floating, and
datetime inputs here and on the WHATWG list, I don't see consensus
among the participants, and if anything I see more questions than
answers.

2. In general I'm concerned about functional divergence of feature
definitions between HTMLWG and WHATWG specs, e.g. for features like
datetime <input>s.


Background: Years ago I spent a lot of time working on the definitions
and functionality of the <time> element and datetime inputs in HTML,
and working to achieve reasonable levels of consensus or broad
understanding with research and change proposals:
https://www.w3.org/wiki/User:Tantekelik/time_element
https://www.w3.org/wiki/User:Tantekelik/time_input_match
http://wiki.whatwg.org/wiki/Input
http://wiki.whatwg.org/wiki/Time
http://wiki.whatwg.org/wiki/Time_element_accepted

Accordingly, we had (fairly) consistent <time> and datetime <inputs>
across specs (good for authors, implementers etc.).

I'm worried that this issue (timezones, naming etc.) is just one case
where such divergence may be happening on the definition of the same
feature in different specs, and that seems like a regression.


>From the existing email threads, I don't think there is much to be
gained in additional email discussion on this topic (though feel free
to follow-up in email if you disagree).


Thus I've added both concerns to the agenda (with additional URLs to
bugs/threads etc) for the upcoming HTMLWG f2f in the hopes that in
person we have a better chance of reaching a broader understanding and
consensus on these topics.

https://www.w3.org/wiki/HTML/wg/2014-04-Agenda#Potential_Topics

If there's additional background reading for these issues, please feel
free to add more URLs to the Potential Topics.

Thanks for your consideration,

Tantek




On Mon, Feb 10, 2014 at 5:15 PM, Travis Leithead
<travis.leithead@microsoft.com> wrote:
> I've now committed these changes to the HTML 5.1 Master branch. Please look
> these over and point out any errors or concerns you may have. As always,
> silence is considered consent. I'll let these bake in 5.1 for a week or so
> before starting the process of porting to 5.0 CR in the absence of feedback.
>
>
>
> Spec with all three changes incorporated:
> http://www.w3.org/html/wg/drafts/html/master/ (building now)
>
>
>
> Commit for the health warning:
> https://github.com/w3c/html/commit/6704d9ac2cf55a8eae2b0e12f675d74df4c3d65f
>
> Commit for removing datetime-local:
> https://github.com/w3c/html/commit/3e5df1ee1aebed37571a23c9b62adc74a92a04b9
>
> Commit for renaming local->floating:
> https://github.com/w3c/html/commit/22162bf56037c266c78f9c9d77ccd1c8fda40b77
>
>
>
> Thanks!
>
>
>
> From: Travis Leithead
> Sent: Friday, February 7, 2014 2:59 PM
> To: 'Phillips, Addison'; Paul Cotton
> Cc: public-html@w3.org; www-international@w3.org
> Subject: RE: <input type=datetime-local> HTML5 CR bugs [I18N-ACTION-279]
>
>
>
> Thank you Addison (and i18n folks)!
>
>
>
> My plan of record is therefore the following:
>
>
>
> 1.      Add a "health warning" about conversion of floating date-times to
> incremental time in the current "local dates and times" section (2.4.5.5)
>
> 2.      Rename "local" to "floating" in section 2.4.5.5 and fix-up related
> references
>
> 3.      Remove the input's "local date and time" state (4.10.5.1.12) and
> related reference
>
>
>
> I will plan on making these changes to HTML5.1 spec, getting a round of
> review/feedback, and then porting them back to the CR branch to resolve the
> three related bugs (16957, 16959, 16960).
>
>
>
> -Travis
>
>
>
> From: Phillips, Addison [mailto:addison@lab126.com]
> Sent: Monday, February 3, 2014 3:53 PM
> To: Paul Cotton
> Cc: public-html@w3.org; www-international@w3.org; Travis Leithead
> Subject: RE: <input type=datetime-local> HTML5 CR bugs [I18N-ACTION-279]
>
>
>
> Hello HTML,
>
>
>
> We discussed these issues in a pair of recent teleconferences and I've been
> actioned with replying on our behalf.
>
>
>
> In general we agree with Travis's email. Our concern is, indeed, that
> "datetime-local" falsely implies local wall time (and thus a time zone).
> Developers are not good at identifying floating times as it is. Confusing
> terminology is not helpful.
>
>
>
> In addition to the WG's position, I agree that the health warning doesn't
> affect normativeness of the text. It'll be good to have. I also agree with
> the list of both pro- and con- arguments for use of a floating datetime
> input field (items 1-5 below). I would tend to add that coercion to an
> incremental time is pretty likely to happen if you pull the data into a Date
> object in JS or on the server unless you are exceedingly careful. Hence the
> need for health warnings.
>
>
>
> To Travis's conclusions, I would add that floating timestamps (date *and*
> time are significant) are the least common case. Usually at that point you
> want to compute a local time value using time zone information. Generally,
> the use of floating time requires some forethought by developers to keep
> from getting into trouble. I could support removing datetime-local as a
> result. If it's kept, I think I18N would prefer it to be renamed to include
> the word "floating" instead of the misleading "local".
>
>
>
> Thanks (for I18N),
>
>
>
> Addison
>
>
>
> Addison Phillips
>
> Globalization Architect (Amazon Lab126)
>
> Chair (W3C I18N WG)
>
>
>
> Internationalization is not a feature.
>
> It is an architecture.
>
>
>
>
>
>
>
> From: Travis Leithead [mailto:travis.leithead@microsoft.com]
> Sent: Monday, January 13, 2014 8:10 PM
> To: public-html@w3.org; www-international@w3.org
> Subject: <input type=datetime-local> HTML5 CR bugs
>
>
>
> i18n, public-html:
>
>
>
> I'm looking at addressing the following 3 HTML5.0 CR bugs:
>
>
>
> Bug #16957/i18n ISSUE 85 - Health Warning for conversion to/from incremental
> time
>
> Bug #16959/i18n ISSUE 88 - local/floating terminology (See also WHATWG
> #17855 - Won't Fix)
>
> Bug #16960/i18n ISSUE 89 - time zones and local dates/times (See also WHATWG
> #17856 - Won't Fix)
>
>
>
> The first concerns authors that might make the mistake of converting from
> input type=date (or type=datetime-local) to JavaScript's Date object, which
> is a conversion from a "floating" time, to an incremental/global time. The
> suggestion is that a "health warning" be added to warn users of the
> potential pitfalls.
>
>
>
> The latter two concern the syntax and use-cases for the input element's
> type=datetime-local state. I'll summarize what I believe to be the key
> points from these two bugs:
>
>
>
> 1. A syntactic concern about the use of the word "local" in the
> type=datetime-local attribute and related spec sections. The term "local"
> might confuse authors into thinking that it means an incremental time (e.g.,
> "absolute" or "global" time) in their "local" timezone (TZ). The bug
> requests that we consider changing "local" to "floating" in the terminology
> of the spec section (issue 88).
>
>
>
> 2. A link to w3.org/TR/timezone on timezone usage should be added to the
> spec. (issue 88)
>
>
>
> 3. Concern that the type=datetime-local does not deal with timezones and
> that its relationship to either floating or incremental time seems
> arbitrary. (Issue 89)
>
>
>
> I think adding the "Health warning" is a fair compromise and doesn't
> normatively impact the spec. I'll work on this and propose the change later
> this week. If this is satisfactory, it can resolve issue 85.
>
>
>
> Similarly, adding a link to the timezone note, in the relavant parts of the
> spec seems like a great idea, and will partially address issue 88 (but not
> all).
>
>
>
> The remainder of issue 88 and issue 89, deal with floating/relative time
> scenarios vs. global/absolute/incremental time scenarios for datetime-local.
> I'll be the first to admit that I'm no expert here, but what I think this
> boils down to is 1) whether the floating datetime-local control is useful,
> and if so, issues with its name.
>
>
>
> I'm pretty convinced by what I've read that there are valid scenarios for
> both "floating" time input as well as "global" time input as articulated by
> Ian [1].
>
>
>
> The spec provides one control for inputting global time, and that is <input
> type="datetime">. The spec provides a variety of controls for inputting
> floating time, such as type=date, type=month, type=week, type=time, and of
> course type=datetime-local.
>
>
>
> Of these floating time input controls, the only one that seems to be
> generating controversy is the last one: datetime-local.
>
>
>
> Those advocating for the _usefulness_ of the datetime-local control have
> made the following points:
>
> 1. date and time controls (no TZ) are useful, thus datetime-local as a
> combination control would appear useful
>
> 2. Use cases: phone alarm (where TZ is just-in-time computed), and events
> celebrated in different TZs at different global times.
>
> 3. Adding the local TZ to datetime-local (without conversion to UTC) is not
> a solution, as it just increases server-side work and introduces potential
> errors with little benefit (there is no "one size fits all" solution).
>
>
>
> Some drawbacks to having a datetime-local control:
>
> 4. The option to set both date + time in one control would seem to imply
> more date (e.g., TZ) than is actually sent--setting up false expectations.
>
> 5. The existing floating date/time controls address common use cases without
> the need for datetime-local, and typically do need to be independent (date
> separate from time control).
>
>
>
> On the naming debate, those in support of the current status-quo:
>
> 6. The extra characters "-local" make it harder to chose the version w/out a
> TZ. "datetime" is expected to be used more. Also datetime maps closer to
> Date() (in JavaScript) than to datetime-local.
>
> 7. The use of "floating" doesn't capture all the use cases (e.g., flight
> scheduler where TZ is implied isn't really floating in the true sense).
>
> 8. "Floating" is already used in "local date and times" section--it would
> confuse readers and the definition.
>
>
>
> A number of arguments were presented for changing the name:
>
> 9. "datetime" is literally concat("date","time") and would be what authors
> expect.
>
> 10. The term "local" could be confusing (seems to imply the "local" TZ)
>
> 11. "floating" is more commonly understood term to describe the use cases
> (see i18n note).
>
>
>
> It is my opinion that the datetime-local control is superfluous when there
> is already a separate date and time control for inputting floating time
> values in the spec. Existing implementations only appear to have appended
> their "date" control UI together with their "time" control UI, which also
> makes me doubt the unique value that datetime-local has in practice.
> Furthermore, most instances where websites today use floating time input
> (e.g., plane/train scheduling) use a date control and a separate time
> control. I don't see why having a datetime-local control would provide
> additional value over the two-control approach on these same sites, and I
> can imagine that it would make certain features harder to use.
>
>
>
> I also think that removing datetime-local would reduce the confusion I've
> seen behind the use cases for the floating vs. global time input (though it
> would still be the case that "date"(no TZ)+"time"(no TZ) != "datetime"(TZ)).
> It seems intuitive that "date" is floating and that "time" is also floating,
> but once you put them together, people start having different expectations.
>
>
>
> [1]
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040277.html

Received on Thursday, 20 February 2014 19:18:17 UTC