| 02:21 | <gsnedders> | there are some specs I really wish that gave a simple one or two line description of what a function does, instead of just giving a formal definition |
| 02:21 | <gsnedders> | because it's far harder to work out what something does from a hundred lines of prose than two sentences. |
| 03:10 | <annevk> | nox: does it matter? If so, maybe |
| 03:14 | <domfarolino> | gsnedders: yeah I've found MDN/Web Fundamentals documentation to somewhat provide that, that is a less "precise" layman definition of formal spec language sorta |
| 03:28 | <annevk> | gsnedders: file a bug? Usually means an introduction is missing |
| 04:27 | <tantek> | yup good point |
| 04:27 | <MikeSmith> | well if nobody actually uses it and/or there’s no spec that defines what it means, then it seems like for <a> and <area> we shouldn’t allow rel=canonical maybe? |
| 04:28 | <annevk> | MikeSmith: what do the counters say? |
| 04:29 | <tantek> | MikeSmith, I'm ok with that - KevinMarks is editing currently and I think only bridged via Slack |
| 04:29 | <tantek> | so that means he's likely [KevinMarks] in #microformats (even if you can't "see" him there) |
| 04:29 | <tantek> | he's in BST TZ |
| 04:30 | <tantek> | from the spec: "Search engines prefer rel=canonical on a <link> element, and will ignore it on an <a> element. " |
| 04:31 | <MikeSmith> | oh |
| 04:31 | <tantek> | so that seems like a pretty strong statement against allowing it on <a> (and <area>) for that matter |
| 04:31 | <MikeSmith> | yes |
| 04:31 | <tantek> | even if it is not clear spec-language (separate issue) |
| 04:31 | <MikeSmith> | yeah |
| 04:32 | <MikeSmith> | annevk: the use counter I added to the checker doesn’t itemize <a rel> and <link rel> usage separately |
| 04:32 | <MikeSmith> | I need to look back at data from Simon to see if that does |
| 08:00 | <annevk> | So many people are playing Zelda and I don't even know when I'm going to get a console |
| 08:01 | <annevk> | Maybe I should start going into actual stores rather than looking around online |
| 08:07 | <KiChjang> | annevk: weird, just the other day at my company people were talking about beating zelda as well |
| 08:12 | <annevk> | KiChjang: it's not that weird, they just released it and lots of folks managed to get their hand on it, leading to a shortage for everyone who was distracted during the launch, like me |
| 08:12 | <KiChjang> | forget about zelda, the web is more interesting |
| 08:31 | <KiChjang> | does anyone here happen to know if a StructuredClone value is in anyway managed by a GC? |
| 08:31 | <KiChjang> | the spec says they're a Record that is indepdent of any realm, but does that mean it is a browser-native object? |
| 08:35 | <Domenic> | KiChjang: not sure what "browser managed object" is but the intention is e.g. it's a bunch of bytes in memory in some browser-specific serialization format |
| 08:36 | <KiChjang> | Domenic, what i mean is whether a StructuredClone is a JS value managed by the JS GC |
| 08:38 | <annevk> | KiChjang: not observable so up to impl |
| 09:03 | <annevk> | Domenic: heya, would reviewing abortable stuff be okay now or still not feeling super happy about it? |
| 09:03 | <Domenic> | annevk: PromiseController you mean? |
| 09:03 | <annevk> | Domenic: in particular, I'm thinking about the PR against DOM |
| 09:03 | <Domenic> | yeah |
| 09:04 | <Domenic> | just commented coincidentally enough |
| 09:04 | <annevk> | heh |
| 09:04 | <annevk> | Domenic: ta |
| 09:06 | <annevk> | KiChjang: I pitched making games for the web to a couple of Nintendo employees once, but they were not super convinced |
| 09:06 | <annevk> | KiChjang: so until that happens it'll have to be web and Zelda (and some other stuff) |
| 09:06 | <KiChjang> | there is a GBA emulator that's being run on the web using JS IIRC |
| 09:07 | <KiChjang> | and worry not, wasm is going to change everything |
| 09:07 | <annevk> | Wouldn't that be nice |
| 09:24 | <nox> | annevk: I don't know if it matters, but it sounds weird at least. |
| 09:27 | <annevk> | nox: a websocket upgrade request is not really that different from other requests without a body |
| 09:27 | <annevk> | nox: so I'm not sure why we'd need a special path |
| 09:27 | <nox> | annevk: It is very different. |
| 09:27 | <nox> | annevk: The thing that rejects responses with a status different than 101 is in establishing a websocket connection, |
| 09:28 | <nox> | when reaching that rejecting step, other algorithms may have needed to wait for body, queued tasks, and whatnot. |
| 09:29 | <nox> | Maybe all these tasks being queued are handwaving and aren't observable though, in which case I guess it doesn't matter. |
| 09:30 | <annevk> | nox: but that algorithm is also in charge of any tasks queued |
| 09:32 | <annevk> | nox: I guess I'll need a bit more detail and an issue if you think it's problematic |
| 09:32 | <nox> | annevk: What is "that algorithm" in what you just said? |
| 09:36 | <annevk> | nox: establishing a websocket connection |
| 09:36 | <nox> | annevk: Where is it in charge? |
| 09:36 | <nox> | It is given an arbitrary client, which is used to create the request, so the client is in charge, right? |
| 09:37 | <annevk> | nox: at some point we need to make this more explicit, but only the caller to fetch does something with the tasks |
| 09:37 | <nox> | Ok. |
| 09:38 | <annevk> | nox: maybe the fetch group does something as well, but that's still super vague and awaiting general lifecycle cleanup in HTML |
| 09:38 | <nox> | Ok. |
| 09:38 | <nox> | annevk: Yeah that's probably just my gripe, that it is super vague. |
| 09:39 | <annevk> | I don't like it either, but there's not many other folks helping chart the waters here so it's basically designing the architecture, new features, and making sure old features keeping working, all at the same time |
| 09:40 | <annevk> | I really want to get to the lifecycle stuff at some point, but I'm also dreading it a bunch |
| 09:41 | <annevk> | Created super basic ancestorOrigins test, two browsers, two results |
| 10:05 | <suds13> | Hi its my first time contributing, so go easy on me. |
| 10:06 | <suds13> | I want to fix this issue : https://github.com/whatwg/html/issues/2500 |
| 10:07 | <suds13> | I forked the repo and in the source file I made this change in the full width latin row: <td> <span data-x="attr-fe-inputmode-state-latin">Latin Prose</span> TO <td> <span data-x="attr-fe-inputmode-state-latin-prose">Latin Prose</span> |
| 10:08 | <suds13> | Is this correct ? |
| 10:27 | <annevk> | suds13: hey, yes, that looks good |
| 11:01 | <suds13> | annevk: I have created a pull request, thanks. |
| 11:02 | <annevk> | suds13: thank you! |
| 11:04 | <annevk> | suds13: merged, standard will be updated in a bit |
| 14:45 | <zcorpan> | TabAtkins: status on fingerprint thing in bikeshed? |
| 15:24 | <zcorpan> | (feel free to reply here while I'm away, i can check the logs. or use botie tell) |
| 16:11 | <annevk> | Domenic: so if you make Streams depend on this new canceling concept you're effectively requiring some kind of Host hook I suppose, if we keep Streams on the JS side of the divide |
| 16:56 | <jyasskin> | Or we smush cancellation into Streams and sneak it into JS that way. |
| 16:57 | <annevk> | jyasskin: I was mostly referring to cancelation (one l, hah) relying on events and maybe DOMException |
| 16:58 | <jyasskin> | Yeah, events are really the only tricky part: if canccelation goes into JS, it'd just be a simple exception. |
| 16:59 | <jyasskin> | I'm kinda surprised JS doesn't have a native event mechanism yet... |
| 17:37 | <TabAtkins> | zcorpan: Sorry, was distracted this week by a bug I thought would be easier (from Domenic), then by a bug that turned out quite hard (TLS >_<) and now I'm sick. |
| 17:38 | <TabAtkins> | So, uh, it's top of my prio list, but dunno precisely when I'll be working on Bikeshed again. Might be Monday, we'll see. |
| 18:27 | <annevk> | TabAtkins: take care 🍵 |
| 18:33 | <TabAtkins> | just a head cold, but i'm still taking it easy ^_^ |
| 20:00 | <zcorpan> | TabAtkins: ok, no worries. there's no rush :-) |
| 22:07 | <tobie> | jyasskin: "I'm kinda surprised JS doesn't have a native event mechanism yet...": https://twitter.com/tobie/status/699552694726426624 and yet… |
| 22:46 | <domfarolino> | Man, slack message "reactions" can be real distracting; IRC is a lot cleaner |
| 23:00 | <smaug> | igrigorik: where is the latest longtask spec? |
| 23:00 | <smaug> | the one in WICG from February has "Not Ready For Implementation" |
| 23:01 | <smaug> | so rather surprising to see Intent-To-Ship |
| 23:02 | <smaug> | perhaps foolip knows the status given that he said LGTM |
| 23:02 | <smaug> | or Domenic |
| 23:04 | smaug | assumes it is not a spec one should implement, but blink is about to ship it anyhow |