freenode :: #whatwg

8 Sep 2017
00:09Domeniccantom: so, we actually generate the dev edition from the real spec these days, so that should be OK :).
00:10Yuhongthe point is doing snapshots based on the dev edition.
00:11cantomDomenic: :D
00:11cantomBig question. Why is the slogan of WHATWG "Please leave your sense of logic at the door, thanks!"
00:12DomenicHaha. 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:12DomenicWe often say "see topic" when someone complains about some old historical thing like "why is typeof document.all 'undefined'???"
00:13cantomDomenic: 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:14Domeniclol, yep, sounds right
00:15YuhongWhich also reminds me of the title of
00:15YuhongNow URL is less complex and less likely to change than the main HTML spec.
00:17Yuhong had not even an editorial commit for a month.
00:35TabAtkinsDomenic: 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:36DomenicI ended up linking to
01:09YuhongAnd government officials are actually another good reason.
01:10YuhongIt 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:44annevksmaug____: what's the status of
07:46smaug____implemented in some form, but the spec hasn't got much updates as you can see
07:46smaug____there are some open bugs, I think
07:47smaug____annevk: why?
07:47annevksmaug____: mostly want [Exposed] added to the interfaces
07:47smaug____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:48annevksmaug____: and since there's not even a GitHub repo I'm wondering where I can reliably file bugs
07:48smaug____w3 bugzilla
07:48annevksmaug____: I see, but not mentioned in the spec somehow?
07:49smaug____aha, I see it is not mentioned there
07:50annevksmaug____: I filed a bug; I guess I'll file another one about mentioning Bugzilla in the spec
07:50smaug____annevk: curious, will you attend TPAC this year?
07:53annevksmaug____: 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:53smaug____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:54annevksmaug____: wanderview will go
07:55annevkThere's a couple more people, but I don't remember all the names
08:27smaug____if it wasn't in Trumpland, I'd attend.
09:02jgrahamannevk: I guess being woken up by a new baby is better than being woken up by the SFO flights passing overhead :)
09:04annevkThat really depends on how much sleep I've had
09:05annevkFirst six months with Oscar were rather rough
09:07jgrahamNot being woken up at all is for sure the best option :)
09:08jgrahamI hope that this time things are a little smoother
09:39annevkzcorpan: hey, where can I find tests for <source type>?
09:41annevkgrep suggests html/semantics/embedded-content/the-img-element/
09:44annevkSeems someone already wrote all the tests I needed
09:55annevkTimothyGu: if you have the time, I&#39;d love a pointer for this magic [[Call]] affecting inheritance stuff
09:57zcorpanannevk: html/semantics/embedded-content/the-img-element/update-the-source-set.html
09:58TimothyGuannevk: huh? what about inheritance
10:00annevkTimothyGu: why custom [[Call]] means there&#39;s no .call
10:01TimothyGuannevk: because .call is on Function.prototype, and document.all&#39;s [[Prototype]] is HTMLAllCollection.prototype
10:01TimothyGuand HTMLAllCollection.prototype&#39;s [[Prototype]] is Object.prototype
10:01TimothyGulike any other interface prototype object
10:04TimothyGuso -- no .call, no .bind, no .apply
10:06TimothyGulikewise, Object.setPrototype(function () {}, Object.prototype) doesn&#39;t have .call either
10:07inoasIs there a dedicated channel for discussing http1/http2 (push, preload, prefetch, preconnect, prerender; as/mime-types/crossorigin; block/async/defer)?
10:39annevkTimothyGu: aah right, I was confusing this with methods
10:39annevkTimothyGu: thanks
10:40annevkinoas: probably this channel
10:40annevkinoas: yoav ^^
10:46yoavhey inoas!
10:46yoavlet&#39;s discuss :)
10:59inoasWell it is more questions, but not &quot;programming details&quot;
11:01inoasWhen 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:02inoasI 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:02inoasand for the execution it can be &quot;blocking&quot; (no attribute), async (non-blocking, in any order) or defer (non-blocking, but in order specified)
11:03inoascrossorigin=anonymous needs to be setup for fonts and otherwise just for remote origins
11:03inoasis that &quot;about&quot; correct so far?
11:05inoasanother thing: I have done some http2 tests (with 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&#39;t be the reason (testing in chrome and firefox, I have also tested with (chrome))
11:10inoasand then another question would be: you can also &quot;preload&quot; 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:11inoasso. ressources: h2 push, preload, prefetch & links: pefetch/preconnect/prerender
11:34inoasyoav: is that about correct?
11:36yoavRE &quot;h2 push (preload header on http2)&quot; - a preload header *may* be used as an indication for the web server to push down that resource
11:37yoavH2 push does not require link preload headers
11:37yoavand link preload headers don&#39;t mean that you&#39;re using h2 push
11:38inoassure it does not require them, I am just saying there are these ways to handle ressource loading and execution priorities
11:38inoash2 push, document header preload etc etc
11:39inoash2 push would be via http header with a very similar semantic to document <head> <link> rel preload
11:39yoav&quot;there is a header that is up to about 7kb larger&quot; - headers this big can definitely result in slowed initial processing, as your effective initial congestion window is reduced from ~14K to ~6K
11:39inoasso what do you think a good header size is?
11:39inoaslike a sweet spot? it isn&#39;t easy to answer, right?
11:40yoavas small as it can be
11:40inoaswell but if you want H2 Preload it has to be in the header instead of the <head>
11:40yoavH2 push is something that works well when your HTML has some &quot;think time&quot;
11:40yoav(so server side processing)
11:41yoavYou 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:41inoasWhat 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:42inoasIt seems like using nopush in conjunction with http2 would make little sense unless you reload only very very few ressources anyway?
11:42inoasbecause the trade off (header bigger vs the client knowing earlier) isnt worth it?
11:42yoavpreload 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:43inoasyes but in header form it is using push on h2, unless nopush is declared, right?
11:44yoavI&#39;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:44inoasso say I limit the amount of preload directives in http headers to maximum of 2kb... and then I prefer the ones without &quot;nopush&quot; then if still space left = the ones with nopush... if there is an overflow... <head> <link preload the rest
11:44yoav&quot;yes but in header form it is using push on h2, unless nopush is declared, right?&quot; depends on your server implementation. It doesn&#39;t have to
11:44inoaswell I am talking about apache 2.4x or so
11:45inoasI cannot change to nginx or H2O
11:45inoasmod_http2 then
11:45yoavpush, preload, etc are not magic dust that you can spray over your sites to make them faster
11:46yoavthey are tools you can use to fix specific bottlenecks in your site&#39;s loading
11:46yoavH2 push should be used to fill in the gaps before your HTML is sent down and right after it
11:46inoasthat&#39;s the reason I want to yield some control to setting up templates and documents in our CMS
11:46yoavpreload should be used for critical resources that are late discovered
11:47inoasas far as magic dust goes. the only magic dust so far is HTTP2... just enabling it really improved performance without any pushing
11:47yoavpreconnect can help you establish TLS connections to third party domains ahead of time
11:47inoasYes I understand, they would be in say a 50kb html document, at the very bottom with async
11:48inoasI 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:48yoavasync scripts are tricky to preload, as I&#39;ve seen cases where loading them earlier actually makes things slower (they run earlier, delaying more critical work)
11:48inoasI hope that&#39;s about correct
11:48inoaswell the async script then needs to be aware of DOMContentLoaded?
11:49yoavyou can just avoid preloading it, turn it into a &quot;defer&quot;ed script (if you don&#39;t care about e.g. IE9)
11:50yoavor load it dynamically
11:50yoavif it&#39;s not critical content, you shouldn&#39;t preload it, at least not upfront
11:50yoavthere&#39;s no way to tell preload &quot;this is a non-critical async script&quot;
11:50yoavwe probably should
11:50inoasPushed responses go into this special push-only cache, and they go into the HTTP cache only when theres 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, &quot;soon&quot;) ?!
11:51yoavas part of perhaps
11:51inoastell preload + non-critical execution?
11:51inoasthought if I push or preload and set async true it would work!?
11:52yoav`async` is not taken into account on link elements
11:52yoav for explanation on the different browser caches
11:52inoasyeah I remember push cache, memory cache, http cache or so
11:53inoasbut it depends on the browser I suppose
11:54inoasif 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:55inoasthe 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:55inoaswould it not be better if there was a flag for preload/push that says: and-also-put-it-into-http-cache?
11:57yoavNot 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:58inoasWould 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:01yoavsounds somewhat reasonable, only that you don&#39;t necessarily have those controls today
12:01yoavwhich brings us to again...
12:03inoasWhy don&#39;t I have those controls? What is missing?
12:03inoas&quot;Even though ASYNC and DEFER dont block the HTML parser, they can block rendering. This happens when theyre parsed and executed before rendering is complete and take over the browser main thread. <= if &quot; if I wrap scripts with DOMContentLoaded checks would the blocking of the main thread not just be very short for async=true?
12:13inoas@ having relative priorities may be nice but maybe also complex because ressouces &quot;need to know&quot; about each other
12:14inoaswhat about supporting weight - layering in CSS is also done via this (z-index) instead of saying below-layer-a
12:16inoashaving 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:16yoavA 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&#39;t block more critical resources even if discovered before them
12:17inoasNo 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&#39;t enough? Preloading should not mean pre-execution, does it?
12:18inoasRelative loading priority (for the same type) would be the priority in the http header / push promise or the <head> <link> order
12:18inoasexecution order: dom order?
12:19inoas&quot;no way to define resources so they won&#39;t block more critical resources even if discovered before them&quot; I don&#39;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:37inoasI 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:14wanderviewsmaug____: annevk: marcosc is going I believe
16:58tobieWhat objects actually implement PerformanceNavigationTiming?
20:10virmahaHello, when i enumerate getBoundingClientRect properties of an element, why do I get toJSON function ?
20:57DomenicProbably because they have a toJSON function!
21:00virmahaDomenic: haha but it wasn&#39;t there in previous version of chrome :p
21:00DomenicProbably Chrome is getting more spec-compliant :)
21:33virmahaDomenic: where can I find in spec
21:33virmahathat toJSON should be part of getBoundingClientRect
21:45virmahatobie: thanks. You are the guy who works on web IDl holy shit that&#39;s so cool :D
21:48tobievirmaha: there&#39;s a number of us, tbh. Currently, this behavior is specified in the spec using serializers. But we&#39;ve changed that recently to use toJSON instead to make it more explicit.
21:50virmahatobie: 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:51tobievirmaha: well, you were talking with Domenic earlierhe&#39;s done loads more for the WebIDL spec (and others) than I have.
21:51tobievirmaha: that said: serializers are super confusing, which is why we&#39;re replacing them with toJSON
21:52virmahatobie: oh nice. thank you Domenic !
21:52tobievirmaha: they were basically a long and complex way of describing different flavors of toJSON methods
21:53virmahatobie: umm if so, why did in previous version of chrome, everything worked fine? What &#39;serializer&#39; did it use?
21:53tobiewhat do you mean by &quot;worked fine&quot;
21:54virmahatobie: earlier, getBoundingClientRect didn&#39;t have toJSON. So I could easily JSON.stringify the output
21:55tobievirmaha: what do you mean by &quot;easily JSON.stringify&quot; the output?
21:55virmahatobie: props = myElement.getBoundingClientRect(); for (var p in props) console.log(p);
21:55virmahathis never printed &#39;toJson&#39; in chrome 60 but it does print toJSon in chrome 61
21:55tobieoh, well, now you should just pass the object itself.
21:56tobievirmaha: so just do: jsonString = JSON.stringify(myElement.getBoundingClientRect());
22:00virmahathanks tobie!
22:01tobievirmaha: glad I could help
22:02virmahaglad I could learn from members who drive the web standards!
22:06virmahaerr tobie , why can&#39;t I see toJSON here :
22:06virmahathat&#39;s from changelog of chrome..or am I looking at wrong file?
22:07tobieThere&#39;s the serializer
22:08tobievirmaha: which now should be [Default] toJSON(); instead
22:08tobievirmaha: but which basically means the same thing
22:09tobievirmaha: see explanation here:
22:15virmahaalright tobie. Thanks a lot.
9 Sep 2017
No messages
Last message: 13 days and 6 hours ago