| 00:25 | <Domenic> | zcorpan: that'd work for me |
| 04:57 | <kochi> | wanderview: are you interested in designing a successor of HTML Imports? |
| 04:58 | <wanderview> | kochi: uh... I'm really just interested in trying to understand the benefits of html imports compared to es modules... I know slightlyoff doesn't think es modules is a replacement |
| 04:58 | <wanderview> | kochi: which led me to reading the html imports spec and then wondering how it works with service workers, etc |
| 04:59 | <kochi> | wanderview: I guess technically ES modules can polyfill what HTML Imports can do, by embedding HTML and style in JS string :) |
| 05:00 | <wanderview> | kochi: right, but from what I have read it seems html imports supports progressive loading while es modules will require all dependencies to be loaded in strict sequence before evaluation |
| 05:00 | <kochi> | Using native HTML parser can have benefit over converting string to HTML via .innerHTML or DOMParser API, though. |
| 05:01 | <wanderview> | right |
| 05:01 | <wanderview> | kochi: it would be nice to see data showing perf benefits of html imports compared to a js polyfill... |
| 05:02 | <kochi> | and yeah, ES modules starts evaluation of the whole script once all the dependency graph is resolved and loaded, while in HTML Imports script inside an HTML Import can be run while loading other dependency branch. |
| 05:03 | <wanderview> | kochi: I guess I should be clear these questions are just coming from personal interest and don't really reflect any change in position from mozilla |
| 05:04 | <kochi> | well, I also would like to have concrete data :) Alex Russel might have some, will ask him. He mentioned such benefit in his talks. |
| 05:05 | <kochi> | wanderview: ok, I won't take it as mozilla's action, but I'd more than welcome your personal interests :) |
| 05:05 | <kochi> | happy to answer any questions |
| 05:05 | <wanderview> | kochi: I asked about data again on twitter last night :-) https://twitter.com/wanderview/status/846687836615028741 |
| 05:06 | <kochi> | good :) |
| 05:06 | <wanderview> | kochi: I'm going to see him at the SW spec meeting next week, so I'll ask him there as well |
| 05:07 | <kochi> | oh, are you here in Tokyo? |
| 05:07 | <wanderview> | I'm in Taipei at the moment... I arrive in Tokyo Saturday |
| 05:07 | <kochi> | okay, that's why your response is so quick :) |
| 05:08 | <wanderview> | yes, I'm awake! :-) |
| 05:10 | <kochi> | Practically html loading network round-trip time >>>> time required to parse HTML, I guess, so the benefit of parallelizing HTML import and HTML parsing is marginal, but in the age of H2 when the server side is more optimized to fill the loading pipeline, that optimization can be useful. |
| 05:13 | <wanderview> | so the es modules approach would parallelize all the network loads, but would delay the evaluation until all loads have completed? |
| 05:16 | <kochi> | yeah, es modules resolve all imports/exports before evaluation. |
| 05:16 | <wanderview> | but does the network loading happen in parallel? I guess I wasn't clear on that point |
| 05:18 | <wanderview> | I guess I should read up on how es modules does that |
| 05:18 | <kochi> | one of the merits of es module is that import dependency can be analyzed statically by parsing module script, no need to evaluate the code. |
| 05:19 | <wanderview> | ah |
| 05:20 | <kochi> | and that's why dynamic import() is not there in the first implementation of ES modules. |
| 05:21 | <wanderview> | I guess the question then is how much benefit is there to being able to run html/style parsers while other dependents are loading from network |
| 05:22 | <kochi> | So if an ES module A imports B, C, D, then loading B,C, D can be in parallel. |
| 05:23 | <wanderview> | and modules approach requires double parsing html/style resources... first as js and then as final html/css after dynamically inserted |
| 05:23 | <wanderview> | and html/css strings must be kept in memory due to js .source requirements |
| 05:23 | <kochi> | true. |
| 05:23 | <Domenic> | (^ all this seems accurate) |
| 05:23 | <wanderview> | Alex Russel mentioned some issue about css-in-js causing cache problems... thats the one I don't understand |
| 05:25 | <wanderview> | I guess maybe separate html/css resources can be cached separately giving a finer grained cache... but not sure if that is what he meant |
| 05:25 | <kochi> | hmm, I want to know what he exactly said, but one reason I can think of is, |
| 05:26 | <wanderview> | kochi: I saw it here: https://twitter.com/slightlylate/status/845435543647248384 |
| 05:26 | <kochi> | when Shadow DOM is used for a component, each shadow has its own style. Many of the same components are used in one document, there are multiple of copies of these styles. |
| 05:27 | <wanderview> | does that shadow DOM issue become worse with es module approach? can it share a stylesheet in memory, but not dynamically inserted style? |
| 05:28 | <kochi> | if such style is static (e.g. <style>...</style> in <template>), Blink does optimization of sharing the stylesheet resource memory. So if JS generates style for each shadow, they can't be shared. |
| 05:29 | <wanderview> | right |
| 05:29 | <wanderview> | we do that within a window as well I believe |
| 05:30 | <wanderview> | not sure if our shadow dom work takes advantage of it, though |
| 05:31 | <kochi> | If JS generates inline styles, I think caching is never expected for CSS? |
| 05:32 | <annevk> | Shadow DOM work in Gecko has not started yet I think, though there might be old patches |
| 05:33 | <annevk> | Custom elements is nearly there though |
| 05:33 | <kochi> | annevk: good to hear! |
| 05:34 | <Domenic> | Oh, I wasn't aware custom elements was happening |
| 05:34 | <kochi> | btw, "CSS in JS" Alex is talking about is probably https://speakerdeck.com/vjeux/react-css-in-js ? |
| 05:36 | <kochi> | and CE is https://bugzilla.mozilla.org/show_bug.cgi?id=889230 ? |
| 05:36 | <wanderview> | Domenic: I'm guessing you are not in NYC right now? |
| 05:36 | <Domenic> | wanderview: in Tokyo :) |
| 05:36 | <annevk> | Domenic: that's why Edgar files issues now and then 😊 |
| 05:37 | <wanderview> | kochi: that looks like the right bug |
| 05:37 | <Domenic> | nice |
| 05:37 | <Domenic> | Still a long ways to go I guess https://bugzilla.mozilla.org/showdependencytree.cgi?id=889230&hide_resolved=1 |
| 05:37 | <wanderview> | Domenic: are you going to be around the SW spec meeting next week? |
| 05:37 | <Domenic> | wanderview: yep! |
| 05:37 | <wanderview> | cool |
| 06:13 | <wanderview> | kochi: btw, I filed an issue with some questions I had around html imports and service workers: https://github.com/w3c/ServiceWorker/issues/1095 |
| 06:13 | <wanderview> | just FYI in case you aren't watching that repo |
| 06:14 | <annevk> | domfarolino: https://medium.com/dev-channel/pretty-printing-d80639fb8881 is probably of interest |
| 06:17 | <domfarolino> | annevk: thanks a lot |
| 06:22 | <kochi> | wanderview: thanks for raising the question! |
| 06:23 | <kochi> | Usually I'm only watching github.com/w3c/webcomponents/ |
| 09:27 | <wanderview> | kochi: are link.import documents considered an "active document"? |
| 09:27 | <wanderview> | for example, I think you can reference an iframe.contentWindow.document after doing iframe.remove()... but the document is not considered active any more |
| 09:28 | <wanderview> | the imported documents seem kind of like that because they are not rendered... but on the other hand they are associated with an environment settings object through the master document global |
| 09:29 | <kochi> | Does Gecko has the same notion as blink about "document is active"? |
| 09:30 | <wanderview> | kochi: hmm... I have no idea what blink does there :-) |
| 09:31 | <wanderview> | in gecko we can check to see if the document is associated with an environment settings object (gecko inner window) and a browsing context (gecko outer window + docshell) |
| 09:31 | <wanderview> | I think iframe.remove() just tears down the browsing context for the frame... but not 100% sure |
| 09:32 | <wanderview> | I know for bfcache we keep the environment settings object alive, but it doesn't have the browsing context associated |
| 09:33 | <kochi> | wanderview: okay, I assume we have similar notion - Blink defines several lifecycle states of Document and e.g. if the document is being shutdown, it's inactive. |
| 09:36 | <kochi> | So as long as <link rel="import"> element is connected to the master document (directly or indirectly) the `link.import` is active. |
| 09:36 | <wanderview> | ok |
| 09:36 | <wanderview> | I guess it was kind of theoretical spec question |
| 09:37 | <wanderview> | I mean, currently an environment settings object has a single document in html spec |
| 09:37 | <wanderview> | but with html imports it kind of has a secondary list of documents in addition to its master document |
| 09:43 | <kochi> | okay, so an import can be in a state that can't happen for a document created using DOMImplementation.creatHTMLDocument(). |
| 09:45 | <wanderview> | I guess the assumption is that anything that uses spec language like "get the document for the given environment settings object" will be working with the master document... all the imported documents are invisible to these specs |
| 09:47 | <kochi> | oh, "active document" should be https://html.spec.whatwg.org/multipage/browsers.html#active-document in the spec world |
| 09:48 | <wanderview> | ok |
| 09:48 | <kochi> | I was meaning different "active", then. |
| 09:49 | <kochi> | The HTML spec says one browsing context has one active document. |
| 09:49 | <wanderview> | I guess conceptually the imported documents hang more off the master document and the environment settings/browsing context doesn't really know about them at all |
| 09:49 | <wanderview> | sorry, just thinking it through |
| 09:51 | <kochi> | no worries. in HTML imports world, wherever script runs, `window.document` is the master document. |
| 09:53 | <kochi> | To get a reference of imported document is to use `link.import` property, or (in script running inside import) `document.currentScript.ownerDocument` (or any node in the import as context object). |
| 10:37 | <annevk> | Domenic: so for HTML you pretty much s/character/code point/, or something else? |
| 10:38 | <annevk> | Domenic: there's currently 1849 matches for "character" |
| 10:39 | <Domenic> | annevk: hmm mostly, although I would focus on the instances where we're actually manipulating strings, not e.g. talking about the user typing. |
| 10:39 | <Domenic> | It sounds pretty thankless though |
| 10:39 | <Domenic> | Maybe not worth it |
| 10:41 | <annevk> | Domenic: maybe we should do it as some kind of ongoing effort whenever we refactor algorithms, just like we do with other Infra things |
| 10:42 | <annevk> | Domenic: it was pretty easy to avoid labels in the IPv6 parser btw, so I'm hopeful that we might not need them |
| 10:43 | <Domenic> | Ongoing effort sounds like a good idea, yeah. |
| 10:44 | <Domenic> | Labels does sound good. I want to implement that change in whatwg-url to check no test results change but yeah it was pretty reasonable. |
| 10:45 | <annevk> | I implemented it in whatwg-url as well to make sure, hopefully you'll find the same |
| 11:46 | <annevk> | zcorpan: GitHub can no longer display the fingerprint resource, claims it's invalid |
| 11:47 | <zcorpan> | annevk: fixing. damned namespaces |
| 11:47 | <annevk> | zcorpan: amateur hour |
| 11:48 | <annevk> | (not that I spotted that, was looking for a well-formedness error) |
| 11:49 | <annevk> | zcorpan: seems better to not have width="46" height="64" inside the SVG |
| 11:49 | <annevk> | zcorpan: viewBox should be enough |
| 11:50 | <annevk> | zcorpan: no other comments from though, thanks for taking it on |
| 11:50 | <zcorpan> | annevk: i figured this would be inlined and then it should have width/height there |
| 11:51 | <zcorpan> | annevk: the aria attributes are also only necessary when inline |
| 11:51 | <annevk> | zcorpan: I see, makes sense |
| 12:59 | <Domenic> | Oh, I thought we'd keep using <img> |
| 13:02 | <annevk> | Domenic: both solutions are fine with me, but it sounded like at least TabAtkins also wanted an inline solution |
| 13:02 | <Domenic> | Right, yeah, but we don't have to host one |
| 13:03 | <annevk> | Alright |
| 13:03 | <annevk> | zcorpan: does that work for you? |
| 13:04 | <zcorpan> | Domenic: annevk: yeah sure. TabAtkins just needs to add width/height/role/aria-label in bikeshed |
| 13:24 | <annevk> | Domenic: what other places can we reach out to about mutable strings? |
| 13:25 | <annevk> | Domenic: or should we just go ahead and start patching IDL? |
| 14:37 | <tobie> | Domenic: I just realized I completely forgot about the distinguishable algorithm which might also be affected. Did you consider it? |
| 14:59 | <tobie> | Domenic: updated the review with that comment. |
| 15:49 | <jyasskin> | kochi/wanderview: Note that ES "evaluation" actually happens in ~4 steps (per adamk), and IIRC 2 of them can happen before the full dependency graph is downloaded. |
| 15:49 | <jyasskin> | s/adamk/aklein/ |
| 15:56 | <kochi> | jyasskin: yeah, load, instantiate, link, evaluate, iirc. |
| 15:58 | <kochi> | ah, maybe no? is "evaluate" further sub-divided? |
| 15:58 | <jyasskin> | Your stages sound like what I was thinking about. |
| 15:59 | <jyasskin> | Sorry for the noise then; you were already ahead of me. :) |
| 16:01 | <domfarolino> | Domenic: regarding the WPT to ensure the non-existence of timeline() and timelineEnd() in console, is there a reason to go with an html test rather than js? I ask bc you mentioned the suffix `-historical.html` |
| 16:24 | <annevk> | domfarolino: suspect Domenic is asleep, but -historical.any.js or some such should be fine too |
| 16:24 | <annevk> | (I suspect) |
| 16:40 | <domfarolino> | I'll go with that for now thanks |
| 17:13 | <domfarolino> | annevk: what does the `.any.` denote anyways? |
| 17:16 | <annevk> | domfarolino: dedicated worker and window |
| 17:17 | <domfarolino> | ah |
| 17:17 | <annevk> | domfarolino: http://web-platform-tests.org/writing-tests/testharness.html has documentation on it |
| 17:17 | <annevk> | domfarolino: you need some kind of prefix otherwise you won't get the boilerplate |
| 17:17 | <annevk> | domfarolino: jgraham has a patch for .window.js but I'm not sure if that has landed |
| 17:20 | <domfarolino> | Ah thank you! |
| 18:09 | <jgraham> | annevk: I think it did, bt I haven't checked |
| 19:06 | <ajeffrey_> | Got a question about https://html.spec.whatwg.org/multipage/embedded-content.html#iframe-load-event-steps |
| 19:06 | <ajeffrey_> | in particular "When the iframe's browsing context's active document is not ready for post-load tasks, and when anything in the iframe is delaying the load event of the iframe's browsing context's active document, and when the iframe's browsing context is in the delaying load events mode, the iframe must delay the load event of its document." |
| 19:07 | <ajeffrey_> | and how to interpret "anything in the iframe". |
| 19:07 | <ajeffrey_> | If there's a child iframe, and its currently active document contains a grandchild iframe, |
| 19:08 | <ajeffrey_> | do all the documents in the iframe's session history count? |
| 19:08 | <ajeffrey_> | or only the currently active document? |
| 19:09 | <gsnedders> | ajeffrey_: they wouldn't delay the active document's load event, would they? |
| 19:09 | <ajeffrey_> | gsnedders: that's what I'm trying to work out :) |
| 19:10 | gsnedders | wonders if the hotel wifi can cope with the HTML spec |
| 19:11 | <ajeffrey_> | the nasty case is something like if the grandchild loads a document A, then while it is still delaying the load, it navigates to B. |
| 19:13 | <gsnedders> | delaying the load event is linked to a document, AIUI |
| 19:14 | <ajeffrey_> | gsnedders: indeed, so what does "anything in the iframe" mean? |
| 19:14 | gsnedders | shrugs |
| 19:14 | <gsnedders> | :) |
| 19:14 | <ajeffrey_> | just the currently active docs? |
| 19:15 | <ajeffrey_> | (which means that traversing the history can change "delaying the load event" non-monotonically) |
| 19:15 | <ajeffrey_> | or all docs? |
| 19:16 | <ajeffrey_> | (which means we care about whether inactive docs are delaying the load event) |
| 19:16 | <ajeffrey_> | neither of these seem great. |
| 19:41 | <smaug> | does chrome have something like about:memory (in FF) |
| 19:45 | <gsnedders> | smaug: chrome://system/ I think is the most granuality you get |
| 21:25 | <jyasskin> | Is there any semi-standard set of github labels that folks are using? We're thinking of setting up a triage process of sorts for spec issues, and it'd be good to match other folks' labels. |
| 21:37 | <TabAtkins> | jyasskin: Check the CSSWG repo? |
| 21:38 | <TabAtkins> | https://github.com/w3c/csswg-drafts/labels |
| 21:38 | <TabAtkins> | In particular the "Needs X" set of labels |
| 21:40 | <jyasskin> | TabAtkins: Thanks. I also have https://github.com/w3c/webauthn/labels with some priority ones. |
| 22:18 | <tobie> | jyasskin: plh (from w3c) has been working on the following list: https://w3c.github.io/spec-labels.html |
| 22:21 | <tobie> | jyasskin: fwiw |
| 22:34 | <jyasskin> | tobie: That is exactly what I was looking for. Thank you! |
| 22:35 | <tobie> | jyasskin: np |