| 05:17 | <annevk> | Domenic: open to alternatives, but suspect that Node.js would not copy CORS and such either, so you would have differences either way |
| 05:20 | <Domenic> | fair point, I guess they mostly copy the API shape, not the actual algorithm |
| 07:48 | <mkwst> | I'm skimming through HTML and DOMParsing in the hopes of understanding how `<script>` inserted via `innerHTML` is prevented from executing. I _think_ it boils down to the fragment parser generated a disconnected `Document` node |
| 07:49 | <mkwst> | (meaning that scripting is disabled, as it doesn't have a browsing context) |
| 07:49 | <mkwst> | Is that at all accurate? |
| 09:26 | <zcorpan> | how did i not know about Sauce Labs? |
| 09:40 | <zcorpan> | hmm only release versions for Edge :-| |
| 11:01 | <jgraham> | zcorpan: I imagine doing tech preview builds of edge is a huge pain, since you need a different Windows version for each one (afaik) |
| 11:03 | <zcorpan> | jgraham: ah. yeah. more reason to provide the service! :-) |
| 11:11 | <jgraham> | Well from our point of view sure :) From their point of view it's probably a lot of hassle for something that isn't too interesting to their core users |
| 11:34 | <nox> | annevk: https://html.spec.whatwg.org/multipage/#abort-a-document How does step 2 relate to Fetch termination? |
| 11:34 | <nox> | mkwst: Yes. |
| 11:46 | <annevk> | nox: open issue iirc |
| 11:49 | <nox> | annevk: Remember which? |
| 11:49 | <annevk> | nox: sorry, all part of lifecycle fun I am avoiding |
| 11:50 | <nox> | annevk: I'm that close to supporting .open() a la WebKit, |
| 11:50 | <nox> | annevk: and suddenly, massive blocker. :) |
| 12:08 | <Ms2ger> | annevk, is a data url iframe cross-origin now? |
| 12:09 | <annevk> | Ms2ger: yes (there's a bug against Gecko) |
| 12:20 | <hsivonen> | is blink-dev supposed to support the normal mailing list subscription mechanism? ("subscribe" to blink-dev-request) |
| 12:24 | <hsivonen> | I get the feeling that figuring out how to subscribe is some kind of CAPTCHA |
| 12:25 | <zcorpan> | mkwst: alternative idea - make <script nonce> in iframe srcdoc never run |
| 12:25 | <zcorpan> | but maybe there are use cases for <script nonce> in srcdoc |
| 12:26 | <MikeSmith> | hsivonen: blink-dev+subscribe⊙co apparently |
| 12:26 | <mkwst> | zcorpan: _I_ don't have any use for it, which is surely representative of the internet at large. |
| 12:26 | <MikeSmith> | hsivonen: according to List-Subscribe header in blink-dev messages |
| 12:26 | <zcorpan> | mkwst: totally. well then! |
| 12:29 | <hsivonen> | MikeSmith: thanks |
| 12:38 | <hsivonen> | MikeSmith: hmm. I still wants to subscribe my @gmail.com address instead of my @hsivonen.fi address |
| 12:38 | <hsivonen> | maybe I need to log out of google before clicking the subscription confirmation link on something |
| 12:39 | <hsivonen> | s/I still/It still/ |
| 12:40 | <MikeSmith> | or try it with lynx :) |
| 12:44 | <hsivonen> | ah, maybe I should reply to the email |
| 12:46 | <Domenic> | Woah, if you get up at 7:30am instead of 11:30am the email load is remarkably reduced |
| 12:47 | <hsivonen> | today's lesson: confirm google groups subscriptions by replying. Don't click the obvious button. |
| 12:52 | <nox> | annevk: Didn't find any issue about unloading a document. |
| 12:57 | <Domenic> | I know there are issues about *discarding* a document, not sure about unloading |
| 13:32 | <nox> | Domenic: Oh right. |
| 13:33 | <nox> | Domenic: Didn't find one that relates to cancelling fetch tasks either. :) |
| 13:34 | <annevk> | Domenic: so there's an issue about fetch groups somewhere |
| 13:34 | <annevk> | nox: ^^ |
| 13:34 | <annevk> | nox: and that's basically what needs to be sorted in order to define this |
| 13:35 | <annevk> | nox: sorry for the delay, I'm having a bad couple of days |
| 13:35 | <nox> | annevk: No problem. |
| 13:53 | <Domenic> | nox: the one I remember is https://github.com/whatwg/fetch/issues/416 |
| 14:47 | <inoas> | Domenic: would you revisit this issue? https://discourse.wicg.io/t/declarative-shadow-dom/1904/6 |
| 14:47 | <inoas> | A strong decoupling of CSS (no leaks outside, optional leaks inside) could be achieved |
| 14:48 | <inoas> | Combined with <link rel="preload"> and/or HTTP2 it would make sense to again write a ton of small css files which then get fetched based on whatever you need, probably already in the cache for further requests, be applied to multiple shadow-doms etc |
| 17:14 | <Domenic> | inoas: nothing new has been said on that issue that would make me revisit it |
| 17:15 | <inoas> | Domenic: I'd highly value a declarative approach that does not make javascript mandatory |
| 17:15 | <inoas> | it would allow soft web components just consisting out of html and css |
| 17:15 | <Domenic> | i'm not at all interested in a web without javascript |
| 17:15 | <inoas> | you are not interested in choice either? |
| 17:16 | <Domenic> | not in that sense, no. when we build features we have to make choices that necessarily close of other choices. I think it's fine to close of bad choices, like artificially restricting what technologies you use to build your pages. |
| 17:17 | <inoas> | well the declarative approach opens up things instead of restricting |
| 17:17 | <Domenic> | In other words, if you choose to artificially restrict yourself out of JavaScript, you're choosing to remove a lot of features from the platform, and that's fine with me. |
| 17:17 | <Domenic> | No. It is strictly less powerful. |
| 17:17 | <Domenic> | It is a restriction. |
| 17:17 | <inoas> | you see some clients like to restrict javascript - and the primary reason is security |
| 17:17 | <Domenic> | That's fine. They then don't get a lot of web features. |
| 17:17 | <inoas> | but that aside, have you been around when NN4 has been used? |
| 17:18 | <Domenic> | Yes, I coded my first websites against NN2 |
| 17:18 | <inoas> | now when you disabled javascript, then css would not load |
| 17:18 | <inoas> | the conclusion is, if you use shadow-dom-technology to isolate css, then if a client decides to disable javascript, it won't see css |
| 17:18 | <Domenic> | yep. |
| 17:18 | <inoas> | that is not progressive but restrictive web |
| 17:19 | <Domenic> | i disagree, as i've stated before. this isn't going anywhere. |
| 17:19 | <inoas> | I am very saddened by the way this is treated |
| 17:19 | <Domenic> | yeah, i am saddened too, that people think disabling js is a realistic thing to build future features like shadow DOM on |
| 17:19 | <inoas> | There is huge gains if css can be isolated to "modules" or "components" |
| 17:19 | <Domenic> | i agree! |
| 17:20 | <Domenic> | you just need to use the whole web platform to do that |
| 17:20 | <Domenic> | not an artificially restricted subset |
| 17:20 | <inoas> | so browser vendors don'T want to double-implement things |
| 17:20 | <inoas> | Domenic: that doesn't counter my agrument |
| 17:20 | <inoas> | I wish javascript was save but it is mostly not |
| 17:20 | <inoas> | and by that reason there is a lot of disabling going on |
| 17:21 | <Domenic> | [citation needed] |
| 17:21 | <inoas> | making javascript enabled to have css features, why? |
| 17:21 | <inoas> | 2.29mio users |
| 17:21 | <inoas> | https://addons.mozilla.org/de/firefox/addon/noscript/ |
| 17:21 | <inoas> | and no I don't want to run no-script |
| 17:21 | <inoas> | I am okay with single page applications running ELM or ReactJS |
| 17:21 | <inoas> | nothing to see without javascript |
| 17:22 | <Domenic> | a statistic that represents how much disabling is going on is number of pageviews with javascript disabled, not number of people who have ever downloaded noscript. |
| 17:22 | <inoas> | Domenic: so what is more likely: a declarative way to "create" a shadow-dom root node and reusing the encapulation shadow-dom technology already does and thus reinforcing shadow-dom WITH javascript alongside, e.g. SYNERGY |
| 17:23 | <inoas> | or a separate html/css based feature that isolates CSS? |
| 17:23 | <Domenic> | neither seem likely at all to me |
| 17:23 | <inoas> | Domenic: so you don't like users to chose? |
| 17:23 | <inoas> | what about future UAs that may depend on another scripting language? |
| 17:24 | <inoas> | or none at all because you want static renders like say - epaper? |
| 17:24 | <Domenic> | Please don't put words in my mouth. |
| 17:24 | <Domenic> | This conversation is going in circles so I'm going to have to go back to work, osrry. |
| 17:24 | <inoas> | Then let me rephrase: how would you allow users to chose? |
| 17:24 | <inoas> | This is very saddening |
| 17:26 | <inoas> | Domenic: I just hope you think about it, neither WhatWG nor W3C are democratic, but industry bodies, still people use the web every day and they rely on technologies that leave people choices. And the web platform has been that opposed to desktop apis or say flash... All the best with your work! |
| 17:30 | <amfc> | question: I think there should be a way to have a "single window" app in the web. some api like calling window.handleNewLocationsInThisWindow(urlPrefix) that will make all requests to same domain with speficied urlPrefix just do the equivalent to a local setLocation() |
| 17:30 | <amfc> | of course only valid in your own same protocol + domain |
| 17:31 | <amfc> | so the question is, is there anything relevant being discussed? |
| 17:31 | <Domenic> | amfc: I remember there were talks of that around service worker |
| 17:31 | <Domenic> | let me try to find the thread |
| 17:32 | <amfc> | i think it quite natural. it's the common case in desktop apps to remain single window. when you port your app to desktop and you follow links you end up with many of them open |
| 17:34 | <Domenic> | I'm not a big fan, I feel like the freedom to do multi-instances is a great part of the web so far, but I understand that a lot of app developers want this as part of their transition from working on desktop apps that have such control |
| 17:34 | <TabAtkins> | That's literally one of the worst parts of native apps. :( |
| 17:34 | <Domenic> | https://github.com/w3c/ServiceWorker/issues/720 and https://github.com/w3c/ServiceWorker/issues/758 |
| 17:35 | <TabAtkins> | Like I can't go searching for a YT video without interrupting the one I'm currently watching, or open several related videos from a single video (if I watch one and then go back, the list changes). |
| 17:35 | <Domenic> | I guess https://github.com/w3c/ServiceWorker/issues/602 too |
| 17:35 | <amfc> | Domenic: I would certainly not limit it, but change the default |
| 17:35 | <amfc> | something like "open in same window" being a default and open in a new window an alternative |
| 17:36 | <Domenic> | isn't that already how it works? |
| 17:36 | <TabAtkins> | That's already the default. |
| 17:36 | <Domenic> | you need target="_blank" to change the default |
| 17:36 | <TabAtkins> | Or a middle-click or Alt+click |
| 17:36 | <amfc> | i mean default from other browser tabs |
| 17:36 | <TabAtkins> | Still the default. |
| 17:37 | <TabAtkins> | Nothing moves to a new tab unless the page author or the user explicitly asks for it to. |
| 17:37 | <amfc> | so you click on a link on tab 3 and by default we open the link in tab 1 if it's already open |
| 17:37 | <tobie> | Domenic: the use case for that is to avoid having 50+ github window open at the end of the day if you receive updates by email |
| 17:37 | <TabAtkins> | tobie: Anti-use-case: Working on one GH issue, take a break to look at email and check on some other GH threads, whoops you just lost the stuff you were first working on. |
| 17:37 | <tobie> | amfc: I think you can build this on top of service workers |
| 17:38 | <Domenic> | I don't think you can yet, thus the open SW issues |
| 17:38 | <tobie> | TabAtkins: yeah, that's trivial to work around provided you understand the sate of your app |
| 17:38 | <tobie> | state |
| 17:39 | <TabAtkins> | tobie: Tell that to every native app I've ever encountered that consumes URL intents. :( |
| 17:39 | <TabAtkins> | Such as the aforementioned YouTube. |
| 17:39 | <tobie> | heh |
| 17:39 | <amfc> | tobie, you mean open a new window that finds the old window and then closes itself? can it focus it? |
| 17:39 | <TabAtkins> | A more direct problem: I can't open two GH issues at the same time to compare things. |
| 17:39 | <TabAtkins> | (Under this proposal.) |
| 17:40 | <amfc> | TabAtkins, you should be able to open two windows |
| 17:40 | <TabAtkins> | (Just like I can't, today, play two YT videos at the same time in the native app, but can easily do it on desktop if I so choose.) |
| 17:40 | <TabAtkins> | "Windows" and "Tabs" aren't meaningfully distinct. |
| 17:41 | <amfc> | TabAtkins, but being a less common case, it would become a little harder. my idea would only trigger itself on "open from outside" (like an email link) or be the default action on clicking links to a declared single window tab from another one. |
| 17:42 | <amfc> | TabAtkins, I would still leave a second option within the context menu (or ALT click) to open it in a new window |
| 17:42 | <amfc> | or you could copy the url, open it in another tab and then paste it |
| 17:42 | <TabAtkins> | New windows are, themselves, an extremely annoying UI affordance most of the time, and why we invented tabs in the first place. ^_^ |
| 17:43 | <amfc> | TabAtkins, of course I don't mean that, i mean open it as a new tab |
| 17:45 | <amfc> | Domenic, thanks! I can see https://github.com/w3c/ServiceWorker/issues/758 is exactly what I mean |
| 18:00 | smaug | wonders how often people just dump [SecureContext] to webidl by thinking it is then somehow "secure" or that information can't leak to http anymore |
| 18:04 | <annevk> | smaug: they don't dump it nearly enough |
| 18:05 | <smaug> | annevk: possible, but I still have the gut feeling that there is the assumption that it makes something really safe |
| 18:06 | <smaug> | yet there are still rather trivial communication channels between SecureContext and non-SecureContext |
| 18:06 | <annevk> | window.open()? |
| 18:07 | <smaug> | BroadcastChannel, localStorage... |
| 18:07 | <smaug> | (well, and in chromium also bugs like https://bugs.chromium.org/p/chromium/issues/detail?id=649686) |
| 18:07 | <annevk> | Oh yeah, if you have two tabs open. |
| 18:08 | <annevk> | So we did make shared workers not work like that, but localStorage / BroadcastChannel went too far? |
| 18:08 | <annevk> | It's been so long since we discussed all this... |
| 18:08 | <annevk> | But I don't think it was ever meant to be perfect, it's just for encouraging HTTPS adoption |
| 18:08 | <annevk> | In particular HTTPS in the address bar, rather than just in a proxy <iframe> |
| 18:10 | <smaug> | sure, but SecureContext as a name kind of hints about well, secure context :) but then it actually has some open doors to non-secure contexts, and those doors might not be obvious to everyone |
| 18:11 | <smaug> | I'm just a tad worried that [SecureContext] is added to specs without understanding what it actually means |
| 18:11 | <smaug> | and that might lead to some unexpected behavior |
| 22:30 | <zcorpan> | mkwst: no. it's this bit: "If the parser was originally created for the HTML fragment parsing algorithm, then mark the script element as "already started". (fragment case)" in A start tag whose tag name is "script" |
| 22:32 | <zcorpan> | mkwst: without that, the script would execute when inserted to the document. (and createContextualFragment unsets it) |
| 22:50 | <zcorpan> | Domenic: if you say <meta charset=utf-16> (with no 0x00 bytes), the chosen encoding is utf-8 :-) |
| 23:10 | <Domenic> | Well that's pretty great. |