| 07:31 | <sideshowbarker> | Per https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values, when parsing floating-point number values: Should implementations return Infinity and NaN if that’s the number value a string parses to — or instead should implementations treat Infinity and NaN be treated as errors ? In that HTML spec algorithm itself, there’s nothing explicit about handling Infinity and NaN — but in the WebIDL spec at https://webidl.spec.whatwg.org/#ref-for-idl-float①, I see:
|
| 07:34 | <Domenic> | sideshowbarker: the HTML algorithm treats strings like "Infinity" or "NaN" as errors, if that's what you're asking. It's completely separate from the Web IDL algorithm, and has different call sites. |
| 07:38 | <annevk> | I'm not sure, but I think there's definitely a worry about changing the existing contract drastically as it'll impact many websites. |
| 07:38 | <sideshowbarker> | So I guess the only way that algorithm would ever return Inifinity or NaN is if it were given "Infinity" or "NaN" as input? If so then I guess another way to state it is: The algorithm never returns "Infinity" or "NaN" — it always returns either an actual number, or an error? |
| 07:39 | <annevk> | That looks correct, from a quick glance. |
| 07:43 | <Domenic> | The latter statement seems correct. But the former doesn't. If the algorithm were given "Infinity" or "NaN" as an input, then it would return error, not Infinity or NaN. |
| 07:45 | <sideshowbarker> | Right, sorry — I misspoke there. I guess meant to say something more like, The only way something would end up getting evaluated (not returned) by the algorithm as Inifinity or NaN would be if it the algorithm were given the strings "Infinity" or "NaN" as input. |
| 10:42 | <hsivonen> | The ZWNJ and ZWJ rules at https://www.iana.org/assignments/idna-tables-12.0.0/idna-tables-12.0.0.xhtml#idna-tables-context affect whether a URL is fetchable, but the middle dot rule seems to affect only the URL bar display the domain. Has anyone researched what the effect of this list should be on browser behavior? https://www.iana.org/assignments/idna-tables-12.0.0/idna-tables-12.0.0.xhtml#idna-tables-context CC annevk |
| 11:12 | <hsivonen> | The ZWNJ and ZWJ rules at https://www.iana.org/assignments/idna-tables-12.0.0/idna-tables-12.0.0.xhtml#idna-tables-context affect whether a URL is fetchable, but the middle dot rule seems to affect only the URL bar display the domain. Has anyone researched what the effect of this list should be on browser behavior? https://www.iana.org/assignments/idna-tables-12.0.0/idna-tables-12.0.0.xhtml#idna-tables-context CC annevk |
| 12:38 | <hsivonen> | annevk: I'm looking at the unit tests of the IDNA crate and have trouble believing what I'm seeing. Is it really intentional that empty DNS labels are allowed in URLs as long as the domain as a whole isn't empty? (Somehow I imagined that only a trailing empty label was allowed.) Browsers don't seem to treat hsivonen.fi.xn-- as equivalent to hsivonen.fi. , but I fail to find spec text that says so. What am I missing? |
| 12:42 | <annevk> | So https://example..com/ parses. I think I was surprised by that as well. Not sure about xn-- though. |
| 12:48 | <annevk> | hsivonen: I guess what's not clear is where decoding xn-- fails. It does seem good for it to fail though as it would normalize away, which seems bad. |
| 12:48 | <hsivonen> | hsivonen: I guess what's not clear is where decoding xn-- failing at all. |
| 12:49 | <hsivonen> | annevk: But are other empty labels supposed to be allowed. Is hsivonen..fi really supposed to be allowed? |
| 12:49 | <annevk> | hsivonen: I think it has worked in all browsers since forever? |
| 12:50 | <annevk> | If we just did DNS there's a whole bunch of things we could ban, but we don't and therefore it's trickier. |
| 12:51 | <hsivonen> | hsivonen: I think it has worked in all browsers since forever? |
| 12:53 | <annevk> | I think per https://www.unicode.org/reports/tr46/#ProcessingStepPunycode and https://www.rfc-editor.org/rfc/rfc3492.html xn-- is indeed expected to become the empty string. That seems like a bug though. |
| 12:57 | <annevk> | hsivonen: r? https://github.com/whatwg/encoding/pull/328 |
| 13:58 | <zcorpan> | Do you mean "reasonable options" for fixing the CORS error? I'm not sure I can think of more than what I've already suggested, tbh. One difficulty is that browsers are often left with insufficient contextual information about a preflight failure to produce a helpful CORS error message. For a typical example, see https://jub0bs.com/posts/2023-02-08-fearless-cors/#9-ease-troubleshooting-by-eschewing-shortcuts-during-preflight |
| 14:42 | <hsivonen> | I think per https://www.unicode.org/reports/tr46/#ProcessingStepPunycode and https://www.rfc-editor.org/rfc/rfc3492.html |
| 14:43 | <dean.highpower> | The existing HTML spec respects no RFC (5321 or 5322), instead invents a new syntax for email addresses. This new syntax rejects perfectly valid us-ascii mailbox addresses that are and have been valid (since at least 1982) with no apparent basis. This is harmful. I have seen this new syntax used by other projects, citing the HTML spec as the authority for their "willful violation of RFC 5322" -- with no mention of the standard they should be looking at, RFC-5321. I understand the practical considerations of wanting a simple grammar to check against. Could we specify a simple syntax check that would not reject any mailbox address considered valid by RFC-5321? A strict check could be used to test exact adherence to the RFC, such checkers exist for many languages. (https://www.npmjs.com/package/smtp-address-parser for JavaScript.) The HTML spec is a "living standard" so should be open to change. Please can we fix it? |
| 14:49 | <annevk> | hsivonen: that would probably be a good property, yeah! |
| 14:52 | <annevk> | It's not about wanting a simple grammar, it's a worry about breaking existing websites. |
| 14:55 | <dean.highpower> | It's not about wanting a simple grammar, it's a worry about breaking existing websites. |
| 14:56 | <dean.highpower> | 😀 |
| 14:58 | <annevk> | Right, I'm well familiar with both sides of this debate. You asked why people might be reluctant so I attempted to explain. |
| 15:05 | <dean.highpower> | Okay, does anybody think that RFC-5322 is the right standard to be looking to for mailbox address syntax? I think this is the underlying mistake (not recognizing RFC-5321 as the relavent document) that lead the HTML spec into inventing it's own syntax. (That's like swallowing a spider to catch the fly...) |
| 15:11 | <dean.highpower> | no blame here, email standard are complex |
| 15:11 | <dean.highpower> | it's easy to get confused |
| 15:12 | <dean.highpower> | this is the count of RFC related to DNS and mail |
| 15:14 | <Andreu Botella> | I'm taking a look at which parts of event handling in the DOM spec server-side runtimes and other non-DOM implementations need to implement and which don't |
| 15:15 | <Andreu Botella> | and I'm wondering about the behavior of an event's path if the same event gets dispatched from an event listener |
| 15:17 | <Andreu Botella> | in dispatch 5.3, before running the listeners, an item is added to the event's path, and then after running the listeners in step 8 the path is cleared |
| 15:17 | <Andreu Botella> | but if you have an event dispatch inside a listener, any "outer" listeners that haven't yet run will have an empty path |
| 15:17 | <Andreu Botella> | am I reading this right? |
| 15:19 | <Andreu Botella> | annevk: |
| 15:26 | <annevk> | I guess I don't think that's a relevant question here. Pretty much everyone is in agreement that this should change. The question is really how, what the processing model is going to be, and what the impact of that change will be (which likely requires some amount of testing and perhaps incremental rollout in some browser). |
| 15:29 | <Andreu Botella> | oh, I just realized that the dispatch flag is meant to avoid this kind of thing |
| 15:30 | <Andreu Botella> | but it doesn't seem to prevent dispatches from el.click() |
| 15:30 | <Andreu Botella> | oh, never mind, that's of course a new event |
| 15:32 | <Andreu Botella> | I'm working on a PR that adds a few assertions and notes to indicate which parts of event handling are not needed for implementers like server-side runtimes |
| 15:32 | <Andreu Botella> | and it seems like for such runtimes, an event's path can be simplified into an EventTarget or null, rather than a list |
| 15:38 | <annevk> | Why would a path ever be an EventListener? That seems weird. That also wouldn't work once we add path support to the EventTarget constructor, as has been requested for a while (mainly needs someone to write down a design). |
| 15:40 | <Andreu Botella> | my bad, an EventTarget |
| 15:43 | <Andreu Botella> | Why would a path ever be an EventTarget constructor", I assume you mean letting custom EventTargets define tree structures? |
| 15:44 | <Andreu Botella> | I didn't know that was being worked on, or in people's todo list |
| 15:51 | <Andreu Botella> | there's still a number of event handling-related things that implementations without a native DOM wouldn't need to support, such as things related to shadow trees or touch target lists |
| 15:52 | <Andreu Botella> | so that PR might still be useful after all, but it's better to wait until the path support is ready |
| 16:19 | <zcorpan> | Right, sorry — I misspoke there. I guess meant to say something more like, The only way something would end up getting evaluated (not returned) by the algorithm as Inifinity or NaN would be if it the algorithm were given the strings "Infinity" or "NaN" as input. |
| 16:27 | <hsivonen> | hsivonen: that would probably be a good property, yeah! |
| 16:28 | <annevk> | hsivonen: see the DNS vs host parser issue on non-DNS systems. They are rather opaque to me. |
| 19:44 | <dean.highpower> | So will the HTML spec going forward define the syntax of email address according to the <Mailbox> ABNF rule from RFC 5321, as extended by RFC 6531? I believe this would be consistent with the vast majority of operational email systems on the public Internet. (Including gmail, outlook, etc.) How is a "processing model" involved in this? (Please forgive my ignorance.) |
| 22:24 | <dean.highpower> | Bonus: once you're citing the correct RFC, there is no need to publish any "willful violation" notice about any irreverent RFCs. |