From 80ba4fa24e5d3d81a10aa1bbd8a2f72f4bcc3f7c Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Wed, 25 Nov 2015 14:01:14 +0100 Subject: [PATCH] Fix #336: remove --- source | 404 ++++++++++----------------------------------------------- 1 file changed, 66 insertions(+), 338 deletions(-) diff --git a/source b/source index dbe657489ca..40b268bbef5 100644 --- a/source +++ b/source @@ -5574,24 +5574,6 @@ a.setAttribute('href', 'http://example.com/'); // change the content attribute d -

A string is a valid normalised forced-UTC global date and time string representing a - date, time, and a time-zone offset if it consists of the following components in the given - order:

- -
    - -
  1. A valid date string representing the date converted to the UTC time zone
    2. - -
  2. A U+0054 LATIN CAPITAL LETTER T character (T)
    3. - -
  3. A valid time string representing the time converted to the UTC time zone and - expressed as the shortest possible string for the given time (e.g. omitting the seconds component - entirely if the given time is zero seconds past the minute)
    4. - -
  4. A U+005A LATIN CAPITAL LETTER Z character (Z)
    5. - -
-

The rules to parse a global date and time string are as follows. This will return @@ -43078,11 +43060,6 @@ interface HTMLFormElement : HTMLElement { Password Text with no line breaks (sensitive information) A text field that obscures data entry - - datetime - Date and Time - A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC - A date and time control date Date @@ -43232,8 +43209,7 @@ interface HTMLFormElement : HTMLElement { Telephone E-mail Password - Date and Time, - Date, + Date, Month, Week, Time @@ -43261,8 +43237,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43286,8 +43261,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43311,8 +43285,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - Yes - + Yes @@ -43336,8 +43309,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43361,8 +43333,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43386,8 +43357,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43411,8 +43381,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43436,8 +43405,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43461,8 +43429,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43486,8 +43453,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43511,8 +43477,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43536,8 +43501,7 @@ interface HTMLFormElement : HTMLElement { · · Yes - · - + · @@ -43561,8 +43525,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes · - Yes - + Yes @@ -43586,8 +43549,7 @@ interface HTMLFormElement : HTMLElement { · · · - Yes - + Yes @@ -43611,8 +43573,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - · - + · @@ -43636,8 +43597,7 @@ interface HTMLFormElement : HTMLElement { · · · - Yes - + Yes @@ -43661,8 +43621,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - · - + · @@ -43686,8 +43645,7 @@ interface HTMLFormElement : HTMLElement { · Yes · - · - + · @@ -43711,8 +43669,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - · - + · @@ -43736,8 +43693,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - · - + · @@ -43761,8 +43717,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - Yes - + Yes @@ -43786,8 +43741,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - Yes - + Yes @@ -43811,8 +43765,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - · - + · @@ -43836,8 +43789,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43861,8 +43813,7 @@ interface HTMLFormElement : HTMLElement { · · · - Yes - + Yes @@ -43886,8 +43837,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43915,8 +43865,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43940,8 +43889,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -43965,8 +43913,7 @@ interface HTMLFormElement : HTMLElement { value value value - value - + value @@ -43990,8 +43937,7 @@ interface HTMLFormElement : HTMLElement { · · · - Yes - + Yes @@ -44015,8 +43961,7 @@ interface HTMLFormElement : HTMLElement { · · · - Yes - + Yes @@ -44040,8 +43985,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -44065,8 +44009,7 @@ interface HTMLFormElement : HTMLElement { · · · - · - + · @@ -44090,8 +44033,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes · - Yes - + Yes @@ -44115,8 +44057,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - Yes - + Yes @@ -44140,8 +44081,7 @@ interface HTMLFormElement : HTMLElement { Yes · Yes - · - + · @@ -44165,8 +44105,7 @@ interface HTMLFormElement : HTMLElement { Yes · Yes - · - + · @@ -44190,8 +44129,7 @@ interface HTMLFormElement : HTMLElement { Yes · Yes - · - + · @@ -44215,8 +44153,7 @@ interface HTMLFormElement : HTMLElement { Yes · Yes - · - + · @@ -44240,8 +44177,7 @@ interface HTMLFormElement : HTMLElement { Yes · Yes - · - + · @@ -44265,8 +44201,7 @@ interface HTMLFormElement : HTMLElement { · · · - Yes - + Yes @@ -44290,8 +44225,7 @@ interface HTMLFormElement : HTMLElement { · · · - Yes - + Yes @@ -44319,8 +44253,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - Yes - + Yes @@ -44344,8 +44277,7 @@ interface HTMLFormElement : HTMLElement { Yes Yes Yes - Yes - + Yes @@ -45408,217 +45340,6 @@ ldh-str = < as defined in Date and Time state (type=datetime) - -

- -

When an input element's type attribute is in - the Date and Time state, the rules in this section - apply.

- -
- -

The input element represents a control for setting the element's - value to a string representing a specific global date and time. User agents may display - the date and time in whatever time zone is appropriate for the user.

- -
- -

If the element is mutable, the user agent should allow the - user to change the global date and time represented by its - value, as obtained by parsing a global date and time from it. User agents must not allow the user to - set the value to a non-empty string that is not a - valid normalised forced-UTC global date and time string, though user agents may allow - the user to set and view the time in another time zone and silently translate the time to and from - the UTC time zone in the value. If the user agent provides a - user interface for selecting a global date and time, then - the value must be set to a valid normalised forced-UTC - global date and time string representing the user's selection. User agents should allow the - user to set the value to the empty string.

- -

Constraint validation: While the user interface describes input that the user - agent cannot convert to a valid normalised forced-UTC global date and time string, - the control is suffering from bad input.

- -
- -

See the introduction section for a discussion of - the difference between the input format and submission format for date, time, and number form - controls, and the implementation notes - regarding localization of form controls.

- -

The value attribute, if specified and not empty, must - have a value that is a valid global date and time string.

- -
- -

The value sanitization algorithm is as follows: If the value of the element is a valid global date and time - string, then adjust the time so that the value - represents the same point in time but expressed in the UTC time zone as a valid normalized - forced-UTC global date and time string, otherwise, set it to the empty string instead.

- -
- -

The min attribute, if specified, must have a value that is - a valid global date and time string. The max - attribute, if specified, must have a value that is a valid global date and time - string.

- -

The step attribute is expressed in seconds. The step scale factor is 1000 (which - converts the seconds to milliseconds, as used in the other algorithms). The default step is 60 seconds.

- -
- -

When the element is suffering from a step mismatch, the user agent may round the - element's value to the nearest global date and time for which the element would not suffer from a step mismatch.

- -

The algorithm to convert a string to a - number, given a string input, is as follows: If parsing a global date and time from input results in an error, then return an error; otherwise, return the number of - milliseconds elapsed from midnight UTC on the morning of 1970-01-01 (the time represented by the - value "1970-01-01T00:00:00.0Z") to the parsed global date and time, ignoring leap seconds.

- -

The algorithm to convert a number to a - string, given a number input, is as follows: Return a - valid normalised forced-UTC global date and time string that represents the global date and time that is input - milliseconds after midnight UTC on the morning of 1970-01-01 (the time represented by the value - "1970-01-01T00:00:00.0Z").

- -

The algorithm to convert a string to a - Date object, given a string input, is as follows: - If parsing a global date and time from - input results in an error, then return an error; otherwise, return a new Date object representing the parsed global date and time, expressed in UTC.

- -

The algorithm to convert a - Date object to a string, given a Date object input, is as follows: Return a valid normalised forced-UTC global - date and time string that represents the global date and - time that is represented by input.

- -
- -
- -

The Date and Time state (and other date- and - time-related states described in subsequent sections) is not intended for the entry of values for - which a precise date and time relative to the contemporary calendar cannot be established. For - example, it would be inappropriate for the entry of times like "one millisecond after the big - bang", "the early part of the Jurassic period", or "a winter around 250 BCE".

- -

For the input of dates before the introduction of the Gregorian calendar, authors are - encouraged to not use the Date and Time state (and - the other date- and time-related states described in subsequent sections), as user agents are not - required to support converting dates and times from earlier periods to the Gregorian calendar, - and asking users to do so manually puts an undue burden on users. (This is complicated by the - manner in which the Gregorian calendar was phased in, which occurred at different times in - different countries, ranging from partway through the 16th century all the way to early in the - 20th.) Instead, authors are encouraged to provide fine-grained input controls using the - select element and input elements with the Number state.

- -
- -
- -

The following common input element content - attributes, IDL attributes, and methods apply to the element: - autocomplete, - list, - max, - min, - readonly, - required, and - step content attributes; - list, - value, - valueAsDate, and - valueAsNumber IDL attributes; - select(), - stepDown(), and - stepUp() methods.

- -

The value IDL attribute is - in mode value.

- -

The input and change events apply.

- -

The following content attributes must not be specified and do not - apply to the element: - accept, - alt, - checked, - dirname, - formaction, - formenctype, - formmethod, - formnovalidate, - formtarget, - height, - inputmode, - maxlength, - minlength, - multiple, - pattern, - placeholder, - size, - src, and - width.

- -

The following IDL attributes and methods do not apply to the - element: - checked, - files, - selectionStart, - selectionEnd, - selectionDirection, - valueLow, and - valueHigh IDL attributes; - setRangeText(), and - setSelectionRange() methods.

- -
- -
- -

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.

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

Had the application used the datetime-local type instead, the calendar - application would have also had to explicitly determine which time zone the user intended.

- -

For events where the precise time is to vary as the user travels (e.g. "celebrate the new - year!"), and for recurring events that are to stay at the same time for a specific geographic - location even though that location may go in and out of daylight savings time (e.g. "bring the - kid to school"), the datetime-local type - combined with a select element (or other similar control) to pick the specific - geographic location to which to anchor the time would be more appropriate.

- -
- -
Date state (type=date)
@@ -45710,8 +45431,26 @@ ldh-str = < as defined in See the note on historical dates in the - Date and Time state section.

+
+ +

The Date state (and other date- and time-related + states described in subsequent sections) is not intended for the entry of values for which a + precise date and time relative to the contemporary calendar cannot be established. For example, + it would be inappropriate for the entry of times like "one millisecond after the big bang", "the + early part of the Jurassic period", or "a winter around 250 BCE".

+ +

For the input of dates before the introduction of the Gregorian calendar, authors are + encouraged to not use the Date state (and the other + date- and time-related states described in subsequent sections), as user agents are not required + to support converting dates and times from earlier periods to the Gregorian calendar, and asking + users to do so manually puts an undue burden on users. (This is complicated by the manner in + which the Gregorian calendar was phased in, which occurred at different times in different + countries, ranging from partway through the 16th century all the way to early in the 20th.) + Instead, authors are encouraged to provide fine-grained input controls using the + select element and input elements with the Number state.

+ +
@@ -46319,7 +46058,7 @@ ldh-str = < as defined in See the note on historical dates in the - Date and Time state section.

+ Date state section.

@@ -46402,10 +46141,6 @@ ldh-str = < as defined in </datalist> -

If the application instead used the datetime - type, then the user would have to work out the time-zone conversions himself, which is clearly - not a good user experience!

-
@@ -56386,7 +56121,6 @@ fur Telephone, E-mail, Password, - Date and Time, Date, Month, Week, @@ -109602,7 +109336,6 @@ input[type=password i] { binding: input-password; } 
@namespace url(http://www.w3.org/1999/xhtml);
 
-input[type=datetime i] { binding: input-datetime; }
 input[type=date i] { binding: input-date; }
 input[type=month i] { binding: input-month; }
 input[type=week i] { binding: input-week; }
@@ -109610,11 +109343,6 @@ input[type=time i] { binding: input-time; }
 input[type=datetime-local i] { binding: input-datetime-local; }
 input[type=number i] { binding: input-number; }
-

When the input-datetime binding applies to an input element whose - type attribute is in the Date and Time state, the element is expected to render as - an 'inline-block' box depicting a Date and Time control.

-

When the input-date binding applies to an input element whose type attribute is in the Date state, the element is expected to render as an