implement "Date type inputs", "Month type inputs" #19385

tigercosmos · 2017-11-26T19:34:47Z

implement "Date type inputs", "Month type inputs"

./mach build -d does not report any errors
./mach test-tidy does not report any errors
./mach test-unit does not report any errors

This change is

highfive · 2017-11-26T19:34:51Z

Heads up! This PR modifies the following files:

@bholley: components/style/attr.rs
@canaltinova: components/style/attr.rs
@emilio: components/style/attr.rs

KiChjang

Sorry to do this to you, but I've come to believe that this code should instead be implemented on DOMString, defined in components/script/dom/bindings/str.rs, so that we can just write domstring.is_valid_date_string().

Also, I see that sanitize_value in htmlinputelement.rs is not being updated to use your code, would you mind updating that so it accurately sanitizes input values?

KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+    let month = value_vec[1];
+    let day = value_vec[2];
+
+    // setp 1


KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+    return true;
+}
+
+/// Valid month string should be "YYYY-MM"


This does not look correct, since step 1 clearly says that the year string can be 4 digits or more.

um.. how about use

Valid month string should be "YYYY-MM", YYYY must be four or more

KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+pub fn is_valid_month_string(value: &str) -> bool {
+    // step 2
+    let value_vec: Vec<&str> = value.split('-').collect();
+    if !(value_vec.len() == 2) {


value_vec.len() != 2 and drop the parentheses.

KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+    let year = value_vec[0];
+    let month = value_vec[1];
+
+    // setp 1


I don't get point here?

I think @KiChjang means there's a typo and have the comment with first character capitalized.

KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+    // setp 1
+    if !(year.len() >= 4 &&
+         year.chars().all(|c| c.is_digit(10)) &&
+         year.parse::<i32>().unwrap() > 0) {


I don't think it's necessary to parse it in order to see whether the resulting i32 is larger than 0.

yes, we only need to prevent the case "0000".
In this case, not parse to int is fine.

KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+    }
+
+    // step 3
+    let month_int = month.parse::<i32>().unwrap();


This can panic if the month string is not convertible to i32. I also think it's not necessary to parse the month string.

I have checked if the string is 0~9 previously.
change to int will let the code clear.
We also can use, such as

month[0] == '1' && month[1]== '0'

but I think this is hard code

KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+    let day = value_vec[2];
+
+    // setp 1
+    let month_string = format!("{}-{}", year, month);


This is pretty awkward, we've just split the string on -, but here we're heap-allocating a String with a - to parse a month string.

YYYY-MM-DD

I want to get YYYY-MM. I don't know how to write it prettier.

KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+
+    // setp 1
+    let month_string = format!("{}-{}", year, month);
+    if !is_valid_month_string(&*month_string) {


If it helps to split the responsibilities between is_valid_month_string and is_valid_date_string more cleanly, we can instead implement parse a month component, and have that algorithm return a Result<(u32, u32), ParseError>.

Ah. I think this is a good way.

KiChjang · 2017-11-27T05:21:38Z

components/style/attr.rs

+    }
+    match month_int {
+        1|3|5|7|8|10|12 => {
+            if day_int > 31 {


Let's instead extract the number of days in month of year into its own function, and have it return a u32 representing maxday.

tigercosmos · 2017-11-27T05:42:26Z

Sorry to do this to you, but I've come to believe that this code should instead be implemented on DOMString, defined in components/script/dom/bindings/str.rs, so that we can just write domstring.is_valid_date_string().
Also, I see that sanitize_value in htmlinputelement.rs is not being updated to use your code, would you mind updating that so it accurately sanitizes input values?

@KiChjang Change to there is OK, but you said in #19172

The valid date strings algorithm is what you will need to implement, and I think the appropriate place to put that algorithm would be in components/style/attr.rs.

How do you think? I can put where you think better.

Update htmlinputelement.rs will be the next step.

KiChjang · 2017-11-27T06:08:06Z

Yeah sorry, forget about what I said in the original issue, that doesn't look like it's a good place to put the validation logic.

tigercosmos · 2017-11-27T08:00:54Z

@KiChjang Where should I put the unit test at?
components/script/dom/bindings/str.rs have no match test folder.
Since /tests/unit/script has no sub-folder

KiChjang · 2017-11-27T09:56:18Z

I think a WPT test would suffice for this; in fact, the tests under tests/wpt/web-platform-tests/html/semantics/forms/the-input-element/month.html already tests for month strings. If you don't find them to be adequate, you're welcome (and encouraged!) to add additional tests under that file. Do realize that these tests are shared across different browsers, and it's a great way to test the web forward!

tigercosmos · 2017-11-29T01:43:10Z

@KiChjang I got a problem
even I set

            atom!("month") => {
                let mut textinput = self.textinput.borrow_mut();
                textinput.set_content("".into());
            }

It will still return the origin value, like

  ▶ Unexpected subtest result in /html/semantics/forms/the-input-element/month.html:
  │ FAIL [expected PASS] Month should be > 0: If the value of the element is not a valid month string, then set it to the empty string instead.>
  │   → assert_equals: expected "" but got "2013-00"
  │ 
  │ @http://web-platform.test:8000/html/semantics/forms/the-input-element/month.html:64:9
  │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1489:20
  │ test@http://web-platform.test:8000/resources/testharness.js:511:9
  └ @http://web-platform.test:8000/html/semantics/forms/the-input-element/month.html:63:7

  ▶ Unexpected subtest result in /html/semantics/forms/the-input-element/month.html:
  │ FAIL [expected PASS] Month should be <= 13: If the value of the element is not a valid month string, then set it to the empty string instead.
  │   → assert_equals: expected "" but got "2013-13"
  │ 
  │ @http://web-platform.test:8000/html/semantics/forms/the-input-element/month.html:60:9
  │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1489:20
  │ test@http://web-platform.test:8000/resources/testharness.js:511:9
  └ @http://web-platform.test:8000/html/semantics/forms/the-input-element/month.html:59:7

KiChjang · 2017-11-29T02:34:01Z

Can you push your code to this branch? It's hard to debug without any context.

tigercosmos · 2017-11-29T03:33:58Z

components/script/dom/htmlinputelement.rs

+            }
+            atom!("month") => {
+                let mut textinput = self.textinput.borrow_mut();
+                if ! textinput.single_line_content_mut().is_valid_month_string() {


@KiChjang
even I set

atom!("month") => { let mut textinput = self.textinput.borrow_mut(); textinput.set_content("".into()); }

It will still return the origin value, like

▶ Unexpected subtest result in /html/semantics/forms/the-input-element/month.html: │ FAIL [expected PASS] Month should be > 0: If the value of the element is not a valid month string, then set it to the empty string instead.> │ → assert_equals: expected "" but got "2013-00" │ │ @http://web-platform.test:8000/html/semantics/forms/the-input-element/month.html:64:9 │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1489:20 │ test@http://web-platform.test:8000/resources/testharness.js:511:9 └ @http://web-platform.test:8000/html/semantics/forms/the-input-element/month.html:63:7 ▶ Unexpected subtest result in /html/semantics/forms/the-input-element/month.html: │ FAIL [expected PASS] Month should be <= 13: If the value of the element is not a valid month string, then set it to the empty string instead. │ → assert_equals: expected "" but got "2013-13" │ │ @http://web-platform.test:8000/html/semantics/forms/the-input-element/month.html:60:9 │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1489:20 │ test@http://web-platform.test:8000/resources/testharness.js:511:9 └ @http://web-platform.test:8000/html/semantics/forms/the-input-element/month.html:59:7

I just saw there's a space between ! and textinput.
Not sure if it will be an issue in Rust?

So, my guess here is that the value content attribute is not properly sanitized when it is first parsed. In other words, bind_to_tree needs to call sanitize_value.

@CYBAI Although this is not proper style, there's no problem with adding a whitespace in-between ! and the expression that it is trying to negate, see https://play.rust-lang.org/?gist=d27e1e8f115cb01c70bf97b8c5312c60&version=stable.

@KiChjang I just follow color method(same code textinput.set_content("".into());), and seems color implement is correct (It passes tests). So..?

@KiChjang You are right. Initialization works.
But I am wondering why color is fine lol

Many other tests pass when I set initialization!

tigercosmos · 2017-11-29T05:06:04Z

tests/wpt/metadata/html/semantics/forms/the-input-element/datetime.html.ini

@@ -21,6 +21,9 @@
  [[month\] stepUp method support on input 'month' element]
    expected: FAIL

+  [[month\] The value must be a value that is a valid global date and time string]


This is caused by time

tigercosmos · 2017-11-29T05:06:39Z

tests/wpt/metadata/html/semantics/forms/the-input-element/url.html.ini

@@ -1,8 +0,0 @@
-[url.html]


fix by initialization

tigercosmos · 2017-11-29T05:08:47Z

tests/wpt/metadata/html/semantics/forms/the-input-element/telephone.html.ini

@@ -1,11 +0,0 @@
-[telephone.html]


fix by initialization

tigercosmos · 2017-11-29T05:33:21Z

components/script/dom/htmlinputelement.rs

@@ -1110,7 +1122,8 @@ impl VirtualMethods for HTMLInputElement {
        if let Some(ref s) = self.super_type() {
            s.bind_to_tree(tree_in_doc);
        }
-


Fix other test and this PR as well

tigercosmos · 2017-11-29T06:10:53Z

I also believe these two are wrong test.
color to date will let the value to be "" not #000000

▶ Unexpected subtest result in /html/semantics/forms/the-input-element/type-change-state.html:
  │ FAIL [expected PASS] change state from color to date
  │   → assert_equals: input.value should be "#000000" after change of state expected "#000000" but got ""
  │ FAIL [expected PASS] change state from color to month
  │   → assert_equals: input.value should be "#000000" after change of state expected "#000000" but got ""
  │ 
  │ @http://web-platform.test:8000/html/semantics/forms/the-input-element/type-change-state.html:55:15
  │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1489:20
  │ test@http://web-platform.test:8000/resources/testharness.js:511:9
  └ @http://web-platform.test:8000/html/semantics/forms/the-input-element/type-change-state.html:37:9

tigercosmos · 2017-11-29T07:11:51Z

The change in previous PR #19330 is wrong
https://github.com/servo/servo/pull/19330/files#diff-a04db4d0de89c245a2878d38e99d51bdL52

tigercosmos · 2017-11-29T07:37:49Z

r? @KiChjang

KiChjang · 2017-11-29T21:36:13Z

components/script/dom/bindings/str.rs

+        let day = value_vec[2];
+
+        // Step 1
+        let month_string = format!("{}-{}", year, month);


This is still not OK. format! heap-allocates a String, and I believe we don't need any heap allocation at all.

KiChjang · 2017-11-29T21:36:13Z

components/script/dom/bindings/str.rs

+        }
+        let year_int = year.parse::<i32>().unwrap();
+        let month_int = month.parse::<i32>().unwrap();
+        let day_int = day.parse::<i32>().unwrap();


Sorry if I wasn't clear on my last request, but what I mean is that check_valid_month_string should instead be parse_month_string, which returns a type of Result<(u32, u32), ()> that contains a 2-tuple of a year-month pair for the success variant, and just an empty error for the other variant. That way, you don't need to parse here.

@KiChjang
There is still year need to parse:

let year_int = year.parse::<i32>().unwrap();

If we parse the three(year, month, day) together would let the code more clear?

That's a code duplication that I would like to avoid, since you should have already parsed the month and year in the parse_month_string algorithm.

KiChjang · 2017-11-29T21:36:13Z

components/script/dom/bindings/str.rs

+        } else if day_int > self.max_day_in_month(year_int, month_int) {
+            return false;
+        }
+        return true;


nit: No explicit returns are necessary for the last expression.

KiChjang · 2017-11-29T21:36:13Z

components/script/dom/bindings/str.rs

+
+    /// Valid month string should be "YYYY-MM"
+    /// https://html.spec.whatwg.org/multipage/#valid-month-string
+    pub fn is_valid_month_string(&mut self) -> bool {


What's the purpose for this function? It looks to me as an unnecessary indirection.

@KiChjang
because the origin usage is:

DOMString.is_valid_month_string()

The logic in it can be use in is_valid_date_string()

So perhaps my question is better phrased as "why is is_valid_month_string and check_valid_month_string" not the same function?

@KiChjang
when we call is_valid_month_string will deal the self.0 string.

But when we call is_valid_date_string and want to use logic in is_valid_month_string, we cannot directly call is_valid_month_string in is_valid_date_string, because at that time self.0 might be 1990-12-20 and is_valid_month_string will return false.

That's why I make the logic out to check_valid_month_string(value: &str). We can give value string for two case usage.

Maybe there is a better way to do this.

I think we need to be careful when reading the spec here - according to my reading, the spec does not fail on parsing a month component if the string contains a date at the end; it simply does not parse the rest of the string, and returns year and month to the caller of this algorithm.

@KiChjang
According to the spec:

A string is a valid month string representing a year year and month month if it consists of the following components in the given order:

Four or more ASCII digits, representing year, where year > 0

A U+002D HYPHEN-MINUS character (-)

Two ASCII digits, representing the month month, in the range 1 ≤ month ≤ 12

Which means only "YYYY-MM" is valid to is_valid_month_string function

Note that it says "consists of the following components" - it's missing the only keyword. In other words, date strings are also valid month strings.

Furthermore, I believe we have agreed to use the parse a month component algorithm instead of the validation algorithm, so this part of the spec shouldn't be relevant to your implementation.

KiChjang · 2017-11-29T21:36:13Z

components/script/dom/bindings/str.rs

+                }
+            },
+            _ => {
+                panic!("Month number must be in range 1~12.")


Instead of panicking here, we can choose to return a Result<u32, ()> instead, and return Err(()) here.

KiChjang · 2017-11-29T21:36:13Z

tests/wpt/web-platform-tests/html/semantics/forms/the-input-element/month.html

      <input id="invalid_value_with_two_digits_year" type="month" value="13-06" />
      <input id="invalid_value_is_set" type="month" />
      <input id="step_attribute_is_invalid_value" type="month" value="2013-06" step="invalid_step_value" />
      <input id="invalid_month_too_high" type="month" value="2013-13" />
      <input id="invalid_month_too_low" type="month" value="2013-00" />
+      <input id="invalid_year_all_zerro" type="month" value="0000-10" />


invalid_year_all_zero

KiChjang · 2017-11-29T21:36:13Z

tests/wpt/web-platform-tests/html/semantics/forms/the-input-element/month.html

      <input id="valid" type="month" value="2011-11" min="2011-01" max="2011-12" />
      <input id="invalid_value" type="month" value="invalid-month" min="2011-01" max="2011-12"/>
-      <input id="value_can_be_empty_string" type="month" value="2013-06" />
+      <input id="value_can_be_empty_string" type="month" value="" />


Why is this change necessary?

The purpose in this test, is testing value to be empty string. But it set value for it.

It sets the value as an empty string in the test below:

document.getElementById("value_can_be_empty_string").value = "";

Why set empty below not set directly? I think it is not intuitive

You may contact the author of this test and ask them this question. However I can venture a guess: the value of the value content attribute is the empty string at initialization, and setting it directly via the IDL setter ensures that we are testing specifically for the value sanitization algorithm.

KiChjang · 2017-11-29T21:36:13Z

tests/wpt/web-platform-tests/html/semantics/forms/the-input-element/month.html

    </div>

    <div id="log"></div>

    <script>
+      test(function() {
+        assert_equals(document.getElementById("valid_value_1").value, "20133-12")
+      }, "year can be more than four number");


"year can be more than four digits"

KiChjang · 2017-11-29T21:36:13Z

tests/wpt/web-platform-tests/html/semantics/forms/the-input-element/month.html

+
+      test(function() {
+        assert_equals(document.getElementById("valid_value_3").value, "0003-01")
+      }, "year must be four or more number even if it is zero");


"year can contain prefixes of zero, as long as there are at least four digits"

KiChjang · 2017-11-29T21:36:13Z

tests/wpt/web-platform-tests/html/semantics/forms/the-input-element/month.html

+
+      test(function() {
+        assert_equals(document.getElementById("invalid_month_with_one_number").value, "");
+      }, "Month should be two number: If the value of the element is not a valid month string, then set it to the empty string instead.>");


"Month should be two digits"

KiChjang · 2017-11-30T03:42:57Z

tests/wpt/web-platform-tests/html/semantics/forms/the-input-element/type-change-state.html

@@ -49,12 +49,12 @@
          } else {
            input.value = "  foo\rbar  ";
            input.type = types[j].type;  // change state
-            if (types[i].type !== "color" && (types[j].sanitizedValue || types[j].sanitizedValue === "")) {
-              assert_equals(input.value, types[j].sanitizedValue, "input.value should be " + types[j].sanitizedValue + " after change of state");
+            if (types[j].sanitizedValue || types[j].sanitizedValue === "") {


I haven't looked closely enough on this change yet; will need some time before I can determine whether this is the actual change we want.

This is in #19330
https://github.com/servo/servo/pull/19330/files#diff-a04db4d0de89c245a2878d38e99d51bdL52

will cause

▶ Unexpected subtest result in /html/semantics/forms/the-input-element/type-change-state.html: │ FAIL [expected PASS] change state from color to date │ → assert_equals: input.value should be "#000000" after change of state expected "#000000" but got "" │ FAIL [expected PASS] change state from color to month │ → assert_equals: input.value should be "#000000" after change of state expected "#000000" but got ""

But actually it should pass

You are correct. This part of the spec makes it clear that the value sanitization algorithm should be run when there is a change of state.

Uh, sorry, that was not the full story. Because the value sanitization algorithm is ran when the input.value is set, color type inputs will sanitize their values, and if it's a " foo\rbar " string, it would instead set the value as "#000000". This makes the expected value "#000000" even when you change the input type to text.

For date and month type inputs however, you're correct that it should expect the empty string instead.

I'll note that removing this check here isn't the correct fix though, we need to think of a more comprehensive way of testing this correctly -- the other PR is currently working on this.

Since the other PR is already fixing this, we should revert the change here.

tigercosmos · 2017-12-03T13:05:00Z

@KiChjang please check.

KiChjang · 2017-12-03T20:09:23Z

components/script/dom/bindings/str.rs

+
+    // Step 1, 2
+    let year_int = year.parse::<u32>().map_err(|_| ())?;
+    if year.len() < 4 || year_int > 0 {


If you check whether the year is greater than 0 then all valid years will be rejected.

KiChjang · 2017-12-04T05:27:02Z

After reverting the changes to type-change-state.html, you'll need to run ./mach update-manifest, push the changes, squash, and r=me.

tigercosmos · 2017-12-04T05:57:17Z

@KiChjang Done . Thanks.

KiChjang · 2017-12-04T07:16:14Z

@tigercosmos I don't seem to see the changes in type-change-state.html reverted?

tigercosmos · 2017-12-04T07:38:19Z

Sorry. I lose reverting!
Update later.

tigercosmos · 2017-12-04T07:57:57Z

@KiChjang Reverted! Thanks for your patient 👍

bors-servo · 2017-12-04T23:21:05Z

☔ The latest upstream changes (presumably #19379) made this pull request unmergeable. Please resolve the merge conflicts.

KiChjang · 2017-12-05T01:18:32Z

@tigercosmos Can you squash this into one commit? After that, this can finally land!

tigercosmos · 2017-12-05T01:33:49Z

@KiChjang done

KiChjang · 2017-12-05T01:36:47Z

components/script/dom/bindings/str.rs

+
+    /// Validates this `DOMString` is a time string according to
+    /// <https://html.spec.whatwg.org/multipage/#valid-time-string>.
+    pub fn is_valid_time_string(&self) -> bool {


This code shouldn't be here, the function is defined twice!

weird.. I will update


        implement "Date type inputs", "Month type inputs"

tigercosmos · 2017-12-05T01:51:21Z

./mach build -d does not report any errors
./mach test-tidy does not report any errors

KiChjang · 2017-12-05T01:52:20Z

@bors-servo r+

Thanks!

bors-servo · 2017-12-05T01:52:21Z

📌 Commit 927fd1d has been approved by KiChjang

bors-servo · 2017-12-05T01:58:09Z

⌛ Testing commit 927fd1d with merge 68cefb1...


        Auto merge of #19385 - tigercosmos:b1, r=KiChjang

implement "Date type inputs", "Month type inputs"  implement "Date type inputs", "Month type inputs" ---  - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] `./mach test-unit` does not report any errors  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/19385)

bors-servo · 2017-12-05T03:02:23Z

☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css1, mac-rel-css2, mac-rel-wpt1, mac-rel-wpt2, mac-rel-wpt3, mac-rel-wpt4, windows-msvc-dev
Approved by: KiChjang
Pushing 68cefb1 to master...

CYBAI · 2017-12-05T04:04:08Z

@tigercosmos @KiChjang WOW! Congrats!

tigercosmos · 2017-12-05T04:15:44Z

@CYBAI thanks! Finally…


        implement "Date type inputs", "Month type inputs"

Upstreamed from servo/servo#19385 [ci skip]

highfive assigned KiChjang Nov 26, 2017

highfive added the S-awaiting-review label Nov 26, 2017

KiChjang requested changes Nov 27, 2017

View changes

KiChjang added S-needs-code-changes and removed S-awaiting-review labels Nov 27, 2017

KiChjang mentioned this pull request Nov 27, 2017

[meta] Implement value sanitizations for different input modes #19172

Closed

7 of 8 tasks complete

tigercosmos changed the title ~~implement "valid date string" and "valid month string"~~ [WIP] implement "Date type inputs", "Month type inputs", "valid date string" and "valid month string" Nov 27, 2017

highfive added S-awaiting-review and removed S-needs-code-changes labels Nov 29, 2017

tigercosmos reviewed Nov 29, 2017

View changes

tests/wpt/metadata/html/semantics/forms/the-input-element/url.html.ini

@@ -1,8 +0,0 @@

[url.html]

This comment has been minimized.

Sign in to view

tigercosmos Nov 29, 2017
Author Collaborator

fix by initialization

tigercosmos reviewed Nov 29, 2017

View changes

tests/wpt/metadata/html/semantics/forms/the-input-element/telephone.html.ini

@@ -1,11 +0,0 @@

[telephone.html]

This comment has been minimized.

Sign in to view

tigercosmos Nov 29, 2017
Author Collaborator

fix by initialization

tigercosmos reviewed Nov 29, 2017

View changes

tigercosmos changed the title ~~[WIP] implement "Date type inputs", "Month type inputs", "valid date string" and "valid month string"~~ implement "Date type inputs", "Month type inputs", "valid date string" and "valid month string" Nov 29, 2017

KiChjang requested changes Nov 29, 2017

View changes

KiChjang added S-needs-code-changes and removed S-awaiting-review labels Nov 29, 2017

KiChjang reviewed Nov 30, 2017

View changes

highfive removed the S-needs-code-changes label Nov 30, 2017

KiChjang requested changes Dec 3, 2017

View changes

highfive added the S-needs-rebase label Dec 4, 2017

KiChjang reviewed Dec 5, 2017

View changes

implement "Date type inputs", "Month type inputs"

Loading status checks…

927fd1d

highfive added S-awaiting-merge and removed S-awaiting-review S-needs-rebase labels Dec 5, 2017

bors-servo merged commit 927fd1d into servo:master Dec 5, 2017
2 of 3 checks passed

2 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details

continuous-integration/appveyor/pr AppVeyor build succeeded
Details

homu Test successful
Details

highfive removed the S-awaiting-merge label Dec 5, 2017

bors-servo mentioned this pull request Dec 5, 2017

Expand InputType to cover all possible types #19471

Merged

tigercosmos deleted the tigercosmos:b1 branch Dec 5, 2017

jdm added a commit to web-platform-tests/wpt that referenced this pull request Jan 4, 2018

implement "Date type inputs", "Month type inputs"

2084273

Upstreamed from servo/servo#19385 [ci skip]

servo-wpt-sync mentioned this pull request Jan 4, 2018

implement "Date type inputs", "Month type inputs" web-platform-tests/wpt#8912

Merged

servo / servo

Join GitHub today

implement "Date type inputs", "Month type inputs" #19385

implement "Date type inputs", "Month type inputs" #19385

Conversation

tigercosmos commented Nov 26, 2017 • edited

highfive commented Nov 26, 2017

KiChjang left a comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

tigercosmos commented Nov 27, 2017

KiChjang commented Nov 27, 2017

tigercosmos commented Nov 27, 2017 • edited

KiChjang commented Nov 27, 2017

tigercosmos commented Nov 29, 2017 • edited

KiChjang commented Nov 29, 2017

This comment has been minimized.

This comment has been minimized.

CYBAI Nov 29, 2017 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

tigercosmos Nov 29, 2017 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

tigercosmos commented Nov 29, 2017

tigercosmos commented Nov 29, 2017

tigercosmos commented Nov 29, 2017

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

tigercosmos Nov 30, 2017 • edited

This comment has been minimized.

KiChjang Nov 30, 2017 • edited

This comment has been minimized.

tigercosmos Nov 30, 2017 • edited

This comment has been minimized.

KiChjang Nov 30, 2017 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

tigercosmos commented Dec 3, 2017

This comment has been minimized.

tigercosmos commented Nov 26, 2017 •

edited

tigercosmos commented Nov 27, 2017 •

edited

tigercosmos commented Nov 29, 2017 •

edited

CYBAI Nov 29, 2017 •

edited

tigercosmos Nov 29, 2017 •

edited

tigercosmos Nov 30, 2017 •

edited

KiChjang Nov 30, 2017 •

edited

tigercosmos Nov 30, 2017 •

edited

KiChjang Nov 30, 2017 •

edited

KiChjang commented Dec 4, 2017 •

edited