| 11:59 | <andreubotella> | annevk: I didn't realize this yesterday, but html#5342's proxy definition of "length" might be too short and without context, it used to be "string length". |
| 12:15 | <annevk> | andreubotella: since <dfn>length</dfn> was available in HTML I think it's fine for this to use it |
| 12:15 | <annevk> | andreubotella: (it'll only be used in the context of a string) |
| 12:16 | <andreubotella> | annevk: I guess that works |
| 12:17 | <andreubotella> | annevk: something else I've come across just now while working on the rest of HTML changes in infra#291 is that the id of infra's length definition is javascript-string-length, not string-length |
| 12:19 | <annevk> | andreubotella: let me put up a fix for Infra as we should probably preserve both |
| 12:19 | <andreubotella> | annevk: ok |
| 12:22 | <annevk> | https://github.com/whatwg/infra/pull/295 |
| 14:59 | <annevk> | littledan: the other worrisome thing is adding more complexity to agents without them having been formalized; on the flipside, I do appreciate we're starting these conversations earlier these days as I'm still sour from how SAB went down (also has a flipside, Domenic and I had quite a bit of fun figuring it out) |
| 17:30 | <TabAtkins> | annevk: I don't understand what you're talking about in https://github.com/w3c/csswg-drafts/issues/4851#issuecomment-597205900 |
| 17:31 | <annevk> | TabAtkins: one URL for one <dfn>, so to say |
| 17:31 | <annevk> | TabAtkins: anyway, it doesn't matter it's not that way |
| 17:31 | <annevk> | TabAtkins: as it turns out tooling makes it look that way to me, mostly |
| 17:34 | <a-ja> | seeing <dfn> reminded me to ask...is there a proposal for a <term> element? saw a reference to one in aria-annotations example |
| 17:35 | <annevk> | a-ja: what's <term>? |
| 17:37 | <a-ja> | dunno....think it was in example using aria-details for a term and its definition. prolly just a mistake |
| 18:36 | <Domenic> | Hooray for unifying our string definitions |
| 18:36 | <Domenic> | Hooray for Infra |
| 18:40 | <MikeSmith> | it is interesting to see https://github.com/ricea/websocketstream-explainer (the WebSocketStream thing) happening |
| 18:41 | <MikeSmith> | I had been (mis)thinking that the Web Socket API was eventually gonna get obsoleted by some combination of Streams with H/2 or H/3 or whatever |
| 18:43 | <MikeSmith> | so I’d now like to learn why it won’t be, and why it’s preferable to build on top of Web Socket |
| 18:44 | <MikeSmith> | what’s lacking still in the rest of the stack that makes Web Socket still attractive as a basis to build new stuff on top of |
| 18:46 | <MikeSmith> | I had kind of thought an implicit goal of the newer stuff was to obviate the need for Web Socket going forward, by baking the right capabiities into other core bits |
| 18:47 | <MikeSmith> | (or if not an implicit goal, at least that from the newer stuff, it would just naturally fall out that Web Socket would not be needed any more) |
| 18:48 | <MikeSmith> | hmm OK at https://github.com/ricea/websocketstream-explainer I see, “WebTransport will also provide backpressure, and may ultimately supercede this work. In the near future the WebSocket protocol has the advantage that it works on networks that block QUIC, and has much existing deployed infrastructure.” |
| 18:54 | <Domenic> | MikeSmith: right, so WebTransport might obsolete it, but it's a third protocol, which will need its own stack and ecosystem spun up. |
| 18:55 | <Domenic> | MikeSmith: the plan to just use H/2 with streams hit a snag where implementers said actual bidirectional streaming was effectively impossible to implement in their architecture. I think there were also concerns about middleboxes. |
| 18:58 | <MikeSmith> | aha |
| 18:59 | <MikeSmith> | yeah that consistently seems to be the problem in general with getting things done in the deployed HTTP ecosystem |
| 18:59 | <MikeSmith> | (and thanks, for info on both points) |
| 19:00 | <Domenic> | Yeah it seems like even basic streaming uploads (not both directions at once, just both directions period) is getting a lot of middlebox concerns :( |
| 19:04 | <MikeSmith> | geez |
| 19:08 | <MikeSmith> | I guess Web Socket was architected pretty well, as as far as hitting the sweet spot for what was practical to get into implementations and for adopters to actually be able to use |
| 21:25 | <annevk> | Turns out HTTP is hard |
| 23:23 | <Dvorapa> | Hi guys, could you please someone revert https://wiki.whatwg.org/index.php?title=MetaExtensions&diff=10289&oldid=10280? It adds redundant/duplicite keyword without specification |
| 23:24 | <Dvorapa> | Or move it to other (failed/incomplete) sections in that page |