| 00:09 | <Domenic> | cantom: so, we actually generate the dev edition from the real spec these days, so that should be OK :). https://blog.whatwg.org/developers-edition-comeback |
| 00:10 | <Yuhong> | the point is doing snapshots based on the dev edition. |
| 00:11 | <cantom> | Domenic: :D |
| 00:11 | <cantom> | Big question. Why is the slogan of WHATWG "Please leave your sense of logic at the door, thanks!" |
| 00:12 | <Domenic> | Haha. It's just an IRC channel topic, but yeah, it's about how the web is designed over a long time and has no sense of logic to it sometimes |
| 00:12 | <Domenic> | We often say "see topic" when someone complains about some old historical thing like "why is typeof document.all 'undefined'???" |
| 00:13 | <cantom> | Domenic: I've been neck deep into URL, HTTP, Unicode + charsets, MIME + multipart, HTML etc. specs and I felt the slogan might refer to that :/ |
| 00:14 | <Domenic> | lol, yep, sounds right |
| 00:15 | <Yuhong> | Which also reminds me of the title of https://whatwg.org/specs/url/2014-07-30/ |
| 00:15 | <Yuhong> | Now URL is less complex and less likely to change than the main HTML spec. |
| 00:17 | <Yuhong> | https://github.com/whatwg/url/commits had not even an editorial commit for a month. |
| 00:35 | <TabAtkins> | Domenic: No, but you can require that there's no syntax errors or unrecognized constructs when using one of the parsing entry points in Syntax. |
| 00:36 | <Domenic> | I ended up linking to https://drafts.csswg.org/css-syntax/#conform-classes |
| 00:36 | <TabAtkins> | Sure. |
| 01:09 | <Yuhong> | And government officials are actually another good reason. |
| 01:10 | <Yuhong> | It should be pretty rare that a page will not work in future browsers if it confirms to a good snapshot and works in current browsers. |
| 07:44 | <annevk> | smaug____: what's the status of https://dvcs.w3.org/hg/speech-api/raw-file/tip/webspeechapi.html? |
| 07:46 | <smaug____> | implemented in some form, but the spec hasn't got much updates as you can see |
| 07:46 | <smaug____> | there are some open bugs, I think |
| 07:47 | <smaug____> | annevk: why? |
| 07:47 | <annevk> | smaug____: mostly want [Exposed] added to the interfaces |
| 07:47 | <smaug____> | Gecko has the synthesis part, and recognition API is implemented too, but I don't know recall when it is enabled. never or only when platform has the support |
| 07:47 | <smaug____> | ah |
| 07:48 | <annevk> | smaug____: and since there's not even a GitHub repo I'm wondering where I can reliably file bugs |
| 07:48 | <smaug____> | w3 bugzilla |
| 07:48 | <annevk> | smaug____: I see, but not mentioned in the spec somehow? |
| 07:49 | <smaug____> | aha, I see it is not mentioned there |
| 07:50 | <annevk> | smaug____: I filed a bug; I guess I'll file another one about mentioning Bugzilla in the spec |
| 07:50 | <smaug____> | annevk: curious, will you attend TPAC this year? |
| 07:53 | <annevk> | smaug____: I can't, if all goes well I have a second child to take care of that's a couple weeks old by then |
| 07:53 | <smaug____> | aha. I think I had heard that but forgot. Hopefully everything goes well. |
| 07:53 | smaug____ | is wondering who from Mozilla will be there |
| 07:54 | <annevk> | smaug____: wanderview will go |
| 07:55 | <annevk> | There's a couple more people, but I don't remember all the names 😕 |
| 08:27 | <smaug____> | if it wasn't in Trumpland, I'd attend. |
| 09:02 | <jgraham> | annevk: I guess being woken up by a new baby is better than being woken up by the SFO flights passing overhead :) |
| 09:04 | <annevk> | Haha |
| 09:04 | <annevk> | That really depends on how much sleep I've had |
| 09:05 | <annevk> | First six months with Oscar were rather rough |
| 09:07 | <jgraham> | Not being woken up at all is for sure the best option :) |
| 09:08 | <jgraham> | I hope that this time things are a little smoother |
| 09:39 | <annevk> | zcorpan: hey, where can I find tests for <source type>? |
| 09:41 | <annevk> | grep suggests html/semantics/embedded-content/the-img-element/ |
| 09:44 | <annevk> | Seems someone already wrote all the tests I needed |
| 09:44 | <annevk> | hurray |
| 09:55 | <annevk> | TimothyGu: if you have the time, I'd love a pointer for this magic [[Call]] affecting inheritance stuff |
| 09:57 | <zcorpan> | annevk: html/semantics/embedded-content/the-img-element/update-the-source-set.html |
| 09:58 | <TimothyGu> | annevk: huh? what about inheritance |
| 10:00 | <annevk> | TimothyGu: why custom [[Call]] means there's no .call |
| 10:01 | <TimothyGu> | annevk: because .call is on Function.prototype, and document.all's [[Prototype]] is HTMLAllCollection.prototype |
| 10:01 | <TimothyGu> | and HTMLAllCollection.prototype's [[Prototype]] is Object.prototype |
| 10:01 | <TimothyGu> | like any other interface prototype object |
| 10:04 | <TimothyGu> | so -- no .call, no .bind, no .apply |
| 10:06 | <TimothyGu> | likewise, Object.setPrototype(function () {}, Object.prototype) doesn't have .call either |
| 10:07 | <inoas> | Is there a dedicated channel for discussing http1/http2 (push, preload, prefetch, preconnect, prerender; as/mime-types/crossorigin; block/async/defer)? |
| 10:39 | <annevk> | TimothyGu: aah right, I was confusing this with methods |
| 10:39 | <annevk> | TimothyGu: thanks |
| 10:40 | <annevk> | inoas: probably this channel |
| 10:40 | <annevk> | inoas: yoav ^^ |
| 10:46 | <yoav> | hey inoas! |
| 10:46 | <yoav> | let's discuss :) |
| 10:59 | <inoas> | Well it is more questions, but not "programming details" |
| 11:01 | <inoas> | When a document loads, depending on the loading and the execution priority of the ressource you can use: h2 push (preload header on http2) OR preload (preload header on h2 with nopush, or <link tag with rel push) OR prefetch |
| 11:02 | <inoas> | I am working on some kind of CMS (with staging, revisions, translations, templates) and I want to pass the options to make this right for linked code assets instead of doing combination and/or inlining (http1 tricks) |
| 11:02 | <inoas> | and for the execution it can be "blocking" (no attribute), async (non-blocking, in any order) or defer (non-blocking, but in order specified) |
| 11:03 | <inoas> | crossorigin=anonymous needs to be setup for fonts and otherwise just for remote origins |
| 11:03 | <inoas> | is that "about" correct so far? |
| 11:05 | <inoas> | another thing: I have done some http2 tests (with localtunnel.me and a vagrant box) using 100-140 image tiles and apache2 / http2 and while there are huge gains when moving from HTTP1.1 to HTTP2 there are little gains or even losses when moving from regular loading to pushing... sure there is a header that is up to about 7kb larger (max 8kb) but that can't be the reason (testing in chrome and firefox, I have also tested with sitespeed.io (chrome)) |
| 11:10 | <inoas> | and then another question would be: you can also "preload" domain resolve, tcp/tls handshake, links and even prerender them... aside prefetch which can also be used on pure ressources on the document itself (say which could but maybe not later used by elements loaded dynamically, say a chat window popping up), the other ones such as preconnect and prerender should be used with links (or domains for preconnect, but links would work, right?)? |
| 11:11 | <inoas> | so. ressources: h2 push, preload, prefetch & links: pefetch/preconnect/prerender |
| 11:34 | <inoas> | yoav: is that about correct? |
| 11:36 | <yoav> | RE "h2 push (preload header on http2)" - a preload header *may* be used as an indication for the web server to push down that resource |
| 11:37 | <yoav> | H2 push does not require link preload headers |
| 11:37 | <yoav> | and link preload headers don't mean that you're using h2 push |
| 11:38 | <inoas> | sure it does not require them, I am just saying there are these ways to handle ressource loading and execution priorities |
| 11:38 | <inoas> | h2 push, document header preload etc etc |
| 11:39 | <inoas> | h2 push would be via http header with a very similar semantic to document <head> <link> rel preload |
| 11:39 | <yoav> | "there is a header that is up to about 7kb larger" - headers this big can definitely result in slowed initial processing, as your effective initial congestion window is reduced from ~14K to ~6K |
| 11:39 | <inoas> | so what do you think a good header size is? |
| 11:39 | <inoas> | like a sweet spot? it isn't easy to answer, right? |
| 11:40 | <yoav> | as small as it can be |
| 11:40 | <yoav> | :) |
| 11:40 | <inoas> | well but if you want H2 Preload it has to be in the header instead of the <head> |
| 11:40 | <yoav> | H2 push is something that works well when your HTML has some "think time" |
| 11:40 | <yoav> | (so server side processing) |
| 11:41 | <yoav> | You can use that time to start pushing critical resources so that they will be available in the network stack once the browser got the HTML and realized that it needs them |
| 11:41 | <inoas> | What I consider is in the software allow to select when/how a code asset is loaded/executed: H2 Push with Fallback <head> Preload (If the maximum H2 Push header size is exceeded OR only HTTP1.1 available), then direct <head> Preload etc. |
| 11:41 | <yoav> | https://blog.yoav.ws/being_pushy/ |
| 11:42 | <inoas> | It seems like using nopush in conjunction with http2 would make little sense unless you reload only very very few ressources anyway? |
| 11:42 | <inoas> | because the trade off (header bigger vs the client knowing earlier) isnt worth it? |
| 11:42 | <yoav> | preload only kicks in after the HTML started sending down to the browser (and you can use preload both in its header form as well as inside the markup) |
| 11:43 | <inoas> | yes but in header form it is using push on h2, unless nopush is declared, right? |
| 11:44 | <yoav> | I'm not a fan of using the link preload header as a push signal. You could maybe use an HTTP server which strips those headers when it pushes |
| 11:44 | <inoas> | so say I limit the amount of preload directives in http headers to maximum of 2kb... and then I prefer the ones without "nopush" then if still space left = the ones with nopush... if there is an overflow... <head> <link preload the rest |
| 11:44 | <yoav> | "yes but in header form it is using push on h2, unless nopush is declared, right?" depends on your server implementation. It doesn't have to |
| 11:44 | <inoas> | well I am talking about apache 2.4x or so |
| 11:45 | <inoas> | I cannot change to nginx or H2O |
| 11:45 | <inoas> | mod_http2 then |
| 11:45 | <yoav> | push, preload, etc are not magic dust that you can spray over your sites to make them faster |
| 11:46 | <yoav> | they are tools you can use to fix specific bottlenecks in your site's loading |
| 11:46 | <yoav> | H2 push should be used to fill in the gaps before your HTML is sent down and right after it |
| 11:46 | <inoas> | that's the reason I want to yield some control to setting up templates and documents in our CMS |
| 11:46 | <yoav> | preload should be used for critical resources that are late discovered |
| 11:47 | <inoas> | as far as magic dust goes. the only magic dust so far is HTTP2... just enabling it really improved performance without any pushing |
| 11:47 | <yoav> | preconnect can help you establish TLS connections to third party domains ahead of time |
| 11:47 | <inoas> | Yes I understand, they would be in say a 50kb html document, at the very bottom with async |
| 11:48 | <inoas> | I understood preconnect so far that it only makes sense for us if we use cdns for static assets or non-origin domain JS APIs etc |
| 11:48 | <yoav> | async scripts are tricky to preload, as I've seen cases where loading them earlier actually makes things slower (they run earlier, delaying more critical work) |
| 11:48 | <inoas> | I hope that's about correct |
| 11:48 | <inoas> | well the async script then needs to be aware of DOMContentLoaded? |
| 11:49 | <yoav> | you can just avoid preloading it, turn it into a "defer"ed script (if you don't care about e.g. IE9) https://calendar.perfplanet.com/2016/prefer-defer-over-async/ |
| 11:50 | <yoav> | or load it dynamically |
| 11:50 | <yoav> | if it's not critical content, you shouldn't preload it, at least not upfront |
| 11:50 | <yoav> | there's no way to tell preload "this is a non-critical async script" |
| 11:50 | <yoav> | we probably should |
| 11:50 | <inoas> | Pushed responses go into this special push-only cache, and they go into the HTTP cache only when there’s an actual request for them. <= however prefetch would put things in http-cache right? (it would be about loading ressources that may or may not get used... whereas push/preload would load ressources that 99% are going to be used on the same page, "soon") ?! |
| 11:51 | <yoav> | as part of https://github.com/WICG/resource-priorities perhaps |
| 11:51 | <inoas> | tell preload + non-critical execution? |
| 11:51 | <inoas> | thought if I push or preload and set async true it would work!? |
| 11:51 | <yoav> | no |
| 11:52 | <yoav> | `async` is not taken into account on link elements |
| 11:52 | <yoav> | https://blog.yoav.ws/tale-of-four-caches/ for explanation on the different browser caches |
| 11:52 | <inoas> | yeah I remember push cache, memory cache, http cache or so |
| 11:53 | <inoas> | but it depends on the browser I suppose |
| 11:53 | <yoav> | yeah |
| 11:54 | <inoas> | if i push/preload a ressource and the browser uses it (otherwise maybe it wasnt a good idea to push it in the first place) then that is going to end in http cache (if cache headers are setup) AFAIU |
| 11:55 | <inoas> | the non-visible (say: below the fold and the user does not scroll) content however would eventually not be requested and thus would not enter http cache? |
| 11:55 | <inoas> | would it not be better if there was a flag for preload/push that says: and-also-put-it-into-http-cache? |
| 11:57 | <yoav> | Not sure but I think there are some security protections in the fact that pushed resources only live during the H2 session unless actually requested |
| 11:58 | <inoas> | Would the following semi-automated logic be okay: Setup Code Assets (JS/CSS) and Media Assets (SVG, JPG, PNG, Audio, Video) in templates/documents. While assigning them, set their Load Priority (Push or Preload, Preload, Prefetch) and their Execution Priority (Defer, Async, Blocking) as well as a natural order for loading and execution? |
| 12:01 | <yoav> | sounds somewhat reasonable, only that you don't necessarily have those controls today |
| 12:01 | <yoav> | which brings us to https://github.com/WICG/resource-priorities again... |
| 12:03 | <inoas> | Why don't I have those controls? What is missing? |
| 12:03 | <inoas> | "Even though ASYNC and DEFER don’t block the HTML parser, they can block rendering. This happens when they’re parsed and executed before rendering is complete and take over the browser main thread. <= if " if I wrap scripts with DOMContentLoaded checks would the blocking of the main thread not just be very short for async=true? |
| 12:13 | <inoas> | @ https://github.com/WICG/resource-priorities having relative priorities may be nice but maybe also complex because ressouces "need to know" about each other |
| 12:14 | <inoas> | what about supporting weight - layering in CSS is also done via this (z-index) instead of saying below-layer-a |
| 12:16 | <inoas> | having something like unix nice/weight/z-index means there is a defintiion of say -20 to +20 and then even remote scripts that load remote scripts can give them an execution priority?! |
| 12:16 | <yoav> | A few missing pieces: no way to indicate async/defer in preloaded resources, no way to indicate relative priority of resources of similar types, no way to define resources so they won't block more critical resources even if discovered before them |
| 12:17 | <inoas> | No way to indicate async/defer in preloaded resources <= so it is not possible to set defer (or async) attribute on the push header/preload link - and just on the tag where the ressource is requested ain't enough? Preloading should not mean pre-execution, does it? |
| 12:18 | <inoas> | Relative loading priority (for the same type) would be the priority in the http header / push promise or the <head> <link> order |
| 12:18 | <inoas> | execution order: dom order? |
| 12:19 | <inoas> | "no way to define resources so they won't block more critical resources even if discovered before them" I don't understand? - would it still not be wise to start implemeting things like suggested above and then just hope for the browsers to do the best. Users would not need to use push/preload, it would be an opt-in feature |
| 12:37 | <inoas> | I ll make a note that we should drop the preload headers after the http server processed them (right? there is no point sending them if the connection is http2) |
| 13:14 | <wanderview> | smaug____: annevk: marcosc is going I believe |
| 16:58 | <tobie> | What objects actually implement PerformanceNavigationTiming? |
| 20:10 | <virmaha> | Hello, when i enumerate getBoundingClientRect properties of an element, why do I get toJSON function ? |
| 20:57 | <Domenic> | Probably because they have a toJSON function! |
| 21:00 | <virmaha> | Domenic: haha but it wasn't there in previous version of chrome :p |
| 21:00 | <Domenic> | Probably Chrome is getting more spec-compliant :) |
| 21:33 | <virmaha> | Domenic: where can I find in spec |
| 21:33 | <virmaha> | that toJSON should be part of getBoundingClientRect |
| 21:41 | <tobie> | virmaha: https://github.com/w3c/fxtf-drafts/pull/220 |
| 21:45 | <virmaha> | tobie: thanks. You are the guy who works on web IDl holy shit that's so cool :D |
| 21:48 | <tobie> | virmaha: there's a number of us, tbh. Currently, this behavior is specified in the spec using serializers. But we've changed that recently to use toJSON instead to make it more explicit. |
| 21:50 | <virmaha> | tobie: yeah but I am talking to one of them:) Also, tbh this is first time I am delving into specs so this serializers and all confuses me |
| 21:51 | <tobie> | virmaha: well, you were talking with Domenic earlier—he's done loads more for the WebIDL spec (and others) than I have. |
| 21:51 | <tobie> | virmaha: that said: serializers are super confusing, which is why we're replacing them with toJSON |
| 21:52 | <virmaha> | tobie: oh nice. thank you Domenic ! |
| 21:52 | <tobie> | virmaha: they were basically a long and complex way of describing different flavors of toJSON methods |
| 21:53 | <virmaha> | tobie: umm if so, why did in previous version of chrome, everything worked fine? What 'serializer' did it use? |
| 21:53 | <tobie> | what do you mean by "worked fine" |
| 21:54 | <virmaha> | tobie: earlier, getBoundingClientRect didn't have toJSON. So I could easily JSON.stringify the output |
| 21:55 | <tobie> | virmaha: what do you mean by "easily JSON.stringify" the output? |
| 21:55 | <virmaha> | tobie: props = myElement.getBoundingClientRect(); for (var p in props) console.log(p); |
| 21:55 | <virmaha> | this never printed 'toJson' in chrome 60 but it does print toJSon in chrome 61 |
| 21:55 | <tobie> | oh, well, now you should just pass the object itself. |
| 21:56 | <tobie> | virmaha: so just do: jsonString = JSON.stringify(myElement.getBoundingClientRect()); |
| 22:00 | <virmaha> | thanks tobie! |
| 22:01 | <tobie> | virmaha: glad I could help |
| 22:02 | <virmaha> | glad I could learn from members who drive the web standards! |
| 22:06 | <virmaha> | err tobie , why can't I see toJSON here : https://chromium.googlesource.com/chromium/src/+/89bc0736a6c3d48eb426ffad99ff87fb6fd4e695/third_party/WebKit/Source/core/geometry/DOMRectReadOnly.idl |
| 22:06 | <virmaha> | that's from changelog of chrome..or am I looking at wrong file? |
| 22:07 | <tobie> | There's the serializer |
| 22:08 | <tobie> | virmaha: which now should be [Default] toJSON(); instead |
| 22:08 | <tobie> | virmaha: but which basically means the same thing |
| 22:09 | <tobie> | virmaha: see explanation here: https://github.com/w3c/fxtf-drafts/issues/200 |
| 22:15 | <virmaha> | alright tobie. Thanks a lot. |
| 22:15 | <tobie> | np |