[html5] r4214 - [e] (0) Examples for type=datetime and type=datetime-local. Fixing http://www.w3 [...]
whatwg at whatwg.org
whatwg at whatwg.org
Tue Oct 20 15:46:44 PDT 2009
Author: ianh
Date: 2009-10-20 15:46:39 -0700 (Tue, 20 Oct 2009)
New Revision: 4214
Modified:
complete.html
index
source
Log:
[e] (0) Examples for type=datetime and type=datetime-local.
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=7865
Modified: complete.html
===================================================================
--- complete.html 2009-10-20 22:08:15 UTC (rev 4213)
+++ complete.html 2009-10-20 22:46:39 UTC (rev 4214)
@@ -33537,7 +33537,28 @@
</div>
+ <div class=example>
+ <p>The following fragment shows part of a calendar application. A
+ user can specify a date and time for a meeting (in his local time
+ zone, probably, though the user agent can allow the user to change
+ that), and since the submitted data includes the time-zone offset,
+ the application can ensure that the meeting is shown at the correct
+ time regardless of the time zones used by all the participants.</p>
+
+ <pre><fieldset>
+ <legend>Add Meeting</legend>
+ <p><label>Meeting name: <input type=text name="meeting.label"></label>
+ <p><label>Meeting time: <input type=datetime name="meeting.start"></label>
+</fieldset></pre>
+
+ <p>Had the application used the <code title=attr-input-type-datetime-local><a href=#local-date-and-time-state>datetime-local</a></code> type
+ instead, the calendar application would have also had to explicitly
+ determine which time zone the user intended.</p>
+
+ </div>
+
+
<h6 id=date-state><span class=secno>4.10.5.1.8 </span><dfn title=attr-input-type-date>Date</dfn> state</h6>
<div class=impl>
@@ -34261,7 +34282,35 @@
</div>
+ <div class=example>
+ <p>The following example shows part of a flight booking
+ application. The application uses an <code><a href=#the-input-element>input</a></code> element
+ with its <code title=attr-input-type><a href=#attr-input-type>type</a></code> attribute set to
+ <code title=attr-input-type-datetime-local><a href=#local-date-and-time-state>datetime-local</a></code>,
+ and it then interprets the given date and time in the time zone of
+ the selected airport.</p>
+
+ <pre><fieldset>
+ <legend>Destination</legend>
+ <p><label>Airport: <input type=text name=to list=airports></label></p>
+ <p><label>Departure time: <input type=datetime-local name=totime step=3600></label></p>
+</fieldset>
+<datalist id=airports>
+ <option value=ATL label="Atlanta">
+ <option value=MEM label="Memphis">
+ <option value=LHR label="London Heathrow">
+ <option value=LAX label="Los Angeles">
+ <option value=FRA label="Frankfurt">
+</datalist></pre>
+
+ <p>If the application instead used the <code title=attr-input-type-datetime><a href=#date-and-time-state>datetime</a></code> type, then the
+ user would have to work out the time-zone conversions himself,
+ which is clearly not a good user experience!</p>
+
+ </div>
+
+
<h6 id=number-state><span class=secno>4.10.5.1.13 </span><dfn title=attr-input-type-number>Number</dfn> state</h6>
<div class=impl>
Modified: index
===================================================================
--- index 2009-10-20 22:08:15 UTC (rev 4213)
+++ index 2009-10-20 22:46:39 UTC (rev 4214)
@@ -33366,7 +33366,28 @@
</div>
+ <div class=example>
+ <p>The following fragment shows part of a calendar application. A
+ user can specify a date and time for a meeting (in his local time
+ zone, probably, though the user agent can allow the user to change
+ that), and since the submitted data includes the time-zone offset,
+ the application can ensure that the meeting is shown at the correct
+ time regardless of the time zones used by all the participants.</p>
+
+ <pre><fieldset>
+ <legend>Add Meeting</legend>
+ <p><label>Meeting name: <input type=text name="meeting.label"></label>
+ <p><label>Meeting time: <input type=datetime name="meeting.start"></label>
+</fieldset></pre>
+
+ <p>Had the application used the <code title=attr-input-type-datetime-local><a href=#local-date-and-time-state>datetime-local</a></code> type
+ instead, the calendar application would have also had to explicitly
+ determine which time zone the user intended.</p>
+
+ </div>
+
+
<h6 id=date-state><span class=secno>4.10.5.1.8 </span><dfn title=attr-input-type-date>Date</dfn> state</h6>
<div class=impl>
@@ -34090,7 +34111,35 @@
</div>
+ <div class=example>
+ <p>The following example shows part of a flight booking
+ application. The application uses an <code><a href=#the-input-element>input</a></code> element
+ with its <code title=attr-input-type><a href=#attr-input-type>type</a></code> attribute set to
+ <code title=attr-input-type-datetime-local><a href=#local-date-and-time-state>datetime-local</a></code>,
+ and it then interprets the given date and time in the time zone of
+ the selected airport.</p>
+
+ <pre><fieldset>
+ <legend>Destination</legend>
+ <p><label>Airport: <input type=text name=to list=airports></label></p>
+ <p><label>Departure time: <input type=datetime-local name=totime step=3600></label></p>
+</fieldset>
+<datalist id=airports>
+ <option value=ATL label="Atlanta">
+ <option value=MEM label="Memphis">
+ <option value=LHR label="London Heathrow">
+ <option value=LAX label="Los Angeles">
+ <option value=FRA label="Frankfurt">
+</datalist></pre>
+
+ <p>If the application instead used the <code title=attr-input-type-datetime><a href=#date-and-time-state>datetime</a></code> type, then the
+ user would have to work out the time-zone conversions himself,
+ which is clearly not a good user experience!</p>
+
+ </div>
+
+
<h6 id=number-state><span class=secno>4.10.5.1.13 </span><dfn title=attr-input-type-number>Number</dfn> state</h6>
<div class=impl>
Modified: source
===================================================================
--- source 2009-10-20 22:08:15 UTC (rev 4213)
+++ source 2009-10-20 22:46:39 UTC (rev 4214)
@@ -37032,7 +37032,29 @@
</div>
+ <div class="example">
+ <p>The following fragment shows part of a calendar application. A
+ user can specify a date and time for a meeting (in his local time
+ zone, probably, though the user agent can allow the user to change
+ that), and since the submitted data includes the time-zone offset,
+ the application can ensure that the meeting is shown at the correct
+ time regardless of the time zones used by all the participants.</p>
+
+ <pre><fieldset>
+ <legend>Add Meeting</legend>
+ <p><label>Meeting name: <input type=text name="meeting.label"></label>
+ <p><label>Meeting time: <input type=datetime name="meeting.start"></label>
+</fieldset></pre>
+
+ <p>Had the application used the <code
+ title="attr-input-type-datetime-local">datetime-local</code> type
+ instead, the calendar application would have also had to explicitly
+ determine which time zone the user intended.</p>
+
+ </div>
+
+
<h6><dfn title="attr-input-type-date">Date</dfn> state</h6>
<div class="impl">
@@ -37853,7 +37875,36 @@
</div>
+ <div class="example">
+ <p>The following example shows part of a flight booking
+ application. The application uses an <code>input</code> element
+ with its <code title="attr-input-type">type</code> attribute set to
+ <code title="attr-input-type-datetime-local">datetime-local</code>,
+ and it then interprets the given date and time in the time zone of
+ the selected airport.</p>
+
+ <pre><fieldset>
+ <legend>Destination</legend>
+ <p><label>Airport: <input type=text name=to list=airports></label></p>
+ <p><label>Departure time: <input type=datetime-local name=totime step=3600></label></p>
+</fieldset>
+<datalist id=airports>
+ <option value=ATL label="Atlanta">
+ <option value=MEM label="Memphis">
+ <option value=LHR label="London Heathrow">
+ <option value=LAX label="Los Angeles">
+ <option value=FRA label="Frankfurt">
+</datalist></pre>
+
+ <p>If the application instead used the <code
+ title="attr-input-type-datetime">datetime</code> type, then the
+ user would have to work out the time-zone conversions himself,
+ which is clearly not a good user experience!</p>
+
+ </div>
+
+
<h6><dfn title="attr-input-type-number">Number</dfn> state</h6>
<div class="impl">
More information about the Commit-Watchers
mailing list