| 01:38 | <Domenic> | We'd like to move away from sniffing, and have tried to require new formats to not be sniffed, but implementations have not agreed. I believe their objections have been non-technical ("why should my format be slightly harder to adopt than all the old formats?") but maybe there are technical reasons too. |
| 07:21 | <annevk> | For SVG implementations already check the MIME type I believe so introducing another such MIME type seems good. |
| 07:47 | <annevk> | keithamus: could you give feedback somewhere that I'd love to enable the two-factor authentication requirement for WHATWG if only it gave the option to give everyone impacted a two weeks heads up? It seems like the current checkbox will just kick everyone out which at this point might well be acceptable given the limited number of people impacted, but it still seems preferable to give everyone a bit of wiggle room. (This lack of clarity around how the requirement is communicated has already delayed our adoption by two years or so.) |
| 08:28 | <keithamus> | Thanks, I'll pass it on to the team responsible for 2fa enforcement |
| 09:34 | <annevk> | Adam Rice: I revived and cleaned up https://github.com/whatwg/encoding/pull/309 as it still seems worth doing |
| 09:40 | <annevk> | Yagiz N: what does https://x.com/yagiznizipli/status/1841855393481302338 mean? |
| 11:18 | <Yoav Weiss> | Hey folks! Question about URLs. If I'm parsing "https://example.com/foo//bar", I wouldn't expect it to be identical to a parsed "https://example.com/foo/bar", right? |
| 11:20 | <Adam Rice> | I don't know what you'd expect, but https://www.ada-url.com/playground?url=https%3A%2F%2Fexample.com%2Ffoo%2F%2Fbar says they are different. |
| 11:21 | <Yoav Weiss> | yeah, that's what I figured |
| 11:21 | <Yoav Weiss> | for some reason I thought the URL parser would remove spurious '/' in the path, but I was wrong |
| 11:23 | <Yoav Weiss> | yeah, the spurious slashes even go out on the network |
| 11:23 | <Yoav Weiss> | I guess it's on the server to dedup them |
| 11:50 | <annevk> | Yoav Weiss: we only ignore infinite slashes after special URL schemes (and a colon), to much chagrin of the curl maintainer |
| 14:05 | <mikedidomizio> | Hey group, Has there at any time been examples of a feature released in browsers where the decision on behaviour has been revisited and revised? I'm wondering the process behind how that works? In this GitHub issue there was some discussion around if people would misunderstand how it's used, and if it should be changed. This all stemmed from my current place of employment recognizing a bug in our code, that fortunately wasn't too bad, but nonetheless a bug due to our misunderstanding of the behaviour. We went ahead and decided to use React to build a layer on top to change the behaviour, replaced current implementations, and forbid all future usages of So far every person I've explained this current behaviour to gave me the same response in that it behaves differently than they would expect. So to close this out, I think helping me understand the process, previous examples, and other statistics you would use to make a decision, would help me understand if it's worth to continue to pursue this or not. I'm hoping I'm not coming off as a nuisance. It's not my intention, I'm focused on respecting developers' time and reducing the likelihood of future bugs. |
| 14:47 | <annevk> | r? https://github.com/whatwg/meta/pull/332 |
| 14:50 | <annevk> | We did briefly discuss your xweet on Wednesday and special casing the parser case would actually be quite a bit of work. I think to me it does signify that tracking state through an attribute was a mistake, but changing it for this existing element would be quite the undertaking. |
| 15:41 | <mikedidomizio> | Thanks annevk . I appreciate you guys taking the time to discuss it further. I assume it's not an easy decision. I'm just learning that the WHATNOT meetings are open to the public (I think), and I see transcripts inside the GitHub issues. Can someone link me the discussion on this? More so out of curiosity. A lot of what you guys do intrigues me. |
| 17:19 | <TabAtkins> | Does anyone have any memory of why the specific list of codepoints were allowed in custom element names? https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name The list excludes emoji like ✨, but allows others, so I'm a little confused by it. |
| 17:21 | <TabAtkins> | (For example, a-🥔 is a valid custom element name, but a-✨ isn't.) |
| 17:23 | <TabAtkins> | This is relevant to CSS, because the Syntax spec just copied HTML's set of allowed characters, but that means --✨ is an invalid custom property name. We at least want to be a superset of HTML's allowed characters, so authors don't have to use escapes to write selectors targeting their custom elements; I'm just checking if there's a good reason for this exact set of restrictions, or if I can relax CSS a bit. |