| 03:55 | <Domenic> | I don't understand the question, sorry... The spec text you quote does not involve the word "sibling", and I can't understand your followup question after you gave the frame tree. |
| 03:56 | <Domenic> | I am curious what exact term in the existing specification you don't understand? |
| 03:57 | <Domenic> | Like if you implement the spec's algorithms as-written (in a small standalone code, e.g. a JS snippet) where do you get stuck? |
| 09:17 | <canadahonk> | I don't understand the question, sorry... The spec text you quote does not involve the word "sibling", and I can't understand your followup question after you gave the frame tree. In reply to Domenic I meant that it doesn't specify what to do with siblings at all as far as I can tell? And WPTs expect it to set in siblings as well I think |
| 09:17 | <canadahonk> | it does specify itself as windows starts with it's own the beginning* |
| 09:21 | <annevk> | canadahonk: per the spec those tests would be wrong |
| 09:23 | <annevk> | canadahonk: if the tests are correct, it might make more sense to track clicks on the agent directly in some kind of origin -> activation timestamp map |
| 09:32 | <canadahonk> |
|
| 09:36 | <annevk> | canadahonk: no |
| 09:39 | <annevk> | canadahonk: I vaguely recall bringing this up at one point and people said this was intentional; would require some checking; but if it's not what's implemented and tested that's all kinda moot |
| 09:39 | <canadahonk> | that's what a WPT expects so :/ (guessing chrome does this too then as it's from them) |
| 09:41 | <annevk> | canadahonk: file an issue? And maybe find the original commit/PR as a bonus? |
| 09:42 | <canadahonk> | yeah I was asking if it is a spec bug or a wpt bug |
| 09:47 | <annevk> | canadahonk: if implementations follow WPT, it doesn't really matter and should be raised at the spec level |
| 10:37 | <canadahonk> | filed https://github.com/whatwg/html/issues/9831 for reference |
| 11:13 | <annevk> | Hmm, for both <input type=url> and <input type=email> we don't attempt to canonicalize the input at all, it seems, across browsers |
| 11:13 | <annevk> | That strikes me as the wrong thing to do |
| 12:23 | <annevk> | I wonder if emilio or jarhar have thoughts on that. As an example, if you enter https://example.org/?q=🏳️🌈 as a URL, that is what gets submitted, not https://example.org/?q=%F0%9F%8F%B3%EF%B8%8F%E2%80%8D%F0%9F%8C%88 (which is what parsing and serializing would return) |
| 12:23 | <annevk> | It's not entirely broken, but it's very much reliant on the fact that the server uses the same email/URL parser |
| 12:39 | <annevk> | It does seem like we have a number of ways we could use to make the display value and actual value diverge, like the modes of the value IDL attribute |
| 14:39 | <annevk> | emilio: jarhar: made it a bit more concrete in https://github.com/whatwg/html/issues/4562#issuecomment-1747014388 |
| 17:12 | <jarhar> | i dont have really strong opinions on this. i can try to implement and ship what you think is best but if it breaks lots of websites then ill have to reconsider |
| 17:55 | <annevk> | jarhar: that's a very kind offer, let's see what the i18n experts have to say (particularly hoping for a reply from Addison) and take it from there |
| 17:59 | <annevk> | jarhar: for IP addresses I guess I should look at that more carefully, I saw some comment that even IPv4 email addresses required some kind of [ ] escaping which I don't think browsers handle, but maybe that was just wrong |
| 18:09 | <bkardell> | annevk: "Also, it's written by Frédéric Wang as well." Can you explain what you mean by this? |
| 18:14 | <bkardell> | ah probably you mean way further down the preview shows, the authors |
| 19:47 | <1ln9> | heya 'yall. :) |