01:38 | <Domenic> | I don't have a lot of hope that doing so would result in new resources magically being discovered. |
02:22 | <Yagiz Nizipli> | For those who are unfamiliar, NativeScript has added a spec-compliant URLPattern implementation to both of their iOS and Android runtimes - https://github.com/NativeScript/ios/pull/268 |
07:34 | <annevk> | Domenic: could I ask you to get someone familiar with URLPattern to comment on https://github.com/w3c/IFT/issues/259? Perhaps the URLPattern specification should have some examples as how to address URI template use cases? |
07:41 | <sideshowbarker> | I’m looking at the test case at https://github.com/web-platform-tests/wpt/blob/3c11c5bae7639991e1a300ad841dd53f571eecf3/html/semantics/forms/constraints/form-validation-checkValidity.html#L96 and trying to determine figure out how the expectation of false aligns with the actual spec requirements. That test case just creates this:
|
07:42 | <sideshowbarker> | So I guess the intent of that test case is, the value shouldn’t be allowed to have a :00 seconds part. |
07:43 | <sideshowbarker> | But determining whether it’s allowed or not involves running the algorithm at https://html.spec.whatwg.org/multipage/input.html#concept-input-min-zero — the second step of which is:
|
07:44 | <sideshowbarker> | So the ”step base” is the same as the value. |
07:46 | <sideshowbarker> | So then I look at https://html.spec.whatwg.org/multipage/input.html#the-step-attribute%3Asuffering-from-a-step-mismatch, and that says:
|
07:48 | <sideshowbarker> | “step base” - value = 0 (since “step base” is the same as the value) |
07:49 | <sideshowbarker> | …and “allowed value step” is 2 * 60 * 1000 |
08:03 | <sideshowbarker> | I’m wondering if the intended requirement is instead to just use the value as-is — that is, not subtract it from “step base” |
08:04 | <sideshowbarker> | So, 12:03:00 is the number 43380000 — and 43380000 is not an integral multiple of 120000 (2 * 60 * 1000) |
08:05 | <sideshowbarker> | Or maybe I’m just misreading the spec requirement — and the spec isn’t saying to do “step base” - value |
08:11 | <sideshowbarker> | Or else at https://html.spec.whatwg.org/multipage/input.html#concept-input-min-zero, the 2nd step of that algorithm should just be removed — and then it would always return 0 unless there’s a min value or a “default step base“ defined (which is only the case for type=week) |
08:12 | <annevk> | Doesn't it create <input type=time value="12:03:00" step="120000"> ? |
08:12 | <sideshowbarker> | Yes |
08:13 | <annevk> | All browsers appear to consider that valid. Maybe the test is wrong? |
08:13 | <sideshowbarker> | Well, all of WebKit/Gecko/Blink pass that test |
08:13 | <annevk> | I don't really like the way the input element is organized in the specification, but I also never attempted a different approach. |
08:13 | <sideshowbarker> | Yeah I really don’t like it either |
08:14 | <sideshowbarker> | But I also don’t have any great suggestions for how else to organize it |
08:15 | <annevk> | It's weird that they all pass. Because :invalid doesn't match in any of them. |
08:15 | <annevk> | https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cstyle%3E%0A%3Ainvalid%20%7B%20background%3Ared%20%7D%0A%3C%2Fstyle%3E%0A...%3Cinput%20type%3Dtime%20value%3D%2212%3A03%3A00%22%20step%3D%22120000%22%3E |
08:16 | <sideshowbarker> | hmm, I hopes this is not one of those cases where existing engines just implemented whatever would get them passing the tests |
08:16 | <sideshowbarker> | the constraint-validation tests are not super-great tests anyway |
08:17 | <sideshowbarker> | the coverage is extremely minimal |
08:18 | <sideshowbarker> | But I’m also not super enthusiastic about being the person who has to add more test coverage for all this stuff |
08:19 | <sideshowbarker> | I think for my implementation I’m going to go ahead and drop step 2 of https://html.spec.whatwg.org/multipage/input.html#concept-input-min-zero from the implementation — with a comment saying why |
08:24 | <sideshowbarker> | Because, If I do that that, the tests pass. And also, I can’t actually make sense of that step. I mean, it seems to me that step is always going to end up returning the same thing as the value attribute value. And it doesn’t logically seem like the “step base” for the element should always be same as the value of the value attribute (in the absence of a min or “default step base“ ). Instead the “step base” should just be either min or a “default step base“ or else just zero. That is, it’s a floor against which the value is evaluated. |
08:30 | <Domenic> | I think this is https://github.com/whatwg/urlpattern/issues/73 , right? It's indeed not something that's possible right now, but with some extra spec and implementation work, it could be. |
08:37 | <annevk> | Ah, I think you're right. Thanks. |
09:14 | <sideshowbarker> | Even if I set value=foo there instead, that :invalid { background:red } doesn’t see to do anything |
09:15 | <sideshowbarker> | Even if I set value=foo there instead, that :invalid { background:red } doesn’t see to do anything |
09:16 | <annevk> | sideshowbarker: oh maybe it only starts applying once there's user modifications? It's kinda weird as :valid does apply. |
09:18 | <sideshowbarker> | Yeah I don’t know. I rightly should understand the details of this API better before trying to implement it 😆 |
09:19 | <sideshowbarker> | but yeah :invalid does seem to only work after user modification |
09:19 | <annevk> | Hmm no, :invalid does not depend on end user input (per spec). Figuring this out properly would require quite a bit of time I want to spend on other things at the moment. |
09:20 | <sideshowbarker> | yeah, no worries |
09:20 | <sideshowbarker> | for now, I’ll just raise an issue about the “step base” thing |
11:11 | <sideshowbarker> | Raised https://github.com/whatwg/html/issues/11097 |