freenode :: #whatwg

10 Oct 2017
00:04bathosjyasskin I answered the question, tried to give attribution for your assistance, and quoted this chat: https://stackoverflow.com/questions/46642569/http2-push-and-native-es-modules-entry-module-push-is-ignored/46656731#46656731
00:04bathos(let me know if youd prefer I didnt and Ill edit accordingly)
00:04bathosI have a feeling this is gonna be helpful for others in the future in any case.
01:47wanderviewDomenic: <script> tags is a subresource of a document/window... a worker script is a top level entity itself
02:48DomenicStill don&#39;t really understand why that matters. I guess we use different rules for picking the service worker in such cases but I don&#39;t understand why or what goes wrong when we don&#39;t.
02:52MekI don&#39;t think anything goes wrong per-se. It just would be a bit weird where currently the service worker controlling a client is determined by the URL the client is loaded from being in scope of the SW, while for a cross-origin worker the URL would never be in scope. So either we change the logic to select a SW for all module workers (making them behave differently than non-module workers), or we only change it for cross-origin workers, which is also a
02:52Mekbit inconsistent.
02:53MekTo me it doesn&#39;t sound too strange to treat them similar to about:blank iframes etc, where we also just take the SW of the creating document as the controlling service worker. Treat cross-origin module workers almost like an anonymous &quot;about:blank&quot; worker that just happens to import a cross-origin module...
02:53wanderviewthere is no cross-origin non-subresource from a service worker perspective... it just matches scopes on that other origin
02:53wanderviewright?
02:55wanderviewwhat Domenic is asking for sounds like window.open(crossOriginURL) where it loads resources from another origin, but then would weirdly be forced the openers origin...
02:57wanderviewDomenic: new Worker(url) is very similar to window.open(url)... they both open top level clients
02:58wanderviewwith the notable difference that we throw a security error for new Worker() if the url is cross origin from the current context
03:00Mekit&#39;s kind of new Worker(&quot;about:blank&quot;) followed by worker.write(&quot;import(&quot;cross-origin-url&quot;)), if that would be possible. I&#39;m not saying it isn&#39;t different than what we do now, but it surely isn&#39;t impossible either. We&#39;d juts have to decide how to treat it.
03:01Mek(and I&#39;m not sure if the difference in treatment should be made at same-origin vs cross origin or at classic vs module worker)
03:02wanderviewhmm
03:04Mek(and for what it&#39;s worth, I think having cross-origin (module) workers that actually are cross origin (access the other origins storage etc) would also be a worthwhile thing to explore, but yet again another complication (it would address at least some of the foreign-fetch/navigator.connect use cases, combined with nested workers)
03:04wanderviewI guess I would be more comfortable just requiring the top level module URL to be same-origin to match classic script loading
03:05wanderviewadding cross-origin worker support seems orthogonal to module loading to me
03:18wanderviewor maybe thats what this PR is about
04:32annevkwanderview: agreed, will file an issue later with hopefully a detailed enough explanation
05:47JakeAjyasskin: bathos: also covered at https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/#requests-without-credentials-use-a-separate-connection
08:38tobieHey folks, if you have thoughts &/|| comments to make about adding mixins to WebIDL, now&#39;s about the right time: https://github.com/heycam/webidl/pull/433
08:59JakeAjyasskin: filed https://bugs.chromium.org/p/chromium/issues/detail?id=773219
11:16ondrasso, is calc() supposed to work in font: shorthand property? as in https://jsfiddle.net/29fsrxq3/
11:44noxondras: calc() is supposed to work everywhere until specified otherwise.
11:45ondrasnox: thanks. will report a bug and a wpt test then.
11:45noxondras: It appears big for me in both Safari and Chrome.
11:45ondrasnox: right. but not in firefox.
11:46noxYep.
12:50annevkhsivonen: what&#39;s a web-observable caller of &quot;UTF-8 decode without BOM or fail&quot;?
12:51annevkhsivonen: I thought I found one in HTML, but that appears to be an error when I tested
13:16annevkhsivonen: I found another decoder, the thing that navigates to fragments...
13:16* annevk is not amused
13:22annevkhsivonen: also, it seems this endpoint doesn&#39;t allow a BOM to override it
13:40Domenicannevk: does not escaping % break the idempotency/parse-serialize-parse guarantees for URLs? Haven&#39;t checked but feels like it might.
13:42annevkDomenic: we only do something for %2e. But you cannot get that serialized I think.
13:42annevkDomenic: at least not in a place where parse will then take it away again
14:04annevkDomenic: hope the module worker issue is clear now
14:05annevkDomenic: also, are implementations first shipping import()? Before <script type=module>?
14:05annevkDomenic: or is <script type=module> happening before workers?
15:27hsivonenannevk: Web Socket as implented in Gecko, maybe?
15:53annevkhsivonen: that does indeed seem required as per https://tools.ietf.org/html/rfc6455#section-8.1
15:53annevkhsivonen: I&#39;ll make a note of that in the source
15:54annevkhsivonen: ta
17:15annevkHmm, NTLMv2
17:15annevkI wonder if I want to explore that further; probably not
17:16gsneddersthe answer is definitely not
17:16jyasskinJakeA: Thanks!
18:34TabAtkinsondras: Yeah, what nox said - calc() represents a <number> or <length> or whatever according to its contents, and should be usable *literally everywhere* that any of those types are accepted.
18:43ondrasTabAtkins: thanks for confirmation. I already submitted a PR to web-platform-tests and there is an existing (~year) old report in mozilla&#39;s bugzilla.
18:46TabAtkinsCool.
18:47noxondras: With Stylo landing soon, it will not get fixed in Firefox right now,
18:47noxondras: but after Stylo lands, the Rust code that do the parsing is way easier to update to support this, so that&#39;s nice.
18:48ondrasnox: I understand that Stylo is some brand new css engine for Firefox and people are focused at delivering it instead of fixing old bugs in the old css engine?
18:49noxondras: Yes and no.
18:49noxondras: Not supporting that in font doesn&#39;t break anything currently,
18:49noxondras: supporting it *could* break things,
18:50noxondras: and we can&#39;t afford to deploy Stylo and suddenly realise it breaks websites because it supports more stuff than the previous engine.
18:52ondrasnox: I see, okay. (calc in font works in both Chrome and Safari, though.)
18:52noxondras: Yeah, so for example, a website could have a font property with calc, for Firefox and Chrome,
18:52noxErr, Safari and Chrome*
18:52noxand a different font property for Firefox, without calc,
18:53ondrasThat is true.
18:53noxand while it&#39;s not much probable, supporting calc in Firefox could then break the site under Firefox (for example if the two fonts were different, because they didn&#39;t combine well with the rest of the stylesheet as interpreted by Firefox),
18:53noxand then we need to disable Stylo on that website, which sucks.
19:03TabAtkinsYeah, it&#39;s reasonable to want to separate out those concerns when doing a big launch. ^_^ It&#39;s not super-pressing, but it is important to fix eventually - calc() not working in random places is very frustrating for devs.
19:15ondrastrue that.
19:16ondrasThe point is that Custom Properties are almost useless without calc(), so I suppose that calc() is now getting a lot more attention. At least in my case :-)
19:21TabAtkinsAh, true!
19:21noxTabAtkins: It&#39;s frustrating to le me who participated into Stylo too!
19:21noxIt takes more code to not support calc() in some places, than to support it everywhere.
19:22noxSo we had issues about having to *unsupport* calc sometimes.
19:22TabAtkinsNice.
19:27annevknox: seems we can undo thos now with 57 having branched?
19:28noxannevk: The story is &quot;don&#39;t worry fam we won&#39;t forget about doing these changes afterwards&quot;.
19:28noxannevk: I myself have been kidnapped for a different adventure, so I&#39;m not in the know anymore about that kind of mundane details.
19:30annevkMaybe SimonSapin knows? Im curious now
19:33SimonSapinRight now pretty much any style system change needs to be done twice. Itll all be much easier when we can remove the old style system
19:33SimonSapinbut itll be a couple release cycles at least before we can
19:34SimonSapinwe need to enable Stylo on Android, support XBL, etc
19:35annevkSimonSapin: ah ok, ta
19:36Domenicannevk: I&#39;m still not sure on why shared workers would be nondeterministic. They are keyed by (creator origin, worker script URL) so they&#39;d always use the service worker of the creator origin.
19:38Mekbut which service worker of that origin?
19:38DomenicOh.
19:42annevkYup
19:42* annevk curses scopes once more
19:44nox360 noscope 4ever
19:50tobieDomenic: hey, so I found a reliable way to check that the WebIDL grammar stays LL(1)
19:50tobieDomenic: Which btw uncovered 3 violations in the existing grammar. :)
19:50DomenicExciting :)
19:51tobieWell, I&#39;m not sure exciting is the best way to characterize that
19:51tobieBut it&#39;s going to solve an otherwise painful problem.
19:51tobieDomenic: It relies on node.js + jsdom + syntax-cli + a custom JS script.
19:52tobieDomenic: and should be called by the deploy script (as it&#39;s going to be more robust if run on a build rather than on bs source)
19:52tobieDomenic: what do you think the best strategy is to incorporate it into the repo/travis file?
19:53tobieDomenic: this is basically what the script looks like: https://gist.github.com/tobie/ea7e12bb4cbbc5a28527684e7f14ef20
19:54Domenic(Use new jsdom API plz ^_^)
19:54tobieDomenic: oh. sure. :D
19:55DomenicBasically I would borrow from https://github.com/whatwg/streams
19:55DomenicSetup travis as if it&#39;s a node project
19:55DomenicCheck in a package.json and the .js file
19:56Domenicand run `node script.js` inside the deploy.sh
19:56Domenicbe sure to update it to exit with return code 1 on failure
19:56tobieCool. That&#39;s perfect.
19:57tobieThat&#39;s what I had in mind, but wasn&#39;t too sure about all the details of handling multiple scripts.
19:57tobieAll set now. Thanks.
19:58Domenic\o/
20:09tobieDomenic: what did you do to jsdom!?!?!? it&#39;s about 2 orders of magnitude faster. o_O
20:09Sebmaster
20:09Domeniclol, dunno, lots of work over time
20:10tobieDomenic: I was running 9.6.0, apparently
20:11Domenictobie: ah, probably https://github.com/tmpvar/jsdom/blob/master/Changelog.md#971
20:12tobieDomenic: that sounds about right (and pretty close to 2 orders of magnitude indeed)
20:13DomenicI wonder how many poor souls are stuck on 9.5.0-9.7.0
20:42tobiewell, one less today. :)
21:05smaug____<a href=&quot;javascript:window.open();&quot; target=&quot;_blank&quot;> Should that open one or two windows
21:05smaug____I assume two, since that would make sense
11 Oct 2017
No messages
   
Last message: 6 days and 16 hours ago