2018-10-01 [22:11:51.0000] :P :D [00:25:04.0000] zcorpan, at 2018-09-30 19:19 UTC, MikeSmith said: https://github.com/bocoup/web-platform-tests.live/issues/2 is the issue about a /submissions replacement [00:25:23.0000] ya [11:12:48.0000] Sigh, trying to search for "http" on SpecRef returns every single reference in the database that has a url. [11:15:23.0000] Opened an issue for it https://github.com/tobie/specref/issues/478 [11:39:57.0000] https://github.com/html5lib/html5lib-tests/pull/108 — can someone more up to date with the html parser look at this? 2018-10-02 [20:59:49.0000] anybody know if there’s an official logo for Android WebView? [21:00:58.0000] I find something at https://cdnjs.loli.net/ajax/libs/browser-logos/41.0.0/android-webview-beta/ that looks familiar, but not certain that WebView is what that logo is really used for [21:28:37.0000] MikeSmith: for what it's worth, I've mostly seen this logo associated with the pre-Chrome built-in browser, https://github.com/alrra/browser-logos/blob/master/src/archive/README.md#android. That's not technically analogous to the WebView interface as used for embedded in apps though, not sure if you meant actual webview vs default browser. [21:30:20.0000] Krinkle: ah OK yeah I guess that’s where I recall seeing it from too [21:30:48.0000] and yeah I do want a logo for actual webview, not default browser [21:31:27.0000] right, a logo app developers would be familiar with, as opposed to end-users. [21:31:34.0000] yeah [21:32:14.0000] that specific context for me is, the data for MDN’s brower-compatibility tables includes WebView data, and I want to associate a logo with that when I show it [21:32:43.0000] similar to caniuse annotations in the HTML spec now [21:33:07.0000] but which don’t have WebView data (I guess because CanIUse doesn’t) [21:34:04.0000] Yeah, they don't track ios embedded webview and android webview currently. [21:34:09.0000] ua-parser does recognise it though. [21:34:22.0000] and yeah, behaviour does differ from a little to a lot. [21:35:14.0000] right [21:37:09.0000] I guess for ios webview, the WebKit logo would be most familiar, which since last year's redesign not matches the style of other developer api logos from Apple. [21:47:18.0000] Krinkle: well MDN doesn’t track browser-compatiablity data for ios webview, so I don’t need that one (yet) [21:57:30.0000] in theory it should state that safari has a broken navtiming implementation in webview :) [21:57:42.0000] (something I've been running into recently) [22:16:15.0000] Krinkle: oh [22:16:26.0000] weird that it would be different [22:17:14.0000] but I guess there’s some rationale for the difference (modulo the unintended brokenness) [01:30:13.0000] what's the right wpt directory for a reftest that tests the interaction of first-line, first-letter and float? [01:31:51.0000] ..in relation to bidi [01:38:21.0000] /me wonders how Microsoft feels about the 360 Secure logo/icon [01:43:53.0000] hsivonen: I'd use css/selectors [01:44:15.0000] annevk: even if it really tests float+bidi? [01:45:27.0000] hsivonen: yeah, it seems they'd still test those selectors otherwise you'd have left them out [01:45:59.0000] annevk: ok. thanks [01:46:16.0000] (deciding the directory for CSS tests is one of the hard problems of wpt) [01:48:19.0000] Tree structures for graph problems generally result in this [02:33:17.0000] aargh. "test case must have a link to a spec" [02:51:10.0000] CSS tests have their own weird requirements I guess? [02:51:21.0000] I wish they'd just align with the defaults we set elsewhere [03:51:09.0000] /me recommends hsivonen experiment with putting the empty string for the link URL, or else "#" [04:47:12.0000] JakeA: so I looked at Background Fetch's open issues and it seems there's still quite a few, including some I opened a long time ago [04:51:09.0000] annevk: I see https://github.com/WICG/background-fetch/issues/16 and https://github.com/WICG/background-fetch/issues/6. In terms of #16, I can't really see how it'd work. Grouping is needed for things like photo uploads, game downloads, movie downloads etc. Given the delivery of events is a particular service worker it feels like the API should hang off that particular service worker registration. [04:51:51.0000] annevk: As for #6. The spec uses keep-alive, but I'm happy to add test explaining this spec vs `sendBeacon` etc. [04:52:35.0000] JakeA: yeah, so to clarify, I'm not sure how relevant they still are, but it seems weird for them to not be resolved [04:52:50.0000] JakeA: esp if Google is keen on moving on [04:52:54.0000] annevk: Fair. I'll go through them tomorrow. [05:57:37.0000] annevk: appreciate the review btw [06:00:37.0000] JakeA: sorry it's taken so long to do another round [06:00:51.0000] JakeA: but it's mostly nits [06:04:21.0000] annevk: starting a spec on my own has taught me a lot tbh. Once this is 'done' it frees me up a bit. Anything I should move on to? I was thinking fetch observer [06:05:09.0000] JakeA: that'd be great; refactoring fetch so it returns a struct and doesn't queue tasks would also be cool, but rather involved [06:06:29.0000] annevk: fixing the task queueing might not be too bad, it's just going through everything that currently uses it and queueing tasks when needed. Is the struct thing so there's a concrete thing to abort etc? [06:10:18.0000] JakeA: yeah abort, concrete thing to take the response from if you don't care about callbacks and just want to use "wait", and maybe changing priority and such if that ever becomes a thing [06:45:02.0000] I always forget whether dictionary or sequence is possible, but I guess it is [07:03:35.0000] has anyone looked at all the specs from GDPR point of view? [07:03:50.0000] or is there some work ongoing perhaps [07:05:22.0000] I guess only very small set of specs need to be looked at [07:08:23.0000] smaug____: I'm not aware of any effort [07:09:29.0000] smaug____: I guess stuff like push notifications or geolocation might need some GDPR specifics depending on how you implement them? [07:10:17.0000] and maybe Reporting API [07:10:44.0000] That's on request from the site, so the site would have to manage that [07:22:07.0000] I blocked anshul1719 organiziation-wide [08:54:58.0000] annevk: do you recall some example where some synchronous algorithm needs to dispatch an event, say when an element is disconnected. [08:55:35.0000] I guess it needs to be defined somehow whether to fire event before or after CEReactions [08:56:50.0000] If sync it’s always before [08:57:05.0000] But we don’t define those atm… [08:57:39.0000] so no examples of this [08:57:40.0000] ok [09:00:07.0000] smaug____: mutation events are still tbd [09:00:40.0000] smaug____: suspect focus/blur might be affected [09:14:26.0000] right [09:14:42.0000] and this is about pointerevent's pointercapture handling when the target is removed from dom [10:29:44.0000] Hacking on browsers is fun [10:41:27.0000] annevk: gah the PRs messed up our CI status on master again... will try to fix [11:14:55.0000] Fixed [11:15:07.0000] https://github.com/whatwg/participate.whatwg.org/pull/33 should help for the future [11:46:12.0000] Domenic: I can r+ that, but I won't review the whole thing in detail, that okay? [11:46:38.0000] annevk: sure, although the actual code changes are pretty small. Also it's not urgent, unless we expect more of these to happen. [11:48:54.0000] Domenic: the actual code looks fine, assuming all the properties are correct 😃 [11:49:13.0000] Yeah, the tests help there, since I pulled that fixture directly from the webhook payload [11:54:31.0000] FWIW: there's been a bunch of html5lib/html5lib-tests PRs about error expectations recently if anyone who knows hte parser better than me atm can look? [12:16:28.0000] Browsers want to align on H/1 request serialization; HTTP editor dismisses entire topic; sigh [12:17:21.0000] Either H/1 becomes obsolete or Fetch will define aspects of it the way this is going… [13:35:56.0000] link? [13:36:41.0000] https://github.com/httpwg/http-core/issues/137 [13:39:08.0000] https://github.com/httpwg/http-core/issues/136 is also lovely. What a helpful group of folks. [13:51:17.0000] is there any evidence of H/1 serialisation as in #137 actually causing issues? [14:20:53.0000] Domenic: how does one test if a stream is cancelled [14:21:04.0000] or anyone i guess [14:49:00.0000] Domenic: https://github.com/httpwg/http-core/issues/136#issuecomment-424489058 is gold [14:49:37.0000] > Even if five major browsers caught fire and imploded upon receipt of multiple challenges, that would only increase the need for those parsers to be fixed (somehow). We can't control the bits received. The easiest fix is to simply parse the field as specified, since that's what the non-browser UAs have been doing for ages. [14:52:56.0000] some serious regime change has been needed there for a long time [14:53:26.0000] the web platform needs a CIA [14:53:40.0000] with a Seal Team 6 [14:54:51.0000] and the IETF needs an Arab Summer [14:57:45.0000] “the web should just work the way I claimed it does in my disseration” [14:58:19.0000] the Web: “I don’t actually work that way. I never have, actually.” [15:02:35.0000] Dunno about the Seal Team 6 part, but I do like the picture of web pages, in all their dissertation-violating glory, filling the streets of the internet to protest unevenly-implemented de jure specs. [15:10:53.0000] literal anarchy [15:36:35.0000] devsnek: https://github.com/web-platform-tests/wpt/blob/master/streams/readable-streams/cancel.js#L59 [15:36:50.0000] ic [15:37:02.0000] Although the recordingReadableStream utility should make this easier, trying to find a usage of that [15:37:12.0000] async makes everything harder 😢 2018-10-03 [01:05:26.0000] smaug____: thanks for the review. can you help running it through try? [01:09:39.0000] (or whatever the right next step is) [01:12:09.0000] I added checkin-needed keyword to the bug [01:31:51.0000] https://hg.mozilla.org/integration/autoland/rev/7da26bb326de [02:09:35.0000] zcorpan_: thanks for the patch [02:09:47.0000] I guess it landed already, so no need for try [02:10:02.0000] it gets backed out if something breaks :) [05:13:14.0000] smaug____: it got backed out. Someone needs to reopen the review for me to be able to update it, I think [05:13:54.0000] reopen review? [05:14:05.0000] can't you just push a new patch for review? [05:14:25.0000] or if pabricator is annoying, just upload a patch to the bug itself [05:17:51.0000] smaug____: we managed to reopen and update https://phabricator.services.mozilla.com/D7420 [05:20:21.0000] smaug____: ok to add checkin-needed again? [05:20:44.0000] zcorpan_: can you land it? [05:20:56.0000] on the right there is something about "Lando" [05:21:13.0000] and there should be, IIRC, button to land [05:21:57.0000] "Unfortunately, you can only login to this website using Mozilla LDAP." [05:22:18.0000] oh, you don't have permission or something [05:22:22.0000] ok, let me tryu [05:22:23.0000] try [05:22:32.0000] thx [05:23:16.0000] it landed something :) [05:23:23.0000] (I don't really use phabricator yet) [05:25:07.0000] cool [05:25:17.0000] will the bug be closed automatically? [05:26:44.0000] Should be [07:35:56.0000] we don't have any issue tracker for meta web platform issues, do we? like, e.g., go through all the confluence data of Chrome/Safari only stuff and figure out how much of it is WebKit legacy that should be dropped/spec'd, given it won't show up elsewhere in views of "only one UA" [07:39:53.0000] No [07:42:17.0000] There's a webcompat repo that might work? 2018-10-04 [18:18:28.0000] Domenic: service workers have their own environments right? (as in, a separate environment from the Window that created them) [18:18:47.0000] domfarolino: yes [18:19:17.0000] Is it safe to assume then, the environment's creation URL would be the service worker's url? (https://w3c.github.io/ServiceWorker/#dfn-script-url) [18:19:40.0000] Depends on how they set up the environment... [18:20:16.0000] https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm seems to indicate so [18:21:19.0000] Exactly what I was looking for. Thanks [22:49:23.0000] “WhatWg is a controversial group. Their specs don't always follow official standards but Python does.” — https://bugs.python.org/issue34875#msg327006 [23:03:12.0000] mathiasbynens: haha [23:04:04.0000] recently somebody went in to some MDN articles and changed the text/javascript mentions to application/javascript [23:04:20.0000] based on that same rationale I guess [23:04:31.0000] I changed them back [23:25:38.0000] MikeSmith: ♥ [23:31:15.0000] annevk: Since in main fetch, we always generate request referrers (unless the `no-referrer`), you'd expect requests "passing through" a service worker to always have their referrer set to the service worker's URL no? [23:35:43.0000] (SW's URL because webappsec rp sets "client" referrers to the environment's creation URL)...oh wait, actually I think requests passing through a SW will only have their referrers set to the SW's URL in the case where a SW forwards the request with a non-empty RequestInit, resetting referrer to "client" (https://fetch.spec.whatwg.org/#ref-for-concept-request-referrer%E2%91%A0%E2%91%A0), and using SW's URL [23:37:21.0000] If that's right, I guess it feels a little strange that SW requests will have non-SW-URL referrers if the SW fetches w/o RequestInit...seems almost unrelated hmm [00:55:23.0000] domfarolino: for passthrough it would already be initialized to a URL [00:56:54.0000] domfarolino: and that is intentional so that adding a SW doesn’t impact observable bits (hence passthrough) [04:28:47.0000] annevk: gotcha, we’d only reset it would for non-null RequestInits though though it seems. (i.e., if the SW “pass through” used fetch(..., {nonNull})) [04:56:41.0000] domfarolino: yeah, because if the SW muddles with it, the SW gets the blame [05:42:55.0000] Makes sense. Doesn’t seem as arbitrary now 👍 [08:53:05.0000] "wasm" is the word of the day on wiktionary today [09:07:17.0000] nice! [09:07:52.0000] Even better when you read it https://en.wiktionary.org/wiki/wasm#English [09:08:10.0000] Is a WebIDL dictionary "empty" if it contains no specified members, but was given unspecified/unexpected members? [09:08:40.0000] domfarolino: yes. The conversion from the JS object to Web IDL dictionary produced an empty dictionary. [09:08:48.0000] perfect [09:08:55.0000] Extra members that are not specified in a dictionary's definition never get copied over into the dictionary structure [09:09:30.0000] That's what I expected. cool [09:16:32.0000] ...and of course I forgot to just check https://heycam.github.io/webidl/#es-dictionary [11:37:41.0000] Can document.domain share between http: and https:? [11:41:10.0000] Signs point to yes [11:59:55.0000] Domenic: so the spec is wrong? (at least the spec seems to require two origins to have schemes that are equal to be considered same origin-domain) [12:03:47.0000] Mek: well I was reading the spec, so more likely I misread it :) [12:04:49.0000] isn't the last example at https://html.spec.whatwg.org/multipage/origin.html#same-origin-domain your case? I.e. everything the same except http vs https, are not same origin-domain [13:58:47.0000] Mek: ah yes you are right [14:20:25.0000] Domenic: MDN annotations at https://arcane-cove-57093.herokuapp.com/multipage/ now have browser-support tables [14:20:54.0000] in the same style as the caniuse ones [14:21:24.0000] except at a higher level of granularity [14:22:12.0000] marked up with
/ 2018-10-05 [18:24:56.0000] does “x” part of “dppx”, “x” at https://drafts.csswg.org/css-values/#x mean that media (min-resolution: 2dppx) { ... } [18:25:06.0000] oofs [18:25:21.0000] .. mean that media (min-resolution: 2dppx) { ... } [18:25:26.0000] sigh [18:25:51.0000] .. mean that media (min-resolution: 2x) { ... } is valid? [18:26:30.0000] 2x and 2dppx are equivalent? [18:54:18.0000] fun fact of the day: the only setter defined in ECMA-262 is Object.prototype.__proto__ [20:02:50.0000] MikeSmith: omg. Gaaahhh I gotta make time to get that all merged. [20:08:42.0000] Domenic: no rush I may be futzing with it further [20:09:12.0000] I want to get feedback from TabAtkins on it, in the context of adding similar support in Bikeshed [20:11:34.0000] Yeah makes sense [23:36:59.0000] Domenic: only cookies leak across the scheme-boundary afaik [23:37:24.0000] Domenic: since new things are SecureContext that should remain so… [01:37:34.0000] A `long` argument accepts `Infinity` just fine, right? [01:37:51.0000] https://html.spec.whatwg.org/multipage/canvas.html#2dcontext:dom-context-2d-putimagedata [01:38:18.0000] https://github.com/web-platform-tests/wpt/blob/master/2dcontext/pixel-manipulation/2d.imageData.put.nonfinite.html#L23 [01:38:25.0000] Is the spec or the test wrong? [01:38:42.0000] I dunno, float/double has an unrestricted variant [01:39:05.0000] Not sure why long is designed differently, probably because this came later... [01:39:08.0000] Yeah but those are longs. [01:41:29.0000] nox: if there are no extended attributes my reading of https://heycam.github.io/webidl/#abstract-opdef-converttoint suggests you should get +0 [01:42:04.0000] Yeah I doubt the conversion code we use in Servo is wrong, so either a spec or test bug. Given all browsers pass the test I guess it's a spec bug. [01:43:35.0000] nox, no, Infinity wraps to 0 [01:43:46.0000] That's what I'm saying. [01:44:26.0000] I'm curious how https://github.com/whatwg/html/commit/362c9315971af63dbba49ef171644312c721444f landed when the TypeError throw test is right there already. [01:45:11.0000] Oh, wait [01:45:19.0000] Could it be that putImageData was float-based before? [01:45:21.0000] Ah Chrome doesn't pass the test. [01:45:47.0000] Ah, you pointed to that commit [01:46:58.0000] nox: it seems those tests were forgotten when other tests were updated [01:47:29.0000] There we are [01:49:07.0000] So the tests are wrong? [01:49:55.0000] Yes [01:51:27.0000] Aah, pre-browser bug era [01:51:30.0000] Bad [01:51:51.0000] Pre-browser? [01:51:58.0000] pre-(browser bug) [01:52:22.0000] Or more specifically, before the policy of filing browser bugs [02:02:45.0000] Another question, [02:02:53.0000] why is this line supposed to do something? https://github.com/web-platform-tests/wpt/blob/master/2dcontext/pixel-manipulation/2d.imageData.put.dirty.rect2.html#L33 [02:03:22.0000] if dx = -20 and dirtyWidth = 20, wouldn't everything that needs to be drawn fall outside the canvas surface? [02:06:48.0000] "For all integer values of x and y where dirtyX ≤ x < dirtyX+dirtyWidth and dirtyY ≤ y < dirtyY+dirtyHeight, copy the four channels of the pixel with coordinate (x, y) in the imagedata data structure's Canvas Pixel ArrayBuffer to the pixel with coordinate (dx+x, dy+y) in the rendering context's output bitmap." Am I being dumb? [02:07:17.0000] Oh yes I am, completely misread that. [06:40:06.0000] can anyone remember why wasn't used? IIRC, it put IE/Mac into quirks, but I can't find a citation for that? [06:53:04.0000] gsnedders: based on my blog post I tried to find corresponding mailing list discussion and I couldn't find any [06:53:14.0000] gsnedders: I'm not sure I tried to trace IRC [06:53:30.0000] annevk: searching for it is way too hard given search engines and punctuation :( [06:53:35.0000] gsnedders: but I basically lost the plot how we decided on this [06:53:45.0000] other than the blog post I wrote, which is easy to find [06:54:05.0000] I'm pretty sure I remember being discarded because it put some UA into quirks. [06:54:17.0000] clearly I should link more [06:56:55.0000] So Firefox, unlike Chrome and Safari, does discard empty headers when combining multiple headers, that's nice [06:58:22.0000] Edge does it wrong too, hurray [06:58:54.0000] To be fair, neither Fetch nor XHR says anything about this [10:57:57.0000] annevk: were you going to finish https://github.com/whatwg/html/pull/3656 ? [11:50:06.0000] Domenic: There's no way to "export" from an inline module script, right? (Or equivalently, to set something on the global, without a cooperating non-module script?) [11:52:04.0000] Oh dang, never mind, I must have mistyped or something. You do have access to `window`, so you can explicitly set things on it that'll be visible to the rest of the page. 2018-10-06 [08:10:39.0000] now that my tests aren't with the changes to the reference impl anymore, how does one continue running them [09:36:54.0000] devsnek: you can change the submodule commit in whatwg/streams to point to your branch [09:37:07.0000] by cding into that directory and doing normal git stuff [09:37:31.0000] well i wanna test before i push [09:37:36.0000] i suppose i can symlink it [09:38:27.0000] oh i could just do all the actual work in that directory [09:38:29.0000] lmao [12:41:13.0000] devsnek: you can also add your other local checkout as a Git remote of the submodule [16:00:59.0000] I would like to suggest that NodeIterator be made iterable. [16:01:39.0000] Currently, attempting to iterator over a NodeIterator using a for-of loop will cause an "is not iterable" TypeError [16:04:39.0000] This is fairly easy to work around or polyfill, but it seems reasonable that the interface itself be made iterable given its name. [16:20:36.0000] Here is an example of a hypothetical polyfill: https://gist.github.com/dshepsis/65b2f305bb408085f6477edf49ff7d10 2018-10-07 [17:32:56.0000] dshepsis: sounds reasonable, could you file an issue at https://github.com/whatwg/dom? [20:28:41.0000] Got distracted, but I made that issue https://github.com/whatwg/dom/issues/704 TimothyGu [20:28:58.0000] please let me know if I've made an error in creating it. [08:24:33.0000] this test should work right? https://gist.github.com/devsnek/a4cd2eccb0f7a6ca9c3c39984db4eaf3 [11:52:48.0000] devsnek: yeah [11:53:50.0000] so there's a bug in the reference implementation then :( [11:54:06.0000] fun times 2018-10-08 [21:34:14.0000] devsnek: just a bug in our @@asyncIterator implementation right? If so, that's why we write the tests :) [21:34:40.0000] Domenic: yep [21:35:02.0000] I saw your comment about Object.prototype somewhere, that's more of an issue with the test runner/jsdom stuff :-/ [21:36:58.0000] Domenic: what is it doing to my prototypes :-/ [21:37:38.0000] We run the reference implementation in Node.js and the tests inside a jsdom (vm) realm [21:37:52.0000] We should run them both in the vm realm I guess but then we'd need to browserify the reference implementation [21:38:16.0000] See https://github.com/whatwg/streams/blob/cf76fa899a142a6e834049b6ce6c37859bdb5f68/reference-implementation/run-web-platform-tests.js#L55-L64 basically [21:38:34.0000] oof [21:38:59.0000] More yaks to shave [21:40:26.0000] what if you just inject require into the vm [21:42:36.0000] Hmm yeah that might work too [21:43:19.0000] Although I'm not sure, I guess it might depend on whether the require cache contains them or not [04:46:30.0000] I'm not really familiar with Blink, but https://chromium-review.googlesource.com/c/chromium/src/+/1264536/2/third_party/blink/renderer/core/frame/csp/content_security_policy.cc seems indicative of some API problem [04:46:46.0000] You should never be able to encode something to UTF-8 without the replacement policy... [04:47:05.0000] I guess I'll comment on the PR [04:49:34.0000] Hmm PR, changeset [05:21:32.0000] is there any way to distinguish an auxiliary browsing context which has been disowned from any other non-auxiliary top-level browsing context? [05:22:14.0000] a) That part of the specification is broken b) Yes [05:22:41.0000] You can basically not become non-auxiliary [05:23:29.0000] b) how? [05:28:20.0000] gsnedders: it depends a bit on how we end up defining window name searching, but it's still in the same name group after you set opener to null [05:28:40.0000] gsnedders: if we're instead talking rel=noopener then note that would imply creating a new top-level browsing context, not an auxiliary browsing context [05:29:13.0000] (and likely also a new "browsing context unit", which is also poorly defined) [05:30:13.0000] bah, noopener isn't supported in Edge still :/ [05:43:11.0000] annevk: https://html.spec.whatwg.org/#following-hyperlinks-2 makes it seem like rel=noopener with target=_blank creates an auxiliary browsing context and then immediately disowns it, so should be the same, no? [05:47:44.0000] gsnedders: again, that's broken 😃 [05:49:21.0000] annevk: so what does noopener actually do in impls? :P [05:50:54.0000] do we have a bug for this? I can't see any searching quickly? [05:53:56.0000] gsnedders: hmm, there's multiple [05:54:20.0000] gsnedders: https://github.com/whatwg/html/issues/1509 https://github.com/whatwg/html/issues/1826 etc. [05:57:20.0000] annevk: none of those cover noopener creating a non-auxiliary? [05:59:48.0000] The second one does… [06:01:06.0000] oh, that isn't at all clear :/ [06:06:00.0000] Anyway, there are many related issues [06:06:46.0000] So once all of these are fixed, will you still be able to distinguish disowned auxiliaries? maybe, depending on what exactly named targets do, and what group they look in? [06:07:43.0000] gsnedders: what do you mean by disowned? [06:08:37.0000] annevk: https://html.spec.whatwg.org/#disowned-its-opener [06:09:16.0000] gsnedders: that doesn't really help, what matters is what endpoint you are using [06:09:30.0000] gsnedders: as I tried to point out before, the spec is broken, so whatever concepts it has are not useful for communication [06:10:05.0000] /me doesn't know how to express the concepts *except* as the spec defines them :( [08:45:28.0000] gsnedders: eg, is this about rel=noopener behavior or setting opener? Something else? [08:53:23.0000] annevk: this is "how using WebDriver can we get something that appears to be the same as a new window/tab opened by a user?" [08:53:55.0000] gsnedders: noopener should do that [15:01:52.0000] Domenic: s/"none"/"omit" in the second line of the commit msg in https://github.com/whatwg/html/pull/3656#issuecomment-427898470 perhaps? [15:02:17.0000] domfarolino: thanks yeah, will edit 2018-10-09 [04:15:16.0000] hsivonen: https://bugs.chromium.org/p/chromium/issues/detail?id=691985 Chrome erroneously defaulting to UTF-8 btw [04:21:32.0000] hsivonen: it's rather frustrating they're not really doing anything about it [05:37:15.0000] Domenic: I'm interested in sorting this https://github.com/jsdom/jsdom/issues/2386 [05:37:50.0000] should I make a new issue in https://github.com/whatwg/html ? [05:38:20.0000] I couldn't find any related issue from a quick search, only for the `html` part's case [05:38:29.0000] XhmikosR: that doesn't seem like something we can change the serialization for at this point [05:38:40.0000] XhmikosR: or are you saying browsers do this differently? [05:38:54.0000] it works fine with lowercase `doctype` [05:39:02.0000] but the spec says uppercase [05:39:16.0000] XhmikosR: yes, because that's how the API works today, right? [05:39:25.0000] XhmikosR: we can't just change the API contract [05:40:42.0000] XhmikosR: https://whatwg.org/working-mode might help [05:42:06.0000] I just find it weird that all browsers seem to work fine with lowercase `doctype` yet the specs say uppercase, so it seems like something that could be adapted, that is why I ask :) [05:42:35.0000] XhmikosR: they work fine with uppercase too, but input isn't what this is about [05:42:49.0000] true [05:42:50.0000] XhmikosR: this is about serialization and the question is what happens there and what tooling around that serialization might depend upon [05:44:08.0000] I don't know, when it comes to the W3C repos, I get lost :P [05:45:05.0000] anyway, just wondering if we can allow this or not, if not I guess I'll try to find a workaround so that I keep the `doctype` lowercase. It's just that more tools do this, even cheerio 1.x IIRC [06:34:47.0000] XhmikosR: annevk is right, serialization is not something we would change. For more on why parse/serialize rountrips never preserve the original, see https://github.com/inikulin/parse5/issues/261#issuecomment-401389295 [06:35:31.0000] yeah, I got it :) Too bad, I guess we are stuck with this [06:50:00.0000] I don't understand. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6264 shows no button appearance in chrome on macOS. But if I open the "Rendered view" in a new tab it does! [06:51:42.0000] zcorpan: identical on Canary [06:52:00.0000] zcorpan: High Sierra though [06:52:23.0000] I also have High Sierra [06:52:45.0000] Sounds like you could use Canary :p [06:53:44.0000] I get the same result in Canary [06:54:47.0000] oooooh [06:54:54.0000] I have non-100% page zoom [06:55:17.0000] oh my [07:11:40.0000] https://bugs.chromium.org/p/chromium/issues/detail?id=893597 [08:16:10.0000] Domenic: "domenic seems to be fine with the pseudo-stream design." - not reading that out of your comment... quite the opposite? https://github.com/w3ctag/design-reviews/issues/303#issuecomment-422235381 [08:19:37.0000] Or did I misinterpret something? [08:26:02.0000] lgrahl: fine until they try to ship it [08:26:12.0000] 😊 [08:26:16.0000] annevk: Heh :) [08:27:21.0000] And yeah, let’s not do another “we’re not convinced of your future so we’ll do our own API design” again [08:29:06.0000] What I find quite funny is that they have just started refactoring their streams from bidirectional to unidirectional... guess which API [08:32:51.0000] But since they just ignore my comments entirely... [08:38:29.0000] I’m sorry, that sounds really bad [08:38:37.0000] Is this on GitHub? [08:47:22.0000] Ah, no worries, I'm just a bit fed up with them. You mean the unidirectional PR? It's here: https://github.com/w3c/webrtc-quic/pull/70 [08:51:13.0000] Not seeing comments of you there and do see some signs of the Streams API [08:51:47.0000] Ah, QUIC, prolly some ways away still [08:55:56.0000] I'm not seeing signs of the Streams API? Or do you mean just general similarities? [08:57:50.0000] (I haven't commented in the PR since there was no reaction to https://github.com/w3c/webrtc-quic/pull/53#issuecomment-420553744) [09:44:55.0000] lgrahl: I might have read too much into the mention of ReadableStream [09:46:30.0000] lgrahl: as long as https://github.com/w3c/webrtc-quic/issues/2 remains open I guess I’m not gonna say much [09:46:58.0000] annevk: Not sure I like the "icebox" label though :) [09:47:07.0000] lgrahl: I could add a comment there that Mozilla would highly likely object to any design that does not use them [09:47:10.0000] I see [09:47:28.0000] I guess I should comment tomorrow then 😟 [09:49:24.0000] I mean, let's be honest, the advantages of the Streams API are obvious and many others will object to the current design. The only risk that I see is that they at some point say "But meh, the implementation is done and redesigning the API would take too long." [09:51:45.0000] The QUIC API hasn't even been accepted by the WebRTC WG so far. I'm pretty sure Jan-Ivar would also reject it in its current state. [09:58:05.0000] As you say, Mozilla will likely object to it and thus they are just making it hard for themselves. [10:03:56.0000] Added a comment [11:14:01.0000] annevk: Cheers! Just hope I haven't started a feud here... :) 2018-10-10 [06:03:31.0000] Domenic: how would createdCallback maintain the same invariants the constructor has to maintain? [06:04:10.0000] Domenic: it seems to me that it can't [07:02:47.0000] annevk: I don't really understand. They're just two pieces of user code one after the other. Everything you can do with the constructor you can do with createdCallback. [08:06:35.0000] Domenic: right, I figured out the same thing meanwhile and commented on the issue [09:55:18.0000] annevk: do you want to sprinkle "topic: browsing context" on a bunch of https://github.com/whatwg/html/issues?q=opener+is%3Aopen+sort%3Aupdated-desc ? Not sure what your criteria was for it [11:53:35.0000] They should have it [11:53:55.0000] Can do tomorrow I suppose 2018-10-11 [05:16:24.0000] zcorpan: did https://github.com/whatwg/html/pull/4079 affect any other implementations? [05:16:32.0000] zcorpan: it'd be good to have impl bugs in that case [05:21:24.0000] annevk: yes. I'll file [05:21:41.0000] zcorpan: thanks, I also have a PR coming up with an editorial nit [05:26:06.0000] firefox doesn't seem to run the test to completion [05:26:36.0000] oh wait no it did [05:29:33.0000] but noopener doesn't seem to do anything in firefox for this test. Did it work before? [05:33:17.0000] i don't actually know [05:33:41.0000] perhaps it was blocked on figuring out the interaction with CSSOM stuff? [05:34:53.0000] hmm no, no open bugs [05:35:00.0000] (about that in particular) [07:00:20.0000] Help (need to sync html5lib-tests to wpt)? https://bugs.chromium.org/p/chromium/issues/detail?id=704534#c8 [09:32:01.0000] <`slikts> the streams api faq calls observables a bad fit for i/o -- why is that? [09:32:11.0000] <`slikts> just because of no backpressure? [09:46:36.0000] Multiple consumers also seems like a key difference [09:48:05.0000] Note also how streams has a bunch of branching to do bytes really well [09:51:05.0000] <`slikts> doing bytes well would be a reason why streams are better, not why observables are bad for io, and I'm not sure why multi-consumer is bad for io [09:51:41.0000] <`slikts> just trying to understand [09:52:37.0000] <`slikts> the only thing clear so far is that since there's no (async) backpressure, too much streaming would degrade the performance for other things running in the thread [09:56:17.0000] Multi-consumer means memory bloat to some extent [09:56:28.0000] And backpressure is imp [09:57:34.0000] <`slikts> you could still have just one subscriber even with observables, though [09:58:49.0000] <`slikts> just like you can fork streams and have more, it's just single by default [10:01:26.0000] <`slikts> I don't particularly like observables, though, based on this presentation: https://docs.google.com/presentation/d/1r2V1sLG8JSSk8txiLh4wfTkom-BoOsk52FgPBy8o3RM [10:02:06.0000] <`slikts> where it compares how much simpler implementing the combinators becomes with async iterables and generators [10:14:04.0000] Yes but you’d need to buffer in case someone else subscribes later? Maybe that is not how that works, but it seems transferables would break down at least [10:20:42.0000] <`slikts> subjects don't buffer; they're like event emitters, the events go nowhere if there's no subscribers [10:22:02.0000] <`slikts> I'm not deeply familiar with observables, though, so not confident about anything [10:27:57.0000] Transferables only work 1:1 [10:58:06.0000] good times http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6278 [11:06:26.0000] `slikts: as annevk briefly mentioned, you lose data with observables since they only push out to current subscribers. You can layer stuff on top of obesrvables (or EventTarget) to fix this, like adding your own buffering. But it's awkward and nonstandard. [11:09:07.0000] <`slikts> Domenic: I see, thanks 2018-10-12 [17:25:20.0000] at that point use a stream [22:22:52.0000] should HTMLDocument be considered deprecated? [22:24:12.0000] if browsers are required to implement it and there are no plans to ever remove it from the platform, then it seems like it shouldn’t be classified as deprecated [22:27:52.0000] sure it’s just specified as an alias for Document, but it’s still specified [23:41:39.0000] MikeSmith: where is it classified as such? [23:42:15.0000] MikeSmith: there are still some open issues around defining it unfortunately [23:52:49.0000] annevk: in MDN and in https://github.com/mdn/browser-compat-data [23:53:02.0000] I updated MDN and will make a PR for https://github.com/mdn/browser-compat-data [23:54:35.0000] in MDN and in that BCD data, some things seem to be flagged as deprecated just because they’re not useful [23:55:14.0000] e.g., NavigatorID: appName and such [23:55:39.0000] will fix those too [01:39:57.0000] MikeSmith: interesting, I guess someone had opinions [02:51:14.0000] https://github.com/httpwg/http-core/issues/148 this took me a while [04:58:57.0000] <`slikts> are there plans to add async iteration to EventTarget [05:02:37.0000] `slikts: https://github.com/whatwg/dom/issues/544 [05:03:05.0000] `slikts: it's unclear whether that or async iteration is really a good fit though, as event listeners are called synchronously [05:06:37.0000] <`slikts> that is about observables, however; what I meant is async iterables [05:06:54.0000] <`slikts> I strongly believe eventtarget should support the language's native async primitive for streams [05:07:35.0000] <`slikts> I've made a library for adapting streams to async iterables in the interim; I'll share it in a moment after updating its readme [05:07:52.0000] <`slikts> it's like streams api-lite [05:08:07.0000] <`slikts> just because I want to use these things now [05:09:08.0000] `slikts: yeah, async interables aren't quite compatible [05:09:26.0000] `slikts: does your library handle invoking preventDefault() from a listener? [05:09:40.0000] `slikts: (observables have the same issue) [05:10:01.0000] `slikts: (and the idea was that both observables and streams would also impl the async iterable protocol) [05:10:36.0000] <`slikts> I've not looked into it that deeply; just in the abstract [05:10:57.0000] <`slikts> I'll read the thread a bit later [05:11:41.0000] `slikts: FWIW, I'm very supportive of adding a better API on top of events somehow, the problem is finding something that's the right fit [05:12:04.0000] <`slikts> there won't be a better fit that what's supported natively [05:12:13.0000] <`slikts> in the base language [05:12:50.0000] <`slikts> *than [05:13:00.0000] If by that you mean async iterables, see above about it not working with everything events can do... [05:13:19.0000] You cannot reframe things on top of a primitive that's a feature mismatch [05:14:30.0000] <`slikts> where there's a will... [05:15:08.0000] <`slikts> I mean, it's already questionable whether observables will make it in since they overlap with async iterables [05:15:33.0000] Observables also fail the preventDefault() test [05:15:37.0000] <`slikts> so an alternative async stream primitive with even less mindshare is even less likely [05:16:45.0000] Something that works for events would be fine [06:19:19.0000] <`slikts> here's the library: https://github.com/slikts/queueable [06:19:31.0000] <`slikts> still wip; I'm adding documentation, demos [06:46:07.0000] So TabAtkins if you're there, do we have that feature yet where you can find who links your spec definition? [06:54:55.0000] annevk: Hey! I have a question regarding https://fetch.spec.whatwg.org/#cors-check and the use of origin-or-null. IIUC, a "null" origin would match a case where the request has a tainted origin. Should we match that in RT's TAO processing in https://w3c.github.io/resource-timing/#sec-timing-allow-origin? [06:55:43.0000] yoav: what do you currently do? [06:56:09.0000] yoav: it’s also for opaque origins [06:56:20.0000] annevk: current processing just compares the document's origin to the header value, and fails if they don't match [06:56:57.0000] but not special casing "null" [07:00:13.0000] yoav: byte-for-byte-comparison is what's supposed to happen [07:00:49.0000] OK [07:01:17.0000] yoav: so "null" automatically works; it's not specialcased in CORS check either [07:02:16.0000] yeah, but IIUC, it's "generated" in https://fetch.spec.whatwg.org/#serializing-a-request-origin [07:02:25.0000] which RT is not using (but maybe it should...) [07:03:40.0000] yoav: does RT have a request header that carries an origin? [07:04:11.0000] not really, the origin comparison are based on the document's origin [07:04:31.0000] so we can't use Fetch's algorithm directly (unless we abstract it a bit) [07:05:03.0000] yoav: so then you also can't have a tainted origin [07:05:16.0000] annevk: `slikts: see https://stackoverflow.com/questions/39439653/events-vs-streams-vs-observables-vs-async-iterators [07:05:18.0000] yoav: which is probably broken [07:05:30.0000] Async iterables are pull, and a bad fit for events [07:05:53.0000] Observables are push, and a reasonable fit for events. They work fine with preventDefault. [07:05:59.0000] yoav: if the response was gotten via redirects that did something malicious [07:06:07.0000] <`slikts> Domenic: they're quite nice for certain applications where you could want to skip events, like frames or mouse moves [07:06:18.0000] ReadableStreams are becoming async iterators already. [07:06:31.0000] <`slikts> Domenic: yeah, I follow that issue [07:06:54.0000] <`slikts> the thing about it is that async iterables are in the language now [07:07:02.0000] <`slikts> observables might never be in it [07:07:30.0000] <`slikts> and observables wouldn't have niceties like generator functions and for-await-of [07:07:55.0000] Domenic: except for promise-returning methods [07:08:06.0000] <`slikts> also, async iterables aren't just pull, they're pull-push [07:08:21.0000] "in the language" is not an interesting distinction. [07:08:28.0000] yoav: open an issue? I can investigate a bit [07:09:05.0000] Those niceties make no sense for events because those niceties are fundamentally pull (e.g. they buffer and operate on promises which breaks preventDefault) [07:09:06.0000] <`slikts> Domenic: it for sure is; having native support, for example, means that engines will focus on optimizations [07:09:12.0000] That's not true [07:09:14.0000] <`slikts> as they have already with async iterables and promises [07:09:31.0000] As an implementer I can guarantee you optimizing user code is just as important [07:09:35.0000] annevk: There's https://github.com/w3c/resource-timing/issues/152 which I thought was a small plumbing issue [07:09:47.0000] Built in things start out slow and catch up to user code as we've seen with promises [07:10:33.0000] <`slikts> Domenic: moreover, it's about optics and stability -- a native feature has official approbation and it also won't get yanked away at stage 3 [07:10:42.0000] annevk: but now sounds like potentially something to go with the larger scale Fetch integration [07:11:15.0000] <`slikts> Domenic: it's also about familiarity -- iterables and promises are already familiar to many users [07:11:35.0000] Well, can't really help you with your perception. All I can say is we're not going to base events on async iterables since that's a mismatch; it's like basing them on numbers or something else totally inappropriate. [07:12:03.0000] yoav: well, some of this can probably be done without all that, but who knows [07:12:08.0000] yoav: relying on https://tools.ietf.org/html/rfc6454 is broken too [07:12:32.0000] <`slikts> Domenic: even if it's a mismatch, calling it totally inappropriate is an overstatement [07:13:03.0000] Dunno if broken, but definitely seems better to use the same primitives as Fetch [07:13:12.0000] <`slikts> they're somewhat isomorphic concepts, if that makes sense [07:14:23.0000] yoav: that entire RFC is replaced by concepts in HTML, URL, and Fetch, but maybe, I guess it depends on the specific usage [07:15:45.0000] <`slikts> observables are just stage 1; it's really hard to sell people on something like that [07:16:06.0000] Observables are a library [07:16:11.0000] yoav: but yeah, seems like there are a number of issues here, some more easy to fix than others [07:16:20.0000] You are using a different notion of "isomorphic" than the accepted one [07:16:25.0000] <`slikts> Domenic: it's even harder to sell people on libraries [07:16:39.0000] <`slikts> Domenic: yeah, I qualified it with "somewhat" [07:16:41.0000] Well, not sure why you need to be selling anything here [07:16:43.0000] <`slikts> you need to squint [07:16:59.0000] <`slikts> Domenic: not here; in general [07:17:13.0000] <`slikts> something being "sold" determines if you get to use it in many cases [07:17:30.0000] <`slikts> it's the difference whether you can use it for a hobby project or something more serious [07:17:44.0000] <`slikts> and get other people to collaborate, build an ecosystem, etc. [07:18:41.0000] <`slikts> I'm very entusiastic about reactive programming, but it's just being realistic that observables have a lot of things working against them [07:18:59.0000] <`slikts> async iterables are a way to get a foot into the door [07:19:13.0000] Yeah, I think they need to stand on their own merits, without language support. [07:19:15.0000] <`slikts> since those, too, are declarative and can be used reactively [07:19:45.0000] <`slikts> above all it's about selling the concept of transformative pipeline programming [07:37:19.0000] Almost ready to define new infrastructure for HTTP header parsing [07:37:37.0000] And then define parsing of all the HTTP headers, to some extent [07:37:46.0000] Content-Type and Content-Length at least, I guess [07:41:00.0000] This is a little exciting [08:03:43.0000] annevk: Any Fetch/HTML WPTs you know if that I can rip off when it comes to testing opaque origins and origin comparison in general? [08:10:49.0000] yoav: not offhand, but there is cors/ and fetch/api/cors/ [08:11:35.0000] ok, cool. I'll look for it [08:15:12.0000] annevk: Would appreciate if you could take a look at https://github.com/w3c/resource-timing/pull/172 and let me know if it seems reasonable [08:16:37.0000] yoav: you need document’s origin in DOM, not the type it holds [08:17:29.0000] yoav: and origins are always serialized in “ASCII” which is why we dropped that from the term [08:18:09.0000] Prolly ok otherwise but omw home on a phone [08:21:39.0000] annevk: not sure what you mean by "you need document’s origin in DOM, not the type it holds" [08:22:10.0000] (none of this is urgent by the way, so we can continue next week if that's better for you) [09:54:57.0000] yoav: you ref concept-origin in HTML, that’s a type [09:55:19.0000] yoav: you want the link I gave in the comment [09:55:34.0000] yoav: that’s a slot on document [10:24:18.0000] annevk: Not yet, no. [10:27:40.0000] TabAtkins: Google search found four so far, so there’s that [11:05:10.0000] https://stackoverflow.com/questions/52771970/use-fetch-streams-api-to-consume-chunked-data-asynchronously-without-using-recur [11:53:20.0000] MikeSmith: so the problem is OOM due to promise allocation? [11:55:03.0000] MikeSmith: if true, I guess that is something not all browsers have tried to optimize and was kind of indicated to be a problem of sorts [11:56:13.0000] MikeSmith: the difference between the two scenarios is 10x promises afaict [14:44:16.0000] annevk: yeah based on “The browser dies at about 50,000 JSON objects” I guess OOM 2018-10-13 [13:36:43.0000] OK, so I'm trying to test Timing-Allow-Origin behavior of an opaque origin iframe, and realizing there's no way for me to communicate the test results from iframe to parent (as it's a cross-origin frame). Is there some way for me to communicate that info? Or somehow set Access-Control-Allow-Origin on a data URI iframe? [14:12:19.0000] yoav: postMessage? [15:05:56.0000] @Domenic yeah, dumb question. Wasn't working for me for some reason, but working now 2018-10-15 [17:15:54.0000] MikeSmith: FYI we'll get the MDN stuff landed before TPAC, that's a good deadline for me. [17:30:33.0000] Domenic: super, thanks [17:31:43.0000] I think I’m done fiddling with it as far as tweaks I wanted to make to get it review-worthy [17:34:33.0000] \o/ [18:59:52.0000] Domenic: FYI https://stackoverflow.com/questions/52771970/use-fetch-streams-api-to-consume-chunked-data-asynchronously-without-using-recur [04:06:29.0000] <`slikts> I rewrote the js-csp ping-pong example using transformstream: https://jsfiddle.net/slikts/0noqL9we/9/ [04:06:39.0000] <`slikts> I'm not really clear on why it produces an error [04:07:21.0000] <`slikts> I mean, why it throws undefined [04:07:30.0000] <`slikts> shouldn't there be an errror message [04:08:06.0000] <`slikts> the error can be from either reader.read or writer.write, and there's no way to tell [04:09:19.0000] <`slikts> also, this is mentioned nowhere, but transformstream is an implementation of CSP in a straightforward sense [04:10:12.0000] <`slikts> and csp is the general abstraction for concurrency in golang and core.async [04:22:50.0000] what spec are the XML expectations of https://wpt.fyi/results/encoding/utf-32.html?label=experimental based on? [04:25:45.0000] (It seems to me that Firefox is right and the test is wrong for XML) [04:26:34.0000] but since the XML tests pass in other browsers, I guess we need to define that is correct for the sake of interop [04:27:22.0000] but I have a hard time explaining the expectation except by actually sniffing for the UTF-32 BOM (which we don't want to do!) and mapping it to windows-1252 [04:27:55.0000] same thing at https://wpt.fyi/results/encoding/unsupported-encodings.any.html?label=experimental [04:44:13.0000] hsivonen: I've been discussing this with Joshua [04:44:25.0000] <`slikts> "Push sources push data at you, whether or not you are listening for it. They may also provide a mechanism for pausing and resuming the flow of data." [04:44:27.0000] hsivonen: https://github.com/web-platform-tests/wpt/pull/13082 [04:44:31.0000] <`slikts> they're not really push sources if you can pause them [04:44:48.0000] <`slikts> it's just an obtuse api for pulling then [04:44:52.0000] <`slikts> push stream can just be sampled from [04:45:02.0000] <`slikts> *a true push stream [04:45:14.0000] <`slikts> if it can be paused/resumed, it can mechanically be transformed to pull [04:45:37.0000] <`slikts> that's from streams spec [04:46:59.0000] <`slikts> a true push stream is, for example, user events [04:47:01.0000] <`slikts> can't pause users [04:47:21.0000] <`slikts> or something based on time, since you can't pause time [04:50:07.0000] annevk: thanks [04:50:24.0000] <`slikts> should I make an issue about that sentence? [06:55:23.0000] <`slikts> do node streams duplicate whatwg streams? [08:21:07.0000] <`slikts> found the answer: https://github.com/nodejs/node/pull/22352 [08:21:59.0000] <`slikts> seems like NIH on node's side [08:22:34.0000] Node way predated these [08:23:37.0000] But also had flaws [08:23:54.0000] Node may adopt WHATWG streams in the future [08:24:35.0000] <`slikts> that'd be reasonable for interop [08:25:25.0000] <`slikts> a polyfill based on node streams instead of from scratch should also be simple [08:25:39.0000] <`slikts> at a glance anyway [11:34:17.0000] This new navigate event is kinda meh, I much rather have some kind of navigate honeypot, whereby you can opt in to handle navigations initiated in other browsing contexts [11:35:21.0000] Basically copy some app-functionality to the web, while also continuing to allow for normal navigations [15:00:45.0000] Is there a way for JavaScript in the browser to tell if an element is a void tag in HTML? [15:48:48.0000] I just tried to find the list by doing tag.outerHTML.toLowerCase().endsWith(``) === false [16:16:35.0000] innovati: why not just check the element name? [16:16:54.0000] it’s not a long list [16:17:18.0000] area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr [16:17:23.0000] https://html.spec.whatwg.org/multipage/syntax.html#void-elements [16:18:59.0000] I know, but since I wrote a plugin to do that, the list had changed, so I was wondering if there was a way for the browser to determine this for itself [16:19:27.0000] I'm also wondering if the browser knows what HTML tags it supports (as I suspect the list of tags it knows about might be greater than HTML) [16:21:56.0000] not sure what you mean by “knows” [16:22:39.0000] things it could create with document.createElement() [16:23:03.0000] the browser already knows about HTML elements [16:24:05.0000] document.createElement("foo") [16:24:42.0000] there's a lot of combinations to try if you were to do it that way, is there any way you can find out from the browser what it knows about? [16:26:12.0000] sorry I still don’t understand what you mean by “knows about” [16:26:28.0000] e.g., do you mean the element has an interface other than HTMLUnknownElement? [16:26:31.0000] or what? [16:26:40.0000] sure? [16:27:14.0000] then I guess your code can check what interface the element has [16:27:39.0000] is there a way to see all of the interfaces a browser has? [16:27:39.0000] programmatically? [16:29:19.0000] I guess there would be, but not sure there’s anything exposed to do it conveniently 2018-10-16 [00:50:28.0000] annevk: Got this issue https://github.com/w3c/resource-timing/issues/173 claiming that "cross-origin resources" is not a well-defined term in Resource-Timing. Looking at the definition, it's based on https://tools.ietf.org/html/rfc6454#section-5, which you said was obsolete. Should I use the same definition ("not same origin") just point at the HTML spec's origin definition? Or is there a better definition somewhere that |I should [00:50:28.0000] point to? [01:02:16.0000] yoav, probably you want something in fetch? [01:02:43.0000] Possibly https://fetch.spec.whatwg.org/#concept-response-type [01:22:58.0000] yoav: looking [01:36:02.0000] yoav: left a comment in the issue [01:36:16.0000] annevk: thanks! :) [07:02:57.0000] document.createElement('foo') instanceof HTMLUnknownElement [07:54:51.0000] cvazac: true if the environment isn't modified somehow [07:57:45.0000] annevk are you talking about createElement/HTMLUnknownElement built-ins being modified? [07:58:23.0000] cvazac: yeah or document [07:59:08.0000] annevk 👍 2018-10-17 [00:25:37.0000] annevk: Is a bot supposed to merge https://github.com/web-platform-tests/wpt/pull/13519 or do I need to ask a human to click a "Merge" button? [00:26:57.0000] hsivonen: no, you can do "rebase and merge" [00:27:09.0000] hsivonen: or I can [00:27:28.0000] hsivonen: I didn't land it for you because I wasn't sure it wouldn't start failing again [00:33:51.0000] annevk: I don't have permission to do "rebase and merge", so I'd appreciate it if you could do it [00:34:16.0000] annevk: thanks [00:34:39.0000] yw [00:34:58.0000] jgraham: maybe add hsivonen to the set of people that can merge on wpt? [00:35:40.0000] remaining failures at https://wpt.fyi/results/encoding?label=experimental are: timeouts for tests that test every byte for every single-byte encoding, incorrect XML UTF-32 tests and not supporting the new streams API [00:35:59.0000] (I filed a wpt issue for the timeouts) [00:36:48.0000] Ooh, I thought zcorpan had fixed the timeout issues somehow [00:36:53.0000] By splitting things up [00:36:58.0000] I guess not entirely then [00:37:17.0000] hsivonen: so I guess that means I can finally close the Encoding Standard issues around tests [00:37:56.0000] annevk: yes [00:45:41.0000] hsivonen: it seems not all tests were upstreamed, e.g., I cannot find gbk [00:46:36.0000] I'll update the outstanding issues I guess [01:21:27.0000] anybody know if a copy of https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html is still preserved somewhere? [01:22:03.0000] that URL now redirects to https://w3c.github.io/editing/ and the content is not there [01:22:20.0000] so all the fragment IDs are broken [01:22:29.0000] Sigh [01:23:04.0000] MikeSmith: I guess it's https://w3c.github.io/editing/execCommand.html? [01:23:26.0000] annevk: ah yeah [01:23:29.0000] seems so [01:23:30.0000] thanks! [01:24:02.0000] I'm really not happy with editing [01:24:09.0000] But then nobody prolly is [01:24:41.0000] yeah [01:27:01.0000] annevk: Will do [01:29:51.0000] annevk: ah well, I see the old fragment IDs don’t resolve there [01:30:07.0000] maybe due to it having been converted to respec [01:30:22.0000] I think I’ll just remove the redirect [01:30:34.0000] *sigh* [01:31:42.0000] yeah, for better or worse, in MDN articles, there are still a bunch of links to https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html [01:31:49.0000] so all of those are currently broken [05:08:04.0000] Hmm, why do HTTP and HTML whitespace differ? [05:08:25.0000] That's like one extra test each time you do something with whitespace [05:13:05.0000] Hmm, and Chrome and Firefox don't consistently use that whitespace definition when parsing headers [06:15:58.0000] Oh no oh no :( [06:16:26.0000] I found another, 0x0B [06:16:41.0000] But I'm probably rediscovering stuff I found before [06:21:03.0000] Domenic: if you ever see Matt Menke in person btw, thank them for me! Super great to have someone giving active feedback on HTTP stuff [06:21:08.0000] (and even implementing some) [06:21:32.0000] Will do! [09:06:20.0000] Suddenly, there are A LOT of stream API questions coming up in the WebRTC WG. Will anyone of you be at TPAC or could participate remotely? I think the WG would greatly benefit from your expertise as there are many questions regarding adoption, etc. [09:06:28.0000] Domenic, annevk: ^ [09:07:19.0000] lgrahl: I'll be there. What day and time? [09:07:31.0000] Let me look that up :) [09:07:35.0000] lgrahl: (if you have W3C Member access there's some page that lists attendees) [09:08:52.0000] gsnedders: Thanks! [09:10:34.0000] Domenic: 22/23, schedule isn't written in stone yet but the current agenda plan is here: https://www.w3.org/2011/04/webrtc/wiki/October_22-23_2018 [09:13:42.0000] Domenic: There might be questions during the "NV Use Cases" slot, during the "Workers and Worklets" slot, definitely during the "Data Channel + WHATWG Streams" and "QUIC + WHATWG Streams" slots [09:18:23.0000] Domenic: A lot of the questions are already in Peter Thatchers slides so you have an idea what questions there will be: https://docs.google.com/presentation/d/1-qK8DCb9Vf6yZ9E0k5WBQb3LusEd2oDlb-Hx5SobU1U [09:18:44.0000] Another couple of slides: https://docs.google.com/presentation/d/1nunzO21RJDGCwe_tVpUVBi_Aka84ukhAwMaFH1WYZ3Y [09:25:45.0000] lgrahl: well that’s a turn for the better [09:26:28.0000] lgrahl: I’m overbooked and not sure I am the best person; ricea would be ideal I suspect [09:26:36.0000] FYI I will not be there in person but will participate remotely [09:27:19.0000] Okay, also pinging ricea in that case :) [09:27:57.0000] I hope to make it, it will depend on what collides... [09:28:09.0000] Thanks for the pre-briefing!! [09:31:35.0000] Domenic: Okay, perfect. :) Can you guys ping ricea later? I'll be off soon. [09:41:49.0000] Not me 2018-10-18 [02:26:39.0000] So I am debugging whatwg.org build failures (which prevent https://github.com/whatwg/whatwg.org/pull/231 from being merged) [02:26:58.0000] It appears we are pip installing the markdown module without pinning it to a version, and it changed in a backward-incompatible way [02:27:21.0000] I am having some trouble figuring out: where to find a changelog or version history for the markdown module, and how to change the `pip install` command to pin the version. [02:27:26.0000] Python experts appreciated. [02:28:16.0000] OK, the answer to the changelog thing is to use pypi.org instead of pythonhosted.org [02:31:01.0000] OK and the latter is just pip install markdown==2.6.11. I guess I was premature asking for help. [02:49:59.0000] Glad you figured that out [02:50:05.0000] Also welcome to Europe? [03:36:08.0000] Ya, at the Paris office for this week [03:37:33.0000] annevk: mind reviewing https://github.com/whatwg/whatwg.org/pull/231 now that the build works [04:22:16.0000] annevk: were pre-java.nio Java encoding canonical names deliberately not added as labels in the Encoding Standard? [04:23:17.0000] annevk: seems related to the Unicode label mapping problem, since many of them would match if hyphens and underscores were ignored when comparing [04:24:08.0000] annevk: see the second column at https://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html [04:26:23.0000] expected rendering, anyone? #block-block-18 select#langlinks{-webkit-appearance:menulist-textfield;-moz-appearance:treeheadersortarrow;appearance:none;background-color:transparent;font-size:9px;height:25px;padding:4px 0 0;width:121px;} [04:34:00.0000] annevk: I wonder if the email-motivated addition of ms932 as a label for Shift_JIS had the root cause of pre-java.nio Java canonical names [05:05:57.0000] hsivonen: the way we did things was looking at the intersection of labels in browsers and that's it [05:06:28.0000] hsivonen: it's not entirely clear to me how browsers derived their initial tables, some combination of IANA, experience, and what whoever wrote the code deemed ok [05:16:21.0000] hsivonen: I'd not be opposed to adding new labels based on anecdata btw, generally it seems that should be safe here [05:16:31.0000] hsivonen: but only if all implementers are on board with such a strategy [05:17:08.0000] annevk: is https://rebeccalynndoug-html-multiple-.surge.sh/ non-conforming per the current URL spec? [05:17:24.0000] galimatias says: [05:17:27.0000] > Invalid host: A label ends with a hyphen-minus ('-'). [05:18:12.0000] MikeSmith: no, we set CheckHyphens to false [05:18:24.0000] oh wait, conforming [05:19:44.0000] MikeSmith: it's currently conforming, but maybe it shouldn't be and we should also use _beStrict_ for CheckHyphens [05:20:51.0000] OK [05:20:54.0000] annevk: thanks. that's what I expected. (I'd be curious to know if ISO8859_1 and the like were part of Opera's rejection of comparison that ignored hyphens and underscores.) [05:22:19.0000] annevk: ash I guess the reason galimatias reports an error is because it’s just relying on icu4j (ICU Java library) and is just passing on the error from that [05:23:35.0000] hsivonen: I think the only reason was "euc_jp" [05:27:24.0000] annevk: OK. that's one of the pre-java.nio Java canonical names [05:27:34.0000] hsivonen: https://lists.w3.org/Archives/Public/public-whatwg-archive/2009Aug/0077.html [05:28:25.0000] I think I remember that being the only case, but it's been a long time [05:36:11.0000] Can anyone explain why https://html.spec.whatwg.org/multipage/dom.html#inner-text-collection-steps runs step 1 & 2 for nodes that are not being rendered? In what cases would such a list not be empty for a node that isn’t rendered? [05:36:11.0000] If I understand “being rendered” right, it means a node has no drawing box at all. Which by definition would mean its children have no box at all? (e.g. display:none; can’t be overwritten on a per-child basis.) So shouldn’t all those extra steps just result in empty lists? [05:41:25.0000] Zegnat: by the time that algorithm is invoked, the being rendered check for the subtree is already made, right? [05:41:36.0000] Zegnat: so presumably something is rendered at that point [05:43:12.0000] The algorithm only checks if it is being rendered in step 3 though. That is what is confusing me. [05:44:24.0000] Why go through all the child nodes of something that isn’t being rendered first. I can’t think of a case where any of the childnodes would magically render when their parent does not. [05:46:49.0000] Zegnat: when this algorithm is invoked the first time we know the parent is being rendered [05:47:08.0000] because of innerText's getter step 1 [05:48:00.0000] Aah, I think I grasp it now! [05:48:11.0000] I was too focussed on the nested looping, woops [05:48:14.0000] Thanks annevk! [06:51:58.0000] annevk: hmmmm I guess the button element is itself not underlined, but the text-decoration can still propagate into it. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6291 [06:52:36.0000] zcorpan: right, if you specify display:inline, I noticed that [06:52:56.0000] zcorpan: ooh okay, I might see what you mean [06:53:09.0000] annevk: I mean it's consistent with replaced elements not being underlined [06:53:11.0000] zcorpan: so if image had a box inside it would propagate there too [06:53:17.0000] zcorpan: okay [06:53:21.0000] right [06:54:06.0000] zcorpan: but for image that still requires a "I'm no longer replaced" setting when displaying alt (even though that's still somewhat replaced due to a potential impl using contents:attr(alt)? [06:54:38.0000] yeah it shouldn't be a replaced element when showing alt [12:53:41.0000] There have been questions about the implementation status of streams in browsers (and perhaps what's planned). (I guess I need to play the middle man since communicating with other WGs seems to be a big no-no for most people in the WebRTC WG...) [13:17:30.0000] lgrahl: implemented everywhere. Firefox is not quite shipped but apparently got unblocked last week. [13:18:48.0000] Domenic: Ok. I was wondering about Firefox, so that's good to know. Does it also include WritableStream? [13:33:12.0000] lgrahl: not sure, I think they have a patch for that somewhere, but haven't seen movement on it in some time. Probably waiting for a customer :) [13:34:10.0000] Domenic: And in Chromium? (I kind of figured that this is a chicken egg problem) [13:52:35.0000] lgrahl: all implemented and shipped to stable [14:00:56.0000] Domenic: Cheers! :) 2018-10-19 [23:33:16.0000] It’ll pretty soon be a compat issue to not support response streams [01:06:41.0000] If anyone can make sense of https://twitter.com/jasonmulligan/status/1053014565028618241 let me know. I've given up [01:21:32.0000] Hooooraaaaay more non-interop from the 90s: https://github.com/whatwg/html/issues/4109 [01:22:03.0000] Anyone want to test Safari [01:24:08.0000] Domenic: B and C are newlines, TAB is a space [01:24:28.0000] annevk: a single space?? [01:25:05.0000] https://irccloud.mozilla.com/file/LGbT6NZZ/Screen%20Shot%202018-10-19%20at%2010.24.47.png [01:25:18.0000] Sure looks like a single space [01:25:20.0000] Amaaaaazing [01:26:05.0000] Note that it's not normalized [01:26:20.0000] If I copy the text, it comes out as TAB, VT, and FF [01:26:43.0000] Which doesn't seem great [01:27:14.0000] Oh I don't think it's selectable on most Windows browsers... Let me check [01:43:40.0000] annevk: Responded; afaict, person is just confused about the API. They think getAll() will return the value itself when the key has only one value (rather than returning a length-1 array). [01:44:46.0000] TabAtkins: I got that impression too, but their assertion they were not confused made me doubt things [01:44:48.0000] Also, that nested-filter thing for counting values that show up more than once is nutzo. [01:44:59.0000] Ah, never trust people to tell you they aren't confused. [01:48:58.0000] TabAtkins: heh, ta [01:53:28.0000] TabAtkins: btw, split on comma except inside X [01:53:40.0000] TabAtkins: I was thinking about this, but I wonder how many specifications need an equivalent algorithm for that [01:54:11.0000] TabAtkins: e.g., I could use something like it for HTTP header parsing to avoid commas inside double quotes, but it'd have to deal with \" and \\ as well [01:54:47.0000] TabAtkins: unless there's multiple cases that need it without such escapes (or the same escapes), it prolly doesn't belong in Infra [01:54:54.0000] Ah, sure. CSS needs to handle \, too, for example. [01:55:35.0000] But is it exactly identical? [01:56:36.0000] But eh. Anyway. If you can CSS-parse the value, this is easy - you can just split on "top-level" comma-tokens, because commas in strings or functions or whatever are moved into the values of the other tokens. [01:56:51.0000] I guess outside of CSS's constraints they're probably too varied right now. [01:57:30.0000] I'll keep an eye out, but that's my suspicion too [01:57:41.0000] /me is always happy to abstract [02:25:09.0000] Domenic: did you test newline copy-and-pasting too? [02:25:46.0000] Domenic: perhaps it's all in the CSS layer / C++^WRust render text layer [02:44:16.0000] annevk: oh, no :(. That does impact whether we normalize then display, or say "display all these things the same way" [02:45:53.0000] Chrome... doesn't allow selecting the text if it's multiline?! [03:37:22.0000] so frustrating that whether emails should be sent in UTF-8 is still a debate in 2018 [03:37:39.0000] I understand that UTF-8 avoidance code had value 20 years ago [03:37:43.0000] it doesn't anymore [03:38:16.0000] hard to get features removed from 20-year-old code bases [03:43:56.0000] TabAtkins: did you have a linkable writeup somewhere that explains that using non-UTF-8 encodings for newly-serialized data has no value? [03:46:04.0000] Ooh, not that I recall. [03:46:17.0000] But I might have written it into an email at some point... [03:52:21.0000] TabAtkins: I think I've read an email from you along those lines [03:53:48.0000] TabAtkins: anyway, please don't spend time searching for it, if it's not already in a blogged form [03:59:28.0000] annevk: lololol that twitter person is now saying that using getAll() all the time is terrible for performance because it's generating unnecessary temp arrays; their own code generates N temp arrays already in the double-filter operation they're performing. [04:00:09.0000] so yeah, feel free to flip the bozo bit on them, jeez [04:02:56.0000] I’m sorry, but at least it’s a lil amusing [04:03:45.0000] hsivonen: https://annevankesteren.nl/2009/09/utf-8-reasons [04:03:56.0000] hsivonen: kinda web biased though [04:07:21.0000] annevk: thanks. indeed too Web-based for today's windmill [04:27:21.0000] annevk: The useless question of Friday, [04:27:30.0000] annevk: out of sheer curiosity, why is your favicon a tilde? [04:29:50.0000] nox: this might be retcon, but I think I saw another site use a Unicode code point as logo of sorts (maybe Daring Fireball?), and decided that'd do for me as well, and then picked something that'd look reasonable [04:30:10.0000] hsivonen: I think I've found a thread you may be thinking of, but it's too CSS-specific for what you need, likely. [04:30:12.0000] Nice. [04:30:47.0000] annevk: I guess I'll choose U+1F956 BAGUETTE BREAD if I ever write a blog. [04:31:01.0000] hehe [04:32:38.0000] TabAtkins: that Twitter thread also reminds me of "premature optimization is the root of all evil" [04:33:54.0000] If it's performance-sensitive code, maybe don't use a JavaScript wrapper object backed by a C++^WRust class to do stuff, just parse yourself in JavaScript [04:46:27.0000] TabAtkins: ok [05:58:03.0000] Domenic: handing folks a link to https://whatwg.org/faq#spell-and-pronounce is my new favorite thing [06:21:17.0000] Properties that disable -webkit-appearance for form controls differs between macOS and windows ;_; [11:53:04.0000] jgraham: what does assert_greater_than_equal assert? [11:53:21.0000] why it is not just assert_greater_than ? [11:53:39.0000] or does it do >= [11:54:07.0000] smaug____: Yes [11:54:37.0000] Shouldn't it then be called assert_greater_than_or_equal [11:55:04.0000] smaug____: Probably [11:55:41.0000] smaug____: Apropos nothing at all, did you see https://web-platform-tests.org/writing-tests/testdriver.html ? The heading at the bottom is broken, but we now have the ability to generate complex series of user gestures in wpt tests [11:56:11.0000] great [11:56:18.0000] need to convert some mochitests to wpt [16:14:48.0000] query: has anyone here used irccloud.com with irc.w3.org ? I'm having trouble getting it to work.... [16:16:25.0000] @TabAtkins et al -- I ferget where the bikeshed autolinking database github repo is -- anyone have a link handy? thanks [16:55:29.0000] equalsjeffh: Seems like some info would be in here? https://github.com/tabatkins/bikeshed-data 2018-10-20 [17:05:17.0000] equalsjeffh: with port 994 it wfm [22:01:54.0000] I'm using port 6667 for it [22:28:29.0000] Yeah, the main point is that the default IRC port does not work [22:35:02.0000] equalsjeffh: btw port 6679 and 994 provide secure connection. https://www.w3.org/Project/IRC/ has some more info [10:09:11.0000] thanks domfarolino, annevk and timothygu -- it was just the silly port# thing -- its a wonder they let me play with computers.... 😜 [10:10:17.0000] and thx tabatkins too [12:53:46.0000] Thoughts welcome on margin annotations in specs https://github.com/whatwg/meta/issues/117 2018-10-21 [08:32:06.0000] Anyone around to approve https://github.com/whatwg/whatwg.org/pull/233 ? /cc MikeSmith. I think that's the last thing and then we can do the merge dance for all MDN annotations... [11:15:45.0000] Domenic: The WHATWG discussions for the WebRTC WG have been moved into a large block on the 23rd from 1030 to 1130. [11:15:51.0000] Err, streams discussions [11:16:27.0000] Domenic: Will you be able to make it (or perhaps someone else?) 2018-10-22 [20:12:13.0000] I could make that perhaps. I told jib various things too though, I think he’s preparing as well [03:30:35.0000] MikeSmith: I'm a little scared of merging two order-dependent PRs with GitHub in its current fragile state, and also how well any subsequent Travis runs and deploys will go. So if we could wait until https://status.github.com/ calms down a bit that'd be ideal. But yeah nothing blocking on the code front. [03:31:25.0000] Domenic: ah yeah, good point [03:32:09.0000] Domenic: I had to try multiple times before I could even successfully submit that issues comment :) [03:32:22.0000] GitHub kept saying, "You can ' [03:32:38.0000] "You can't comment right now." [03:32:47.0000] Yeah, I think sometimes it goes through though. Like I've gotten 15 emails from Jake's comment on service worker F2F agenda. [03:33:03.0000] So I actually tried to reply on-thread and then saw it fail and decided to go here instead, to avoid potentially sending N emails of my own while retrying. [06:29:31.0000] annevk: any reason to wait on merging https://github.com/whatwg/html/pull/4099 ? [06:29:59.0000] I guess maybe because GitHub is shaky [06:36:05.0000] Domenic: I didn't do it because it wasn't sure about the commit message, feel free [06:36:21.0000] And I guess I wanted to give dbaron some time to chime in, but it's probably okay [06:37:52.0000] lgtm [06:39:30.0000] I was just forwarding an email to the right place... [06:47:32.0000] Merged [07:38:25.0000] annevk: working on https://github.com/whatwg/html/pull/4076/files but I am really confused because "associated Document" does not seem defined... [07:41:58.0000] Domenic: hmm yeah, I guess that was never defined [07:42:15.0000] Trying to formulate something alternate and maybe a bit simpler, but not sure if it's equivalent... [07:43:22.0000] relevant Document is probably Location object's relevant global object's browsing context's active document [07:44:13.0000] I think it's: [07:44:14.0000] The relevant Document of a Location object loc is loc's relevant settings object's responsible document, if that Document is active, and null otherwise. [07:45:13.0000] Yours maybe is better [07:45:25.0000] Is "active document" null for detached iframes? [07:45:33.0000] (Sounds like a question we've asked before...) [07:46:08.0000] That shouldn't be active, I think [07:46:29.0000] https://github.com/whatwg/html/issues/1073 [07:47:31.0000] good times [07:48:11.0000] I think ours are equivalent [07:48:27.0000] Happy with either, although with yours we should add a note pointing to 1073 and clarify the intent [07:48:42.0000] Hmm no we need the note with both [07:49:11.0000] I'll capture on GitHub [07:51:40.0000] I really wish documents were dumber/not tied to anything [07:58:17.0000] heh [13:27:29.0000] o/ [13:29:04.0000] Access to Raw Audio... is this something you would consider in scope for WHATWG streams? https://docs.google.com/presentation/d/1WOihY0SMJbWvfbc-41GA78F4yzPSwmyDOJ8GbRoU7dw/edit#slide=id.g445c72bf7e_1_0 (slides 30 to 38) [13:29:04.0000] I honestly don't know in this case. [13:35:16.0000] lgrahl: from what I can tell that is about real-time audio processing, which is not as good a fit (in part because real time audio is very specialized). But if you were talking just streaming access to the audio bytes of a RTC stream, that would make sense, and in fact there's a proto-spec for it [13:36:22.0000] Domenic: Yeah, I think this is mainly about real-time transformation. I guess this is better suited for Worklets. [13:37:27.0000] Domenic: I think we will see a couple of slides tomorrow that suggest using streams for RTP 'n stuff [13:37:29.0000] https://discourse.wicg.io/t/rfc-proposal-for-integration-streams-mediastreamtrack-api/2256 for streaming access to raw bytes of a MediaStreamTrack [13:37:41.0000] Exciting. I should be able to make it. [13:37:58.0000] Great! :) [13:52:09.0000] Jan-Ivar and I were thinking whether we should create an API that can handle both binary and string data (since that is what WebSocket and Data Channels currently allow to send)... or just binary and say that encode/decode should be a transformation. [13:52:09.0000] I do kind of like the latter approach. [13:52:43.0000] Yeah the latter is what we're doing with modern APIs these days like fetch [13:53:12.0000] These days it's as easy (in spec land and in Chrome) as `const stringReadable = byteReadable.pipeThrough(new TextDecoderStream())` [13:54:12.0000] Oh, that's good to know :) [13:54:40.0000] hi [13:56:03.0000] jib: You may want to take a look at the latest comment from Domenic (see the log). Might be a neat example. [13:56:09.0000] I saw [13:57:16.0000] but that requires cooperation to know what's text and what's not [13:57:58.0000] Then again, the application will usually know. It could even use separate channels for that purpose. [13:58:43.0000] well sure, but it requires dedicating a single channel per type. that's easy [13:59:10.0000] Today, we can do dc1.send("A"); dc1.send(fileB); do2.send("C"); dc2.onmessage = ({data}) => (data instanceof Blob)? processFile(data) : log(data); [13:59:39.0000] which lets you mix heterogeneous messages by type at least [14:00:30.0000] Yes and I wouldn't want to change that now. However, it does support the argument that we shouldn't bother about having a stream support strings, too. [14:00:45.0000] It does? how? [14:01:50.0000] If we go with .onmessage spitting out streams for binary data and DOMString for strings, then you still have both. If you want to send huge strings, just encode/decode them and send them as binary. [14:02:04.0000] We might be able to do the same with streams, with e.g. onreadable = ({readable}) => (readable.type == "bytes")? readable.pipeTo(fileProcessor) : readable.pipeTo(logger); [14:02:36.0000] If I encode strings, how will receiver tell them apart from files? [14:03:05.0000] ss/onreadable/dc2.onreadable/ [14:03:16.0000] Why would the receiver not know what it is going to receive? [14:03:33.0000] Which application does stuff like that? :) [14:03:37.0000] because we support it today? do dc1.send("A"); dc1.send(fileB); do2.send("C"); dc2.onmessage = ({data}) => (data instanceof Blob)? processFile(data) : log(data); [14:03:48.0000] It seems surprising to me that you've so far privileged one type's byte-serialization (strings) over others, and made it auto-decode. Why not do the same for numbers, or JSON, or protobufs? [14:04:24.0000] isn't that what websocket does? [14:05:00.0000] Ah, so just following web sockets? [14:05:13.0000] as opposed to? [14:05:22.0000] Following fetch or other modern APIs [14:05:54.0000] RTCDataChannel is modeled after websocket. How would we follow fetch? [14:06:39.0000] Operate on bytes, and let applications choose their semantics by decoding those bytes appropriately. This allows a mucher richer set of types to all have equal support, instead of privileging strings. [14:06:54.0000] Also makes the transport less complicated [14:07:57.0000] makes some sense. Specs are a bit confusing wrt ReadableStream, it seems type-agnostic at times, but other times seems to be bytes only, to me [14:08:39.0000] Let me say again: This is meant as an extension. You can still get strings out of .onmessage. I'm just saying that we shouldn't care about handling backpressure for strings. It would make the stack unnecessarily complicated for a moot use case (IMO). If someone is sending gigantic strings, it could easily drop in TextDecoderStream. [14:09:10.0000] Yeah I can see that. The ones from the network are bytes, but the type itself supports everything, which lets you do things like write transforms that go from ReadableStream -> ReadableStream or ReadableStream or ReadableStream or... [14:09:46.0000] lgrahl: ok I'll buy that [14:10:59.0000] I think you've convinced me [14:11:29.0000] /me cheers [14:11:47.0000] fewer options simplify slides [14:12:10.0000] Nice side effect :) [14:12:17.0000] Btw on naming, How do we feel about dc.createWritable() ? The word "stream" is a bit overloaded in webrtc [14:12:46.0000] If it were TypeScript, I would like "createMessage" because the return type is clear [14:12:59.0000] hmm [14:13:20.0000] but it's not typescript ;) [14:13:45.0000] /me likes ducktyping [14:13:51.0000] /me too [14:14:05.0000] if it reads and writes like a duck... [14:14:14.0000] Given the overloaded meaning of stream that seems pretty solid. [14:14:42.0000] I assume it should be a function, not a property, because calling it causes some locking or change into "write via a stream" mode? [14:14:43.0000] ok [14:15:07.0000] Yeah, it would lock .send [14:15:13.0000] yeah [14:15:14.0000] Or, actually... it might not even need to [14:15:24.0000] Seems simpler [14:15:43.0000] Agree. We should lock. Let's not make things more complicated. [14:16:44.0000] dc1.send("A"); fileB.pipeTo(dc1.createWritable()); do2.send("C"); // emits A, B0, B1, B2 ... Bend, C [14:17:07.0000] uh s/do2/dc2/ [14:17:43.0000] Is there some kind of indications on when the piping is complete? [14:17:52.0000] it's closed() [14:17:54.0000] pipeTo promise will settle [14:18:01.0000] ah [14:18:04.0000] thanks [14:18:08.0000] Okay, good. Because otherwise the locking would be awkward [14:18:17.0000] dc1.send("A"); await fileB.pipeTo(dc1.createWritable()); do2.send("C"); // emits A, B0, B1, B2 ... Bend, C [14:18:37.0000] Noob question, why is the last example do2/dc2, not dc1 [14:18:55.0000] cause I cut'n'pasted my earlier typo ;/ [14:19:00.0000] dc1.send("A"); await fileB.pipeTo(dc1.createWritable()); dc2.send("C"); // emits A, B0, B1, B2 ... Bend, C [14:19:09.0000] OK but why dc2 instead of dc1 [14:19:14.0000] dc1.send("A"); await fileB.pipeTo(dc1.createWritable()); dc1.send("C"); // emits A, B0, B1, B2 ... Bend, C [14:19:17.0000] :*) [14:19:20.0000] OK now it makes sense [14:19:21.0000] Heh [14:19:48.0000] Hmm now I guess I see how no-locking might be fine if it's just a queue of stuff to do anyway [14:19:56.0000] ? [14:20:05.0000] oh with await [14:20:07.0000] well [14:20:25.0000] What happens if I do: [14:20:36.0000] Yeah, it's a queue, but we shouldn't encourage people to fill it if we want to avoid backpressure [14:20:47.0000] No yeah I'm starting to see the problems again [14:20:58.0000] dc1.send("A"); const p = fileB.pipeTo(dc1.createWritable()); dc1.send("C"); await p; // should probably also emit A, B0, B1, B2 ... Bend, C [14:21:13.0000] or gremlins [14:21:36.0000] Exception in your face [14:21:46.0000] Yeah there's no way to make that give the order you want I now realize [14:22:14.0000] If you don't prevent dc1.send() while the piping is ongoing (i.e. while the writable stream is not-closed), then interleaving happens [14:22:26.0000] So yeah locking good [14:22:31.0000] I think so [14:22:32.0000] Thanks for bearing with me :) [14:22:38.0000] sure np! [14:23:07.0000] Btw, my slides are also going to claim that streams of streams make no sense [14:23:27.0000] just running this by here first, to check [14:23:36.0000] Interleaving of messages on the same channel is actually being prevented by SCTP but... I still think locking makes more sense as users could get the wrong impression on order. [14:23:37.0000] Also makes it either to port to WebSocket later. [14:23:49.0000] *easier [14:24:19.0000] I'm not sure they make _no_ sense, but I can see how they wouldn't but you much, and it seems like you've found a nice cut point to introduce them that gets most (all?) of the benefits without disturbing everything [14:24:57.0000] I think they would make sense if we would design a new API from scratch [14:25:11.0000] Unsure about that even [14:25:15.0000] here's my thinking: [14:25:21.0000] Message semantics are appealing for multiple (heterogeneous) finite payloads. [14:25:27.0000] Stream semantics are appealing for single payload; outsourcing chunking & pressure. [14:25:35.0000] A queue of streams is appealing to manage multiple discrete payloads of large size. [14:25:41.0000] A “stream of streams” doesn’t add much over queue of streams; hurts: Competing semantics; Outsourcing chunking & pressure again hides messages. [14:26:22.0000] I don't understand the hurts [14:26:31.0000] Yes, shimming stream semantics on top of messages works in demos, but hijacks channel for single payload and loses control of messages. Stream semantics on top of streams has the same problem. A multi-payload quasi-stream as API isn’t a stream [14:27:00.0000] Isn't part of the value of a stream not having any semantic overload of its "chunks"? [14:27:09.0000] Like if someone is producing a stream of streams and wants to give it to a Web RTC consumer then making them go through a different API, and lose backpressure on their inner-stream production, seems sad [14:27:27.0000] Not sure exactly what you mean by that [14:28:40.0000] The semantics of stream of stream hurts my head basically, not sure what it adds over queue of streams [14:29:07.0000] Backpressure and easy piping/interop with other streams-of-streams, I think [14:29:17.0000] (There are no other streams-of-streams yet of course) [14:29:37.0000] nested backpressure? [14:29:50.0000] I think it's just a different model. But in comparison to events, we can automatically handle backpressure across multiple messages. Say, if you would pipe a stream of messages from one data channel to another. [14:30:44.0000] (where messages is another word for Stream) [14:30:50.0000] I thought we settled on sstream of bytes [14:30:51.0000] *message [14:30:51.0000] right [14:31:09.0000] Yeah nested backpressure :). Like if your inner-streams are files and your outer-stream is deciding whether to open new files from the filesystem, backpressure would tell you "don't open a new file yet, I'm backed up processing the ones you already gave me" [14:31:30.0000] Piping a whole directory [14:32:35.0000] but why stream a queue? [14:33:08.0000] because you can process more than one at a time? [14:33:37.0000] I mean aren't all streams (async) queues? Just queues that you care about backpressure on? [14:34:11.0000] the backpressure stuff makes sense to me for buffers, but my understanding falls apart for types without a predetermined length [14:34:53.0000] Well at that level the length of every file is "1" [14:35:03.0000] And it's a question of "if I am backed up by 3 files then maybe don't open any more for me" [14:35:05.0000] hmm [14:35:19.0000] I guess you could do actual file size stuff but I wasn't thinking of it that way [14:35:29.0000] Wow my internet is dying. Maybe a sign it's time to sleep. [14:35:37.0000] heh [14:35:56.0000] ok thanks for the chat, it was very helpful! [14:36:15.0000] \o/ [14:36:36.0000] I think I'm going to stick with queue of streams for now, maybe my understanding will grow over time with that [14:36:50.0000] A queue of streams might make sense for proxying websites for example [14:39:05.0000] backpressure with bytes makes sense to me, e.g. "ok we can handle 16000 more bytes please" [14:39:34.0000] Imagine a fetch API that allows to queue fetch operations and move the body into the stream (I guess this could be easily written). That is essentially a Stream> [14:39:46.0000] but saying "we can handle 5 more files" hardly seems deterministic, because it all depends on file sizes [14:40:05.0000] hmm [14:40:54.0000] A requests page 1, 2 and 3. A is very slow in processing the data, though. B now uses that imaginary API to start fetching all pages but with automatic backpressure. B would only fetch the data as fast as A can process it and one after another. [14:43:19.0000] ok maybe I'm focusing too much on the backpressure value. Maybe there's API value solely in being able to creates pipes out of these things [14:43:57.0000] Yeah, I believe so. [14:44:39.0000] so what would stream of streams look like for RTCDataChannel? [14:45:25.0000] The premise of pipeTo() seems to rely on other stream objects of similar type [14:45:35.0000] or lots of clever transforms [14:45:53.0000] That might lose a lot of people [14:46:05.0000] case in point: promises [14:46:29.0000] async/await is soooo much simpler to explain and get right, than promises [14:46:42.0000] at least for me [14:47:25.0000] It would have a .readable attribute of type ReadableStream> and a corresponding .writable attribute. Again, I would only suggest that for NV. I agree it's hard to wrap your head around and we need to find easy and convincing examples first. [14:48:16.0000] I guess we can add that later, have both [14:48:28.0000] or, hmm [14:48:47.0000] I think it will be a while before we discuss NV APIs [14:49:08.0000] Or at least their final versions [14:49:12.0000] tomorrow? ;) [14:49:27.0000] Btw, when you say ReadableStream with the < and > that's not any webidl syntax is it? [14:49:45.0000] I'm not sure actually [14:50:01.0000] I mean, 'bytes' is an abstraction anyway [14:50:05.0000] sure [14:50:23.0000] but byte is valid webidl [14:50:54.0000] https://heycam.github.io/webidl/#idl-promise [14:51:16.0000] They use Promise so I guess we can use ReadableStream [14:51:57.0000] except there's no ReadableStream in https://heycam.github.io/webidl/#idl-promise [14:53:19.0000] I would go that far and say this syntax is fairly well-known [14:53:34.0000] But for actual WebIDL definitions... [14:53:40.0000] it's not valid webidl, at least not yet [15:20:59.0000] TimothyGu: https://github.com/servo/servo/pull/21882/files [15:26:48.0000] jib: I'll get some sleep :) [15:27:10.0000] jib: goodnight, thanks for your help! [15:27:13.0000] uh [15:27:31.0000] lgrahl: ^ [15:27:33.0000] /me is tired [15:28:06.0000] /me is so tired that he didn't even see the wrong mention [16:35:03.0000] Domenic: yay! 2018-10-23 [00:49:33.0000] jib: o/ [00:50:41.0000] did someone already create a searchfox instance for webkit? [00:50:58.0000] I think Ms2ger or someone was planning on doing it [00:54:57.0000] lgrahl: hi [00:56:49.0000] jib: Going through your slides right now. Anything we need to talk about? :) [00:57:10.0000] lgrahl: you tell me ;) [00:57:14.0000] Ok! [00:57:20.0000] First two look good [00:57:26.0000] I left out a slide on stream of streams, as I didn't want to blow people's mindss [00:57:52.0000] Yeah, I think that's a good idea. We can come back with that later. NV is still in its infancy. [01:01:58.0000] Adding a couple of comments for you right now [01:11:20.0000] lgrahl: jib: still on track for streams stuff to start at 10:30? [01:11:53.0000] possibly, we have a 30 min break first [01:12:15.0000] maybe shortened to ~20 mins at this point [01:12:16.0000] OK, well, I'll be in the break area, feel free to grab me [01:13:45.0000] Domenic: breaking now, we'll start at 10:30 [01:13:47.0000] 15 min break [01:36:02.0000] jib: Done with my comments now (I think) [01:36:22.0000] ok I hope I've addressed most of them [01:41:10.0000] Domenic: Made it? :) [01:41:15.0000] Yep! [02:04:45.0000] This is going well :) [02:08:10.0000] jib: Good work :) [02:08:36.0000] Domenic: It was a lot of work getting them there though. [02:09:26.0000] lgrahl: thanks for your help! [02:09:44.0000] Domenic: thank you as well [02:11:50.0000] Domenic: ^ that [02:16:23.0000] smaug____, no, wasn't me [02:17:31.0000] smaug____, though I saw a reference to http://178.128.32.224/ earlier [02:32:08.0000] jib: I think one important question is: What of this should be in NV and what an extension? [02:38:58.0000] lgrahl: define "this" [02:39:23.0000] streams for RTP, streams for all the other stuff [02:41:31.0000] define "NV" ;) [02:41:53.0000] I don't know the answer basically [02:42:24.0000] Yeah, I guess my mindset is still kind of separating NV from 1.0 whereas it might actually evolve over time from 1.0 to NV [03:01:59.0000] MikeSmith: looks like it is still not moving the