| 01:40 | <sideshowbarker> | Andreu Botella: for the CSS mirror tooling, we should update the client-side redirect handling so that it preserves the fragments. Right now, as far as I can see, it’s not preserving them — the fragments get dropped then the redirect happens. I can work on a patch for it myself, unless you beat me to it. |
| 03:38 | <sideshowbarker> | aja: ↑ I think you already know this, but just wanted to note that you have the option to persistently filter out the “Self-closing tag syntax in text/html documents is widely discouraged” warnings |
| 03:51 | <aja> | yeah...stumbled upon it. already habitually ignore those warnings anyway; thanks for reminder, though :) |
| 04:10 | <aja> | btw, seem to recall instance of an error handling inline style element's closing comment, rather than just warning. some day if it annoys me enough i'll actually file an issue :/ |
| 04:12 | <aja> | css @layer has issues last i checked, too. figured it'd get there soon enough if i have some patience :) |
| 04:14 | <sideshowbarker> | btw, seem to recall instance of an error handling inline style element's closing comment, rather than just warning. some day if it annoys me enough i'll actually file an issue :/ |
| 04:18 | <sideshowbarker> | css @layer has issues last i checked, too. figured it'd get there soon enough if i have some patience :) Yeah that’s likely just because @layer is new and the support hasn’t been added to the CSS-checking backend. I’ve never been the main maintainer of the CSS-checking backend; I worked on it quite a lot a few years ago, but it’s been a long time since I made any changes there. However, the main maintainer there is really good about adding support for things, whenever somebody raises an issue asking for something. |
| 04:22 | <sideshowbarker> | Jeremy Roman: the “data:text/html,<img name=getElementById> … document.getElementById is now an HTMLImageElement, not a function” thing is pretty cool |
| 04:23 | <sideshowbarker> | (incidentally, wish the Chromium and WebKit projects would use Matrix instead of Slack…) |
| 04:39 | <Andreu Botella> | Currently redirects are done with meta refresh, which doesn't use any JS |
| 04:40 | <Andreu Botella> | I still like the idea of making the redirects usable without JS, and you can't cancel a meta refresh from JS |
| 04:40 | <Andreu Botella> | but I guess I could have a navigation triggered from JS before the redirect can happen |
| 04:51 | <Andreu Botella> | ... though I guess if the page takes some time to load, the meta refresh might still win |
| 04:52 | <Andreu Botella> | cc Domenic |
| 05:42 | <Domenic> | ? |
| 05:47 | <Andreu Botella> | (I thought Matrix threads showed up to clients that don't support them as replies to the original or previous message, but I checked bakkot's logs and it seems like that isn't the case) |
| 05:48 | <Andreu Botella> | anyway, in a thread I was talking to sideshowbarker about changing the redirects in my CSS mirror setup to keep hashes, which doesn't currently happen because they use a meta refresh redirect |
| 05:49 | <Andreu Botella> | I don't want to get rid of the meta refresh so the redirects worked without JS, but the alternative is probably having a location.replace() navigation in JS before load |
| 05:49 | <Andreu Botella> | but the meta refresh might still win over if the page takes some time to load |
| 05:50 | <Andreu Botella> | I don't understand a lot of the depths of navigation in terms of cancelling and so on, but I was tagging Domenic to check if that could be the case |
| 05:51 | <Domenic> | I think in almost all cases the meta refresh will get canceled by the JavaScript navigation starting |
| 05:51 | <Domenic> | So the meta refresh becomes only a backup for non-JS clients |
| 05:52 | <Domenic> | The only case where the meta might win would be if a network packet boundary contained the meta and the next packet contained the JavaScript and something weird goes wrong that delays the second packet all the way until we get a response from the destination |
| 05:55 | <Andreu Botella> | the spec says that the timer for meta refresh starts on page load, so something like this should be fine, right: |
| 05:58 | <Domenic> | Hmm now I am not so sure, if it starts at page load, then maybe it will happen after the script call... |
| 05:58 | <Domenic> | Best to test and see what happens :) |
| 06:01 | <Andreu Botella> | seems to be working, but that's when testing locally |
| 06:03 | <Andreu Botella> | alternatively, I could use <noscript> |
| 06:49 | <annevk> | Domenic: shall we ask tobie if we can move webidl-grammar-post-processor to the WHATWG organization? |
| 06:50 | <annevk> | Would that break anything with npm? |
| 06:50 | <Domenic> | Wouldn't break anything. Although I wonder if perhaps it should just be in the webidl repo itself. |
| 06:51 | <Domenic> | I guess it's separate now so that pr-preview can use it more easily, but, we aren't actually using that pr-preview feature. |
| 06:54 | <annevk> | It would be kinda nice if pr-preview also ran the build script. |
| 06:56 | <Domenic> | It's much less important for Web IDL since we have inline JS that does it at runtime |
| 06:59 | <annevk> | True, I filed an issue. I don't really care which of the two options we pick, but the WHATWG org should be in charge of its "core" technologies I think |
| 06:59 | <Domenic> | Yeah seems reasonable to me |
| 07:00 | <Domenic> | annevk: want to rebase or recreate the RD PR now? It should in theory work. |
| 07:08 | <annevk> | Domenic: yeah will do |
| 07:19 | <annevk> | Domenic: it seems that ArgumentParser doesn't do the thing the Python code expects |
| 07:20 | <annevk> | With review.py -f shortnames webidl or review.py -f shortnames=webidl it ends up with either shortnames not being a directory or shortnames=webidl not being a directory |
| 07:21 | <Domenic> | It's just review.py -f webidl |
| 07:21 | <Domenic> | Named arguments for non-options |
| 07:21 | <hsivonen> | FYI regarding slash on MDN, there is now https://github.com/orgs/mdn/discussions/242 |
| 07:26 | <annevk> | Domenic: ooh |
| 07:30 | <annevk> | Domenic: should be published shortly |
| 07:55 | <Domenic> | Success https://webidl.spec.whatwg.org/review-drafts/2022-09/ |
| 08:42 | <annevk> | smaug: I know you wanted to change some things in the declarative shadow DOM algorithm to make it more efficient. Are those changes captured somewhere? |
| 09:58 | <sideshowbarker> | FYI regarding slash on MDN, there is now https://github.com/orgs/mdn/discussions/242 |
| 18:32 | <smaug> | annevk: not exactly, since it needs profiling. But the spec issue/pr (I think the HTML one) has the possible issues mentioned. Is it about creating temporary nodes or about adopting nodes to another document, or both, not sure. Or, it is of course both, but would be nice to see some performance profiles to see how much each extra step takes. I'm waiting to get the profiles from Google. |
| 23:31 | <karlcow> | More "demons slasher" |