| 02:16 | <rektide> | can someone please merge @domenic's https://github.com/whatwg/loader/tree/impl-status tree (one commit) |
| 02:17 | <rektide> | i kind of keep spazzing out thinking module-loader has seen zero progress since June & everyone is doing nothing, and some linkage to https://github.com/tc39/proposal-dynamic-import would help de-consternate the world on this particular point |
| 02:18 | <rektide> | specifically there is https://github.com/whatwg/loader/pull/152 for the pR |
| 02:32 | <Domenic> | XhmikosR: loading a 4 MB file in 0.6 s is pretty fast |
| 02:46 | <Domenic> | I guess it's only 1.4 MiB |
| 04:26 | <rektide> | i just filed https://github.com/whatwg/html/issues/2235 |
| 04:27 | <rektide> | would really like to see HTMLScriptElement have- when it is type="module"- properties that in some way reflect what the module exports |
| 04:27 | <rektide> | seems like a missing link between DOM<-> JS. |
| 07:27 | <XhmikosR> | Domenic: I check TTFB etc. Anyway, aparently from USA it's faster so it's just a a matter of location. Still, it could definitely be a lot faster. |
| 08:27 | <XhmikosR> | Domenic: is there any interest for this? https://github.com/whatwg/html/compare/master...XhmikosR:xmr-optimize-images Todat saves should be around 80KB |
| 08:31 | <annevk> | XhmikosR: if indeed lossless, yes! |
| 08:31 | <XhmikosR> | yeah I used zopfli too for the PNG files for another ~5% save |
| 08:32 | <annevk> | XhmikosR: we don't really have any CDN at the moment, I suppose we could look into using one at some point for faster delivery of content |
| 08:34 | <XhmikosR> | annevk: still, the server seems slow to me even from USA |
| 08:34 | <XhmikosR> | maybe it's poorely configured or something |
| 08:34 | <annevk> | XhmikosR: I guess DreamHost isn't the fastest 😟 |
| 08:34 | <annevk> | For a while HTTPS was pretty poorly configured |
| 08:34 | <XhmikosR> | I still think it's a matter of config :/ |
| 08:35 | <XhmikosR> | https://gtmetrix.com/reports/mpc-hc.org/WsZu4GXS#waterfall |
| 08:35 | <XhmikosR> | see how fast is the html load? |
| 08:35 | <XhmikosR> | I have disabled .htaccess though and that can make a big diff |
| 08:37 | <XhmikosR> | and that server is just a 3 core non SSD based on Amsterdam so nothing fancy :) |
| 08:38 | <annevk> | Our current approach to the server setup is rather hands off since nobody really wants to play sysadmin, although MikeSmith has made the occasional noise |
| 08:39 | <annevk> | So anything that would require a non-default setup on DreamHost isn't really considered |
| 08:39 | <XhmikosR> | have you thought about Cloudflare? |
| 08:40 | <XhmikosR> | personally I disagree with their SSL approach but still it's the best free CDN |
| 08:43 | <XhmikosR> | annevk: https://github.com/whatwg/html/pull/2236 |
| 08:45 | <XhmikosR> | also, I could maintain the server if you trust me ofc, since as far as I can tell only basic stuff are needed. For my servers I use Debian 8 with MPM Event and not prefork which was the old default |
| 08:48 | <annevk> | I think it's worth considering improving the setup |
| 08:49 | <annevk> | Domenic: this is another reason to setup whatwg/meta to have these kind of discussions somewhat coordinated, if you don't object I think I'll go ahead and make it later today |
| 08:51 | <XhmikosR> | Domenic: just figured out why the whitespaces are in the output html |
| 08:52 | <XhmikosR> | all except for one that is :p |
| 08:52 | <XhmikosR> | perl .pre-process-main.pl $($VERBOSE && echo "--verbose") < $HTML_SOURCE/source > $HTML_TEMP/source-expanded-1 |
| 08:52 | <XhmikosR> | it's due to the spaces before and after the redirection operators |
| 09:44 | <annevk> | hsivonen: any thoughts on https://github.com/whatwg/encoding/issues/85? |
| 09:44 | <annevk> | hsivonen: oh actually, I guess I still haven't created tests to proof that it is required |
| 11:10 | <annevk> | Testing navigation is full of surprises |
| 12:15 | <annevk> | igrigorik: let me know when you're around again, want to ask about https://github.com/whatwg/url/issues/26 |
| 12:41 | <hsivonen> | annevk: encoding_rs already supports "with BOM removal" and "without BOM handling" variants with any encoding, not just UTF-8 |
| 12:42 | <annevk> | hsivonen: why would you remove the BOM but not honor it? |
| 12:43 | <hsivonen> | annevk: the spec requires it for UTF-8 already |
| 12:43 | <hsivonen> | let's see |
| 12:43 | <hsivonen> | https://encoding.spec.whatwg.org/#utf-8-decode |
| 12:43 | <hsivonen> | so whatever external spec uses that hook requires that functionality to be there |
| 12:43 | <hsivonen> | XHR with JSON, I think is one |
| 12:44 | <annevk> | Well, but that doesn't remove a UTF-16 BOM |
| 12:44 | <hsivonen> | annevk: in encoding_rs, if you use decode_with_bom_removal with UTF-16BE/LE, it does |
| 12:45 | <hsivonen> | annevk: (no use case at present, just making all the BOM options do something instead of panicing with all encodings) |
| 12:46 | <annevk> | Mkay, I rather keep the specification algorithms limited to what is actually needed for the web |
| 12:46 | <hsivonen> | annevk: I guess I misunderstood the question about issue 85 |
| 12:59 | <JakeA> | annevk: I'm thinking of closing the "aborting a fetch" issue and starting a new one, with a summary of the story so far. Any objections? |
| 13:00 | <annevk> | JakeA: that's fine, the load time is getting out of hand |
| 13:02 | <JakeA> | annevk: heh, yeah. Part of that is down to a GitHub "bug" where it serves us an editor with every comment. Ends up being 5.2mb of HTML |
| 13:03 | <JakeA> | annevk: logged out users 'only' get 495k |
| 16:41 | <mounir> | annevk: it sounds that Notification.actions does not return a parsed URL for `icon`. Is that correct? |
| 17:35 | <annevk> | mounir: that's prolly wrong |
| 17:35 | <annevk> | mounir: should be normalized |
| 17:36 | <annevk> | mounir: that would make sense anyway |
| 18:02 | <annevk> | jgraham: I catched https://github.com/w3c/web-platform-tests/pull/4378 by chance after the fact |
| 18:02 | <annevk> | jgraham: is there some kind of plan to ping test creators? |
| 18:03 | <annevk> | rbyers: it's unclear to me what the specification motivation was for landing that |
| 18:33 | <jgraham> | annevk: No specific plan. What did you have in mind? |
| 18:55 | <annevk> | jgraham: include them as reviewer I thought |
| 18:55 | <annevk> | jgraham: I guess it might need a way to opt out though, might get tricky |
| 18:55 | <jgraham> | Oh, I see what you mean. Yeah that might be possible. |
| 18:59 | <annevk> | JakeA: https://github.com/whatwg/fetch/issues/447 is already long again |
| 18:59 | <annevk> | JakeA: guess that was to be expected |
| 18:59 | <annevk> | JakeA: so the main thing I don't want to get lost is that cancelation is not the only extension we need to add |
| 19:00 | <annevk> | JakeA: we also want something for changing priority and observing pushes |
| 19:01 | <wanderview> | I don't see why priority wouldn't just be part of the Request like cache control |
| 19:02 | <annevk> | wanderview: I mean changing priority after the fact, once the request is already transmitted |
| 19:02 | <wanderview> | annevk: what is the use case? |
| 19:02 | <wanderview> | and does anyone support that? |
| 19:02 | <annevk> | wanderview: H/2 does |
| 19:03 | <annevk> | wanderview: I've had several requests for it, don't immediately know the use case, but if it's available at a low-level it seems reasonable it might someday be exposed |
| 19:04 | <annevk> | JakeA: wanderview: progress events is another thing that sorta wants to be on an object representing the ongoing fetch |
| 19:05 | <annevk> | JakeA: wanderview: the promise object still seems like a fairly natural fit for all these |
| 19:05 | <annevk> | URL is back to a single issue page \o/ |
| 19:52 | <smaug> | what is the role of authoring rules in HTML spec? Does anyone care about them? |
| 19:59 | <gsnedders> | smaug: the cult of the validator lives on! |
| 20:27 | <tantek> | what is the role of block vs inline markup where some tags are not allowed inside other tags? |
| 20:35 | <annevk> | tantek: mostly parser limitations |
| 20:35 | <tantek> | based on bad SGML design assumptions |
| 20:37 | <zcorpan> | tantek: https://html.spec.whatwg.org/#restrictions-on-content-models-and-on-attribute-values |
| 23:30 | <smaug> | does some spec talk about out-of-memory situations? |
| 23:33 | <gsnedders> | No. It's just covered in the general "hardware limitations" clause, typically. |
| 23:33 | <gsnedders> | I think ES might touch slightly more, esp. with Typed Arrays. |