| 07:20 | <MikeSmith> | JakeA: was there an issue or PR associated with the “Reject on cache add/addAll/put if the response has Vary: *” https://github.com/w3c/ServiceWorker/commit/8c3dbf1 |
| 07:21 | <MikeSmith> | nm I found https://github.com/w3c/ServiceWorker/issues/656 |
| 08:43 | <annevk> | mkwst_sheriff: why samesite cookies? I thought you wanted "site" reserved for registrable domain type stuff? |
| 08:49 | <annevk> | jyasskin: MikeSmith: I filed https://github.com/whatwg/infra/issues/158 to keep track of this |
| 08:55 | <mkwst_sheriff> | annevk: They key on registrable domain. |
| 08:56 | <mkwst_sheriff> | `accounts.google.com` => `docs.google.com` |
| 08:56 | <mkwst_sheriff> | Because cookies are nuts. *shrug* |
| 09:02 | <annevk> | mkwst_sheriff: wait so how are they different from normal cookies? |
| 09:03 | <annevk> | mkwst_sheriff: ooh I see |
| 09:04 | <annevk> | mkwst_sheriff: the original "first party" name was more clear to me |
| 09:04 | <mkwst_sheriff> | It was originally "first-party". Folks objected. |
| 09:05 | <mkwst_sheriff> | Well. One folk. |
| 09:05 | <annevk> | mkwst_sheriff: was there also some same-origin cookie effort? |
| 09:05 | <annevk> | mkwst_sheriff: I guess I got this confused with that |
| 09:06 | <mkwst_sheriff> | There was. We ended up punting on it in favor of the `__Host-` prefix, which was trivial to implement, and gets us most of the way there (still doesn't deal with ports). |
| 09:07 | <annevk> | aah okay, thanks for clearing up my confusion |
| 09:07 | <annevk> | mkwst_sheriff: jochen__ has an idea for ports, but you know that |
| 09:07 | <mkwst_sheriff> | jochen__ has lots of ideas! |
| 09:07 | <mkwst_sheriff> | I thought his ports idea was for `document.domain`? |
| 09:08 | <annevk> | I happen to like this one |
| 09:08 | <annevk> | mkwst_sheriff: I think he wanted to extend it to all things that do document.domain-like things |
| 09:08 | <annevk> | So also cookies and webauthn |
| 09:12 | <mkwst_sheriff> | Hrm. I'm staring at the back of jochen__'s head through a door, but I think I'll have to wait until he walks out to see what his idea for cookies is. |
| 09:12 | <mkwst_sheriff> | (Is it that we don't store cookies on weird ports?) |
| 09:17 | <annevk> | Whoa, unicode.org supports HTTPS now?! Nice find MikeSmith! |
| 09:18 | <annevk> | mkwst_sheriff: if you got them over port 80 or 443, they're only going out to port 80 or 443 |
| 09:18 | <annevk> | mkwst_sheriff: if you got them from a weird port, they'll continue to go to all ports |
| 09:18 | <annevk> | mkwst_sheriff: iirc |
| 09:19 | <MikeSmith> | annevk: yeah I was surprised by that too. Found it just be going through all the References one-by-one to see which might need to be updated |
| 09:19 | <annevk> | That must have been a very recent change |
| 09:19 | <MikeSmith> | yeah, weeks or a few months I guess |
| 09:20 | <MikeSmith> | anyway I ended up looking through the References only because of when I discovered last week that we didn’t have the Secure Contexts spec in there |
| 09:20 | <annevk> | Every now and then I go through http:// links and it's always unicode.org that sticks out |
| 09:21 | <annevk> | But no longer! |
| 09:21 | <MikeSmith> | heh :) |
| 09:21 | <annevk> | Even iso.org |
| 09:21 | <MikeSmith> | well you have my anxiety to thank for it :) |
| 09:22 | <MikeSmith> | after noticing that spec missing from the References, I got bothered about what else we might need to update there |
| 09:22 | <MikeSmith> | so, started pulling that thread |
| 09:22 | <MikeSmith> | then, N different PRs later I think I’m done for now |
| 09:23 | <MikeSmith> | though I still worry there’s something I overlooked |
| 09:23 | <MikeSmith> | didn’t really did it all very systematically |
| 09:23 | <mkwst_sheriff> | annevk: I guess we'd need to deal with `example.com:443` and `example.com:81` both trying to store a session ID or something? Either explicitly storing the port or sharding the cookie jar or something? |
| 09:23 | <MikeSmith> | Progress Not Perfection |
| 09:24 | <mkwst_sheriff> | It's not crazy! I imagine 99% of navigations are to standard ports. |
| 09:25 | <annevk> | mkwst_sheriff: I don't recall what the plan was when :81 adds something, if that's only for non-standard ports or if there's some kind of way that can also be used on :443 and :80 |
| 09:26 | <mkwst_sheriff> | annevk: I just mean that we'd need to spec sane behavior for the case when a standard port sets a cookie, and then a non-standard port sets the same cookie. |
| 09:27 | <mkwst_sheriff> | Whatever the behavior, we'd need to store some metadata about the way the cookie was set, or put it into a separate jar based upon that context. |
| 09:27 | <mkwst_sheriff> | So we'd probably end up doing the simple thing and adding an int to the cookie database. |
| 09:27 | <mkwst_sheriff> | Which is probably fine. |
| 09:27 | <annevk> | mkwst_sheriff: ah yeah, I suspect the idea was to just say default-port yes/no and take that into account when making requests |
| 09:28 | <annevk> | mkwst_sheriff: that was also the plan for document.domain, the addition of a boolean |
| 09:29 | <mkwst_sheriff> | I thought the plan for `document.domain` was to just stop ignoring the port when doing comparisons. |
| 09:31 | <mkwst_sheriff> | https://www.chromestatus.com/metrics/feature/timeline/popularity/2025 is his metric for the `document.domain` bit. Not sure if it's hit stable yet... |
| 09:31 | <annevk> | mkwst_sheriff: anyway, addition of boolean or int |
| 09:31 | <annevk> | mkwst_sheriff: best to ask jochen__ for specifics, maybe it changed around |
| 09:31 | <mkwst_sheriff> | Sure. Boils down to the same thing. Being explicit about it is probably for the best. |
| 09:32 | <mkwst_sheriff> | Not sure how much it really helps for cookies, given that they span subdomains, not just ports, but `document.domain` and `WebAuthn` seem like good targets. |
| 09:33 | <annevk> | document.domain and WebAuthn also span subdomains, that's the whole point |
| 09:33 | <mkwst_sheriff> | (https://tools.ietf.org/html/draft-west-origin-cookies-01 was the origin cookie proposal, btw. Reading it again, it's pretty ugly.) |
| 09:33 | <annevk> | That's why they're all in the same boat |
| 09:33 | <mkwst_sheriff> | Fair. |
| 09:33 | <annevk> | That's also why I pushed jochen__ to not just restrict document.domain, since we'd still have the leak with webauthn/cookies |
| 09:43 | <mkwst_sheriff> | Presumably fixing the algorithm in HTML would also fix WebAuthn. |
| 09:49 | <annevk> | mkwst_sheriff: can we make cookies use that algorithm too? |
| 09:49 | <annevk> | mkwst_sheriff: would be nice if they all used a shared primitive |
| 09:50 | <mkwst_sheriff> | AFAIK, they all basically rely on "registrable domain" as the relevant primitive. `document.domain` additionally relies on the `domain` attribute of `Origin`. |
| 09:50 | <mkwst_sheriff> | But the comparison for each should be the same. |
| 09:51 | <annevk> | mkwst_sheriff: I meant reuse of "is a registrable domain suffix of or is equal to" |
| 09:52 | <mkwst_sheriff> | Cookies rely on "domain-match" (https://tools.ietf.org/html/rfc6265#section-5.1.3). |
| 09:53 | <mkwst_sheriff> | And on not setting cookies for public suffixes (Step 5 of https://tools.ietf.org/html/rfc6265#section-5.3) |
| 09:53 | <mkwst_sheriff> | Basically the same thing. |
| 09:54 | <annevk> | Sure, I just figured it would be nicer if they all actually used the same thing |
| 09:54 | <annevk> | But it doesn't matter much, as long as we don't forget they're all doing the same thing, so any updates should affect all three |
| 09:57 | <mkwst_sheriff> | It would be nicer if they all actually used the same thing. |
| 09:57 | <mkwst_sheriff> | And since I'm going to have to argue with folks about referencing Fetch and HTML from an RFC anyway, might as well argue with them even more, I guess. |
| 09:59 | <MikeSmith> | annevk: in https://github.com/whatwg/infra/issues/158 not sure what you mean by “it was suggested to require things from documents instead, but that doesn't quite work for APIs” |
| 10:00 | <MikeSmith> | the code that uses an API is (logically) part of the document |
| 10:00 | <MikeSmith> | so we can say, “Documents must not use this API in way that ...” or whatever |
| 10:03 | <annevk> | MikeSmith: I guess if everything is a document that might work |
| 10:03 | <annevk> | MikeSmith: my bad in that case |
| 10:04 | <annevk> | mkwst_sheriff: enjoy |
| 10:33 | <nox> | The spec for <video> says that when there is nothing to show, the <video> elements represents transparent black with no intrinsic dimensions, |
| 10:33 | <nox> | but if I load data:text/html,<video%20style="border:1px%20black%20solid"> in Safari, Chrome or Firefox, it draws a 300x150 box. |
| 10:33 | <nox> | Should the spec change? |
| 10:36 | <annevk> | nox: maybe |
| 10:36 | <nox> | annevk: Should I just file an issue? |
| 10:38 | <annevk> | nox: yeah, though I'm guessing it's not technically an issue since that's just what it represents |
| 10:38 | <nox> | annevk: What do you mean? |
| 10:38 | <annevk> | nox: it still needs to be rendered per the replaced element rules |
| 10:38 | <nox> | I don't understand what that means. |
| 10:38 | <jochen__> | what's up with ports & cookies? |
| 10:39 | <nox> | annevk: 'The video element represents its poster frame, if any, or else transparent black with no intrinsic dimensions.' is the only thing that specifies that <video> is supposed to not render anything by default, right? |
| 10:39 | <annevk> | jochen__: mkwst_sheriff and I were wondering how the "new model" would work with a cookie set on :81 vs one set on :443 |
| 10:40 | <annevk> | nox: so wait if it doesn't have intrinsic dimensions isn't the fallback defined by CSS 300x150? |
| 10:40 | <nox> | annevk: Where? |
| 10:40 | <annevk> | nox: it still seems a little weird that we don't define this in the rendering section though |
| 10:40 | <nox> | annevk: I've never heard about such a fallback, so if you could point it out to me that would be well appreciated. |
| 10:41 | <annevk> | nox: https://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width |
| 10:42 | <nox> | annevk: Thanks! |
| 10:48 | <nox> | annevk: But why do these rules apply? |
| 10:48 | <jochen__> | annevk: I'd basically introduce another bit to origin that says "default port", so http://example.com/ would be (http, example.com, 80, true) and https://test.com:31337 would be (https, test.com, 31337, false) |
| 10:48 | <annevk> | nox: you agree it's a replaced element? |
| 10:48 | <nox> | annevk: Maybe? |
| 10:49 | <jochen__> | and the "is default port" bit has to match in any case |
| 10:49 | <nox> | Where is that stated? |
| 10:49 | <annevk> | nox: in the rendering section |
| 10:49 | <nox> | annevk: Where is that in the spec? |
| 10:49 | <annevk> | jochen__: okay, mkwst_sheriff thought you wanted to to store the port |
| 10:49 | <nox> | I can't find "replaced" in the spec of <media>. |
| 10:50 | <jochen__> | annevk: for cookies? |
| 10:50 | <nox> | (Nor <video>..) |
| 10:50 | <annevk> | nox: https://html.spec.whatwg.org/multipage/rendering.html#embedded-content-rendering-rules |
| 10:50 | <jochen__> | annevk: I'd basically end up with two cookie jars, one for default_port = true and one for false |
| 10:50 | <nox> | annevk: Thanks. |
| 10:50 | <annevk> | jochen__: yeah, he thought the extra field would be int, not boolean |
| 10:51 | <annevk> | jochen__: anyway, looking forward to seeing that progress, it's a nice additional restriction I think |
| 10:51 | <nox> | annevk: Is there any more up-to-date spec than CSS2.1 that says the same thing? |
| 10:54 | <annevk> | nox: there wasn't a couple years ago |
| 10:55 | <nox> | Ok. |
| 10:55 | <annevk> | nox: maybe half a decade, it's been a while I suppose |
| 11:08 | <nox> | annevk: Any wording for the fact that <video width=500> will not keep 150 for the height, and will instead preserve ratio? |
| 11:10 | <smaug____> | annevk: "page" isn't any specified thing, right? |
| 11:10 | <smaug____> | like, not top level document + all the documents in iframes underneath, or anything like that |
| 11:22 | <gsnedders> | nox: yes, somewhere |
| 11:25 | <gsnedders> | nox: https://drafts.csswg.org/css2/visudet.html#inline-replaced-width |
| 11:25 | <gsnedders> | nox: uh, https://drafts.csswg.org/css2/visudet.html#inline-replaced-height |
| 11:26 | <nox> | gsnedders: "has a height not greater than 150px" wat |
| 11:27 | <gsnedders> | nox: hey, be glad the 300x150 default finally got spec'd |
| 11:27 | <nox> | lol |
| 11:27 | <nox> | gsnedders: But the words "has a height not greater than 150px" are wrong right? |
| 11:27 | <gsnedders> | nox: but yeah, "Otherwise, if 'height' has a computed value of 'auto', and the element has an intrinsic ratio then the used value of 'height' is: |
| 11:27 | <gsnedders> | nox: is the case <video width=500> is in |
| 11:27 | <gsnedders> | nox: (assuming the video format has an intrinsic ratio, which all that I'm aware of do) |
| 11:28 | <nox> | gsnedders: I literally meant <video width=500>. |
| 11:28 | <nox> | No src, no source child, nothing. |
| 11:28 | <gsnedders> | nox: oh, then yeah it's the 150px case |
| 11:29 | <gsnedders> | nox: and yeah, that's a bit awkward to read |
| 11:29 | <nox> | gsnedders: So the spec is wrong? |
| 11:29 | <gsnedders> | nox: I haven't read what's in the HTML spec about this :) |
| 11:29 | <nox> | gsnedders: I mean, |
| 11:29 | <nox> | if the ratio of 2:1 needs to be preserved, |
| 11:29 | <nox> | how do you do that if the width is >300px? |
| 11:30 | <nox> | And the height cannot be >150px. |
| 11:31 | <gsnedders> | yeah, the spec doesn't seem very clear there. file a bug? |
| 11:31 | <nox> | Mmh <video width=500 style="border: 1px black solid"> is not rendered the same as <object width=500 style="border: 1px black solid">. |
| 11:31 | <nox> | gsnedders: So what's missing, I think, is a definition of the intrinsic ratio of the video element. |
| 11:34 | <annevk> | Hmm, http://cldr.unicode.org/ doesn't use HTTPS; you'd think that would be even more important |
| 11:35 | <annevk> | smaug____: I think it has some meaning in CSS printing |
| 11:35 | <smaug____> | right, but not in DOM |
| 11:35 | <annevk> | smaug____: not in any DOM/HTML context that I know of |
| 11:36 | <smaug____> | I was trying to understand pointer events spec, and couldn't. Filed a bug, well 3. |
| 11:36 | ondras | uses @page for printing stuff |
| 11:37 | <nox> | gsnedders: Filed. https://github.com/whatwg/html/issues/3090 |
| 12:33 | <annevk> | tobie: oh, so https://github.com/tobie/specref/blob/master/refs/legacy.json is parsed later or something? |
| 12:34 | <annevk> | tobie: which files from https://github.com/tobie/specref/tree/master/refs are auto-generated? |
| 12:34 | <tobie> | annevk: nope, that's all the ones that were too hard to automatically parse |
| 12:35 | <tobie> | they're dumped as a string to the clients who then have to deal with it. |
| 12:35 | <tobie> | annevk: that's why ideally they should be fixed |
| 12:35 | <tobie> | annevk: all but biblio and legacy |
| 12:36 | <annevk> | tobie: what's the source for csswg.json? |
| 12:36 | <tobie> | annevk: but it's a little more subtle than auto-generation, though, as they're fed into the input themselves |
| 12:36 | <annevk> | tobie: it was last patched manually 5 months ago it seems |
| 12:36 | <tobie> | annevk: which makes them manually patched for some cases |
| 12:37 | <tobie> | annevk: http://dev.w3.org/csswg/biblio.ref |
| 12:38 | <tobie> | annevk: at https://github.com/tobie/specref/blob/master/scripts/csswg.js#L46 |
| 12:38 | <annevk> | tobie: I see, that URL can now be HTTPS |
| 12:39 | <annevk> | tobie: do you want a PR for that? |
| 12:39 | <tobie> | annevk: sure |
| 12:40 | <annevk> | MikeSmith: the redirect for http://dev.w3.org/2009/dap/contacts/ is rather useless |
| 13:26 | <annevk> | Domenic: how is forging in https://github.com/whatwg/dom/issues/270#issuecomment-333531823 a problem though? |
| 13:28 | <annevk> | Domenic: is there a new subtlety the subsequent comments didn't go into? |
| 13:29 | <Domenic> | annevk: it basically means you are no longer constrained by the API; seems pretty unsafe. |
| 13:29 | <Domenic> | you can get a pointer to objects you weren't originally allowed to access, since everyone shares the same global space ("integers") |
| 13:31 | <annevk> | Domenic: so this is only problematic if we actually expose the buffer? |
| 13:32 | <annevk> | I guess you can still queue invalid operations or with integers that potentially are used for some other purpose |
| 13:32 | <annevk> | Maybe |
| 13:32 | <Domenic> | Yeah, it's problematic if we use integers for the arguments to these methods |
| 13:33 | <Domenic> | (or return them) |
| 13:35 | <annevk> | If they return integers to get a handle on a node later and we only return nodes within the appended tree (so these are not global references) it might be okay |
| 13:36 | <annevk> | I mean, it's definitely something we need to be mindful of, but I'm not sure it's a showstopper for the general idea |
| 13:36 | <annevk> | We also haven't really seen any alternatives pop up, but this also hasn't gotten any experimentation yet unfortunately |
| 13:37 | <annevk> | Might be another interesting intern project |
| 14:22 | <annevk> | TabAtkins: doesn't CSS also need some way to reference Node objects from another thread? |
| 14:22 | <annevk> | TabAtkins: for layout worklets and such? |
| 14:23 | <annevk> | TabAtkins: or is that worked around differently? |
| 14:23 | <TabAtkins> | Worked around differently |
| 14:23 | <annevk> | surma: hey, where is that proposal you talked about in HTTP 403? |
| 14:23 | <TabAtkins> | You just get a property bag and some objects representing the box tree |
| 14:23 | <annevk> | surma: assuming you're that surma |
| 14:24 | <surma> | i am that surma ^^ |
| 14:24 | <annevk> | TabAtkins: kk, was wondering if you maybe shared a need with https://github.com/whatwg/dom/issues/270 |
| 14:24 | <surma> | You mean tasklets? |
| 14:24 | <annevk> | surma: yeah |
| 14:24 | <surma> | https://discourse.wicg.io/t/proposal-tasklets/2199 |
| 14:25 | annevk | wonders if JakeA learned meanwhile that Worklets are very much intended to be able to run on a different thread |
| 14:25 | <annevk> | surma: new version of https://github.com/esprehn/tasklets basically? |
| 14:26 | <annevk> | Seems your variant has more commits, but a similar README |
| 14:26 | <surma> | Yeah esprehn, bfgeek and I had 3 versions before the canonical one on ChromeLabs got created |
| 14:27 | <surma> | The commits mostly stem from the polyfill that we wrote. |
| 14:28 | <surma> | Which reminds me I need to Backport all the progress and features I made with Comlink |
| 14:28 | <JakeA> | annevk: ohhh, I think I knew that. I was unsure if they had an event loop. At one point I thought async stuff wasn't allowed in them, but not sure where I got that from |
| 14:30 | <annevk> | JakeA: they have an event loop of sorts, but very little is queued to it |
| 14:30 | <annevk> | JakeA: but e.g. audio worklets have a postMessage API so very much need to loop |
| 14:31 | <annevk> | JakeA: and I suspect paint has similar things and will at least need to deal with promises |
| 14:32 | <JakeA> | annevk: so the only difference between them and workers is the ability to run on the same thread as eachother, and perhaps different APIs exposed? |
| 14:33 | <annevk> | JakeA: I think the difference is that there's less APIs exposed (just ECMAScript builtins and a couple basic things; though some worklets might still expose quite a bit of new objects) |
| 14:34 | <JakeA> | annevk: unrelated, but do you know of any web APIs that have the ability to terminate fetches in a standardised way? Aside from fetch & xhr |
| 14:34 | <annevk> | JakeA: I don't think it's really sorted what the ideal mapping to OS threads is (though they won't be able to use Atomics.wait, which dedicated workers can, but no other workers can) |
| 14:35 | <annevk> | JakeA: maybe window.stop()? But I couldn't really create good tests with that myself |
| 14:35 | <annevk> | JakeA: another trick might be navigating a document that has ongoing fetches |
| 14:35 | <annevk> | JakeA: the latter one is documented, but there's a bunch of interop and timing differences between browsers |
| 14:36 | <annevk> | surma: that proxy bridge is interesting, but also the first proxy we'd add after we have deprecated them all |
| 14:36 | <annevk> | surma: not sure how I feel about that |
| 14:36 | <JakeA> | annevk: timing isn't really an issue. Navigating an iframe sounds like a good bet |
| 14:37 | <annevk> | JakeA: oh, window.close() should be similar |
| 14:37 | <annevk> | JakeA: and maybe removing an <iframe> |
| 14:38 | <annevk> | JakeA: (you can use window.open() within web-platform-tests, it's safelisted) |
| 14:38 | <JakeA> | annevk: I thought about removing an iframe, but wondered if it might keep the fetches alive while there's a reference. |
| 14:39 | <JakeA> | Good few avenues to test there, though |
| 14:39 | <annevk> | JakeA: I don't think it should, since removing an <iframe> triggers some synchronous stuff |
| 14:39 | <annevk> | JakeA: that is, removing and then appending is destructive |
| 14:40 | <annevk> | JakeA: yeah, removing an <iframe> triggers discard for the browsing context, which triggers discard for documents, which triggers abort for the document |
| 14:43 | <JakeA> | annevk: that'll do the trick then, thanks! |
| 14:54 | <annevk> | surma: might also be good to update those older repositories to point to the one true source for tasklets |
| 14:57 | <Domenic> | +1 updating older repos |
| 15:02 | <annevk> | gwicke: why does Wikipedia percent-encode URLs with Unicode in them? |
| 15:03 | <annevk> | gwicke: if you consistently enforce UTF-8 it would presumably save quite a bit of bandwidth on non-Western content to not do that |
| 15:03 | <gwicke> | annevk: in the default desktop view that is a historical hold-over |
| 15:04 | <gwicke> | part of the damage inflicted by the xhtml validator back in the day |
| 15:04 | <gwicke> | the newer parsoid parser uses UTF8 wherever it can |
| 15:04 | <annevk> | gwicke: okido |
| 15:05 | <gwicke> | annevk: thanks for the prod! |
| 15:07 | <surma> | annevk: feel free to comment on the wicg thread. Good point about the old repos, I wasn't actually aware that they got shared outside Google. |
| 15:12 | <annevk> | surma: I guess I'll file an issue |
| 15:13 | <surma> | Appreciate it! |
| 15:24 | <gsnedders> | who should be pinged about CSSOM stuff? |
| 15:24 | <gsnedders> | now zcorpan is gone (:() |
| 15:27 | <annevk> | gsnedders: Glenn Adams! |
| 15:29 | <gsnedders> | oh, I mean CSSOM View seemingly. still the same answer? |
| 15:49 | <gsnedders> | Also: is there anyone around IRC I can ask probably stupid font-related questions? |
| 15:50 | <gsnedders> | (I ask to ask given I've only ever got silence before :)) |
| 16:10 | <TabAtkins> | gsnedders: I'll probably do unofficial editting on the spec until we decide on a real editor. |
| 17:30 | <annevk> | jyasskin: won't derail the thread further, but your statement doesn't work generically for worklets either |
| 17:30 | <annevk> | jyasskin: consider audio worklets |
| 17:30 | <jyasskin> | annevk: What's wrong for audio workets? |
| 17:31 | <annevk> | jyasskin: they need to be on their own thread, nothing's wrong |
| 17:31 | <jyasskin> | annevk: Couldn't the browser multiplex multiple audio worklets from a single origin onto the same thread? |
| 17:33 | <annevk> | jyasskin: I don't see why that would be okay but it wouldn't be okay for workers |
| 17:33 | <jyasskin> | annevk: Ah, no, the AudioWorklet spec says they're multiplexed onto the rendering thread: https://webaudio.github.io/web-audio-api/#AudioWorklet |
| 17:34 | <annevk> | jyasskin: I guess I don't understand why that's okay, but it's not okay for workers |
| 17:34 | <annevk> | jyasskin: other than worklets being a subset they're fundamentally the same, and audio worklets also have a messaging channel |
| 17:36 | <jyasskin> | annevk: I'm not certain why it doesn't work for workers. I think it has something to do with their synchronous APIs, but I don't know the JS engine details that prevent us from pausing those to switch to another worker. |
| 17:37 | <annevk> | jyasskin: so maybe it only applies to dedicated workers because of Atomics.wait? |
| 17:37 | <annevk> | jyasskin: I guess that must be it |
| 17:40 | <jyasskin> | I'd also include synchronous XHR and probably some of the OffscreenCanvas API, but again I'm not certain. |
| 17:41 | <annevk> | jyasskin: according to lth it's problematic for anything that can wake |
| 17:42 | <annevk> | jyasskin: which seems to suggest these cooperative multithreading designs are somewhat at odds with SAB |
| 17:45 | <jyasskin> | annevk: That's the part I'm still missing. I see the conflict with Atomics.wait(), but that already explicitly guards itself with AgentCanSuspend() and so wouldn't be usable from a cooperative-multithreaded agent. |
| 17:46 | <annevk> | jyasskin: I think I convinced lth that the issue also arises with a document and a child document |
| 17:46 | <annevk> | jyasskin: next step is filing an issue to explore further when there's more time |
| 17:47 | <jyasskin> | Thanks :) |
| 17:47 | <jyasskin> | Also thanks for your Infra issue. |
| 17:50 | <ato> | Does anyone have a hotline to Hixie? http://software.hixie.ch/utilities/cgi/data/data appears to be malfunctioning. |
| 18:05 | <annevk> | jyasskin: did reach a resolution, apparently cooperative multithreading still meets the definition of fp |
| 18:05 | <annevk> | jyasskin: they just really want workers to be actually 1:1 with threads |
| 18:06 | <annevk> | jyasskin: fp being forward progress |
| 18:06 | <jyasskin> | And they probably would have written that into the forward progress definition if anyone knew how to specify forward progress precisely. The C++ committee is in the middle of years of work trying to specify the guarantees systems actually provide. |
| 18:18 | <annevk> | jyasskin: you mean requiring threads? |
| 18:18 | <annevk> | jyasskin: if they had done that that would've been bad for worklets and friends |
| 18:19 | <jyasskin> | annevk: We do need two different forward progress guarantees for Workers vs Worklets. |
| 18:20 | <jyasskin> | I don't know, I wasn't in the discussion, and maybe TC39 had other reasons for wanting a weaker FP guarantee for Workers than anyone actually wanted to implement. |
| 18:22 | <jyasskin> | Fundamentally, a dedicated Worker should be able to run "while (true){}" without blocking anything else, and Worklets, Service Workers, Tasklets, etc. shouldn't have that property. Right? |
| 19:30 | <annevk> | ato: in what way? |
| 19:31 | <annevk> | jyasskin: yeah, though [[CanBlock]] is not the signifier for this even though it rather strongly appears that way |
| 19:32 | <jyasskin> | [[CanInfiniteLoop]] would be more like it. ;) |
| 19:32 | <ato> | annevk: The ‘Generate’ button doesn’t create a data URI and redirects back to the main page. |
| 19:33 | <annevk> | ato: hmm works here |
| 19:34 | <ato> | annevk: Are you sure? In Firefox it does nothing, whereas Chrome complains about ERR_UNSAFE_REDIRECT. |
| 19:35 | ato | wonders if the Mozilla network people have broken something more when they tried fixing IPv6 for the nth time |
| 19:35 | <annevk> | ato: suspect navigating to data URLs is restricted in Fx too now |
| 19:35 | <annevk> | ato: I’m only aware of putting them in opaque origins |
| 19:36 | <ato> | Is that a CSP directive that should be whitelisted or somesuch? |
| 19:56 | <gsnedders> | TabAtkins: really I wouldn't object to using something like CSSOM View for a more WHATWG-like editorial expierments in the CSS WG |
| 20:11 | <rwaldron> | Are the substeps of "7.8.1 Navigating across documents", step 12 (found here: https://html.spec.whatwg.org/multipage/browsing-the-web.html#javascript-protocol ) always expected to occur in a later task queue? |
| 20:13 | <rwaldron> | It says "queue a task", so I'm assuming yes, but I'm reviewing tests for "javascript:" behaviors (in form action) and every browser disagrees |
| 20:37 | <annevk> | ato: no, basically no longer a feature, but not fully standardized either |
| 20:38 | <annevk> | rwaldron: there are some known issues; don’t remember any on timing though |
| 20:38 | <annevk> | rwaldron: would be good to file |
| 21:14 | <domfarolino> | annevk: (Domenic too): where would you recommend domintro boxes for the fetch spec go, below the class IDL in section 5? That seems to be a good place as that's where the event domintro box is in the dom spec. |
| 22:03 | <TabAtkins> | gsnedders: Strongly agree. It's a low-churn spec, and most changes are just implementation-chasing anyway; it seems perfect for doing WHATWG-style. |
| 22:06 | <jyasskin> | Domenic/bz: I'm reviewing https://github.com/w3c/webappsec-credential-management/pull/93, and pulling on thread-safety keeps getting hairier. For example, [[Store]] currently takes a Credential instance, but it's called in parallel, so reading fields off instances isn't allowed. It seems like we're assuming that a struct-of-primitives is made and copied before going in parallel, and that exactly which struct it is |
| 22:06 | <jyasskin> | depends on which subtype of Credential we got. Do any other specs demonstrate concise ways to describe this? |
| 22:26 | <jyasskin> | (I could be wrong about whether reading fields off instances is disallowed. If they're otherwise readonly, maybe it's ok? I think this isn't specified anywhere.) |