2023-02-01 [00:32:19.0257] https://twitter.com/Hixie/status/1620694008405331968 [00:32:39.0205] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC3KVdAlLGOsK6gFoEOD0/edit?resourcekey=0-bPajpoo9IBZpG__-uCBE6w# [00:46:02.0914] https://twitter.com/Hixie/status/1620704532748701697 [00:51:26.0327] maybe we could call it “The Second System”… [00:52:15.0697] or if we’re really optimizing for irony, “Web4” [00:53:25.0437] or else just skip to “Web5” (and also create some entertaining narrative for why we skipped past “Web4”) [00:56:23.0383] anyway, this rightly seems like something we should have seriously started working on already — and I’ve not heard any sound objections to it other than some assertions that the performance benefits wouldn’t be significant enough to merit the spec work and implementation work required [00:57:12.0544] but as Hixie says in one of his tweets, _“The goal is simplicity and developer ergonomics, more than performance”_ [00:57:49.0001] * anyway, this rightly seems like something we should have seriously started working on already — and I’ve not heard any sound objections to it other than some assertions that the performance benefits wouldn’t be significant enough to merit the spec work and implementation work required [03:53:34.0758] WABI [05:57:52.0023] "applications could ship with their own implementations of high-level concepts like layout, widgets, and gestures" seems like an anti-goal to me. [05:58:10.0698] And not one any other successful platform has embraced [06:39:44.0482] I think Flutter at least has already essentially embraced it, for their Web output — at least as an option. See https://docs.flutter.dev/development/platform-integration/web/renderers — the CanvasKit renderer: https://skia.org/docs/user/modules/canvaskit/, which amounts to every app shipping with its own embedded layout engine (Skia) [07:44:42.0424] I feel like I have a lot of thoughts myself, but also - I kind of don't get at all how aria fits in that particular mix really [08:12:01.0441] well, I guess "at all" is an overstatement really [08:14:18.0595] but like - it feels like a lot of the industry was trying to go in a not totally dissimilar direction around 2004 before whatwg... like, lots of VMs with core and then a thing atop trying to add an application version of a markup maybe - flex/flash, java/jfx, silverlight/xaml ... no? [11:12:47.0694] Has anyone seen https://github.com/ada-url/ada? [12:32:54.0273] > <@domenicdenicola:matrix.org> And not one any other successful platform has embraced what about X11/Wayland? [12:33:09.0759] and Android now, with Jetpack Compose [12:33:27.0562] also, most gaming platforms [12:34:32.0453] really the web is the _only_ platform where the bootstrap mode is so high-level that you're literally a document [12:35:03.0635] even android, which bootstraps you into a java environment via the zygote doesn't start that high [13:15:16.0649] Ian Hickson: do you imagine any kind of document there? One geared toward apps? like that sort of thing almost existed (did in a way in flex, xaml, xul, jfx) and they do kind of exist now - like QML is a thing, right? [13:17:32.0921] * Ian Hickson: do you imagine any kind of document there? One geared toward apps? like that sort of thing almost existed (did in a way in flex, xaml, xul, jfx) and they do kind of exist now - like QML is a thing, right? [13:21:07.0899] * Ian Hickson: do you not imagine any kind of document there? One geared toward apps? like that sort of thing almost existed (did in a way in flex, xaml, xul, jfx) and they do kind of exist now - like QML is a thing, right? [13:39:06.0678] not sure i understand the question [14:04:24.0672] > <@hixie:matrix.org> not sure i understand the question Yeah, I mean, I guess I kind of confused too, so probably not asking the question well enough... sorry :(. [14:22:53.0608] so in your idea, things still have a URL I guess and the thing at the end of the URL is just.... straight to WASM, and that WASM you're suggesting would have some kind of (new) core libraries available to it based on WebGPU, WebHID and ARIA (the taxonomies, at least)... I guess it would probably need _some_ additional primitives there or I'm not sure how you apply them together? Am I understanding that at least generally or just way off what you are describing? [14:23:35.0235] (also, happy to take this to a different room if this is just silly for the main whatwg channel but you're still willing to answer potentially dumb questions) [14:31:39.0870] * so in your idea, things still have a URL I guess and the thing at the end of the URL is just.... straight to WASM (but like, an archive? some descriptor?), and that WASM you're suggesting would have some kind of (new) core libraries available to it based on WebGPU, WebHID and ARIA (the taxonomies, at least)... I guess it would probably need _some_ additional primitives there or I'm not sure how you apply them together? Am I understanding that at least generally or just way off what you are describing? 2023-02-02 [16:50:49.0249] bkardell: yeah, every web app still has a URL, and the thing at the end of the URL is straight to WASM That is, the thing at the end of the URL is a single binary, a single executable, completely just object code — a single `.wasm` file/resource And so then for that app, all that the browser does is just to load that single binary into memory and execute it — execute it in the existing WebAssembly execution environment that all browsers already have. And that’s all in contrast to what browsers need to do now with the current HTML/DOM+JS+CSS stack, which is: browsers must load three different things into memory: the must a DOM tree/object, a JavaScript global object, and CSS cascade/Stylesheet object — and then also keep those three in sync through all the DOM mutations and everything [16:52:40.0951] With this WABI alternative, there’s no DOM at all, there’s no JavaScript global at all, there’s CSS Stylesheet at all [16:53:19.0969] Instead, browsers load only the binary object code for the app, and just execute that [16:55:26.0486] And the WABI binary is the equivalent of statically linked object code — that is, it has all of its dependencies already compiled in, and doesn’t need to link into anything else nor load anything else [16:56:34.0611] So a WABI binary can contain its own layout engine, and its own complete runtime [17:00:05.0119] As far as that goes, one analogy is how server-side Java apps can be built today — which is that you use `jlink` to compiles a singole binary that embeds a JVM runtime and all the Java libraries that the app depends on (and so, users don’t need to have a Java runtime installed on their systems to run that app, because the app itself contains the runtime) [17:04:23.0402] But that analogy is not at all exact, because in that case the binary is an architecture-specific binary that can only run on a single platform — that is, a Windows binary, or a Linux binary, or a macOS binary. But a WABI binary is not architecture-specific but instead is a portable binary in every way that WASM binaries already are [17:08:58.0019] I think the loading code that’s currently required in browsers for HTML/DOM loading and JS loading and CSS loading may be the single most complex part of browsers implementations, and may be one of the most fragile parts — in the sense that it’s prone to regressions and to new bugs getting introduced that are hard to troubleshoot [17:11:05.0727] And at least I can say from experience as patch contributor to Chrome, that loading code is just incredibly complicated and intimidating to try to work on. Chrome has an entire team that’s devoted to just that loading code. [17:14:50.0374] And for web apps (as opposed to documents), all that loading code arguably should be unnecessary anyway — it’s just a side effect of having needed to bolt an application-execution environment on top of a model that’s not fundamentally designed for running apps but instead is just designed for laying out documents [17:19:01.0842] So there is huge value alone in just being able to cut out the need for all that loading code, and all its complexity, and (over the long run) all its ongoing maintenance cost in implementations. (Because this is the web, implementations would also forever need to still retain all that code — to run all the content that exists on the web now — but over the long run, developers building web apps would mostly move to targeting WABI instead, and most web apps would be running in the WABI execution environment instead.) [17:30:48.0367] * bkardell: yeah, every web app still has a URL, and the thing at the end of the URL is straight to WASM That is, the thing at the end of the URL is a single binary, a single executable, completely just object code — a single `.wasm` file/resource And so then for that app, all that the browser does is just to load that single binary into memory and execute it — execute it in the existing WebAssembly execution environment that all browsers already have. And that’s all in contrast to what browsers need to do now with the current HTML/DOM+JS+CSS stack, which is: browsers must load three different things into memory: they must a DOM tree/object, a JavaScript global object, and CSS cascade/Stylesheet object — and then also keep those three in sync through all the DOM mutations and everything [17:31:24.0915] * As far as that goes, one analogy is how server-side Java apps can be built today — which is that you use `jlink` to compile a singole binary that embeds a JVM runtime and all the Java libraries that the app depends on (and so, users don’t need to have a Java runtime installed on their systems to run that app, because the app itself contains the runtime) [17:31:31.0624] * As far as that goes, one analogy is how server-side Java apps can be built today — which is that you use `jlink` to compile a single binary that embeds a JVM runtime and all the Java libraries that the app depends on (and so, users don’t need to have a Java runtime installed on their systems to run that app, because the app itself contains the runtime) [17:32:05.0030] * I think the loading code that’s currently required in browsers for HTML/DOM loading and JS loading and CSS loading may be the single most complex part of browser implementations, and may be one of the most fragile parts — in the sense that it’s prone to regressions and to new bugs getting introduced that are hard to troubleshoot [17:32:18.0981] * And at least I can say from experience as a patch contributor to Chrome, that loading code is just incredibly complicated and intimidating to try to work on. Chrome has an entire team that’s devoted to just that loading code. [17:33:04.0590] * So there is huge value alone in just being able to cut out the need for all that loading code, and all its complexity, and (over the long run) all its ongoing maintenance cost in implementations. (Though, because this is the web, implementations would also forever need to still retain all that code — to run all the content that exists on the web now — but over the long run, developers building web apps would mostly move to targeting WABI instead, and most web apps would be running in the WABI execution environment instead.) [01:55:04.0086] annevk: About `URLSearchParams` `has()` and `delete()`, do you think use counters would be helpful to see if they're called with extra arguments? [04:54:59.0817] Posting here for more visibility: https://github.com/whatwg/fetch/issues/1601 [06:14:16.0289] > <@sideshowbarker:matrix.org> So there is huge value alone in just being able to cut out the need for all that loading code, and all its complexity, and (over the long run) all its ongoing maintenance cost in implementations. (Though, because this is the web, implementations would also forever need to still retain all that code — to run all the content that exists on the web now — but over the long run, developers building web apps would mostly move to targeting WABI instead, and most web apps would be running in the WABI execution environment instead.) I disagree. That code, or something equivalent, will still be needed---it will just be built by framework developers. And re-built, over and over and over, with the same mistakes repeated and missed and some of the frameworks good at using the a11y parts of the "ABI" and some bad and some doing a good job at meeting user expectations and some bad. For better or for worse, to build a successful UI framework you *need* a lot of code complexity---witness the thousands of people-years spent on them throughout history, from Win32 to WPF to Cocoa to Carbon to the web. Ones built by smaller teams, e.g. Flutter or the various Java or Linux GUI-framework-from-scratch attempts, tend to be painful for end users. GUI frameworks are just a hard problem; wishing you could start over and do it better this time is, IMO, not a good use of the tech industry's collective effort. The web works, and we even have escape hatches like wasm and WebGPU on top of it for cases like video games or CAD software or porting native apps to the web or whatever. But if you want a set of controls, loading primitives, etc., what we have is good and recreating it will not work well. [06:15:09.0390] (Try using a Flutter Web app and you'll see what I mean!) [06:18:10.0872] > <@timothygu:matrix.org> Has anyone seen https://github.com/ada-url/ada? This is neat! Hadn't seen it before. [06:21:11.0571] Domenic: I think mobile is the place where the current HTML/DOM+JS+CSS stack is not working well — as far as providing good user experiences for end users on mobile [06:23:42.0696] I think it’s clear that we began to lose a huge segment of developer share around 2009 when the iPhone really took off and Android did too, and we were busy enough anyway, in the following years, with just trying to evolve the core web runtime in the necessary ways, with the features that were needed for good app experiences on the web to viable at all even on desktop [06:24:07.0838] …and we have not won those developers back [06:24:31.0223] I think that problem is two-pronged. One, "document-like" web sites/apps are bad on mobile because of cookie banners/ads/etc. "App-like" mobile web apps are few and relatively hard to build well, but it also seems clear if the developer puts in enough effort they can get good results: see e.g. Twitter or Uber. For the rest, are developers not putting in enough effort, or is it too hard to put in enough effort because the web's UI framework is bad comparatively? I could see it being the latter. I doubt having everyone download a UI framework per web app, created by indie teams, would be a good solution though. [06:25:04.0902] yes, the web's UI framework is bad comparatively [06:25:09.0769] Reasons developers might not put in the effort are mostly around: capabilities gap; lack of app store access. There's some really interesting UX research by Chrome folks about this [06:25:39.0535] E.g. teams which tried to build web apps but found when surveying users that the users found the web app *less* trustworthy than a native app---the web is where all the viruses come from, etc. [06:26:02.0352] (Or just, the competitors were on the app store, so users assumed something must be wrong with the web app if it couldn't make it through the app store process.) [06:26:38.0772] I think the core reason currently starts from the reality that _users_ currently choose mobile apps because the user experience of those apps is relatively much better than they get from web apps [06:27:51.0467] and developers choose to write native mobile apps because those mobile apps provide a better user experience for users, and are relatively dead simple to create using available SDKs and tooling [06:28:18.0690] developers do not need to be stellar developers in order to create mobile apps that end users will actually use [06:28:24.0601] It's not clear there's any one core reason, such that if you fixed it we'd change things. I suspect it's a bunch of self-reinforcing reasons, which have trapped us in an inadequate equilibrium. E.g. if you could snap your fingers and fix the web's UI framework, the app store stickiness and capabilities gap remain. If you could fix the capabilities gap, the other two issues remain. And even if you could magically fix them all, the historical inertia remains. It's not great. [06:28:46.0373] they can instead just develop mobile apps only, with much less trouble and pain [06:29:49.0245] …and they forgo creating web apps because, in practice currently, their users prefer native mobile apps anyway [06:31:49.0441] And I think the reason that SDK and authoring-tool vendors don’t consistently provide mechanisms for generating output for the web runtime with a great user experience is: in practice it’s still so incredibly hard and costly to implement and maintain the code needed to generate HTML/DOM+JS+CSS output that provides a great user experience on mobile [06:31:55.0292] It's a potential hypothesis that it's easier for a company to create two good native mobile apps than one good mobile web app. I'd give it somewhere around 50% odds. I don't think WABI is really related to that hypothesis; building a good web UI framework to make app development easier isn't something that framework developers have been unable to do because the browser doesn't have a native MIME type handler for application/wasm. [06:32:11.0724] * It's a potential hypothesis that it's easier for a company to create two good native mobile apps than one good mobile web app. I'd give it somewhere around 50% odds. I don't think WABI is really related to that hypothesis; building a good web UI framework to make app development easier isn't something that framework developers have been unable to do because the browser doesn't have a native MIME type handler for application/wasm. [06:32:16.0893] * And I think the reason that SDK and authoring-tool vendors don’t consistently provide mechanisms for generating output for the web runtime with a great user experience is: in practice it’s still so incredibly hard and costly to implement and maintain the code needed to generate HTML/DOM+JS+CSS output that provides a great user experience on mobile [06:32:53.0685] yes, I think the _“potential hypothesis that it's easier for a company to create two good native mobile apps than one good mobile web app”_ has proven to be true thus far [06:33:01.0614] * yes, I think the _“potential hypothesis that it's easier for a company to create two good native mobile apps than one good mobile web app”_ has proven to be true thus far [06:33:07.0089] > <@sideshowbarker:matrix.org> I think the core reason currently starts from the reality that _users_ currently choose mobile apps because the user experience of those apps is relatively much better than they get from web apps > that's really far too over simplified imo, there's so many factors here pushing users that way i don't think you can say users really chose tbh [06:33:18.0884] I think it would remain incredibly hard---in fact, probably be harder---if you chose to restrict yourself to WebGPU + ARIA + whatever when creating this hypothetical better-than-iOS-and-Android-SDKs web framework. [06:35:03.0010] I agree with Domenic on this ^ [06:35:43.0885] well part of the context around this is, we’ve been trying with the current stack since at least 2009 to create an ecosystem where better-than-iOS-and-Android-SDKs web frameworks can be developed and can flourish — but it has not happened [06:35:49.0128] (and the user experience will at the very least involve a long download time for first load, which is not a great start.) [06:36:04.0737] > <@domenicdenicola:matrix.org> (and the user experience will at the very least involve a long download time for first load, which is not a great start.) that’s very true yeah [06:36:27.0138] But also i feel like this aria part (much if it really) needs a little meat to be able to even discuss it. The "and aria" i feel like is handwaved but load bearing [06:37:06.0231] Again, I think it's really unclear whether iOS/Android SDKs are that much better. Remember that Flutter and SwiftUI are based on the React paradigm, which was pioneered on the web! [06:38:39.0296] My hypothesis is that the gap comes mainly in a good control library, and having stuck my foot in that area for a half-year and failed with a small team of Googlers, it comes back to my earlier point that you basically need major institutional buy-in (e.g. a large team working for 5-10 years) to get to the same level that Windows/macOS/Android/iOS have gotten to. [06:39:17.0702] Saying "you have WebGPU, raw HID events, and some ARIA thing---community, please build a good control library!" seems like a recipe for disaster to me. [06:40:04.0620] Flutter's tried for some number of years, don't know the size of their team, and the apps still feel quite unnatural to try to use on both Android and the web. [06:40:22.0187] > <@domenicdenicola:matrix.org> My hypothesis is that the gap comes mainly in a good control library, and having stuck my foot in that area for a half-year and failed with a small team of Googlers, it comes back to my earlier point that you basically need major institutional buy-in (e.g. a large team working for 5-10 years) to get to the same level that Windows/macOS/Android/iOS have gotten to. Yes — and the companies that are financially in the position to put that kind of investment in making it happen may not have great incentives for doing so [06:43:40.0695] But part of what’s implicit in the design sketch as Hixie wrote it up is that the primitives would not all need to be implemented at once anyway [06:44:37.0377] We could start with just the “ABI to spawn a JavaScript environment” piece [06:44:45.0886] The primitives are all already there; the only novel thing in Hixie's writeup is the new MIME type handler to remove the need for a one-line HTML document. (And, I guess, the magic world where we get Safari/Firefox to implement WebHID.) [06:45:18.0940] The document is basically "what if Flutter apps could save one line of code?" [06:49:31.0254] my understanding of implementation costs could be naïve, but it seems to me there is in fact a non-insignificant real cost to currently needing the HTML and JS “glue code” for WASM apps to run, and to needing to parse and load that [06:49:43.0866] Cost to who? [06:51:12.0129] I meant, cost to browser implementors relative to a new code path that didn’t require it [06:52:08.0167] Nah, no cost. If you have a JS escape hatch/bridge of the type Hixie's doc talks about, then the JS -> wasm step is free from that. And the HTML -> JS step has been implemented for ~20 years. [06:52:44.0561] I see [06:53:21.0308] Building something that was straight wasm would be more costly, as you'd have to figure out what kind of document that produces (presuming you don't want it to just auto-generate like .pdf generates ; I feel like the latter would violate the spirit of the thing) [06:53:57.0849] (And you need a "document" in at least some broad sense, so that you have some idea of what the back/forward button does, and what other windows see when they reach into yours.) [06:56:55.0080] would it absolutely have to create a document at all? could it instead be done without even instantiating a document at all but instead having a new kind of object that the browser operates directly? [06:57:03.0139] * would it absolutely have to create a document at all? could it instead be done without even instantiating a document at all but instead having a new kind of object that the browser operates directly? [06:57:20.0303] ah, I see you answered that already [06:57:55.0218] so Hixie responded somewhat to that already, in his Twitter thread, I think [06:58:03.0955] /me looks [06:59:43.0639] Yeah I mean it's conceivable you could invent something new, and have some sort of Document-like facade when other parts of the browser or other websites look at it, but it's unclear what the gain is; especially if the point was to reduce implementation complexity, I am quite sure that sort of thing would not reduce it. [06:59:54.0099] > <@domenicdenicola:matrix.org> Saying "you have WebGPU, raw HID events, and some ARIA thing---community, please build a good control library!" seems like a recipe for disaster to me. very much agree here. [07:00:33.0600] it would very quickly be "you have WebGPU, raw HID events, some ARIA thing and flutter"... [07:08:02.0722] A more interesting question to me is not why developers aren't using the web as much for these app-like experiences, but why the web is not used even for document experiences. For example, why isn't the web the dominant way that readers read ebooks? Why isn't it the dominant way that publishers publish ebooks? [07:08:52.0726] Lack of integration with stores is part of it, but that can't be the only thing or public domain books would be read on the web, and I don't believe that they are. [07:13:10.0492] I agree it's useful to look at other stuff there too, but I also think anyone looking for a *the* technical why on any of these is trying to force simplcity where it doesn't exist like that in practice. There are tons of reasons and often they aren't even techinically good or necessarily logical. [07:17:13.0460] The ebooks question is quite interesting as a smaller test case of the app question. I like that; I hadn't thought about it much before. [07:18:28.0763] Possible answers: the web is bad for commercial distribution; HTML subsetting allowing a wider tooling/device ecosystem; the technical lack of packaging format makes parts of the pipeline awkward [07:21:22.0672] Why people use 'native apps' is many things. It's a combination of the fact that the app stores tell us we should and the app store is by the same people who make the OS, and sometimes the device too so as customers people say "seems legit". It's the fact that sometimes people _like_ the app store... If you're looking for a thing you open over and over again it's very handy - you _think_ of it as an app and you don't want to search the web for that... You want maybe somewhere where you can see how many other people got it and read some reviews and comparisons -- a lot like why you would use a brick and mortar store... You have some sense that you can learn somethign about the quality. In practice I think that is mostly bunk - we need to do better than what we do, but yeah, same reason people like amazon reviews/purchase data, etc. You can't get that easily today with the web. But also then we built this whole movement where businesses which would do great with a PWA and who could build the great UX, etc still think they gotta build the native thing and use their site to push you to it, which again makes users think "oh, I guess that's better"... Basically that is a self-fulfilling prophecy even if all other things were equal (I think they aren't, but still) [07:21:34.0225] * Why people use 'native apps' is many things. It's a combination of the fact that the app stores tell us we should and the app store is by the same people who make the OS, and sometimes the device too so as customers people say "seems legit". It's the fact that sometimes people _like_ the app store... If you're looking for a thing you open over and over again it's very handy - you _think_ of it as an app and you don't want to search the web for that... You want maybe somewhere where you can see how many other people got it and read some reviews and comparisons -- a lot like why you would use a brick and mortar store... You have some sense that you can learn somethign about the quality. In practice I think that is mostly bunk - we need to do better than what we do, but yeah, same reason people like amazon reviews/purchase data, etc. You can't get that easily today with the web. But also then we built this whole movement where businesses which would do great with a PWA and who could build the great UX, etc still think they gotta build the native thing and use their site to push you to it, which again makes users think "oh, I guess that's better"... Basically that is a self-fulfilling prophecy even if all other things were equal (I think they aren't, but still) [07:21:35.0210] Public domain books do exist on the web, e.g. Project Gutenberg, https://standardebooks.org/, things like the Rust book etc. But the online reading experience is not great for those in my experience. E.g. my bookmarks get lost among a sea of other bookmarks; reliance on scroll position instead of pagination [07:22:44.0107] (And of course, no Kindle integration) [07:23:22.0326] > <@domenicdenicola:matrix.org> Public domain books do exist on the web, e.g. Project Gutenberg, https://standardebooks.org/, things like the Rust book etc. But the online reading experience is not great for those in my experience. E.g. my bookmarks get lost among a sea of other bookmarks; reliance on scroll position instead of pagination I think for a brief moment edge had a built in ebook reader [07:26:38.0154] ebooks are differently complex than apps in a way because standards have changed and moved venues and probably they tried to solve a lot of problems before we had critical things in place. It would be really great to make that wonderful at last [07:26:56.0803] now they can at least all display math :) [07:27:48.0870] Can they, though. Publishers still tend to use pixelated pngs for math in the eBooks I've seen. [07:28:25.0942] now i kind of want to build some ebook web components. [07:30:29.0045] Building an ereader in HTML/JS shouldn't be that difficult, I can't think of any technical limitations that prevent it. I think things like Project Gutenberg don't have great web ereaders because not enough of their users use it, to make it worth their while [07:30:31.0546] > <@domenicdenicola:matrix.org> Can they, though. Publishers still tend to use pixelated pngs for math in the eBooks I've seen. where do you read your eboooks? [07:30:59.0519] Kindle [07:31:00.0163] (can was referring to browsers can, sorry) [07:31:08.0707] kindle has their own rendering engine for that [07:32:13.0859] Yeah I meant it's more of a publisher pipeline thing, presumably [07:32:21.0224] yeah [07:33:28.0092] also another (I think) critical thing is the next gen rendering engine reworks in theory enable a lot of that stuff to actually be practical -- like pagination, etc... previously kind of very shoehorned, but we have good fragmentation design etc now [07:33:54.0262] so like, the web today would be a real nice basis IMO for all this [07:36:24.0560] * so like, the web today would be a much nicer basis IMO for all this if we were coming at it fresh today [08:37:55.0131] "shouldn't be" means ideally or today? The guttenberg thing is very chicken and egg. I have only read a few books digitally and all but one has been public domain. I just like physical books 🤷 in fact, I like physical book _stores_ still, and libraries :) Even as a lover of the web, any kind of digital is still just not my ideal choice for most of my actual _book_ reading. [08:38:00.0221] > <@matthewcp:matrix.org> Building an ereader in HTML/JS shouldn't be that difficult, I can't think of any technical limitations that prevent it. I think things like Project Gutenberg don't have great web ereaders because not enough of their users use it, to make it worth their while * "shouldn't be" means ideally or today? The guttenberg thing is very chicken and egg. I have only read a few books digitally and all but one has been public domain. I just like physical books 🤷 in fact, I like physical book _stores_ still, and libraries :) Even as a lover of the web, any kind of digital is still just not my ideal choice for most of my actual _book_ reading. [08:39:52.0291] I think if you were solving this problem today you would probably not come up with .epub [11:14:20.0911] As an avid ebook user, I believe the ebook "issue" is almost entirely (1) payment/drm, and (2) pagination. For the latter, it just turns out that pagination is *usually* a bad UI pattern on the web and scrolling is better; books are one of the rare places where the opposite is true. [11:15:28.0877] Related: *good* book rendering involves some algorithms that have bad worst-case runtime complexity but are perfectly fine for rendering things like book pages. [11:15:46.0563] I will agree those are a very big part :) [11:16:13.0242] So once you're inventing pagination yourself, doing *the rest* of book rendering is actually quite simple and avoids most of the problems with replacing the web (no need for a bunch of input controls, complex layouts, etc) [11:17:17.0188] So the cost of doing it all natively, vs wrangling the web into doing it when you're trying to tweak things at a level below the primitives it naturally exposes, just leans pretty heavily towards native, and that's not unreasoanble. [11:18:25.0323] I'd certainly *like* good book rendering on the web, like we could just iframe an epub and it would Just Work, but it would be a pretty large effort with very questionable return on value. [11:19:27.0875] why would you need to iframe it? [11:19:59.0714] I mean, loading up a `http://example.com/book.epub` would work just as well, sure [11:20:11.0371] but assuming you were rendering a reader site around it [11:20:21.0387] right. I think that used to work in ms briefly [11:21:15.0181] maybe not well - idk I never used it... I just think I remember someone, maybe rossen showing me some talks [11:30:03.0603] I'm always surprised that folks think UAs would produce an excellent epub reader, given how bad things like HTML date inputs were (and continue to be, depending on UA) for years [11:46:29.0709] kinda curious how those are related - I definitely think what Matthew Phillips is saying is that books are documents about text, you know the thing the web is supposed to be great at. Date pickers, are mostly used in stuff that is more of a stretch for that model [12:02:21.0728] Yeah, I'm not seeing the connection. Several browsers rendered some form controls in a relatively shitty manner (tho I've seen *worse* in userland; rarely, but still), but that doesn't seem to have any bearing on how everything else is rendered. [14:19:38.0496] fwiw, i think the "but then you'd have a million frameworks all reinventing text editing" argument doesn't match reality. we've run the experiment. there aren't a million frameworks on android, there's a half dozen real ones and maybe a dozen more small ones. on the other hand the web has literally thousands and more pop up every year. they don't reinvent text editing, instead they reinvent other things, but they still exist, in a way that just doesn't happen on other platforms. i'm not sure i 100% understand why, but i think it's curious nonetheless. also, "save flutter one line of code" is exactly what this proposal is, yes. i mean, it's more like "one stub file" than "one line of code", but it's basically the same thing. the idea is for the web to recognize it's in 2023 not 1991, so that when you boot a web app it doesn't have to first get you from real mode to protected mode and then from protected mode to long x64 mode (or rather, from 1991 CERN document mode to 1997 DOM mode to 2020 Wasm mode to 2023 WasmGC mode etc). everything this proposal suggests is already possible, the proposal is just to clean up the technical debt around it. [14:22:29.0713] there's shades of the 2004 w3c apps & compound documents meeting in this, where mozilla and apple (and microsoft and sun!) were telling the w3c they can either get on the train or be left at the station, except this time the train is wasm&webgpu :-) [14:43:54.0679] > <@hixie:matrix.org> there's shades of the 2004 w3c apps & compound documents meeting in this, where mozilla and apple (and microsoft and sun!) were telling the w3c they can either get on the train or be left at the station, except this time the train is wasm&webgpu :-) this is exactly what I was getting at/referencing above in https://matrix.to/#/!AGetWbsMpFPdSgUrbs:matrix.org/$iRXTwv9IAQjoP_M8ri_OoA0RIJlMYqvDPXnausitzK4?via=matrix.org&via=mozilla.org&via=igalia.com [15:06:24.0000] we are saying completely different things about how it is related to 2004 I think though :) [15:23:31.0599] * we are saying completely different things about how we interpreted its relationship to 2004 I think though :) [15:26:13.0324] WPF would have been amazing, i'm still surprised microsoft didn't succeed at that [15:26:35.0388] it only really lacked two things, a security model and vendor-neutrality [15:27:00.0202] this is our opportunity to finally get there 20 years later though [15:27:17.0099] if you squint at your proposal the right way does it resemble flash a little? [15:27:25.0937] it resembles flash a lot [15:27:51.0782] flash was a huge boon for the web, with a few fatal flaws, the prime of which was again, lack of vendor-neutrality [15:28:08.0513] ok 😆 I was afraid to say that because I didn't want to insult you or something, but it is what I was saying too [15:28:10.0764] it's kind of amazing that nothing ever really took its place [15:28:20.0876] SVG i guess sort of did [15:28:35.0895] but not like back then [15:28:35.0952] this thing called html 5 came along and told it to stop [15:28:37.0366] :) [15:28:49.0839] well, html5 was sort of orthogonal to what flash did [15:29:00.0423] html5 was more about stopping xforms [15:29:23.0651] that might have been the intent [15:29:37.0218] i think apple had more of a hand in killing flash than html5 [15:29:47.0326] but we also got canvas and animations and all kinds of things that made flash less necessary [15:30:08.0398] somewhat. but those animations that flash made? we never really got them back. [15:30:21.0584] youtube provides the non-interactive version i guess [15:30:23.0731] svg coming :) [15:30:34.0111] if svg was going to do it, it would have done it already [15:31:18.0535] anyway, i think wasm+webgpu is going to enable a whole category of things that we've been lacking every since flash and wpf died [15:31:28.0699] (whether or not we do the thing i proposed) [15:31:42.0916] we see it already in the kinds of apps people are making with flutter on web [15:31:44.0552] like Rive [15:31:58.0010] youtube is interesting I was saying the other day how i wanted to write a post called Howard the Doc about this idea that how you think about what it is you're doing is hard and you always have to kind of squint at it. A doc is one model, but like, flash's was a movie. Hypercards was a stack. [15:32:26.0022] * youtube is interesting I was saying the other day how i wanted to write a post called Howard the Doc about this idea that how you think about what it is you're doing is hard and you always have to kind of squint at it. A doc is one model, but like, flash's was a movie. Hypercards was a stack. [15:33:16.0461] none of those are apps, but what is an app? When you look at the UI history the web and native clearly cross pollenate one another with ideas on how the model should be [15:34:05.0362] > <@hixie:matrix.org> like Rive LInk? I'm unfamiiliar it seems hard to google [15:34:41.0986] > <@hixie:matrix.org> anyway, i think wasm+webgpu is going to enable a whole category of things that we've been lacking every since flash and wpf died what about webxr? you see any relationship here? [15:38:29.0772] rive.app, it's the first google result for "rive" [15:38:46.0523] not familiar with webxr 2023-02-03 [17:00:28.0884] Ah apparently i was searching with... Not Google 😊 [17:08:41.0670] for users and developers, we definitely have regressed from what could be done easily with Flash [17:09:58.0741] …for that class of web content that was being produced with Flash — that timeline-based experience [17:11:14.0539] which is admittedly only a subset, and different from a full “app” experience the way that mobile apps provide [17:11:37.0281] but the web losing Flash was not a win for end users and developers [17:12:33.0175] Flash enabled a lot of people to develop content without needing to be “coders” — the tooling made it easy for them to create content [17:13:16.0617] and they did it on scale, and users on scale liked the experience it provided [17:16:04.0567] And it had ubiquity all the way up until the first iPhone came out — on which even Safari was just barely even usable running on the iPhone on its own. And so it just literally wasn’t feasible to have the Flash runtime also running on top of the browser runtime in Safari on the first iPhones [17:16:30.0764] And so Flash lost the key property of ubiquity it’d had until then [17:17:02.0168] * And it had ubiquity all the way up until the first iPhone came out — on which even Safari was just barely even usable running on the iPhone on its own. And so it just literally wasn’t feasible to have the Flash runtime also running on top of the browser runtime in Safari on the first iPhones [17:55:13.0219] I’ve been thinking back to 2004–2005 when Flickr and other such sites first launched, and I was still working at Openwave and we had a mobile browser [17:55:33.0768] * I’ve been thinking back to 2004–2005 when Flickr and other such sites first launched, and I was still working at Openwave and we had a mobile browser [17:57:36.0929] once I learned that XHR was what those sites were using to make the user experience they gave, I remember talking with people on the browser team and saying to them, Well, clearly now we really need to enable XHR in our browser [17:58:08.0558] But there response at the time was, No, we really don’t, because what we have now is working [17:59:49.0663] And they were provably right when they said that, because our browser (EZWeb browser) was shipping preinstalled on literally millions of browsers in Japan, and that browser was solving problems for literally millions of people in Japan who were using it every day to do all kinds of things [18:00:22.0970] And we were making great money from it all [18:00:48.0199] But my feeling was still, we can do better than this [18:02:53.0779] The browser was well designed, and worked with content written in XHTML and CSS, not just WML — and it even had scripting. But it wasn’t JavaScript — it was WMLScript instead [18:06:03.0146] And I remember people from the browser team patiently telling me that, with just our current stack, we could actually enable developers to create richer user experiences of the kind that were coming out in sites then, in 2004 and 2005 — that it in part, just needed developers to start doing some things differently and better (and providers buying more of our server products) [18:07:46.0718] And then into our market came the full Opera browser shipping preinstalled on just one phone, labeled as “PC Site Viewer” — and users in Japan could then, on their mobile phones, access real full web content, from real web sites [18:09:08.0339] with some XHR support in the browser [18:09:55.0336] but for us at Openwave, enabling XHR meant adding support to JavaScript, switching from WMLScript to JavaScript [18:12:04.0201] but the company just did not at all have the economic incentives to invest in doing that — we already had the customers shipping our browser on millions of devices, we had a huge number of developers creating content that worked well in it already, and we had millions of users already using it [18:13:07.0350] and the browser PMs and engineers just saw no good strong need for it [18:13:47.0305] …and that’s when I left and went to work at Opera [18:16:41.0700] among the great things at Opera was that among the engineering team and QA team the default attitude really was “we can do better than this”, and they were wiling to try out some risky, nutty, unproven ideas — and the company management then really supported that (all the way up to Jon von Tetzchner and Haakon, especially) [18:20:30.0342] * but for us at Openwave, enabling XHR meant adding support for JavaScript to the browser, switching from WMLScript to JavaScript [10:30:28.0205] Is there a canonical way to go from a Navigator to the environment settings object that contains it? [10:44:18.0065] I guess I want relevant settings object [10:59:37.0671] > <@tabatkins:matrix.org> So the cost of doing it all natively, vs wrangling the web into doing it when you're trying to tweak things at a level below the primitives it naturally exposes, just leans pretty heavily towards native, and that's not unreasoanble. I don't think I understand this point. Are you saying that not having built in pagination elements / primitives / whatever is enough of a reason to go native? Not debating just trying to understand the point. [11:00:28.0550] I'm saying that the cost of reproducing those, compared with the cost of losing the rest of the web platform, tilts the economics pretty decently toward "do it yourself in native code" [11:00:45.0871] You just don't need much of the web platform in an ereader [11:01:14.0461] But you do need pagination and better text layout, which the web platform doesn't provide and doesn't give you the primitives to reasonably do yourself. [11:01:36.0809] No, but building a full ereader from scratch in native is more complicated than building a pagination widget in JS, no? [11:01:51.0517] * No, but building a full ereader from scratch in native is more complicated than building a pagination widget, no? [11:02:05.0395] * No, but building a full ereader from scratch in native is more complicated than building a pagination widget in JS, no? [11:02:27.0449] That one bit, yes. There's more that you end up needing to reinvent. [11:03:10.0217] Other things I mentioned above: drm (and its precursor, dependable local storage) [11:04:35.0588] Ok, so things that are possibly fixable. [11:04:52.0646] Everything's potentially fixable, yeah [11:05:26.0006] But small things in comparison to the "reinvent the web on wasm" idea :) [11:05:34.0077] It's just that several of them aren't high-prio (or even perhaps medium prio) for web content as it exists today, so making the argument for working on it (specs and impls) isn't easy. [11:05:55.0334] Different people are reinventing the stuff in that case, with different incentives. ^_^ [11:08:18.0316] The upside here is potentially huge though. Inventing an ereader in native is a lot of work. So much so that only a few companies have ever even tried. The web is close here. And the upside would be that publishers could avoid the Amazon tax. [11:09:33.0459] So what is it about payment? Is it just the friction (which presumably web payments removes) or is it something else? [11:10:07.0478] Payment's gotten a lot better in the last few years! It was still pretty bad even five years ago. [11:10:41.0019] Tho the app stores getting more aggressive with their cuts make the friction argument less and less relevant to the bottom line. [11:11:23.0191] Like, the Nook app on Android no longer lets you buy books in it (because they'd have to give 30% of the price to Google). All you can do is wishlist, then they'll link you to the b&n website to actually buy it. [11:11:57.0571] Does Google take the same cut from web payments? [11:13:00.0532] Surely not; the CC processers would scream bloody murder and they're a powerful mafia. [11:13:14.0145] But I don't know the details. [11:13:15.0171] Comixology (Amazon company) had to do the same thing in their Android app. It makes the experience really bad. Feels like an opportunity for the web. [11:14:23.0734] ok, that makes sense, i was thinking that web payments had the same UI overlay as native but that doesn't mean that google is taking a cut [11:20:29.0574] So if we were doing a list: - Payments: fixed? - Pagination: some nice web components could pave the way for builtins later. - DRM: What is this? preventing Save Page As? - Better text layout: What is this one? What's wrong with text on the web? [13:57:23.0309] DRM: Remove 2023-02-04 [18:56:16.0469] Pagination: there are plenty of ways to simulate pagination in web components, but since we do not provide useful primitives for this they all rely on breaking apart and re-assembling markup elements which is a hard and expensive thing to do [18:58:22.0095] Better text layout: The main missing thing (at least for English text) is better line breaking. If you consider more than one line of text at a time, you can come up with better line breaks over an entire paragraph. All browsers only consider one line at a time at the moment. [06:54:12.0136] I would not call payments near fixed, at the moment. The web is stuck in a very inadequate equilibrium there and I suspect no single actor could move it. (E.g., even if all browsers wanted to move, payment processors / merchants might not.) But I guess if books are already shelling out to the web, at least a web-based reader would not be worse. 2023-02-06 [01:13:24.0056] hsivonen: have you made up your mind on how to deal with the gb18030 update? Or maybe Adam Rice looked into it? [01:44:57.0725] > <@annevk:matrix.org> hsivonen: have you made up your mind on how to deal with the gb18030 update? Or maybe Adam Rice looked into it? It's unclear to me to if the upstream standard change is driven by practical improvement or by theory. At least I'm not advocating in favor of a browser change at this time. [01:45:27.0377] Or are we talking about a different gb18030 update? [01:53:26.0665] hsivonen: nah that one; https://www.unicode.org/L2/L2023/23003r-gb18030-recommendations.pdf was also brought to my attention [02:34:37.0894] > <@annevk:matrix.org> hsivonen: nah that one; https://www.unicode.org/L2/L2023/23003r-gb18030-recommendations.pdf was also brought to my attention Interesting. I guess a reasonable position for the Encoding Standard is to wait and see what reaction (if any) that letter gets. [03:08:12.0217] Andreu Botella: Luca Casonato: will either of you update https://github.com/whatwg/fetch/pull/1346? [03:10:18.0956] I'm also happy to do some work if that would be easier. I think there's enough agreement to merge this and give it a go. [03:53:42.0338] > <@annevk:matrix.org> Andreu Botella: Luca Casonato: will either of you update https://github.com/whatwg/fetch/pull/1346? I would update it if I had write permissions for fetch [03:57:40.0024] or if Luca gave me write access to his branch [04:00:35.0846] Andreu Botella: I gave you write access [04:00:43.0540] thanks [04:08:18.0920] Is there a place I'm missing where UI events create a task on the event loop? Seems like they don't and we rely on "SHOULD"-style somewhat implementation-specific behavior, but I wanted to make sure [04:17:34.0736] Noam Rosenthal: the sequence of events should be that there's user input, which results in some computation and a task consisting of a set of steps, and those steps then end up dispatching the event [04:17:50.0148] Noam Rosenthal: you're correct that UI events has been hand-wavy about this since say forever [04:18:15.0610] Noam Rosenthal: there are some issues and depending on where you look you might find me complaining about it [04:24:41.0496] annevk: gotcha, thanks for the context. [06:59:32.0259] Ms2ger: What use case is this test ensuring proper support for? https://github.com/tc39/test262/issues/1696 That is, are you aware of a use case where it's actually useful to load a search collation into the sorting-oriented API? I'm seriously considering sending an Intent to unship: Search collations. (Due to making libxul larger with no reasonable use case that I can see given the API surface available.) [07:01:05.0251] (My question at https://github.com/tc39/ecma402/issues/256#issuecomment-979760435 has remained unanswered for over a year.) [10:23:48.0361] > <@hsivonen:mozilla.org> Ms2ger: What use case is this test ensuring proper support for? https://github.com/tc39/test262/issues/1696 That is, are you aware of a use case where it's actually useful to load a search collation into the sorting-oriented API? I'm seriously considering sending an Intent to unship: Search collations. (Due to making libxul larger with no reasonable use case that I can see given the API surface available.) This sounds like something to raise to TC39-TG2, the ECMA-402 committee, to see if people are still interested. It's been part of Intl since the beginning. [10:24:11.0791] e.g., in one of their calls [10:25:37.0860] I raised this in #tc39-ecma402:matrix.org [13:22:31.0223] > <@matthewcp:matrix.org> So if we were doing a list: > > - Payments: fixed? > - Pagination: some nice web components could pave the way for builtins later. > - DRM: What is this? preventing Save Page As? > - Better text layout: What is this one? What's wrong with text on the web? Re: the DRM part, I mean a way to serve purchased books that doesn't trivially allow the user to just save the file and email it to someone else. (I feel very strongly that DRM is fundamentally immoral, but it's absolutely a business requirement in this case.) [13:23:47.0533] For example, if I buy a book from B&N for my Nook, by default it's in a proprietary format that's locked to my account. Luckily the DRM is easy to strip off to obtain the epub inside the container, so I can archive my book collection, but aiui the process is somewhat more difficult for Kindle books. 2023-02-07 [01:02:06.0251] > <@littledan:matrix.org> I raised this in #tc39-ecma402:matrix.org Thanks. It doesn't look particularly indicative of strong use cases existing that there isn't already a use case given on the channel while two collator implementors (Markus Scherer and I) on GitHub are saying that the sorting API isn't suitable for searching. [01:25:16.0631] > <@hsivonen:mozilla.org> Thanks. It doesn't look particularly indicative of strong use cases existing that there isn't already a use case given on the channel while two collator implementors (Markus Scherer and I) on GitHub are saying that the sorting API isn't suitable for searching. I have no opinion about the contents of this, but would you be interested in joining one of ECMA-402’s fortnightly calls to discuss with people who might? It would be nice to make a cross-browser decision about unshipping. [01:41:07.0489] > <@littledan:matrix.org> I have no opinion about the contents of this, but would you be interested in joining one of ECMA-402’s fortnightly calls to discuss with people who might? It would be nice to make a cross-browser decision about unshipping. When is the call scheduled? [02:40:10.0676] > <@hsivonen:mozilla.org> When is the call scheduled? I have a monthly call on my calendar which is next Thursday (the 9th) at 10:00-12:30 Pacific [03:14:05.0452] > <@hsivonen:mozilla.org> Ms2ger: What use case is this test ensuring proper support for? https://github.com/tc39/test262/issues/1696 That is, are you aware of a use case where it's actually useful to load a search collation into the sorting-oriented API? I'm seriously considering sending an Intent to unship: Search collations. (Due to making libxul larger with no reasonable use case that I can see given the API surface available.) And to answer your question: I don't recall [05:57:20.0387] > <@ms2ger:igalia.com> I have a monthly call on my calendar which is next Thursday (the 9th) at 10:00-12:30 Pacific Thanks. [05:58:49.0229] > <@ms2ger:igalia.com> And to answer your question: I don't recall OK. I remain unaware of a use case, then. [07:02:29.0144] TabAtkins: is https://twitter.com/tabatkins/status/1622642301163175937 another base 6 ploy? 😂 [07:06:48.0886] Actually no! My base 6 ploy for time is at https://www.xanthir.com/hex/clock/ [13:11:46.0056] Hello, We just released the first version of Ada, a spec compliant url parser, which is also the successor of Node.js's URL parser. https://github.com/ada-url/ada/releases/tag/v1.0.0 2023-02-08 [00:22:34.0252] > <@yagiznizipli:matrix.org> Hello, We just released the first version of Ada, a spec compliant url parser, which is also the successor of Node.js's URL parser. https://github.com/ada-url/ada/releases/tag/v1.0.0 Very cool! Looking forward to you upstreaming the additional tests I see you all have been working on. [01:37:32.0998] huh, I show up twice as a co-author in https://github.com/web-platform-tests/wpt/commit/14151646ae4684a32638d73187381fc0ed86e2c8 [01:38:18.0834] * huh, I show up twice as a co-author in https://github.com/web-platform-tests/wpt/commit/14151646ae4684a32638d73187381fc0ed86e2c8 [01:45:39.0958] Andreu Botella: you were listed twice with separate email addresses and I didn't want to presume so I kept both [01:46:49.0218] Also, congrats to you and Luca Casonato for getting that feature done. I'm personally quite happy Headers now has full HTTP parity [01:47:07.0298] thanks! 🎉 [01:47:48.0884] I still have the task of convincing the TAG and the Chromium API owners that it's a good idea though 😅 [01:50:20.0068] about that, I kept my personal email as the github default, since not everything open-source I do is related to Igalia, but that causes trouble when committing suggestions [01:50:29.0832] > <@annevk:matrix.org> Andreu Botella: you were listed twice with separate email addresses and I didn't want to presume so I kept both * about that, I kept my personal email as the github default, since not everything open-source I do is related to Igalia, but that causes trouble when committing suggestions [01:52:17.0531] thanks annevk! happy that this is landed now :) [03:08:06.0490] A C++ implementation of the URL standard called Ada? Maybe next we can have a Java implementation called Rust? ;p [05:02:37.0898] I guess we may or may not have all the Twitter bots breaking on us: https://twitter.com/TwitterDev/status/1621026986784337922 vs https://twitter.com/elonmusk/status/1622082025166442505 [05:31:22.0761] I've just published a post about what a good CORS middleware library should look like. Feedback welcome! https://jub0bs.com/posts/2023-02-08-fearless-cors [05:34:47.0762] It's quite long, but I've broken it down into 12 principles, so you can dip in and out 😇 [05:55:42.0601] > <@jgraham_:matrix.org> A C++ implementation of the URL standard called Ada? Maybe next we can have a Java implementation called Rust? ;p :) The project is a gift to my first soon-to-be born child, who will be named Ada [05:56:14.0560] Ada also means "island" in Turkish [06:00:32.0146] I'm just gonna assume the vCard way to specify Mastodon is `X-SOCIALPROFILE;type=mastodon:[URL]` which is near identical to what I have for Twitter, but if that can be improved let me know [06:00:58.0784] * I'm just gonna assume the vCard way to specify Mastodon is `X-SOCIALPROFILE;type=mastodon:[URL]` which is near identical to what I have for Twitter, but if that can be improved let me know [06:03:15.0723] Yagiz Nizipli: Congratulations in advance on the child :) [06:13:50.0179] johannhof: could you please fix the URL Standard build error as I believe you said you would? If you're otherwise occupied I can take care of it though [06:19:12.0241] annevk: ah, thanks for reminding me. I can take care of it, but need a few mins to get back to a computer :) [06:19:37.0024] /me is reminded of Chris Pine [06:27:58.0520] I C what you did there [06:29:59.0473] We're looking to implement domain to ascii algorithm of URL spec to drop the ICU requirement of Ada. It's an ongoing process at https://github.com/ada-url/idna. Is there an example implementation other than ICU for it? [06:30:40.0149] * It's quite long, but I've broken it down into 12 principles, so you can dip in and out 😇 Thanks to sideshowbarker, who kindly agreed to review an early draft of the post 🙏 [07:02:18.0352] hsivonen: I vaguely recall you looking into the above? [07:03:01.0309] Yagiz Nizipli: there's also https://github.com/mathiasbynens/punycode.js though be mindful of https://github.com/jsdom/whatwg-url/issues/239 [07:22:37.0732] Yagiz Nizipli: it might make sense to list Ada in https://github.com/whatwg/spec-factory/blob/main/factory.json and https://github.com/whatwg/meta/blob/main/MAINTAINERS.md; at some point we probably need a better system for that, but I don't think we hit the breaking point yet [07:36:15.0982] annevk: Yes, Ada is merged into Node.js. I think we should add Ada. We have a Github workflow for keeping our tests in sync with WPT - https://github.com/ada-url/ada/blob/main/.github/workflows/wpt-updater.yml. Might be a good idea to recommend such approach to all implementers, in order to reduce the non-automated part of compliance. [07:36:24.0511] * annevk: Yes, Ada is merged into Node.js. I think we should add Ada. We have a Github workflow for keeping our tests in sync with WPT - https://github.com/ada-url/ada/blob/main/.github/workflows/wpt-updater.yml. Might be a good idea to recommend such approach to all implementers, in order to reduce the non-automated part of compliance. [07:42:35.0090] Yagiz Nizipli: I see, I guess in that case for URL we may no longer need to ping Node.js directly? It would be good to keep it to one of the projects in any case [07:47:10.0706] annevk: I'd still recommend keeping Node.js in the loop. There are some folks who might be interested & informed about the changes. If other runtimes will adopt Ada, we might drop them and just keep Ada for creating issues. [07:48:18.0447] annevk: Due to the missing tests on WPT, Ada can't test every change directly, simply because we don't have a JS layer to test it on. If this wasn't the case, it would be a lot easier to maintain and the need to inform Node.js would significantly decrease. [07:52:40.0414] Yagiz Nizipli: to be clear, you cannot modify the template on whatwg/url directly, you'll have to modify the files I linked above [12:54:53.0552] annevk Yagiz Nizipli : https://github.com/unicode-org/icu4x/issues/2850 is on my mental todo list, but haven't gotten further than writing down what I've written down in that issue. 2023-02-09 [00:27:26.0417] hsivonen: nice, note that Validity Criteria might change if they accept my upcoming CheckBidi feedback (CheckBidi would move to Processing) [00:54:33.0064] > <@yagiznizipli:matrix.org> We're looking to implement domain to ascii algorithm of URL spec to drop the ICU requirement of Ada. It's an ongoing process at https://github.com/ada-url/idna. Is there an example implementation other than ICU for it? There is a Rust implementation that does not rely on ICU [00:56:20.0328] https://github.com/servo/rust-url/tree/master/idna [07:46:21.0119] Could I join the WinterCG triage call today (for the ShadowRealms topic)? [08:02:15.0517] littledan: I'm guessing you mean HTML, I can DM you the link [08:03:35.0887] * Could I join the HTML triage call today (for the ShadowRealms topic)? [08:03:49.0815] oops yes please! [08:03:55.0960] thank you [08:06:00.0355] To be clear, as far as I know Domenic is out so we might have to defer [08:28:02.0349] If you help with issue triage and miss labels, please add suggestions to https://github.com/whatwg/meta/issues/270 [08:28:57.0177] > <@lucacasonato:matrix.org> There is a Rust implementation that does not rely on ICU Thanks! [09:03:40.0464] Does CORB live in any spec today? [09:04:10.0540] https://www.chromium.org/Home/chromium-security/corb-for-developers/ links to https://fetch.spec.whatwg.org/#corb which DNE [09:04:26.0870] and I know ORB is currently stuck in a Fetch PR [09:06:39.0258] Question: Is there a publicly known benchmark suite across URL parsers? I'm searching for research done within this area. [09:40:56.0686] Dominic Farolino: it was removed due to there being only a single impl [09:41:06.0290] * Dominic Farolino: it was removed due to there being only a single impl [09:41:18.0572] Yagiz Nizipli: not aware [13:24:17.0190] Has there ever been a discussion about requiring JPEG, PNG, or GIF support in visual browsers? I was going down a