2022-01-01 [19:04:44.0380] If I were in charge of the web, I'd probably tell GitHub to change GitHub pages or they'd be left behind (It's probably a good thing I'm not in charge of the web) [09:09:38.0243] Hi people, hope you are having a good day. I have a question, how would one unit test the correctness of an HTML parser, should I just find several malformed html pages and test against what Chrome or Mozilla parses in the browser, I'll also appreciate it there are links to test cases, e.g if you have so so so malformed structure, you get the following output, something like that. I have seen few but I need more to test rigorously. Thanks [09:15:25.0029] devsrealmguy: you may get a better response on https://matrix.to/#/#wpt:matrix.org (though there is a lot of shared people between these rooms) [09:16:22.0205] Thanks, I'll join the room now [11:13:27.0681] annevk Am I correct in my interpretation that `Foo: abc, xyz\r\n` and `Foo: abc\r\nFoo: xyz\r\n` are both fetch spec compliant on the wire encodings for a request issued with `fetch` as follows? ```js fetch(url, { headers: [["Foo", "abc"], ["Foo", "xyz"]] }) ``` 2022-01-02 [07:31:45.0943] https://stackoverflow.com/questions/70553932/fetch-api-abort-doesnt-works-after-1st-cancel [10:26:02.0682] I’m trying to clone an `SVGRect` object using `structuredClone()`, but am getting _DataCloneError: The object could not be cloned` error_ — because, I guess, the `SVGRect` object isn’t serializable. [10:26:25.0558] But what part of it wouldn’t be serializable? [10:28:39.0384] Specifically, what I have is an SVG `marker` element with a `viewBox` attribute, and I assign that to a `marker` variable, and when I log `console.log(marker.viewBox.baseVal), the browser logs this: ```js [object SVGRect] { height: 10, width: 10, x: 0, y: 0 ``` [10:30:04.0258] …but if I then do this: ```js let foo = self.structuredClone(marker.viewBox.baseVal); ``` …it fails and that browser logs that _DataCloneError: The object could not be cloned_ [10:30:11.0671] * …but if I then do this: ```js let foo = self.structuredClone(marker.viewBox.baseVal); ``` …it fails and that browser logs that _DataCloneError: The object could not be cloned_ error [10:30:22.0717] * …but if I then do this: ```js let foo = self.structuredClone(marker.viewBox.baseVal); ``` …it fails, and the browser logs that _DataCloneError: The object could not be cloned_ error [10:30:34.0791] * …but if I then do this: ```js let foo = structuredClone(marker.viewBox.baseVal); ``` …it fails, and the browser logs that _DataCloneError: The object could not be cloned_ error [10:32:21.0213] * I’m trying to clone an `SVGRect` object using `structuredClone()`, but am getting a *DataCloneError: The object could not be cloned`error* — because, I guess, the`SVGRect` object isn’t serializable. [10:32:43.0697] * I’m trying to clone an `SVGRect` object using `structuredClone()`, but am getting a _DataCloneError: The object could not be cloned_ error — because, I guess, the`SVGRect` object isn’t serializable. [11:59:02.0426] * …but if I then do this: ```js let foo = structuredClone(marker.viewBox.baseVal); ``` …it fails, and the browser logs that *DataCloneError: The object could not be cloned* error [12:46:49.0240] Web APIs are by default not serializable, even with `DOMRect`, which is as close to a plain object as it gets [12:47:29.0258] Maybe it'd be worth it to try and identify such interfaces [12:55:26.0084] I see 2022-01-03 [16:17:11.0133] It is kind of understandable that SVGRect is not serializable though. It is not a plain object; it has an inner connection to a SVG element. And serializing that across realm boundaries is tricky. [16:17:23.0319] DOMRect is very simple though and could be made serializable. [16:17:51.0184] I believe the spec still says SVGRect is simple but this was a misstep in the spec and they need to change it back to match implementations https://github.com/w3c/svgwg/issues/706 [16:17:54.0714] We ran into this in jsdom [16:18:35.0701] TIL [00:12:02.0920] Luca Casonato: I guess it's strictly speaking not defined, yeah [01:26:47.0804] Luca Casonato: given that people notice it we might still want to define it though [01:29:31.0544] I guess we could. The current spec language makes what Deno does the most obvious thing to do I think, as headers in the inner header list are not concatenated. Chrome and FF both concatenate the headers on the wire it seems. I didn’t check Safari or Cloudflare Workers [01:36:51.0738] And annevk, as for who noticed that: the author of node-fetch. Have received no reports from “regular” users who are not intimately familiar with the fetch spec. [01:39:57.0596] Yeah fair [01:40:25.0401] Combining is also tricky for Set-Cookie, though that's tricky anyway atm [03:26:30.0518] Is it possible to request target in `asterisk-form` (`OPTIONS *`) with the fetch (or another) API? Any pointers on history/discussion would be great. [03:33:08.0954] * Is it possible to request target in `asterisk-form` (`OPTIONS *`) with fetch, xhr (or another)? Any pointers on history/discussion would be great. [04:35:46.0278] csarven: it's not possible, don't recall discussion [12:47:46.0417] Would it be inaccurate to describe the WebIDL `readonly` keyword as essentially meaning “not assignable”? [15:24:43.0021] sideshowbarker: It's accurate 2022-01-04 [16:21:21.0605] EveryOS: thanks [16:21:41.0078] You're welcome [16:24:41.0236] looking now at https://github.com/mdn/content/issues/11697 I find that the CSP spec no browsers seem to conform to the CSP spec requirement to block `element.style.cssText = 'display:none'` in the same way they block `element.setAttribute('style', 'display:none;')` [16:25:11.0672] and looking at WPT, I find we have no tests for it https://wpt.fyi/results/content-security-policy/style-src?label=experimental&label=master&aligned [16:27:07.0381] step 4 at https://w3c.github.io/webappsec-csp/#directive-style-src is where the relevant requirement is defined, and it even explicitly mentions: > This would include, for example, all invocations of CSSOM’s various `cssText` setters and `insertRule` methods [16:27:38.0826] * step 4 at https://w3c.github.io/webappsec-csp/#directive-style-src is where the relevant requirement is defined, and it even explicitly mentions, This would include, for example, all invocations of CSSOM’s various cssText setters and insertRule methods [16:28:15.0608] * step 4 at https://w3c.github.io/webappsec-csp/#directive-style-src is where the relevant requirement is defined, and it even explicitly mentions, *This would include, for example, all invocations of CSSOM’s various `cssText` setters and `insertRule` methods* [16:28:27.0456] * step 4 at https://w3c.github.io/webappsec-csp/#directive-style-src is where the relevant requirement is defined, and it even explicitly mentions, This would include, for example, all invocations of CSSOM’s various `cssText` setters and `insertRule` methods [16:28:37.0917] * step 4 at https://w3c.github.io/webappsec-csp/#directive-style-src is where the relevant requirement is defined, and it even explicitly mentions > This would include, for example, all invocations of CSSOM’s various `cssText` setters and `insertRule` methods [16:28:48.0025] * step 4 at https://w3c.github.io/webappsec-csp/#directive-style-src is where the relevant requirement is defined, and it even explicitly mentions: > This would include, for example, all invocations of CSSOM’s various `cssText` setters and `insertRule` methods [16:29:29.0068] * looking now at https://github.com/mdn/content/issues/11697 I find that no browsers seem to conform to the CSP spec requirement to block `element.style.cssText = 'display:none'` in the same way they block `element.setAttribute('style', 'display:none;')` 2022-01-05 [08:40:46.0490] sideshowbarker: there are some existing CSP + CSS issues, not sure if they cover this [08:42:05.0697] Oh right, the spec even links https://github.com/w3c/webappsec-csp/issues/212 [11:06:34.0650] annevk: thanks [12:04:02.0755] I've just learned that `postMessage` is async, such that if you do `worker.postMessage(); while (true) {}` the message will never actually fire. Is there a reason for this? If no, could it be changed, possibly as an opt-in option? This comes up in the context of emscripten. [12:09:29.0250] I don't think that's true per the spec [12:09:30.0043] https://html.spec.whatwg.org/multipage/workers.html#dom-worker-postmessage [12:10:25.0841] The only task or microtask queued in that algorithm is the one that is actually queued on the worker's event loop [12:12:14.0827] But I guess it comes down to the notion of observability, since you can't observe the result of a task in a worker thread if the main thread is stuck in a loop [12:13:34.0204] you can with a SAB [12:13:46.0792] True. Then this is a bug [12:25:56.0599] MDN has it documented: > After postMessage() is called, the MessageEvent will be dispatched only after all pending execution contexts have finished. For example, if postMessage() is invoked in an event handler, that event handler will run to completion, as will any remaining handlers for that same event, before the MessageEvent is dispatched. [12:28:02.0789] I can't actually tell from reading the spec if the "add a task" implies adding it on the current thread or the worker's, but I'll take your word for it. [12:30:32.0783] That task fires the `message` event, and event firing is synchronous, so it must be on the worker's thread [12:47:33.0759] I think this is related to https://github.com/whatwg/html/issues/3691 . Basically, postMessage() infrastructure assumes the target could be cross-process. Although this is not true for dedicated workers it could be for iframes or shared/service workers. The spec as-written doesn't really acknowledge this so it acts as if you can get synchronous access to the target's message queue. But, in general, you cannot; if your process is busy-looping you're gonna have a hard time pushing messages across process boundaries, I believe. [12:48:21.0468] So in theory implementations could maybe special-case dedicatedWorker.postMessage() to make that work even in the presence of busy loops. In practice that'd probably be quite involved as they'd essentially have to create a parallel message-queuing infrastructure for dedicated workers only. [12:54:06.0434] huh, ok, it looks like I was actually wrong (I wrote a test case but it was bugged) and the MDN page is are also wrong [12:54:21.0188] here's my test case (now that I've fixed it) ``` let workerSrc = ` let arr; self.addEventListener('message', e => { switch (e.data.message) { case 'init': { console.log('worker: got init'); arr = new Int32Array(e.data.buf); Atomics.notify(arr, 0); break; } case 'next': { console.log('worker: got next'); arr[1] = 1; break; } } }); `; let blob = new Blob([workerSrc], {type: 'application/javascript'}); let worker = new Worker(URL.createObjectURL(blob)); (async () => { let buf = new SharedArrayBuffer(16); let arr = new Int32Array(buf); worker.postMessage({ message: 'init', buf }); if (typeof Atomics.waitAsync === 'function') { await Atomics.waitAsync(arr, 0, 0).value; } else { // give the worker time to start await new Promise(res => setTimeout(res, 1000)); } console.log('init'); worker.postMessage({ message: 'next' }); console.log('now we busy-wait, with arr[1] initially =', arr[1]); for (let i = 0; i < 1e8; ++i) { if (arr[1] === 1) { console.log('done! took until i =', i); return; } } console.log('never initialized'); })().catch(e => console.error('error', e)); ``` [12:54:47.0964] in chrome and FF this does actually finish; FF seems to take literally no iterations of the loop, where chrome takes a couple hundred [12:54:56.0127] apologies for the confusion [12:57:22.0464] * huh, ok, it looks like I was actually wrong (I wrote a test case but it was bugged) and the MDN page is also wrong [13:38:49.0121] Hi, could someone explain main what is the purpose of this line? https://github.com/html5lib/html5lib-python/blob/master/html5lib/_inputstream.py#L141 [13:59:36.0216] > <@bakkot:matrix.org> huh, ok, it looks like I was actually wrong (I wrote a test case but it was bugged) and the MDN page is also wrong please file an MDN issue for it [14:06:07.0897] per discussion above the MDN page might be right in other cases, despite the spec [14:06:22.0307] but I'll file an issue saying "this is wrong at least some of the time" [14:06:22.0731] OK [15:50:32.0292] oh hey there's even WPT tests for postMessage being sync - https://github.com/web-platform-tests/wpt/pull/23270 2022-01-06 [16:16:46.0479] the actual behavior in Chrome appears to be, you can synchronously send messages _except in an onmessage handler_, which is pretty bizarre [17:04:43.0409] Oh wow nice find. Sad to hear my speculation was so off the mark. [17:14:26.0028] I'm in a bunch of spec-related servers (because I reference the specs a lot, as I'm making an implementation of them) But I always feel out of place in these servers, because the people in them are more focused on actually developing them [17:14:45.0678] And also, these channels seem super-formal [06:45:06.0569] i always wear a tuxedo on matrix [06:45:45.0812] EveryOS: no need to feel out of place, all are welcome [07:33:05.0584] > <@miketayl_r:mozilla.org> i always wear a tuxedo on matrix wait do we not have to? [09:21:15.0350] Yoav Weiss: Domenic: do either of you happen to know what happened to maintenance of https://github.com/w3c/longtasks/issues? [09:22:12.0410] in terms of who owns this spec? [09:22:57.0185] Yoav Weiss: well it seems the Perf WG owns it, but it hasn't been moving along the REC track [09:23:12.0389] Yoav Weiss: and issue addressing went kinda silent a couple years ago [09:23:59.0863] There was a FPWD in 2017 and that's it [09:24:28.0794] From the eng side, it can use a little more attention. I'm hoping to make progress on attribution later this year [09:25:43.0345] On the spec/WG side, it was adopted to the WG with one implementation. The amount of progress in can make on the REC track without a second implementation is limited [09:26:37.0941] Any specific issues you feel need addressing? [09:27:44.0748] Not sure, but I imagine some are not really up for being addressed if Chrome has shipped this for that long [09:28:30.0974] And for some I wonder what ended up being implemented, e.g., elsewhere Perf APIs do account for long URLs, but here the issue is still open [09:30:15.0732] OK, let me take an action item to go over the issues and make sure we make progress on the ones we can make progress on (and close the ones where we can't) [09:31:04.0131] agree that data URI handling should be similar here and elsewhere [09:31:17.0089] s/data URI/long URLs/ [09:53:24.0844] Ta! [09:53:42.0246] EveryOS While we do try to avoid being general-conversation-y in here, we're not formal otherwise. [13:14:37.0984] Weird. The site says I got 18 pings even though I only got 2 [13:14:48.0969] > <@tabatkins:matrix.org> EveryOS While we do try to avoid being general-conversation-y in here, we're not formal otherwise. Ok, I see [13:16:26.0384] * Weird. The site says I got 18 pings even though I only got 2 EDIT: Oh. There were probably 18 messages in total, but the indicator was red because I got pings, which made it look like I had 18 pings. 2022-01-07 [03:56:39.0689] emilio: so :active/:hover use the flat tree, but :has() uses the node tree? Is using the flat tree for selector matching not really expensive? [04:26:39.0976] > <@annevk:mozilla.org> emilio: so :active/:hover use the flat tree, but :has() uses the node tree? Is using the flat tree for selector matching not really expensive? That is right. :has() uses the node tree like all other selector combinators, why would it use the flat tree? [04:26:56.0527] Not that it would be impossible to do but it'd be weird [04:28:31.0240] emilio: yeah never mind, I guess it all makes sense. And :has can't really use the flat tree as that'd break encapsulation, I think. [04:30:59.0627] Right [07:48:47.0837] Thinking of trying to tackle https://github.com/whatwg/dom/issues/849 again, or at least make progress ... is there any easy way to know what element names the HTML parser accepts? Or do I have to walk through various parser states? [07:49:33.0344] I guess looking at https://html.spec.whatwg.org/#tag-open-state + tag name state is not too bad... [08:14:37.0657] can someone who understands how event dispatch is specified comment on https://bugs.webkit.org/show_bug.cgi?id=234730? because I've utterly confused myself now. [08:27:09.0889] Domenic: can element names contain `>` today? That seems problematic [08:27:46.0860] Domenic: I doubt we want to allow CR [08:27:57.0487] \> is excluded from LenientElementNameStartChar and LenientElementNameChar in my sketch [08:28:03.0756] * \> is excluded from LenientElementNameStartChar and LenientElementNameChar in my sketch [08:28:27.0629] I think CR is probably disallowed by the parser but as preprocessing, so I didn't see it when reading. Good catch. [08:28:34.0509] Although what about entities hmm [08:29:56.0557] Entities don't work in tag names, huh [08:30:15.0366] Oh I missed `>` there [08:30:26.0933] Yeah entities only work inside attributes or between tags [08:30:48.0959] (Context is https://github.com/whatwg/dom/issues/849 fwiw.) [08:31:18.0637] The other thing I wonder about is whether we should only add leniency for the HTML namespace [08:32:26.0125] But maybe it doesn't matter so much as you can already create trees that cannot serialize as XML so simplicity ought to win [08:33:10.0967] I cannot find what in the spec disallows the parser from creating elements with CR [08:33:14.0791] But browsers do not allow it http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=9940 [08:34:00.0724] I think https://html.spec.whatwg.org/#tag-name-state is missing CR [08:34:12.0004] CR is handled in the preprocessing stage [08:34:39.0059] > Before the tokenization stage, the input stream must be preprocessed by normalizing newlines. [08:34:40.0846] I couldn't find that Ctrl+Fing for "CARRIAGE RETURN", and lots of parser steps actually look for CR... [08:35:06.0884] OK, so why does CR appear explicitly in places like https://html.spec.whatwg.org/#the-initial-insertion-mode [08:35:56.0596] Domenic: I think that might be due to an entity reference? [08:36:13.0056] Seems plausible [08:37:31.0228] Yeah, it's a conformance error, but it will get through [08:37:32.0459] Yeah because the tokenizer converts them then returns to the state it was in previously [08:37:50.0375] No idea why that was not normalized as well... [08:37:55.0048] OK, updating whatwg/dom thread to exclude CR, and it looks like there are no spec bugs around CR [08:38:35.0068] I guess it wasn't normalized because you can also get there through JS and guarding all entry points would be somewhat pointless overhead [08:39:16.0101] (Not that specific point, but as an attribute value, say.) [08:39:17.0841] Well I think the idea is if you do ` ` in certain places then you actually should end up with a CR in the resulting parsed data [08:39:50.0855] And so e.g. if you do that in early parts of the document then the initial insertion mode state will actually see the CR and ignore it, not normalize it [08:40:50.0668] Right, though then the question is why `�` doesn't work (but JS equivalents do) [08:40:54.0997] https://html.spec.whatwg.org/#parsing-main-incolgroup is a better example where it inserts the CR instead of ignoring it. [08:41:39.0657] Hmmm [08:41:48.0392] Finding logic in the parser might not be the best use of our time 🙂 [08:42:28.0095] Yeah OK good point [08:42:48.0257] For strictly split on : it might be worth clarifying you'd split on the first or concatenate return values 1...N [08:45:07.0601] For Prefix there might still be some edge cases I suspect due to XML 4th/5th edition divide, where browsers didn't uniformly stick with the 4th (not entirely sure if some updated the parser, but not the corresponding DOM methods) [08:47:03.0913] Yeah I wonder about tests, I wonder if we can apply https://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-floatsso-test-them-all/ to this [08:47:31.0105] Probably not :) [08:48:18.0296] For PCENChar I think the banning of noncharacters is a bit dumb and removing that would simplify the production a lot [08:48:35.0510] Yeah I don't have strong feelings there, happy to take a new suggestion. [08:54:00.0208] Oh I see, that came from XML and we'll preserve some of that through NameStartChar. I guess I'd consider simplifying that as well to C0 and above or even A0 and above (like URL code points), but I'm not sure how much we want to go for [08:55:30.0020] On the one hand, it's pretty separable. On the other hand, maybe we should do this all at once, since it's hard to get momentum for these sorts of things. [08:56:20.0358] Oh, or you mean just making LenientNameStartChar even more lenient [08:56:45.0291] Well all of them I suppose. Less range checks ftw [08:57:57.0457] Nobody has ever proven the value of segmenting Unicode in such a way to my knowledge and most things work fine without it [08:58:00.0441] Unpaired surrogates? [08:59:16.0236] Hmm that's a good point, you included them but does that actually work? [09:00:38.0994] Oh wait, URLs do consider noncharacters non-conforming, but they do work. Surrogates cannot work there however. [09:06:29.0048] I think they work http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=9941 [09:06:40.0472] Domenic: as for testing, given Unicode is 2^21 if I'm not mistaken that might actually be feasible? Element-creation is a bit more expensive than floats though I suppose 🙂 [09:06:56.0574] Yeah that's my worry. [09:07:26.0151] IIRC we already have a cloneNode test that can cause timeouts just when creating + cloning one instance of every existing/historical HTML tag name [09:07:43.0997] C++ unit tests in browsers could probably be exhaustive though [09:09:56.0650] We could have a manual test for us to verify things on the side and for when computers get fast [09:10:07.0698] It does seem that surrogates are fair game, hurray [09:15:08.0441] I guess the question is whether we want to make it *easier* to create non-serializable DOMs via DOM APIs. I think that's slightly bad? So maybe sticking with the union of current DOM API values + HTML parser values would be better than just allowing the DOM APIs to be maximally free. [09:28:45.0900] Domenic: that would somewhat argue for branching on the HTML/SVG/MathML namespaces which is a bit odd [09:29:16.0884] But I guess it still works if the approach is minimal set of steps starting from the status quo, or some such [09:29:19.0090] Well, within reason, I guess :) [09:29:41.0817] I'll add a comment with your approach [09:30:50.0245] Thanks, I guess I mainly want to hear from someone that these range checks are negligible, since otherwise we might as well improve that while we're there [09:35:08.0505] In your version what is the justification for excluding tab, LF, CR, FF, space, /, >, and NULL? If we are no longer concerned about serializability seems like they could be allowed... [09:42:08.0220] Domenic: I think it would all still work in the HTML parser when serialized? It's mainly XML that's affected for worse [09:42:22.0832] Oh right [09:42:35.0020] Not sure what I was thinking [09:42:44.0173] OK I am more in favor of your proposal now [09:50:21.0437] OK no I see what I was saying. Consider the following element local name: "$a". This is currently disallowed by createElement(). And the parser cannot parse it. But if we allow a larger set for createElement(), then the resulting serialization is something the parser cannot parse. [09:51:11.0145] Like ideally createElement() would only accept ASCII alpha for the first character; that would guarantee it only ever creates elements which serialize in a parseable way. But we already accept, for whatever reason, NameStartChar. The conclusion then is we should probably not expand beyond NameStartChar. [10:54:32.0507] Domenic: Hi! I'm curious about how the anchoring works, and how/if it affects the containing block of the element? are designed to be in the top layer which forces the containing block to the viewport, so it's a question i'm wondering. [10:54:54.0092] ntim: I don't know much about ; mfreed is the person to ask there. [10:55:52.0635] /me hopes it's not yet another special positioning algorithm that isn't CSS describable [11:04:15.0303] As far as I know, anchoring of popups is still under discussion. This has some history, and there’s a current proposal linked at the end: https://github.com/w3ctag/design-reviews/issues/599 2022-01-08 [14:09:16.0081] Do browsers really not support floats in `sx` and `sy` values for canvas `drawImage`? https://github.com/mdn/content/pull/11825 [14:10:00.0551] https://html.spec.whatwg.org/multipage/canvas.html#2dcontext:dom-context-2d-drawimage-3 says they’re doubles [15:21:02.0889] Maybe by "all browsers" that person means "all browsers on iOS" [15:57:41.0061] > <@domenicdenicola:matrix.org> Maybe by "all browsers" that person means "all browsers on iOS" Ah yeah that seems more likely 2022-01-09 [04:04:48.0850] Domenic: I guess either that or indeed lift all restrictions as it doesn't matter much (though for custom elements we probably want to continue to have parser-compatible requirements) 2022-01-10 [08:06:51.0739] mek: heya, back from the holidays yet? 2022-01-11 [01:54:49.0794] The CSS specs are down again [08:14:01.0409] Mattias Buelens: are the tests in https://github.com/web-platform-tests/wpt/pull/32072 ready for review? Did you check coverage of the new lines perchance? [08:45:37.0831] The new tests can already be reviewed, but we're probably going to need a couple more tests. I haven't checked the coverage yet, I'll do that. [11:10:59.0386] Domenic: Your link to your tweet in the csswg issue just links to the timeline ^_^ [11:19:28.0167] > <@tabatkins:matrix.org> Domenic: Your link to your tweet in the csswg issue just links to the timeline ^_^ Doh! 2022-01-12 [04:29:11.0190] Does there exist something like [this](https://htmlparser.info) for css? [04:59:48.0858] I don't think so, but CSS was much more designed so if you go over the CSS grammar iterations you can find out a lot [05:00:20.0981] Probably the biggest change came in 2.1 with it getting defined error handling (iirc) [05:09:09.0805] okay thankyou! 2022-01-13 [16:25:53.0869] In principle basically every case should've been defined in CSS1 (but probably wasn't): https://www.w3.org/TR/REC-CSS1/#forward-compatible-parsing [08:46:35.0183] emilio: I'd appreciate if you could review https://github.com/whatwg/html/pull/7361 as well, it looks fine editorially, but I'm not a 100% comfortable with the focus algorithms [08:47:11.0976] annevk: will try to get to it today, thanks (and btw sorry but I can't make it to the new triage meeting time today, conflict :/) [08:49:21.0594] Understandable, it's not ideal for Europe to begin with 🙂 [10:42:33.0191] i'm not good at bay area geography, is europe north bay or south bay? [11:02:24.0427] all of europe is north sea [11:06:30.0227] tho another answer is that the north/south bay divide is probably right around 37°37′, which means all but the southernmost tips of spain, italy, and greece are north bay [11:07:02.0899] turkey actually has some non-trivial south bay population [11:12:48.0213] miketayl_r: Sausalito? Kinda [11:13:52.0615] Also where does that leave Boston? [12:36:40.0577] just past Berkeley, i think [13:19:08.0532] @domenic I believe we should also file spec bugs with Firefox and Safari for the changes to *default readers* in https://github.com/whatwg/streams/pull/1168 ? That PR affects *both* default and BYOB readers. [13:20:02.0642] > <@mattiasbuelens:matrix.org> @domenic I believe we should also file spec bugs with Firefox and Safari for the changes to *default readers* in https://github.com/whatwg/streams/pull/1168 ? That PR affects *both* default and BYOB readers. Oh shoot, I somehow missed that obvious fact. Honestly we shouldn't have merged without getting their buy-in. My bad. Please let's file the bugs and if they have objections we can roll back. [13:20:43.0016] All right 🙂 [13:27:21.0884] Would it be a huge deal of extra work for you all to also open implementation issues on Deno and Node repos for spec changes in whatwg/streams? Just a simple "heads up: this thing is changing" with a link to the PR, or a "cc @lucacasonato @jasnell" on relevant PRs would be very awesome :-) [13:28:06.0298] > <@lucacasonato:matrix.org> Would it be a huge deal of extra work for you all to also open implementation issues on Deno and Node repos for spec changes in whatwg/streams? Just a simple "heads up: this thing is changing" with a link to the PR, or a "cc @lucacasonato @jasnell" on relevant PRs would be very awesome :-) Good call, I'll open bugs with them too. :) [13:28:20.0111] Thank you :-) [13:29:23.0961] Would be nice to make this part of our process some day, see https://github.com/whatwg/streams/issues/1141 [13:30:15.0003] Ah cool - if I ever have some free time (hahahaha), I can give this a shot. [13:33:07.0641] I'm already familiar with the spec-factory infrastructure, it shouldn't take me too long [13:44:07.0674] too late, i already did it [13:44:39.0460] apparently i can "free" time for useful things :D [13:50:29.0727] https://github.com/whatwg/spec-factory/pull/35 <- here we go [13:56:18.0744] Looks good! For completeness, maybe we can also update https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests with links on where to file Node and Deno issues? 🙂 [13:56:43.0452] Already opened a PR 5 minutes ago :-) https://github.com/whatwg/meta/pull/238 [13:56:50.0954] I'm too slow :P [14:27:56.0864] Question about streams specification; I was looking at an older [chrome security bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1045874). Some cursory testing suggests that in addition to the chrome change, it has been fixed at the specification level. Nevertheless, I'm wondering: For lists being iterated where calling into user-defined code, does it make sense to change the specification to adopt a similar policy to the chrome change (move the list into a local, iterate the local instead). Defensively I think it makes sense for our implementation, but I'm not sure how this is looked at from a specification perspective. [14:33:56.0719] Well, exactly that was just landed in https://github.com/whatwg/streams/pull/1168. 😛 We now move the list into a local variable first before we iterate it. This turned out to be necessary for the correctness of the async iterator steps ([see comment](https://github.com/whatwg/streams/pull/1168#discussion_r778476614)). [14:35:31.0169] (Github has those links broken, but I found the conversation). Nice! Looks like I'm ahead of the game for once 2022-01-14 [16:48:17.0693] has anyone ever suggested the ability to control undo/redo? i didn't see anything on the gh [16:49:10.0823] the use case i have in mind is like, say you're switching between tabs of some ui that contain inputs. when you switch tabs, those inputs get removed and added and whatnot, so they lose their history [17:05:11.0379] devsnek: https://rniwa.github.io/undo-api/ [17:05:46.0032] oo [17:07:20.0442] Ryosuke Niwa put a lot of work into it some years back, but I think it ran into the same kinds of underlying problems that all the editing-related APIs have 2022-01-15 [20:25:38.0507] `navigator.userAgentData` doesn’t work in my Chrome Canary v99, despite https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData claiming Chrome has supported it since v90 2022-01-17 [20:28:01.0383] oops didn't mean to leave [23:57:56.0477] zcorpan: had you seen https://bugzilla.mozilla.org/show_bug.cgi?id=1687557? [01:03:15.0541] annevk: Hey, I was just going through my old needinfos and noticed https://bugzilla.mozilla.org/show_bug.cgi?id=1708354 [01:04:02.0243] And that bug itself aside, it feels to me like Chrome and Firefox both shipped this restriction but didn't end up updating the spec (I can't even find an issue for it) [01:06:32.0535] But I'm slightly confused about which spec is responsible for defining these restrictions, is it the Notifications spec or Permissions? [01:07:08.0350] i.e. would it be enough that Notifications says "this is a powerful feature" and then we derive somehow that these are either PP controlled in iframes or forbidden? [01:45:57.0823] johannhof: I think the idea was that Permissions Policy would take care of this, but it might not have been integrated everywhere just yet [01:49:12.0581] annevk: Right, so, I guess there are two things here. As per that bug, these checks should not only apply when requesting permission but also when notifications are sent. The second question is what does PP do for features that are powerful but not explicitly part of PP (which I think notifications is not?) [01:50:33.0578] Oh right, I guess those we have to update, but that hasn't happened. Same for persistent storage. [01:51:02.0101] I guess point 1 might be captured by having the permission check in the constructor https://notifications.spec.whatwg.org/#constructors, so that might only be a Firefox implementation issue [01:52:57.0366] And then step 3 of https://w3c.github.io/permissions/#reading-current-states will only do the correct thing (deny the request) if there's a policy controlled feature for "notifications" that's always forbidden [01:55:03.0551] What is the state of the registry for permissions policy? Is it still up to the individual standards to define their own entry? So would this be a change in Notifications and Storage? [02:29:47.0243] johannhof: for notifications it probably needs to be a local change; for persistent storage I'm not entirely sure what the model should be [02:30:31.0764] It makes sense to me that you cannot ask for persistent storage permission, but if you're non-partitioned (i.e., have "storage access") you should probably have persistent storage there [02:30:56.0498] The equivalent doesn't make sense for notifications however [02:31:28.0802] Although I guess for storage as well it being non-partitioned is a thing that will soonish no longer be possible [02:48:32.0157] Yeah, you're right, storage is more complicated... [02:49:01.0523] Another edge case that always partitioning helps with :) [03:19:50.0589] annevk: thought about this some more and filed https://github.com/whatwg/notifications/issues/177 [04:42:14.0137] Hello, who have I reached? [06:02:05.0961] Hi! This is the WHATWG, see https://whatwg.org/faq#what-is-the-whatwg 2022-01-18 [00:18:51.0852] Hi annevk! I rebased me HTML/FETCH/RT integration from before the holidays and have a few PRs pending if you can add them to your queue. [00:22:22.0658] annevk: hey, quick question about test changes for my Exposed PRs. Would you like me to prepare wpt PRs with the IDL changes ported over manually, or could I wait until the bot lands them and add the code to test against ShadowRealms afterwards? [00:52:08.0505] foolip: thoughts on Ms2ger 💉💉's question? I guess it's fine either way? [00:52:54.0707] Ms2ger 💉💉 annevk I think it's fine to just wait for them to come via an @webref/idl update. [00:53:28.0352] Ms2ger 💉💉: thanks for merging https://github.com/web-platform-tests/wpt/pull/31873! [00:54:02.0682] Ms2ger 💉💉: oh, it broke some of the tests though: https://wpt.fyi/results/geolocation-API/idlharness.https.window.html?diff&filter=ADC&run_id=5741853509943296&run_id=5635100688515072 [00:54:18.0910] Huh, I thought I checked, sorry [00:54:29.0081] Ms2ger 💉💉: for these PRs one needs to look at the wpt.fyi checks if there are gray boxes [00:54:43.0282] Will fix in a sec [00:55:07.0589] The checks don't fail because it's not disallowed to introduce failing tests, after all. But it results in a confusing situation. [00:57:54.0868] https://github.com/web-platform-tests/wpt/pull/32425 [01:00:34.0834] https://github.com/web-platform-tests/wpt/pull/32426 [01:57:43.0025] Who wants less noise in new PRs? https://github.com/web-platform-tests/wpt/pull/32427 [02:21:39.0723] It's funny that we added Dependabot for code that hasn't been touched since 2013 :) https://github.com/web-platform-tests/wpt/pull/32428 [02:32:12.0933] Hey, it looks like the HTML spec lists the `contextmenu` event in the list of events, but that event is not fired from anywhere in the spec [02:32:56.0319] It seems like before https://github.com/whatwg/html/pull/2742 there was spec text defining when to fire it, but I'm not sure if removing it was a bug, or if that text actually moved to some other spec [02:34:42.0674] All browsers fire the event on right-click, so the discussion about planned browser support arguments clearly only applies to the `` element [02:34:55.0681] * All browsers fire the event on right-click, so the discussion about planned browser support arguments clearly only applies to the `` element, not to the `contextmenu` event [02:42:01.0945] Yeah, agreed. That should probably be restored or moved to UI Events. [02:42:43.0685] Also, while looking into this I noticed that the dfn panels in commit snapshots of the HTML spec reflect the latest commit, not the commit snapshot [02:43:01.0068] it's looking for `/xrefs.json` [02:44:23.0545] huh, the commit snapshots don't actually have a xrefs.json file 😥 [07:59:01.0345] > <@sideshowbarker:mozilla.org> `navigator.userAgentData` doesn’t work in my Chrome Canary v99, despite https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData claiming Chrome has supported it since v90 Were you in a secure context? [09:29:02.0381] annevk: want to do an editorial pass on https://github.com/whatwg/html/pull/7361 or happy with emilio's review? [09:48:19.0701] annevk Could take a look at https://github.com/whatwg/spec-factory/pull/35 some time this week? [10:36:43.0885] I don't understand this algorithm: https://html.spec.whatwg.org/#rendered-text-fragment Steps 3.2 and 3.3 append to /fragment/ but what is that /fragment/ ? [10:37:21.0642] Is it missing some step where DocumentFragment should be created? Or perhaps I just didn't notice it. [10:38:16.0841] https://dom.spec.whatwg.org/#converting-nodes-into-a-node is a bit similar, but it has explicit DocumentFragment creation [10:48:12.0867] That's an algo bug, yeah. That variable is never initialized. [12:04:47.0131] Would https://github.com/whatwg/html/issues/7505 be editorial? [12:25:55.0217] > <@domenicdenicola:matrix.org> Were you in a secure context? Yes — just checking from the console while navigated to, e.g., this page [12:43:09.0389] Domenic: Come to think of it, I should've kept the ID of the dfn [12:43:18.0610] Should I open a new PR? [12:54:30.0568] Andreu Botella (he/they): IMO it's OK to lose it, unless someone complains or we know of prominent instances linking to it. [12:55:18.0010] https://developer.mozilla.org/en-US/docs/Web/API/Element/contextmenu_event links to it, but I'm about to open a PR to change it 2022-01-19 [16:26:03.0164] > <@annevk:mozilla.org> zcorpan: had you seen https://bugzilla.mozilla.org/show_bug.cgi?id=1687557? I had not, thanks [20:52:48.0678] When did github add visual image diffs for PRs? [20:52:59.0100] https://github.com/mdn/content/pull/12158/files [20:53:30.0240] can’t recall ever before seeing it show those [20:56:48.0717] oh wow, it even has an interactive “onion skin” control to examine the differences [20:58:14.0195] …and apparently it’s been there for 10 years… https://github.blog/2011-03-21-behold-image-view-modes/ I have no idea why I didn’t notice this before now [01:20:49.0306] Mozilla folks: This feature will land in Chrome soon, and is already supported in Safari. I think most of the implementation is already in Skia, so this might be a 'good first issue' for someone https://bugzilla.mozilla.org/show_bug.cgi?id=1746248 [05:43:23.0031] > <@jakea:matrix.org> Mozilla folks: This feature will land in Chrome soon, and is already supported in Safari. I think most of the implementation is already in Skia, so this might be a 'good first issue' for someone https://bugzilla.mozilla.org/show_bug.cgi?id=1746248 We don't use skia for non-canvas stuff, fwiw (though it probably isn't a lot of work to add it to webrender) [05:43:36.0621] ohh, TIL [10:14:57.0082] I'm not super clear (from https://participate.whatwg.org/ or from reading old github issue threads) what level of engagement requires completing an organizational Participant Agreement [10:15:24.0405] is it: opening an issue? proposing text? opening a PR? making suggestions in chat or a github issue? [10:18:44.0205] npd: only normative spec changes [10:19:35.0168] if I make a text suggestion in a github thread, and then one of the editors adopts it as a normative spec change, does that require confirming the participant agreement is completed? [10:20:07.0429] I am not sure - probably depends on the specific circumstances. 2022-01-20 [02:42:34.0502] Hmm, didn't webidl spec used to have the useful table of contents one the left side? [02:43:15.0966] That was before it was moved to the WHATWG and started using the WHATWG bikeshed template/stylesheet [02:43:36.0085] though I think TabAtkins might be working on fixing that [02:43:44.0248] Aha [02:44:05.0728] Especially with Webidl, which is full of small definitions, it is particularly useful [02:44:12.0389] but it is actually useful with most of the specs [02:45:09.0893] indeed [02:45:18.0534] Right now webidl spec has tons of whitespace on left and right, at least on a common 16:9 display [07:01:09.0187] Yeah it's on my short list [08:39:24.0208] People who asked for my input: I might be able to get to it tomorrow, failing that early next week. [09:41:00.0938] Where is the best place to submit a proposal for the HTML spec? [09:42:12.0101] If it's a bug fix or a relatively small feature, the issues in the HTML spec repo. For something more significant, WICG, or Open UI for form controls [09:47:36.0298] is that openui.org? [09:55:06.0378] https://open-ui.org/ [13:07:18.0839] usage question: a poem in a book that is a collection of poems. the poem, the book, or both (in one or two s)? not obvious from any of the examples. 2022-01-21 [23:59:16.0222] aja: name of the poem and the book going from the description of the element [00:06:02.0858] Yoav Weiss: Ari Chivukula about https://github.com/WICG/savedata/pull/3 I can’t find any Chromium bug for changing the name. Nobody’s written a patch for it yet, I guess? [05:14:19.0629] Luca Casonato: I'll land the spec-factory change on Monday + create the PRs for affected specs [05:16:00.0632] > <@annevk:mozilla.org> Luca Casonato: I'll land the spec-factory change on Monday + create the PRs for affected specs Thanks 🙏 [09:11:37.0965] > <@sideshowbarker:mozilla.org> Yoav Weiss: Ari Chivukula about https://github.com/WICG/savedata/pull/3 I can’t find any Chromium bug for changing the name. Nobody’s written a patch for it yet, I guess? That's correct, it's on the roadmap [09:49:03.0024] > <@annevk:mozilla.org> aja: name of the poem and the book going from the description of the element thanks, makes sense to me. have to play some styling games to match italic/quotation marks wanted in various style guides, but that's easy enough. [09:55:01.0254] I want some credit for resisting the urge to dump a redesigned element proposal into https://github.com/whatwg/html/issues/6578 ... it's very tempting, but I know incremental progress is way more likely to happen here than a redesign and me doing that would only derail the discussion. [10:46:51.0002] I think openui has that covered anyway ^_^ [12:10:04.0254] /me wonders when dictionary definition of glacial "Extremely slow, like the movement of a glacier" will be updated. 2022-01-24 [00:31:12.0838] "of a glacier (hist.)" [02:02:17.0159] looking at https://github.com/mdn/content/issues/12370 [02:02:37.0821] calling `backgroundFetch.fetch()` for a `chrome-extension` URL throws with: > TypeError: Failed to execute 'fetch' on 'BackgroundFetchManager': Refused to fetch 'chrome-extension://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/stream' because only the https: scheme is allowed, or http: for loopback IPs. [02:02:51.0229] …but where, in which spec, is that requirement defined? [02:03:02.0619] it seems like it’s probably because it requires a secure context, but I don’t see anywhere in https://wicg.github.io/background-fetch/ that actually states it needs to be a secure context [02:03:30.0289] and I don’t see the `SecureContext` WebIDL attribute anywhere [02:18:57.0191] I don't know about whether `BackgroundFetch` adds further requirements, but regular fetch only supports a few schemes: https://fetch.spec.whatwg.org/#scheme-fetch [03:20:55.0399] Luca Casonato: I assume https://github.com/whatwg/spec-factory/pull/35#issuecomment-1019990419 looks okay? [03:26:37.0768] > <@andreubotella:mozilla.org> I don't know about whether `BackgroundFetch` adds further requirements, but regular fetch only supports a few schemes: https://fetch.spec.whatwg.org/#scheme-fetch True but regular fetch at least does support http schemes [03:28:04.0872] …but that `because only the https: scheme is allowed, or http: for loopback IPs` message seems to make clear that `BackgroundFetch` is even disallowing http — so it’s enforcing some requirement beyond regular fetch [03:28:48.0550] the problem is that the Background Fetch spec itself doesn’t seem to state any such requirement [03:29:27.0893] I guess it’s possible that Chrome is imposing some additional requirement beyond what’s in the spec [03:49:34.0485] sideshowbarker: did you try data: URLs? If that doesn't work it is, but otherwise it would follow from Mixed Content [03:50:01.0285] haven’t tried that yet but will [03:53:44.0565] but now I wonder, does Mixed Content say anything about fetches for unknown URL schemes from secure contexts? [03:54:25.0486] I mean, I don’t expect it says anything about the `chrome-extension` scheme specifically, but maybe something more general [03:54:39.0199] I guess I should just look myself and see [03:56:58.0163] hmm I guess it comes down to `chrome-extension` not being explicitly defined as “potentially trustworthy” https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-origin [05:31:03.0658] sideshowbarker: well Fetch only allows https://fetch.spec.whatwg.org/#fetch-scheme [05:33:02.0022] yeah but if that’s the restriction the browser were enforcing in this case, it seems like the browser would be logging an error message which says that, rather than the different error message it is actually logging in this case [05:33:22.0968] * yeah but if that’s the restriction the browser were enforcing in this case, it seems like the browser would be logging an error message which says that, rather than the different error message it is actually logging in this case [05:34:23.0595] > <@annevk:mozilla.org> Luca Casonato: I assume https://github.com/whatwg/spec-factory/pull/35#issuecomment-1019990419 looks okay? LGTM! [05:34:43.0764] Thanks for getting this landed :-) [06:26:47.0361] Ms2ger 💉💉: maybe file a bug against Deno/Node.js for Exposed=* changes too? https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests [06:27:07.0749] Oh, that's new, is it? Will do [06:27:46.0021] For Deno, link to https://github.com/denoland/deno/issues/13239, since it's gonna take a while to sort that out [06:28:52.0713] Thanks! (And yeah, today-ish new.) [06:28:52.0733] (cue Ms2ger 💉💉 insisting on me switching to the compilers team at Igalia 🤣) [06:29:00.0104] :) [09:24:14.0123] 👋 Trying to reason a bit about the expectation around globals and WebIDL interfaces. I've [been looking at some of the JS engine tests we wrote for or streams](https://bugzilla.mozilla.org/show_bug.cgi?id=1750634#c1). One of which tries to assert that if you invoke another global's ReadableStream.prototype.getReader with a stream in your current realm, you get a reader back that is in the *other global*, not your current one (tested using `instanceof`) Right now, Safari and Chrome disagree: Safari has the reader in a different global, Chrome has it in the current global. Firefox disagrees with itself depending on which streams implementation I test: JS-implemented streams agrees with Safari, DOM+WebIDL implemented streams agrees with Chrome. [09:25:57.0857] So, in this exact case, the question is one of: Which realm is implied by [Step 1 of AcquireReadableStreamDefaultReader](https://streams.spec.whatwg.org/#acquire-readable-stream-reader), "let reader be a new ReadableStreamDefaultReader" ? [new](https://webidl.spec.whatwg.org/#new) links to the WebIDL spec which asks a specification to specify a realm... [09:38:13.0639] Hey All! Hope this is the appropriate place to ask questions like this. I am reading through the HTML specifications and I was wondering whether a FAQ page would be considered a valid use case for the details and summary elements? For example https://codepen.io/schalkneethling/pen/524ed00bc39a135f0d76de3c1519eaeb?editors=1100 - Thank you in advance. [09:52:25.0722] > <@mgaudet:mozilla.org> So, in this exact case, the question is one of: Which realm is implied by [Step 1 of AcquireReadableStreamDefaultReader](https://streams.spec.whatwg.org/#acquire-readable-stream-reader), "let reader be a new ReadableStreamDefaultReader" ? [new](https://webidl.spec.whatwg.org/#new) links to the WebIDL spec which asks a specification to specify a realm... This is not well-specified in the spec, I agree. The intention is generally, per https://github.com/heycam/webidl/issues/135 , that in `ReadableStream.prototype.getReader.call(x)`, it comes from `x`'s global. [09:59:19.0558] Ok. That works for me. Is this the kind of thing that I should (maybe eventually no promises) submit WPT tests for, or better to let things lie (given Safari currently does it by realm) [09:59:43.0893] WPTs would be super-lovely if possible. I will try to work on the spec side soon-ish. [10:00:29.0280] > <@schalk_neethling:matrix.org> Hey All! Hope this is the appropriate place to ask questions like this. I am reading through the HTML specifications and I was wondering whether a FAQ page would be considered a valid use case for the details and summary elements? For example https://codepen.io/schalkneethling/pen/524ed00bc39a135f0d76de3c1519eaeb?editors=1100 - Thank you in advance. I guess another use case is for a tools sidebar. Something like https://codepen.io/schalkneethling/pen/09dbffb3dde2d48a0dd76667790648bc [10:24:55.0603] Schalk Neethling: It's fine semantically, but practically I think it's only really usable in current Chrome, which now has the ability for find-in-page, url hashes, etc to automatically open `details` when appropriate. When other browsers support that as well, it'll be more broadly usable. [10:27:04.0068] > <@tabatkins:matrix.org> Schalk Neethling: It's fine semantically, but practically I think it's only really usable in current Chrome, which now has the ability for find-in-page, url hashes, etc to automatically open `details` when appropriate. When other browsers support that as well, it'll be more broadly usable. Thanks TabAtkins , can you point me to some reading material around this? Would be much appreciated. [10:27:37.0718] I have also heard that the `dialog` element is not accessible ☹️ Is this true? [10:31:06.0056] https://twitter.com/JosephArhar/status/1479525286211248128 2022-01-25 [23:49:25.0989] Dominic Farolino: https://github.com/whatwg/console/pull/210 [02:50:36.0820] annevk: PTAL https://github.com/web-platform-tests/wpt/pull/32446 https://github.com/web-platform-tests/wpt/pull/32447 [07:41:24.0855] Sec-CH-UA-WoW64 World of Warcraft? [07:48:31.0716] hmm, but what does that make WoW on WoW64? [07:51:51.0597] WoWoW [08:26:29.0521] WOW64 is WOW Ultra-Classic, originally played on a PDP-1 [08:27:45.0438] > The PDP-1 is the first computer in Digital Equipment Corporation's PDP series and was first produced in 1959. [08:33:15.0857] 18-bit word size, wow [09:18:18.0803] Kinda sad how we thought UA client hints would be a beautiful modern API and we keep just adding stuff onto it that make it stranger. (E.g. Sec-CH-UA-WoW64 separate from arch or bitness; Sec-CH-UA-Full-Version already being deprecated and replaced with the strangely-named Sec-CH-UA-Full-Version-List) [09:29:32.0595] I'm still not sold on the general idea of client hints; https://github.com/WICG/ua-client-hints/issues/155 [11:40:53.0831] Domenic: yeah, hard to make everything beautiful and perfect on the first go [11:42:06.0919] Domenic: would you have named full-version-list something different? [11:42:21.0378] (it's a mouthful for sure) [11:43:20.0170] miketayl_r: Probably Full-Version. None of the others include their type in the header name. (E.g. it's not Sec-CH-UA-Mobile-Boolean or Sec-CH-UA-List.) But of course Full-Version is taken, because it launched for a few milestones... [11:43:51.0722] changing the type of the already existing full-version seemed risky [11:44:05.0031] but yeah, i had considered it [11:44:51.0366] Yep. No good solutions. Just kinda sad that what was supposed to be greenfield quickly turned into a similar brownfield as the existing User-Agent header. [11:45:37.0213] maybe in 5 or 10 years we will have removed the warts ^__^ [11:45:54.0905] But this is basically just the usual sadness that theoretical purity gets pushed to the bottom of the list ^_^ [11:46:24.0787] we can ship UA-CH2 in our hearts 2022-01-26 [09:03:36.0661] Domenic: maybe an initial goal should be to just get a decent overview of document state APIs may depend on: bfcache/fully active/prerender/focused/visible? [09:04:40.0869] And yeah, delay makes sense to me given that the event loop runs. [09:12:15.0430] annevk: yeah I like that goal. Especially now that we have things like system focus more well-defined. [09:12:30.0632] User activation is another one we found, e.g. a lot of APIs needed no changes for prerendering since they were dependent on user activation which can never happen while prerendered. [09:14:18.0869] Domenic: hmm, I guess that depends on how user activation delegation works, does that do some kind of same TLBC check? [09:14:47.0524] Well we made prerendering BCs top-level BCs so I think it wouldn't impact it? [09:14:49.0062] Oh, and even with that it might go wrong? If the same TLBC is used for the prerendered doc? Or maybe that doesn't work. How does that work? 🙂 [09:15:12.0456] They get an entirely separate TLBC [09:15:41.0298] Domenic: so if you prerender a same-origin doc and then navigate to it, you break opener relationships? [09:16:37.0458] Anyway, it would still require user activation delegation to do a TLBC check but I guess it already has to. You don't want it to travel to some other tab. [09:16:38.0558] Yeah I think that's the current plan, like a COOP switch [09:17:00.0029] Let me double-check... 2022-01-27 [03:23:48.0076] Hey. Just making sure, there isn't any API (implemented, in the works, or anything) to access the browser's spellchecker and detect misspellings in an input field and get dictionary suggestions, right? [03:47:02.0263] Not that I know of [03:54:14.0308] I'm looking through a patch in Bloomberg's fork of Chromium that exposes a number of internal details when a context menu opens, and they're probably incorporating the dictionary suggestions into their custom context menu [03:56:42.0969] something like that might be very useful to editing tools [06:48:08.0150] Unfortunately it's a major entropy leak; we decided we aren't allowed to expose similar in css [06:52:52.0519] My thoughts were that it surely would not leak anything more than the union of user agent and locale, but I hadn't taken into account that the user's name and address might be added to the dictionary [09:18:14.0702] Does CSS not highlight misspellings? That also gives some information, but you'd have to brute force it. [09:27:41.0462] > UAs that implement ::spelling-error and ::grammar-error must prevent pages from being able to read the styling of such highlighted segments. [09:27:49.0214] https://drafts.csswg.org/css-pseudo-4/#highlight-security [09:55:42.0848] Hmm, security requirements in the security section rather than in getComputedStyle etc. Hopefully that works out... [12:14:09.0270] > <@domenicdenicola:matrix.org> Let me double-check... annevk: confirmed, the plan is to do a BCG switch. I will comment more in https://github.com/whatwg/html/issues/6356 which seems very related. [12:43:00.0159] TabAtkins: The image labels in the sidebar in https://drafts.csswg.org/css-writing-modes-4/#text-flow aren't very legible in dark mode 2022-01-28 [16:22:08.0413] Andreu Botella (he/they): Ugh, indeed, the sidebar's background color is manually specified with the assumption of light mode. I'll fix. [17:43:48.0384] FYI https://github.com/WICG/proposals/issues/46 [06:12:57.0151] Jake Archibald: have you ever seen service workers create JSON responses? Trying to figure out browser interest for https://github.com/whatwg/fetch/issues/1389 [06:32:17.0380] annevk: I am I correct in thinking that according to the mime spec, the following mime types should parse like this? - `text/html;in]valid=asd` -> `text/html` - `text/html;in]valid=asd;foo=bar` -> `text/html;foo=bar` [06:32:50.0727] All browser engines just accept this invalid name as valid. [06:34:58.0309] Which brings me to this highly depressing page: https://wpt.fyi/results/mimesniff/mime-types?label=experimental&label=master&product=chrome&product=firefox&product=safari&aligned&q=mimesniff. Not even half of the tests pass in any browser [07:54:54.0324] I think that's mostly due to Blob/Request/Response not having been updated accordingly [07:56:23.0510] Luca Casonato: and yeah, not all invalid MIME types yield failure, same as with HTML and URLs [07:57:08.0832] At least in the web platform "does it parse?" and "is it valid?" can have different answers [09:37:53.0648] > <@annevk:mozilla.org> I think that's mostly due to Blob/Request/Response not having been updated accordingly Ah ok, that makes sense. [11:20:48.0041] > <@lucacasonato:matrix.org> annevk: I am I correct in thinking that according to the mime spec, the following mime types should parse like this? > - `text/html;in]valid=asd` -> `text/html` > - `text/html;in]valid=asd;foo=bar` -> `text/html;foo=bar` You can test current spec using https://npm.runkit.com/whatwg-mimetype . Maybe we should make a live-mime-viewer page... [14:42:35.0829] > <@domenicdenicola:matrix.org> You can test current spec using https://npm.runkit.com/whatwg-mimetype . Maybe we should make a live-mime-viewer page... Thanks, that's pretty much what I did ultimately. Ran the following in my Deno repl: ```js import MIMEType from "https://esm.sh/whatwg-mimetype"; console.log(new MIMEType("text/html;a]=bar;b[=bar;c=bar").toString()); // text/html;c=bar console.log(new MIMEType('text/html;valid=";";foo=bar').toString()); // text/html;valid=";";foo=bar console.log(new MIMEType('text/html;in]valid=";";foo=bar').toString()); // text/html;foo=bar ``` 2022-01-31 [18:15:32.0230] If I have an element `
`, and set someattr to an empty string, is the tag said to "have" the someattr attribute? [18:17:51.0096] Never mind, I quickly wrote a dummy page on Chrome to test I probably should have thought to do that before asking [06:39:24.0969] hsivonen: ping https://github.com/whatwg/html/pull/7430 [13:34:50.0393] does anyone know something like platform.js but also maintained and supports ua client hints stuff?