2017-07-01
[21:57:46.0000] <GPHemsley>
am I correct in my understanding that the WPT URLSearchParams tests are all embedded in HTML?

[06:26:52.0000] <annevk>
GPHemsley: yeah, I think that's the case

[06:27:15.0000] <GPHemsley>
annevk: Any particular reason for that?

[06:28:09.0000] <annevk>
GPHemsley: easiest

[06:31:34.0000] <GPHemsley>
wait... the URL live viewer has additional fields that get hidden with `display: none`?

[06:31:39.0000] <GPHemsley>
why is that?

[06:32:31.0000] <annevk>
GPHemsley: the different HTML files in https://quuz.org/url/ are identical but show different things (except for the last)

[06:33:00.0000] <annevk>
GPHemsley: https://github.com/annevk/live-url-viewer/issues/1

[06:33:07.0000] <annevk>
GPHemsley: I haven't really taken the time to fix it yet

[06:33:34.0000] <GPHemsley>
ah

[06:33:45.0000] <GPHemsley>
I'd read that issue before; didn't realize what it meant

[06:38:28.0000] <GPHemsley>
annevk: What's the difference between 1 and 2?

[06:43:12.0000] <annevk>
GPHemsley: with 2 you can specify a base URL

[06:43:27.0000] <GPHemsley>
is there a reason you wouldn't want to do that?

[06:51:08.0000] <annevk>
GPHemsley: yeah, you get different results

[06:51:21.0000] <GPHemsley>
oh?

[06:51:42.0000] <GPHemsley>
to clarify, I meant, is there a reason you would want to use 1 over 2

[06:52:10.0000] <GPHemsley>
not about wanting to set a base

[07:28:31.0000] <annevk>
GPHemsley: yeah, for the null base case

[09:45:15.0000] <GPHemsley>
annevk: but 1 uses the current URL as the base

[09:45:24.0000] <GPHemsley>
i.e. the URL of the page

[11:36:06.0000] <GPHemsley>
(and 2 does for an empty base, as well)

[12:28:10.0000] <GPHemsley>
something seems to be wrong with the test runner in WPT

[12:28:39.0000] <GPHemsley>
not getting results for Safari or Chrome because of a python exception

[12:29:10.0000] <GPHemsley>
Edge too

[12:30:32.0000] <GPHemsley>
and it's an error that is apparently not failing the build

[12:30:47.0000] <annevk>
GPHemsley: hmm it might well be buggy

[12:31:05.0000] <annevk>
GPHemsley: it's also not synced with the last version of whatwg-url

[12:31:25.0000] <GPHemsley>
I think this issue is well upstream of that

[12:31:42.0000] <GPHemsley>
it's in wptrunner itself, AFAICT

[12:32:55.0000] <GPHemsley>
jgraham: Looks like this may have been you

[12:32:59.0000] <GPHemsley>
https://github.com/w3c/web-platform-tests/commit/8eadce2c378c5380fb3199338a440cfc46b0a03e

[12:33:24.0000] <annevk>
GPHemsley: I was talking about Live URL Viewer

[12:33:28.0000] <GPHemsley>
(and apparently the initial commit was added with [ci skip])

[12:33:34.0000] <GPHemsley>
annevk: Oh, that makes more sense :)

[12:34:18.0000] <GPHemsley>
jgraham: This would probably explain why Firefox doesn't have the problem. ;)

[12:40:30.0000] <GPHemsley>
filed https://github.com/w3c/web-platform-tests/issues/6447

[14:38:40.0000] <jgraham>
GPHemsley: Ooops, thanks


2017-07-03
[11:40:27.0000] <virmaha>
I've put a 280 MB video on dropbox. I wrote a simple html page to show the video. In network tab of chrome, the content-length in response header is 380 MB but the time is 3.67s and Size column shows 3.1 MB. Why is that? There's no way my browser downloaded 280 MB vid in 3.67s. Can someone help?

[11:47:14.0000] <TabAtkins>
It looks like the browser downloaded 3.1MB of the file in 3.67 seconds, which is reasonable? And then didn't do more yet, presumably because you haven't started playing the video.

[11:50:04.0000] <ondras>
virmaha: check out https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests

[11:53:33.0000] <virmaha>
TabAtkins: so then why is content-length shows as 280 MB when the data sent was 2.1 MB?

[11:53:35.0000] <virmaha>
3.1*

[11:53:48.0000] <virmaha>
ondras: yeah I did read but it doesn't answer my query.

[11:54:17.0000] <TabAtkins>
Because the browser implicitly made a range request, like ondras said.

[11:54:39.0000] <TabAtkins>
The content-length is still the full size .

[11:54:48.0000] <ondras>
virmaha: are there any Range-related headers present in the request/response?

[11:54:53.0000] <virmaha>
yeah ondras

[11:54:57.0000] <ondras>
virmaha: that is because the content's size *is* 280MB

[11:55:00.0000] <virmaha>
request was for Range : 0-

[11:56:18.0000] <ondras>
virmaha: can you show the complete set of response headers? preferrably unfiltered by your browser's devtools, i.e. a wireshark/tcpdump output

[11:56:18.0000] <virmaha>
I thought I'd see content-length 280MB only after the entire video was downloaded

[11:57:19.0000] <ondras>
it could also have been a HEAD request

[11:58:11.0000] <virmaha>
no it was a GET request. I saw..Let me give you tcpdump output

[12:00:00.0000] <virmaha>
at a high level, I'd imagine it this way. Range request comes in for bytes 0- , I get the filename and start and end range, I set appropriate headers, read the file as per offsets and then send the content.

[12:03:29.0000] <Maranatha>
So. The Internets...

[15:16:16.0000] <KiChjang>
how recent is the "invention" of promises?

[15:16:41.0000] <KiChjang>
it feels like there are still some details about it that has yet to be ironed out

[16:28:27.0000] <TabAtkins>
Official JS promises are, what, two years old now? Something like that. They showed up in libraries substantially earlier, and have showed up in other languages before that.

[16:28:38.0000] <TabAtkins>
What do you think needs to be ironed out?

[16:34:03.0000] <KiChjang>
TabAtkins, i mean that i still see TC39 proposals that extend/enhance the usability of promises

[16:34:23.0000] <KiChjang>
perhaps having a special syntax like await?

[16:37:06.0000] <TabAtkins>
Yeah, we're still adding new stuff.

[16:41:53.0000] <GPHemsley>
a form on an HTTP page submits sensitive data via an HTTPS form action... how safe is this data?

[16:46:10.0000] <GPHemsley>
let me google that for me...


2017-07-04
[17:24:04.0000] <TabAtkins>
Not safe, as the origin page might be compromised.

[17:24:25.0000] <TabAtkins>
But if we pretend that it's not, then yeah, data is safe - browser negotiates an https connection to the destination and transports over that.

[17:24:41.0000] <TabAtkins>
GPHemsley: ^^^

[17:25:24.0000] <GPHemsley>
yeah... I ain't putting my SSN into that form

[01:52:21.0000] <mkwst>
GPHemsley: Browsers are starting to explictly mark HTTP pages as non-secure when they contain password forms: https://arstechnica.com/information-technology/2017/01/firefox-chrome-start-calling-http-connections-insecure/. You can imagine that we'll get more aggressive on that front over time.

[01:55:24.0000] <mkwst>
tobie, et al: Is there any WebIDLish mechanism for specifying attribute setters of various types that don't do implicit conversion?

[01:56:19.0000] <mkwst>
Like, say I have `attribute DOMString innerHTML`. Can I have a setter for that attribute that accepts some other specific type that isn't a `DOMString`, without an implicit call to the stringifier?

[02:36:23.0000] <tobie>
mkwst: a union type wouldn't work in that context?

[02:37:15.0000] <mkwst>
tobie: Hrm. I guess a union type could work. The getter would just always return `DOMString`?

[02:40:03.0000] <tobie>
mkwst: yeah. :-/

[02:40:39.0000] <mkwst>
I mean, that's what I want. :) I'm just trying to find the right way of expressing the kind of thing I'm trying to play around with.

[02:41:42.0000] <mkwst>
It didn't occur to me that something like `attribute (SpecialType or DOMString) whatever` would actually work.

[02:42:39.0000] <tobie>
mkwst: we have this discussion quarterly. Types are both a coercion system and a documentation for the return value of the getters… which tbh is quite confusing.

[02:42:57.0000] <mkwst>
Well, it is Q3. :)

[02:43:27.0000] <tobie>
Good. Love it when we have it so early.

[02:43:33.0000] <tobie>
:D

[02:43:40.0000] <mkwst>
Right. Getting it out of the way... ;)

[02:43:55.0000] <tobie>
Yeah, thanks!

[02:45:05.0000] <tobie>
So the fact that it always returns a DOMString will need to be specified in prose.

[02:46:31.0000] <mkwst>
Makes sense. :)

[04:45:14.0000] <GPHemsley>
jgraham: Dunno if this is you, but something is still wrong with the testrunner in Chrome

[04:45:34.0000] <GPHemsley>
Safari and Edge are fixed

[04:50:30.0000] <GPHemsley>
annevk, Domenic: It appears that Edge treats a base URL with a single-letter protocol as a Windows drive letter, and then converts it to file:

[04:51:09.0000] <annevk>
GPHemsley: https://github.com/whatwg/url/issues/271

[04:53:19.0000] <GPHemsley>
ah, very nice

[05:15:01.0000] <jgraham>
GPHemsley: https://github.com/w3c/web-platform-tests/pull/6456 seems to have reasonable looking results for Chrome

[05:23:42.0000] <GPHemsley>
jgraham: Well, I dunno what happened here then: https://travis-ci.org/w3c/web-platform-tests/jobs/249949077

[05:24:25.0000] <GPHemsley>
is it possible there's an upper limit on test output from Chrome?

[05:25:23.0000] <jgraham>
GPHemsley: Looks like a chromedriver bug

[05:25:34.0000] <jgraham>
(and yeah, travis has a log size limit)

[05:26:15.0000] <jgraham>
But "PID 6909 | [1.563][SEVERE]: Bad inspector message: {…" seems like something rbyers should look at

[05:26:46.0000] <GPHemsley>
sounds good, thanks

[05:27:29.0000] <jgraham>
(I think that Chrome might just have a size limit on those messages, so tests with many many subtests are a problem)

[05:42:18.0000] <GPHemsley>
this is the first I've seen of it, so may have just reached that with this PR

[06:21:15.0000] <JakeA>
annevk: Surprised that opaque responses are known as "CORS-cross-origin" given that they're usually the result of a no-cors request https://html.spec.whatwg.org/multipage/urls-and-fetching.html#cors-cross-origin

[06:27:28.0000] <annevk>
JakeA: Ian minted those terms a long time ago and I haven't bothered to refactor (or lift those terms into Fetch) yet

[06:27:45.0000] <JakeA>
fair enough


2017-07-05
[23:16:41.0000] <MikeSmith>
is Service Worker importScripts(urls) still needed or can the same thing be accomplished with ES6 modules/imports

[23:17:31.0000] <MikeSmith>
JakeA: ⬆️

[00:39:49.0000] <JakeA>
MikeSmith: I'm hoping we can replace it with imports. There's some spec work to be done here so we can cache the resulting module tree

[00:40:14.0000] <MikeSmith>
super

[00:41:07.0000] <JakeA>
Moz folks: https://twitter.com/jaffathecake/status/879626556544618496 — I've asked for evidence here a few times, is there something I'm missing?

[00:41:33.0000] <JakeA>
Given some of the blog posts etc I've seem from Mozilla I'm worried it's a new strategy

[00:49:52.0000] <annevk>
JakeA: I kinda doubt it's related to that, but I've also got no special insights

[00:52:16.0000] <annevk>
JakeA: and as far as the new marketing strategy thing, I mostly understood that to be about pushing back a bit since Google advertising Chrome all over Google properties is obviously not helping Firefox

[00:53:05.0000] <annevk>
JakeA: I hope it takes a constructive form and that that blogpost was just a fluke (it was deleted from the official @firefox account after all), but time will tell

[00:54:15.0000] <JakeA>
annevk: the negative campaigning makes me sad, but I get it. I'm more worried about the hate-fiction "here's what Google people are saying…" stuff

[00:55:04.0000] <JakeA>
I guess I should just continue to ask for evidence and hope others do the same

[00:57:35.0000] <annevk>
JakeA: it seems a little disingenuous to go from "not that I don't believe you" to "hate-fiction"

[00:59:30.0000] <JakeA>
annevk: time was a factor there. I ask multiple times over multiple days. I assumed it either truthful or a misunderstanding at first, but now (plus other things) I'm worried it's deliberate

[03:00:19.0000] <annevk>
smaug: do you support https://github.com/whatwg/dom/pull/467?

[03:00:35.0000] <annevk>
smaug: giving EventTarget a constructor that is

[03:01:24.0000] <smaug>
annevk: sure, but how do I see the actual proposal

[03:01:39.0000] <smaug>
I guess some pr, but don't know which one

[03:01:47.0000] <annevk>
smaug: that's a link to the PR

[03:02:10.0000] <annevk>
smaug: each PR in whatwg/dom has Preview and Diff links in the first message

[03:02:11.0000] <smaug>
is there some way to see that in more readable  form

[03:02:21.0000] <smaug>
ahaa

[03:02:29.0000] <smaug>
now I need to find the Preview link :)

[03:02:38.0000] <annevk>
smaug: bottom of the first message

[03:03:51.0000] <smaug>
so there is no parent links here?

[03:04:00.0000] <smaug>
do we think EventTarget will be used without parent links?

[03:04:34.0000] <annevk>
smaug: folks could use it for XMLHttpRequest or WebSocket-like classes

[03:04:44.0000] <smaug>
is that something people need?

[03:05:16.0000] <annevk>
smaug: given that Node.js ended up inventing its own eventing system, I'd think so

[03:05:33.0000] <smaug>
and they don't have event target chain?

[03:06:39.0000] <annevk>
smaug: I don't think so, given https://nodejs.org/api/events.html

[03:06:49.0000] <annevk>
smaug: note that we could add a parent chain feature later

[03:07:12.0000] <annevk>
smaug: this is just the most minimal thing we can do

[03:07:35.0000] <smaug>
just wondering if we are adding something no one will use

[03:07:48.0000] <smaug>
(we have too many such features in the platform)

[03:11:43.0000] <annevk>
That event libraries exist make me somewhat hopeful, but it's always a risk of course

[03:14:13.0000] <smaug>
annevk: there is also the thing that if script libraries implement their own event target object, they can keep all processing in JS and possibly performance is better

[03:15:11.0000] <annevk>
smaug: that's something we should really try to solve over time, performance cliffs when you touch browser-implemented libraries is a problem

[03:15:48.0000] <annevk>
smaug: but it seems similar to suggesting folks should use JavaScript to animate because CSS animation isn't optimized, or some such

[03:16:00.0000] <annevk>
smaug: not great long term advice

[03:16:04.0000] <smaug>
not really similar

[03:16:17.0000] <smaug>
native side and JS side really both have their advantages

[03:17:07.0000] <smaug>
say, doing anything which touches lots of nodes in JS is slow, since it guarantees the wrappers must be created

[03:17:21.0000] <smaug>
so native helper methods are good for that kind of case

[03:18:11.0000] <smaug>
(my current guess is that servo will need to change their DOM implementation to be more like in other browsers to not create wrappers since beginning)

[03:37:53.0000] <smaug>
hmm, in general, should we think of how to make the platform faster

[03:38:47.0000] <smaug>
like create such APIs that if script libraries were using those, it would more likely that web pages would be less janky or load faster

[03:39:10.0000] <smaug>
so far it has been more like ad-hoc approach

[03:39:36.0000] <MikeSmith>
isn’t that what the webperf group is supposed to be focused on

[03:40:25.0000] <annevk>
smaug: could you comment in https://github.com/whatwg/dom/issues/414 about event creation?

[03:41:02.0000] <smaug>
MikeSmith: they seem to focus on measurements

[03:41:44.0000] <MikeSmith>
yeah I guess so

[05:24:54.0000] <annevk>
HTML no longer links to legacy bugs?

[05:37:08.0000] <JakeA>
smaug: fwiw I've wanted to have an extendable EventTarget in my own projects, and have used libraries since I couldn't use the browser's.

[05:37:19.0000] <JakeA>
I haven't needed bubbling

[05:37:59.0000] <JakeA>
I might not need it as much in a web components world, since I get it for free

[05:38:57.0000] <smaug>
JakeA: have you had parent chain with these event target like objects?

[05:39:37.0000] <JakeA>
smaug: if you mean capturing/bubbling, no, I haven't needed it

[05:39:54.0000] <smaug>
aha, I thought you just didn't need bubble phase

[05:40:01.0000] <smaug>
but ok, no propagation

[05:40:19.0000] <JakeA>
yeah, sorry. I mean I haven't needed the chain

[06:47:59.0000] <wanderview>
JakeA: to your question to "moz folks" above... i think we've had these concerns for a while... its not google saying "ignore best practices", but instead signal boosting anything related to PWA with other web best practices relegated to a footnote or ignored completely... classic example I can think of is flipkart (which obviously I was concerned about long before we had a billboard)

[06:48:26.0000] <wanderview>
flipkart worked out in the end... but it easily could have gone sideways

[06:49:26.0000] <JakeA>
wanderview: in terms of it being Chrome only?

[06:50:01.0000] <JakeA>
(my memory is foggy here, was it Chrome only?)

[06:51:15.0000] <wanderview>
JakeA: I took an animated gif of what it did at the time here: https://blog.wanderview.com/blog/2016/06/10/flipkart-google-and-the-web/

[06:51:24.0000] <wanderview>
I don't really want to re-litigate that

[06:51:40.0000] <wanderview>
I only mention it in response to the question "is this a new sinister messaging plot from mozilla"

[06:52:45.0000] <wanderview>
if anything, mozilla is a cacophony of voices and coherent messaging is one of the things we don't know how to do at all

[06:53:48.0000] <JakeA>
wanderview: that's fair. I agree that Flipkart at the time was a poor example of the P in PWA, but I hope we never suggested that their initial shrugging of Firefox was a good (or ok) thing

[06:54:23.0000] <JakeA>
I guess that might have seemed implicit by singing Flipkart's praises.

[06:54:27.0000] <wanderview>
JakeA: google boosted it as a good example... never said that practice was bad in a public place... what is the implication to random people reading about it?

[06:54:35.0000] <wanderview>
yea

[06:54:58.0000] <JakeA>
Back then, PWA examples were thin on the ground, but I take your point

[06:55:03.0000] <wanderview>
JakeA: anyway, I don't see that happening as much lately... but I'm not keyed into other web practices that might be getting less coverage like accessibility

[06:55:20.0000] <wanderview>
I do recall accessibility being on topic at PWA Summit last year, though

[06:55:25.0000] <JakeA>
I think I publicly said it wasn't progressive (and complained about the lack of server rendering)

[06:55:32.0000] <wanderview>
JakeA: but I think its more from this kind of thing that people are concerned

[06:56:42.0000] <wanderview>
JakeA: sure, and that was appreciated... but a tweet is poorly balanced against glossy copy on a google.com domain

[06:58:05.0000] <JakeA>
That's fair

[07:01:23.0000] <wanderview>
JakeA: obviously google can't always be saying "PWA's are awesome, but let me talk for an hour about all the other web stuff you should also be doing"... so I see why things have been done the way they have and I don't think it was sinister in any way... but I also just understand why some people are concerned

[07:01:45.0000] <wanderview>
/me sees both sides and has no solutions.

[07:01:49.0000] <wanderview>
/me is useless.

[07:02:23.0000] <wanderview>
I think things like you the slide you linked above in your tweet are good

[07:02:35.0000] <wanderview>
including accessibility topics in summits is good

[07:02:58.0000] <wanderview>
and on balance "PWA" has been good

[07:03:08.0000] <JakeA>
wanderview: I'm also concerned about the lack of P in many PWAs. But yeah, we need to increase the volume on PWA != SPA

[07:04:47.0000] <wanderview>
JakeA: I agreed with a lot of Jeremy's post: https://adactio.com/journal/12461

[07:08:11.0000] <JakeA>
Same

[07:21:20.0000] <nox>
JakeA: Given you are a Googler, what is your opinion on the Houdini stuff?

[07:24:11.0000] <nox>
If you have any, that is.

[07:24:21.0000] <JakeA>
nox: It's sometimes difficult to figure out what's part of it and what isn't. The typed OM for CSS is much needed, especially now we have things like DOMMatrix. I'm not hugely excited about a paint worklet, but I might be lacking imagination. I'm very excited about an animation worklet, for running animations on the compositor thread and linking them to things like scrolling. I'm fascinated about what custom layout will allow.

[07:24:37.0000] <nox>
JakeA: What I had in mind was custom paint etc,

[07:24:48.0000] <nox>
things that pcwalton doesn't like, based on knowledge I don't possess.

[07:24:59.0000] <JakeA>
But I haven't read any of the specs in detail, so I'm only commenting on vague details

[07:25:05.0000] <nox>
Ok.

[07:26:27.0000] <annevk>
Didn't pcwalton mention compositor could maybe be merged with some other layer, maybe paint?

[07:26:29.0000] <JakeA>
nox: I didn't know that pcwalton wasn't keen on it. I imagine him having more to say about the compositor & layout stuff than paint

[07:26:45.0000] <nox>
Oh yes.

[07:27:01.0000] <nox>
JakeA: My knowledge is so limited I still have troubles distinguishing all these parts from each other. :D

[07:27:06.0000] <JakeA>
Same!

[07:27:40.0000] <nox>
"The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people

[07:27:41.0000] <nox>
implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread."

[07:27:45.0000] <nox>
is the piece I had in mind.

[07:28:03.0000] <nox>
https://news.ycombinator.com/item?id=14427494

[07:29:59.0000] <JakeA>
I disagree in regards to layout. In an ideal world we should have been able to polyfill grid before browser support landed.

[07:30:43.0000] <JakeA>
For me, it's about being able to add features in a fast way, rather than taking an existing feature and making it faster.

[07:31:05.0000] <nox>
JakeA: Isn't his point that if things were fast enough, they could be polyfilled without custom layout?

[07:31:57.0000] <JakeA>
nox: Wouldn't that involve implementing layouts in JS? Whereas he suggested it was performance (not features) that caused people to do that

[07:32:40.0000] <nox>
AFAIU his comment, he is saying people are pushing for custom layout because implementing layout in JS is too slow, because of architectural issues in general in the major browsers.

[07:32:57.0000] <nox>
Oh I misread that indeed.

[07:33:33.0000] <nox>
JakeA: Later he agrees with you I think. "That's fair. I don't have an issue with Houdini if it's actually used to create custom layouts that you can't reasonably do in CSS."

[07:34:23.0000] <gsnedders>
Houdini is mostly JS APIs, though. So surely it would involve implementing layouts in JS whatever you do?

[07:34:27.0000] <JakeA>
Ahh, fair enough. I agree with that bit. I'm interested in a world were layout performance isn't an issue, but I'd need to see it to believe it :D

[07:34:55.0000] <JakeA>
gsnedders: I think the plan is to spin up light weight worklets in multiple threads

[07:35:20.0000] <nox>
JakeA: I take pcwalton's comment as "SERVO GOT 99 ISSUES, BUT FAST LAYOUT AIN'T NONE"

[07:35:22.0000] <nox>
:)

[07:35:37.0000] <JakeA>
haha

[07:35:54.0000] <JakeA>
I guess I should try and get a build working on a phone and throw some width/height animations at it

[07:36:00.0000] <nox>
2,169 (known) issues, to be correct.

[07:36:01.0000] <annevk>
I doubt it'll be a non-issue (especially now there's the 120 Hz push from Apple and the eventual 240 Hz push for VR), but I do believe Servo shows we can do much better

[07:36:05.0000] <wanderview>
in fairness, servo's parallel layout is incomplete and more of a proof-of-concept

[07:36:17.0000] <nox>
wanderview: It's not *that* incomplete.

[07:36:30.0000] <JakeA>
I'm fighting for moving clip-path to the compositor, as "reveal" animations seem to be our sticking point right now

[07:36:34.0000] <annevk>
nox: pcwalton said it basically needed to be redone

[07:36:54.0000] <nox>
annevk: WR 42 could exist that Patrick would say it needs to be redone, IMHO. :P

[07:37:12.0000] <annevk>
nox: current architecture doesn't scale well or some such

[07:37:18.0000] <annevk>
nox: not sure what WR 42 is

[07:37:19.0000] <nox>
Oh ok.

[07:37:24.0000] <nox>
annevk: WebRender 42.

[07:37:37.0000] <nox>
annevk: I'm just saying Patrick and Glenn seems to be rewriting it every 6 months. :)

[07:37:39.0000] <annevk>
nox: WebRender isn't parallel layout though

[07:37:55.0000] <annevk>
nox: WR is post-layout

[07:37:58.0000] <nox>
annevk: Cf. what I said earlier about not distinguishing them parts.

[07:38:00.0000] <nox>
annevk: You are right.

[07:38:05.0000] <annevk>
nox: parallel layout is box creation and such

[07:38:20.0000] <nox>
Layout is the crate that scares me just as much as WR so I can't distinguish them in my mind. ( ._.)

[07:38:28.0000] <annevk>
hah

[07:43:06.0000] <gsnedders>
JakeA: tbf, AIUI some of the objections to it are the fact that some of the perf bottlenecks used to justify Houdini are essentially "this isn't in the compositor" when Servo shows you can do them in the compositor

[07:44:11.0000] <JakeA>
annevk: The HTML spec is complaining at me using <code> (because there's no dfn), but I'm using it for things like byte-sequences. What's the workaround?

[07:44:29.0000] <annevk>
JakeA: <code data-x="">...</code>

[07:44:38.0000] <JakeA>
\o/ cheers

[07:45:58.0000] <Domenic>
When I tried Servo it was super-slow, so I was not impressed by the claims of servo showing we can do better... Planning to re-judge when someone shouts from the Twitters that there has been progress, but I think at least the narrative that if you just do everything right from scratch it will be fast is falsified. You still need a lot of optimization effort to get something reasonable for the web.

[07:46:03.0000] <annevk>
From Twitter, update on Streams: https://blog.whatwg.org/progressing-streams

[07:46:18.0000] <Domenic>
annevk: "HTML no longer links to legacy bugs?" I haven't noticed that, but it's plausible we broke it somewhere :-/

[07:46:43.0000] <annevk>
Domenic: afaict the top just has "Open Issues"

[07:46:53.0000] <Domenic>
annevk: oh, the top, not the margins

[07:47:09.0000] <Domenic>
Yeah I removed that to make room for the dev edition because an odd number of things looks really bad on mobile

[07:47:28.0000] <gsnedders>
Domenic: super-slow perceptively?

[07:47:53.0000] <Domenic>
gsnedders: yeah, just trying to browse some websites and scroll and click things

[07:48:22.0000] <gsnedders>
Domenic: AFAIK a lot of that is simply the fact that things that make a big perceptive difference are quite bad, though the traditionally slow stuff like layout is super-fast

[07:48:54.0000] <Domenic>
Sounds plausible I guess.

[07:49:11.0000] <nox>
Cf. the demo by a googler with the animated shapes.

[07:49:50.0000] <nox>
Domenic: I don't do any graphics or layout or whatever, but I do some DOM in Servo,

[07:50:22.0000] <nox>
Domenic: animations and whatnot can hit 60 fps with no issues, and aside from that then you have HTMLCollection that is extremely naive,

[07:50:38.0000] <nox>
and for example in the past if you did for elem in collection,

[07:50:55.0000] <nox>
it would just internally call collection.item(i) for all i from 0 to the length of the collection,

[07:51:08.0000] <nox>
and the traversal to retrieve the ith element would always start from the root of the document.

[07:51:59.0000] <JakeA>
nox: that might have been me https://www.youtube.com/watch?v=u0hYIRQRiws - but it didn't involve layout

[07:52:05.0000] <nox>
So yeah, some things are extremely slow.

[07:52:11.0000] <nox>
JakeA: Ugh, yes and yes.

[07:52:20.0000] <nox>
I'll just assume that layout is never what I have in mind. ;)

[07:53:04.0000] <nox>
JakeA: Oh right, animations obviously are post-layout, is that right?

[07:53:49.0000] <JakeA>
nox: it was only changing transform, background & border-radius, none change layout

[07:54:10.0000] <nox>
JakeA: Right. Hence why you mentioned animating width and height earlier, right?

[07:55:46.0000] <JakeA>
Yeah, those would change layout inside and probably outside the element

[07:56:11.0000] <JakeA>
http://output.jsbin.com/surane/quiet runs very well in Safari these days (in the tech preview at least)

[09:41:09.0000] <annevk>
wanderview: there's tests for AbortController and AbortSignal

[09:41:21.0000] <annevk>
wanderview: not sure about fetch() + AbortSignal, JakeA might know

[09:42:06.0000] <annevk>
wanderview: I guess if we had tests for fetch() + AbortSignal that would be enough to proceed with the impl, perhaps we should focus on that first rather than figuring out how to refactor Fetch

[09:48:14.0000] <JakeA>
annevk: I can pick that up

[09:50:20.0000] <annevk>
JakeA: cool, I guess if we can put all the edge cases in tests, it'll make it easier to figure out the spec (or at least we know what it should say)

[09:57:03.0000] <JakeA>
annevk: the tests shouldn't include signals in a service worker right? That's v2?

[10:14:08.0000] <annevk>
JakeA: yeah, though passing a signal to fetch() in a service worker should work

[10:17:32.0000] <JakeA>
annevk: yeah, I'll test in worker contexts too. What's the purpose of t.step_func? Does the test fail if one of the step_funcs isn't called?

[10:18:17.0000] <annevk>
JakeA: it makes sure that exceptions in callbacks get routed to the test as well

[10:18:29.0000] <annevk>
JakeA: basically makes callbacks part of the test

[10:19:13.0000] <JakeA>
ahhhh yeah of course

[10:19:27.0000] <JakeA>
(I've only written promise tests so far)

[10:19:33.0000] <wanderview>
annevk: keeping everything in promises kind of does the same, though

[10:19:50.0000] <wanderview>
and you don't have to pass t around

[10:20:21.0000] <annevk>
wanderview: yeah, it makes less sense to use for promise APIs I suppose, though you'll need it here for the callback maybe?

[10:20:31.0000] <annevk>
wanderview: that is, the abort event

[10:20:38.0000] <wanderview>
ok

[10:20:54.0000] <wanderview>
I have mostly avoid t.step_func() because I didn't understand it

[10:21:06.0000] <JakeA>
It makes sense in https://github.com/w3c/web-platform-tests/pull/5960/files as it needs to ensure the event fires synchronously

[10:21:08.0000] <wanderview>
/me just presses keys till the thing works...

[10:21:14.0000] <JakeA>
Same :D

[10:22:00.0000] <annevk>
Basically if you don't use it and the browser fails something you get a global failure and otherwise you just get a test failure

[10:22:39.0000] <annevk>
But it's a little tricky indeed, especially with all the t.step_func_done() variants and such

[15:25:36.0000] <TabAtkins>
nox: pcwalton's opining on Houdini is missing the entire point; you *absolutely cannot* implement layout in JS today in a way that faithfully interacts with the built-in layout system properly (for example, providing proper min-content and max-content contributions, which Flex and Grid layout use extensively).

[15:25:59.0000] <TabAtkins>
The point of Houdini isn't to magically make anything faster, but to provide the correct hooks into the existing systems.

[15:26:29.0000] <nox>
TabAtkins: I think that's the part of Houdini he conceded was useful, no?

[15:26:34.0000] <TabAtkins>
(It will in many cases make things faster, as we can provide you the right information and only ask you to do work when it's needed, but that's a benefit on top.)

[15:26:40.0000] <nox>
Or did you mention layout just as an example?

[15:26:49.0000] <TabAtkins>
Just as an example.

[15:28:24.0000] <TabAtkins>
Same applies to, for example, Paint - Houdini gives you the right lifecycle hooks (draw only when we need a new image) and the right information (here's the size the image will be rendered at) to let you do correct, efficient painting. Without Houdini, you can draw to a canvas and render to a data url, but your image won't be at the proper resolution (matching up canvas pixels to screen pixels) unless you manually coordinate

[15:28:24.0000] <TabAtkins>
things, and you'll probably draw too early, and/or too often.

[16:22:37.0000] <jolvera>
would be useful to add some kind of syntax highlighting for code snippets?

[16:22:58.0000] <jolvera>
e.g. https://dsh.re/5918b


2017-07-06
[18:08:30.0000] <Domenic>
jolvera: definitely, yeah.  We have one possibility in progress at https://github.com/whatwg/html/pull/2751 but it's client side and breaks some things that currently work, like where the spec highlights certain parts of the code as bad or good or changed.

[18:08:56.0000] <Domenic>
I'm hoping TabAtkins can factor out his highlighter from Bikeshed so we can run through that

[18:09:29.0000] <TabAtkins>
Oh, you want that? It's just Pygments, with some extra code to merge highlighting into existing markup.

[18:09:42.0000] <TabAtkins>
Tho there's also now custom line-numbering/highlighting code too.

[18:11:42.0000] <TabAtkins>
Oh, plus it relies on widlparser for highlighting WebIDL, because Pygments doesn't do that language.

[18:12:25.0000] <Domenic>
Yeah, don't need the line number stuff really, but packaging up pygments + merge + Web IDL into something we could shell out to would be lovely

[18:14:25.0000] <TabAtkins>
Can you just shell out the html contents of a given element? Much easier if that's all I need to worry about, rather than parsing and finding the highlightable elements myself.

[18:22:00.0000] <jolvera>
if it's Pygments it can be added through the build process

[18:22:03.0000] <jolvera>
right?

[18:22:09.0000] <TabAtkins>
Actually, I need an intermediate format - text requires me to include a full parser, but markup doesn't have a cross-lang built-in data structure. You have the parsed spec, right? Can you generate a `[tagname, {attrs}, ...contents]`-style tree?

[18:22:32.0000] <TabAtkins>
jolvera: It's not *just* Pygments, because Pygments only works on raw text. Bikeshed has extra smarts to merge it into existing markup.

[18:24:37.0000] <jolvera>
oh ok, im not familiar with Bikeshed

[18:35:53.0000] <Domenic>
TabAtkins: yes, that should work.

[18:36:09.0000] <Domenic>
Oh, then I read the intermediate format thing

[18:36:28.0000] <Domenic>
Probably still doable

[18:36:31.0000] <Domenic>
Let me capture this in an issue

[18:38:16.0000] <jolvera>
i've another question, that maybe i should ask in the issue, but

[18:38:17.0000] <jolvera>
https://github.com/whatwg/html/issues/2779

[18:38:33.0000] <jolvera>
the former implementation used a search_index.json that probably was generated on build process

[18:39:31.0000] <jolvera>
https://github.com/benschwarz/developers.whatwg.org/blob/97ff943a8f5b8fe38f78e224b4b44b472ccefb57/javascript/master.js#L44-L53

[18:40:06.0000] <Domenic>
jolvera: yep, re-generating that is the primary task. Unfortunately our build tooling is kind of hard to hack on :(.

[18:40:32.0000] <jolvera>
generating the index on page load async isn't an option?

[18:41:04.0000] <Domenic>
Like... downloading and spidering every page of the spec to assemble it each time? That seems pretty slow to me...

[18:41:15.0000] <jolvera>
not on load, and if someone happen to click the search box before it's done adding a message of loading?

[18:41:24.0000] <jolvera>
well, just getting the list of links to create a index on memory

[18:41:50.0000] <jolvera>
as in https://dsh.re/c3498

[18:41:57.0000] <Domenic>
Still, spidering 40+ pages to find all their headings seems pretty hard...

[18:42:16.0000] <Domenic>
And slow

[18:42:25.0000] <Domenic>
Better than nothing I guess?

[18:43:21.0000] <jolvera>
worth a try

[18:44:56.0000] <jolvera>
unless, is there a way to add separate processes like in python

[18:45:13.0000] <jolvera>
a small python script could do this on build process

[18:45:28.0000] <jolvera>
or node

[18:46:12.0000] <Domenic>
Yeah, that is probably the best middle ground

[18:46:23.0000] <Domenic>
Ideally we would integrate it into our existing build tooling, which is already traversing the document

[18:46:29.0000] <Domenic>
I think I'd like to try that, at least

[18:46:39.0000] <Domenic>
But the tooling is written in FreePascal, which makes it hard to find contributors

[18:46:47.0000] <Domenic>
So we're open to slower alternatives written in normal languages

[18:47:49.0000] <jolvera>
kk

[18:50:44.0000] <Domenic>
https://github.com/whatwg/html-build/issues/113 for syntax highlighting, TabAtkins

[19:30:49.0000] <jolvera>
Domenic is it possible to add classes to h2, h3, and h4 inside the section page?

[19:31:20.0000] <jolvera>
`<h3 id="is-this-html5?">` to `<h3 id="is-this-html5?" class="section-heading">`

[19:31:57.0000] <Domenic>
jolvera: I don't see why we'd need it? h3 is always a section heading

[19:32:26.0000] <jolvera>
to generate the search_index.json and make the scrapping faster

[19:32:39.0000] <jolvera>
and get each one ordered on the way

[19:33:22.0000] <jolvera>
instead i'd have to get all  h3's then h4's and order based on the '.secno'

[19:35:37.0000] <Domenic>
Why order based on secno? They're already in order

[19:35:46.0000] <Domenic>
querySelectorAll("h3, h4") --> all in order

[19:38:20.0000] <jolvera>
oh ok, you right, that actually works on python too

[19:38:49.0000] <Domenic>
\o/

[19:38:51.0000] <jolvera>
html.cssselect('h3, h4') gives me the same output. nvm then :)

[22:38:55.0000] <jolvera>
i've created a python script that generates the same search_index.json file as the ruby version

[22:38:58.0000] <jolvera>
https://gist.github.com/thinkxl/f8722c6fba97e97d67e84cb32c22cb5f

[22:40:48.0000] <jolvera>
if we would use this, how it could be integrated into the build process

[22:41:03.0000] <jolvera>
it has two dependencies, lxml and cssselect

[22:41:08.0000] <jolvera>
cc Domenic

[22:43:02.0000] <jolvera>
i'll update the GitHub issue

[02:39:27.0000] <annevk>
TabAtkins: nox: I think the main concern with Houdini is that it might force slow paths in the future as it's primarily being built on top of a single-thread architecture for doing all things CSS

[02:41:20.0000] <annevk>
TabAtkins: nox: see e.g. https://twitter.com/pcwalton/status/835937849237106688

[02:41:28.0000] <annevk>
(and replies)

[04:56:34.0000] <yhirano__>
annevk: can you tell me the relationship between RFC2045 and mime type parsing algorithm in https://mimesniff.spec.whatwg.org/?

[05:02:07.0000] <annevk>
yhirano__: I haven't investigated MIME type parsing

[05:03:05.0000] <yhirano__>
It's referenced from XHR overrideMimeType, and you wrote a wpt depending on the behavior.

[05:03:50.0000] <yhirano__>
annevk: http://w3c-test.org/XMLHttpRequest/overridemimetype-blob.html

[05:06:58.0000] <annevk>
yhirano__: I tried to pick MIME types that are invalid in both the RFC and the MIME Sniffing

[05:06:59.0000] <yhirano__>
annevk: "HI/x;test", used in the last case, seems valid in the algorithm and invalid in RFC2045. Is that intentional?

[05:08:22.0000] <annevk>
yhirano__: it wasn't

[05:08:40.0000] <annevk>
yhirano__: I'd be okay if we changed that to ;test=test

[05:09:13.0000] <yhirano__>
annvk: thanks, we

[05:09:28.0000] <yhirano__>
annevk: thanks, we'll change it.

[05:59:04.0000] <GPHemsley>
yhirano__: It's been a while, but I might be of some assistance here

[06:02:14.0000] <GPHemsley>
yhirano__: As I recall, the decision to allow keys without values in the MIME type parsing algorithm was to accommodate 'base64' in data URLs

[06:02:37.0000] <GPHemsley>
so we didn't have to special case

[06:04:06.0000] <GPHemsley>
(see step 9 in serializing a MIME type0

[06:19:12.0000] <yhirano__>
GPHemsley:  We are currently using the parser for RFC2045 and as an implementer it would be really great if the spec could also use it. Maintaining many similar (but differnt) parsers is really hard...

[06:21:33.0000] <yhirano__>
GPHemsley:  It's OK to add or remove some restrictions to/from the RFC2045 rule, but with the current (really complicated) algorithmic style It's hard to see how different it is from the RFC2045 rule.

[06:27:37.0000] <GPHemsley>
yhirano__: When the definition of a language goes from context-free to context-sensitive, the parsing algorithm necessarily becomes more complex.

[06:28:01.0000] <GPHemsley>
yhirano__: That said, I'm no longer the maintainer of the spec, so changes (or lack thereof) are no longer my call.

[08:41:46.0000] <wanderview>
JakeA: who cares about requestIdleCallback() in chrome?

[08:42:48.0000] <wanderview>
eh, I'll just write an issue

[08:43:10.0000] <JakeA>
wanderview: igrigorik & Ross Mcilroy

[08:44:19.0000] <wanderview>
thanks

[08:44:25.0000] <wanderview>
igrigorik: is this expected behavior? https://bugs.chromium.org/p/chromium/issues/detail?id=739750

[08:45:27.0000] <JakeA>
ohh that's a good one


2017-07-07
[01:40:17.0000] <annevk>
smaug: I guess given https://github.com/whatwg/dom/issues/441#issuecomment-313061068 we can move ahead now with the EventTarget constructor?

[01:41:23.0000] <smaug>
yup

[01:52:24.0000] <smaug>
/me thinks about implementation. I guess EventTarget::Constructor would just return DOMEventTargetHelper, and that one would have WrapObject method to return EventTarget binding. webidl + ~10 lines code?

[01:52:35.0000] <smaug>
annevk: there will be some wpt too, right?

[01:52:54.0000] <annevk>
smaug: yeah, I just reviewed those

[01:53:08.0000] <annevk>
smaug: https://github.com/w3c/web-platform-tests/pull/6306

[07:03:09.0000] <annevk>
P: "To be perfectly clear, ..." Me: *Great* P: *not at all clear* Me: 😟

[07:08:18.0000] <wanderview>
JakeA: the response on that chromium issue was surprising to me... but ¯\_(ツ)_/¯

[07:11:02.0000] <annevk>
wanderview: I think they were just explaining how it works, maybe not whether it's a great setup?

[07:11:47.0000] <wanderview>
¯\_(ツ)_/¯

[07:12:42.0000] <annevk>
😊

[07:21:21.0000] <wanderview>
JakeA: does the spec really say what browsers have to do in the background?  Seems like browsers tend to do impl specific stuff for rAF, setTimeout(), etc in the background

[07:25:13.0000] <JakeA>
wanderview: It's suggested in this note https://www.w3.org/TR/requestidlecallback/#start-an-event-loop-s-idle-period, but yeah it isn't normative

[07:25:41.0000] <wanderview>
/me shakes head at JakeA using TR specs.

[07:25:54.0000] <JakeA>
ah shit

[07:26:03.0000] <wanderview>
wasn't Domenic going to make an addon to auto-fix spec links?

[07:26:12.0000] <wanderview>
JakeA: but the editors draft is the same: https://w3c.github.io/requestidlecallback/#start-an-event-loop%27s-idle-period

[07:26:53.0000] <wanderview>
we limit to one idle period per second while in the background, fwiw

[07:26:57.0000] <JakeA>
wanderview: few, that'd have been even more embarrassing otherwise

[07:27:06.0000] <wanderview>
simply because we leverage the same code that our setTimeout stuff uses

[07:30:07.0000] <JakeA>
*phew

[07:30:22.0000] <JakeA>
ugh I wish I could see even half the shit I spell wrong

[07:30:53.0000] <wanderview>
JakeA: I think people just blame auto-correct these days

[07:31:22.0000] <JakeA>
wanderview: I have no such excuse right now, but I'll use it anyway

[07:41:31.0000] <annevk>
Sigh, week went by quickly

[07:41:41.0000] <annevk>
Haven't really made any progress on navigation

[07:46:28.0000] <wanderview>
JakeA: difference in behavior between chrome and FF on this is interesting: https://idle-no-render.glitch.me/

[07:46:41.0000] <wanderview>
firefox runs ~14 idle periods when there is no rendering

[07:46:47.0000] <wanderview>
chrome maxes the cpu

[07:47:09.0000] <wanderview>
feels like maybe a bug in firefox

[07:48:15.0000] <wanderview>
although I think we try to anticipate things like timeouts scheduled to run on the main thread... and we do have more of that kind of stuff since we run browser chrome script in our content processes

[07:48:21.0000] <wanderview>
so maybe its correct

[07:48:27.0000] <wanderview>
we just have a busier main thread

[07:49:05.0000] <JakeA>
wanderview: Is the number number of calls per second?

[07:49:12.0000] <wanderview>
JakeA: yea

[07:49:26.0000] <wanderview>
its slower than with requestAnimationFrame running... seems weird

[07:49:45.0000] <JakeA>
wanderview: In Firefox, if I select the text and flail the mouse around, it goes up to 60, which is the opposite of what I'd expect

[07:50:20.0000] <wanderview>
yea

[07:50:22.0000] <JakeA>
Rendering causes it to increase

[07:51:02.0000] <wanderview>
/me files a bug

[07:53:53.0000] <wanderview>
https://bugzilla.mozilla.org/show_bug.cgi?id=1379178

[08:53:15.0000] <wanderview>
JakeA: farre suggests that we fire fewer rIC callbacks when not rendering because we have switched to "long idle periods"... this is kind of talked about in a note here: https://w3c.github.io/requestidlecallback/#idle-periods

[08:54:33.0000] <wanderview>
I guess I should track what our deadline in each callback is

[10:40:45.0000] <wanderview>
yea, I don't think chrome is waiting for the next idle period like its supposed to

[12:07:50.0000] <Domenic>
MikeSmith: sideshowbarker.net is down preventing spec deploys that are using it for validation :-/

[13:09:47.0000] <minot>
is https://checker.html5.org/ down?

[13:17:49.0000] <KiChjang>
looks like so, i'm not able to connect to it

[13:18:32.0000] <Domenic>
Probably related to MikeSmith's servers being down

[15:12:16.0000] <jsbell>
Any reason we haven't made DataTransferItemList iterable<> ?

[16:48:25.0000] <Domenic>
jsbell: I think it automatically is because of the indexed getter and length property

[16:48:40.0000] <jsbell>
ah yes...

[16:49:03.0000] <Domenic>
https://heycam.github.io/webidl/#es-iterators second bullet

[16:50:12.0000] <jsbell>
ah well, I wanted to .map it anyway. Array.from() FTW

[16:51:21.0000] <Domenic>
Or [...list], at least in non-Edge browsers


2017-07-08
[17:05:44.0000] <jolvera>
Domenic i see JavaScript code using fetch in the html repository

[17:06:00.0000] <jolvera>
can we use fetch and reduce for the search bar?

[17:07:49.0000] <Domenic>
jolvera: definitely. For dev edition at least we should be able to assume latest of each browser IMO.

[17:07:58.0000] <jolvera>
nice

[18:31:05.0000] <a-ja>
MikeSmith: ping

[18:33:56.0000] <a-ja>
mkwst: ping

[18:48:29.0000] <bigblind>
Hi, I have a possibly weird question. Would it be worthwhile to propose a standard for servers that serve images to suggest alt tags? Dynamically generated images like badges on Github, Stackoverflow flare and 90's visitor counters can't have a useful alt tag at the moment.

[18:51:04.0000] <bigblind>
oh and by alt tags, I mean an alt attribute :)  It's late here and my brain is too fried to use correct terminology.

[19:10:07.0000] <a-ja>
bigblind: perhaps https://www.w3.org/TR/html-alt-techniques/   <== now defunct

[19:13:45.0000] <a-ja>
https://www.w3.org/TR/IMPLEMENTING-ATAG20/

[19:15:12.0000] <bigblind>
a-ja: Even the link where that document says more content can be found seems broken, it just links to the html element, and the ID doesn't exist on the page as far as I can tell

[19:18:14.0000] <a-ja>
indeed

[19:19:23.0000] <a-ja>
think there was an old whatwg authoring guidance doc at some point, too, though i can't seem to be able to find that one anymore.

[20:34:47.0000] <TabAtkins>
Hm, like a header for alt value? Might be interesting.

[20:39:57.0000] <bigblind>
Yep, that's what I was thinking

[21:27:47.0000] <MikeSmith>
Domenic: https://sideshowbarker.net is back

[21:28:27.0000] <MikeSmith>
and https://checker.html5.org/ is back (though the downtime there was unrelated)

[21:28:37.0000] <MikeSmith>
a-ja: here now

[21:34:28.0000] <a-ja>
MikeSmith: never mind...thought there was a validator problem with = signs in CSP report-to

[21:36:31.0000] <MikeSmith>
a-ja: OK

[21:36:50.0000] <a-ja>
MikeSmith, gonna support link/header rel=serviceworker any time soon?

[21:37:41.0000] <MikeSmith>
I thought I already added support for link rel=serviceworker

[21:37:52.0000] <a-ja>
MikeSmith, btw, nice that you cleaned up the page footer :)

[21:37:59.0000] <MikeSmith>
as far as the header checking, no plan to add support for that at this point

[21:38:04.0000] <MikeSmith>
cleaned up the page footer?

[21:38:15.0000] <MikeSmith>
I can’t remember making any recent change there

[21:39:06.0000] <MikeSmith>
I’m not opposed to adding rel=serviceworker Link header checking if there’s some value that merits adding it

[21:39:23.0000] <a-ja>
doesn't like scope, updateviacache, or workertype attributes

[21:39:29.0000] <MikeSmith>
but in general the checker isn’t doing header checking, with a few exceptions

[21:39:33.0000] <MikeSmith>
ah

[21:39:39.0000] <MikeSmith>
yeah those were added recently

[21:39:47.0000] <MikeSmith>
so I need to update the source

[21:40:11.0000] <MikeSmith>
if you could file an issue for that with a minimal test case, that would help

[21:40:21.0000] <MikeSmith>
I can add the support this weekend

[21:40:51.0000] <MikeSmith>
aslo FYI if there is ever an HTML checker issue with checking CSP headers, it’s due completely to the underlying code in the Salvation library the checker depends on for that

[21:40:51.0000] <a-ja>
no Github account, but I guess now's the time to get one

[21:41:11.0000] <MikeSmith>
well yeah you should have a github account :)

[21:41:23.0000] <MikeSmith>
you will find it useful for other things

[21:42:03.0000] <MikeSmith>
like filing bugs against the Salvation sources too :)

[21:42:10.0000] <a-ja>
heh

[01:49:26.0000] <nox>
TabAtkins: I see that Webkit serialises calc(42) as 42 but Gecko doesn't. Is that completely unspecified?

[06:56:00.0000] <TabAtkins>
nox: Specified, but the section is less than a year old https://drafts.csswg.org/css-values/#calc-serialize

[07:45:06.0000] <nox>
TabAtkins: Thanks.

[07:56:02.0000] <nox>
TabAtkins: So calc(42) is calc(42) when serialising specified values, and 42 when serialising computed values, right?

[07:56:09.0000] <TabAtkins>
Yeah

[07:56:17.0000] <nox>
And for a specified non-negative number, calc(-42) becomes calc(0) and then 0?

[07:56:37.0000] <TabAtkins>
Yup.

[07:57:10.0000] <nox>
TabAtkins: ACK.

[07:57:25.0000] <nox>
Will try to align Servo and see if Gecko tests fail.

[07:57:31.0000] <TabAtkins>
Assume that's "message recieved" and not "Cathy-like freaking out".

[07:58:07.0000] <nox>
TabAtkins: The former indeed. :)

[08:00:31.0000] <TabAtkins>
Just to clarify - the "becomes calc(0) and then 0" happens at computed-value time. It's still calc(-42) at specified value time.

[08:04:22.0000] <nox>
TabAtkins: Oh!

[08:04:31.0000] <nox>
TabAtkins: Well, guess I have nothing to fix then! :D

[08:04:49.0000] <TabAtkins>
Good then!

[08:05:47.0000] <TabAtkins>
Yeah, all that happens at specified-value time is that you resolve it down to a sum of units, and combine identical ones.


2017-07-09
[15:58:15.0000] <domfarolino>
Does it seem a little unintuitive that the two examples in this fiddle (https://jsfiddle.net/domfarolino/d5e58o4j/) produce different results?

[15:58:24.0000] <domfarolino>
...I mean I'm reading `innerText` in HTML spec and the results are not surprising, but does it seem a little odd it is defined this way to anyone or am I just missing something?

[16:00:55.0000] <domfarolino>
"defined this way" = defined in a way such that the recursive portion of the algorithm is only a subset of the entire thing ("is rendered" checks only happen one time no matter how many times we recurse)...actually the more I think about it..is the intention of this to be more performant and not constantly recalc styles all the time? cc Domenic

[16:39:42.0000] <domfarolino>
Meh this fiddle (https://jsfiddle.net/domfarolino/fr3pd3f0/) is more intuitive


2017-07-10
[21:12:06.0000] <MikeSmith>
botie, inform a-ja I added scope/updateviacache/workertype support to the checker sources and pushed to https://checker.html5.org/ & https://validator.w3.org/nu/ I also added some filtering for now to suppress the warning about child-src

[21:12:07.0000] <botie>
will do

[00:07:10.0000] <annevk>
domfarolino: sounds like you didn't leave your sense of logic at the door

[00:19:47.0000] <MikeSmith>
annevk: if/when you have time please read https://stackoverflow.com/questions/45004354/when-should-i-really-set-access-control-allow-credentials-to-true-in-my-resp/45005539#45005539 and either comment to correct anything I might have gotten wrong there, or else post another answer (and I can delete mine)

[00:20:22.0000] <MikeSmith>
/me steps away for a while pick up the master of the house from daycare

[00:35:12.0000] <annevk>
MikeSmith: added a minor comment

[00:35:42.0000] <annevk>
MikeSmith: master of the house, hah, that escalated quickly

[01:58:21.0000] <MikeSmith>
annevk: :) “There can be only one” ... I’m Ramirez and he’s the younger guy

[01:58:39.0000] <MikeSmith>
(and thanks for the comment and reviewing the answer)

[02:33:57.0000] <domfarolino>
annevk: True lol. Gonna chime in on (https://github.com/whatwg/html/issues/1679) in the morning. I would like to help clean up the section if necessary, a little confused about a couple things regarding the algorithm

[03:40:06.0000] <annevk>
JakeA: how does canceling and no-cors interact?

[03:40:25.0000] <annevk>
JakeA: can you create a partial response body that way?

[03:40:41.0000] <annevk>
JakeA: I think there's an issue on that somewhere

[03:41:56.0000] <JakeA>
annevk: hmm yeah, I guess it's something to point the security folks at. I mean, you'd have a stream that definitely errored, and probably related violations in terms of content-length

[03:42:14.0000] <JakeA>
I'd expect a script element to not-execute if the content stream errored

[03:42:20.0000] <annevk>
JakeA: yeah, it's related to the old content-length issue

[03:42:25.0000] <JakeA>
but I guess that's worth investigating

[03:42:42.0000] <JakeA>
annevk: the tests I wrote expect no-cors cancelling to "work", but it is new

[03:43:10.0000] <annevk>
JakeA: https://github.com/tc39/proposal-cancelable-promises/issues/4

[03:43:26.0000] <annevk>
JakeA: yeah, your tests reminded me

[03:50:11.0000] <annevk>
JakeA: what's the best way to track the no-cors issue? Should I just open it as a new issue against Fetch that we link from all the various places?

[03:51:56.0000] <JakeA>
annevk: Yeah, and I'll email our security folks and get them involved

[03:53:24.0000] <annevk>
JakeA: I noticed btw that we have a similar "how to design canceling" problem with HTML's navigate algorithm

[03:53:42.0000] <annevk>
JakeA: it's rather vague and hand-wavy

[03:54:00.0000] <annevk>
JakeA: XHR has some state stuff, but also not great

[03:54:44.0000] <JakeA>
annevk: I've been using XHR to validate my tests to some extent, and there's a few weird race conditions which I guess is the result of hand-waving in the spec

[03:59:07.0000] <JakeA>
annevk: actually, this email I'm writing would make a good intro to the issue, so if you haven't started already, I can create the issue

[03:59:54.0000] <annevk>
JakeA: I PM'd you my notes

[04:00:03.0000] <annevk>
JakeA: feel free to finish

[04:02:34.0000] <annevk>
JakeA: so I think what you said about <script> and erred streams makes sense

[04:02:43.0000] <annevk>
JakeA: the problem would be with streaming stuff

[04:02:55.0000] <annevk>
JakeA: e.g., CSS that gets applied incrementally (is that a thing?)

[04:03:03.0000] <JakeA>
it isn't a thing

[04:03:16.0000] <JakeA>
but HTML parsing

[04:03:25.0000] <annevk>
JakeA: we have incremental HTML rendering, but that's already required to be non-opaque

[04:03:47.0000] <JakeA>
annevk: there's img, video, audio

[04:03:57.0000] <annevk>
JakeA: well, do we want to prevent incremental CSS?

[04:04:10.0000] <annevk>
JakeA: those are good examples too

[04:04:34.0000] <JakeA>
annevk: I think streaming CSS would result in a lot of shifting around during page load

[04:04:45.0000] <annevk>
JakeA: I'm guessing if we don't want to make things worse we'd just not error streams

[04:04:48.0000] <JakeA>
Eg .hide-this {…} at the end of the CSS resource

[04:05:11.0000] <annevk>
JakeA: we could still error the request though, but once you have the whole response header, no more canceling

[04:05:46.0000] <annevk>
JakeA: even if layout isn't done yet, should the CSSOM be allocated all at once?

[04:06:30.0000] <JakeA>
annevk: that's an interesting question. I thought it'd be all at once.

[04:06:42.0000] <JakeA>
But I guess I have no reason to think that

[04:07:00.0000] <JakeA>
I thought the CSSOM would represent actionable CSS

[04:07:06.0000] <annevk>
The spec doesn't really say it either way I think

[05:18:34.0000] <annevk>
JakeA:  fetch/api/abort/general.js contains the majority of tests, right?

[05:18:45.0000] <JakeA>
annevk: yeah

[05:20:43.0000] <jochen__>
annevk: re html issue 2792 - I don't get your comment?

[05:21:25.0000] <annevk>
jochen__: can cookies be shared across ports, can WebAuthn be shared across ports?

[05:21:42.0000] <jochen__>
document.domain is a script only feature, no?

[05:21:51.0000] <annevk>
jochen__: it builds upon a shared primitive

[05:22:22.0000] <jochen__>
i'm not sure I agree

[05:22:57.0000] <annevk>
You don't agree with the specs?

[05:23:12.0000] <jochen__>
now that there's something shared in how document.domain and cookies work

[05:23:19.0000] <jochen__>
s/now/no,/

[05:23:27.0000] <annevk>
JakeA: "() => log.push(`${bodyMethod}-resolve`)" any reason that's not assert_unreached?

[05:24:11.0000] <annevk>
jochen__: cookies share in a very similar way, they just don't have the opt-in switch

[05:25:45.0000] <JakeA>
annevk: assert_unreached seems like a more standard way. Will push a change now

[05:29:16.0000] <jochen__>
annevk: webauthn tries to match cookies, and explicitly states that that's different from what same-origin domain means :/

[05:30:16.0000] <annevk>
jochen__: WebAuthn integrates with HTML directly

[05:30:31.0000] <annevk>
jochen__: that refactoring landed earlier this year

[05:30:48.0000] <annevk>
jochen__: and unless you can tell me how cookies are different, I think you might be missing something

[05:32:18.0000] <annevk>
jochen__: see https://bugzilla.mozilla.org/show_bug.cgi?id=1329764 for such refactoring making its way into Fx

[05:34:49.0000] <jochen__>
annevk: in webauthn, a token's scope is the relying parties origin, or any registratable domain suffix

[05:35:06.0000] <jochen__>
annevk: for document.domain, you have to decide for one domain, suffixes won't match

[05:36:30.0000] <annevk>
jochen__: what do you mean with having to decide for one domain, suffixes won't match?

[05:36:44.0000] <jochen__>
if I want to access another iframe

[05:36:58.0000] <jochen__>
my document.domain has to be the same as the other iframe's document.domain

[05:37:05.0000] <jochen__>
if I want to access a token

[05:37:20.0000] <jochen__>
my document.domain has to be the same or any suffix of the token's domain

[05:37:21.0000] <annevk>
it's about what document.domain can be set to

[05:37:39.0000] <annevk>
what's the reach it gives you

[05:37:52.0000] <annevk>
that's the shared primitive

[05:38:48.0000] <jochen__>
I see

[05:39:01.0000] <jochen__>
then I think the reach is too broad if it ignores the port

[05:39:38.0000] <annevk>
that's fair and I'm wondering if we also want to make that decision for Webauthn and cookies then

[05:39:45.0000] <annevk>
as there ports are also not considered

[05:40:00.0000] <jochen__>
cookies have a ton of options

[05:40:02.0000] <annevk>
or if we want to fork the shared primitive somehow

[05:40:18.0000] <jochen__>
I could imagine to add a kind of cookies that is only usable via default ports

[05:40:52.0000] <annevk>
to make cookies and Webauthn similar you'd just restrict them to the same port

[05:41:14.0000] <jochen__>
well, basically, if you're on a non-default port, I don't care, as long as you don't match default ports

[05:41:59.0000] <annevk>
Cookies additionally ignore scheme, I guess for document.domain that's no longer an issue because of mixed content blocking

[05:42:08.0000] <annevk>
And I guess/hope Webauthn requires HTTPS too?

[05:42:50.0000] <annevk>
Anyway, all I meant to say with my comment is that I want them considered together, since they all have the same kind of leak

[05:43:09.0000] <annevk>
If we only patch one, that should be a conscious decision

[05:46:09.0000] <jochen__>
yes, it's https only

[05:46:17.0000] <jochen__>
ok, makes sense. Thx for clarifying :)

[08:15:12.0000] <gsnedders>
JakeA: damnit, can't better .310s

[08:16:10.0000] <JakeA>
gsnedders: I wonder if it differs from device to device. I can't better .200, but some people are claiming 0.01

[08:16:14.0000] <JakeA>
They might be liars :D

[08:17:02.0000] <gsnedders>
JakeA: Are you sure they aren't Valtteri's throwaways?

[08:17:12.0000] <JakeA>
haha

[08:18:03.0000] <gsnedders>
I'm pretty consistently around 0.330s

[08:19:14.0000] <gsnedders>
But really clicking is easy, no coordination between hands and feet needed

[08:20:43.0000] <gsnedders>
Anyhow, yes, work.

[10:08:08.0000] <Domenic>
annevk: I realize I woke up too late to make this a realistic ping, but ping on writing tests for https://github.com/whatwg/html/issues/2753#issuecomment-311753445


2017-07-11
[17:57:06.0000] <virmaha>
Hello. If I load page which has video with autoplay=true and I modify the dom so that video becomes child of another div, I don't get the 'play' event. Is that valid behavior?

[03:12:59.0000] <annevk>
Domenic: thanks


2017-07-12
[04:50:35.0000] <botie>
a-ja, at 2017-07-10 04:12 UTC, MikeSmith said: I added scope/updateviacache/workertype support to the checker sources and pushed to https://checker.html5.org/ & https://validator.w3.org/nu/ I also added some filtering for now to suppress the warning about child-src

[11:04:45.0000] <domfarolino>
Domenic: for my PR on HTML you commented on a bit ago, if I pull those inner steps out into its own algorithm would it be worth putting a <p class=note> underneath the first step of the innerText algorithm saying this is codifying some legacy behavior etc?

[11:05:25.0000] <Domenic>
domfarolino: I don't know if I'd go as far as to call it legacy behavior. But maybe an example showing how it can sometimes be surprising would be helpful.

[11:05:43.0000] <domfarolino>
Domenic: cool! Yeah I like that

[12:25:05.0000] <jolvera>
Domenic just saw the last edits on the search bar PR, most of the changes was me trying to match style of the old version

[12:25:18.0000] <jolvera>
might be worth to have a style guide for js/css code?

[12:25:27.0000] <Domenic>
jolvera: yeah no problem, just cleaning it up a bit since now we're maintaining it instead of the previous author

[12:25:34.0000] <Domenic>
jolvera: yeah I think that would definitely be a good idea

[12:25:56.0000] <Domenic>
jolvera: currently I'm trying to hack it to see if it's possible to just use focus instead of manipulating .selected, but so far it isn't working. So probably will merge very soon.

[12:26:15.0000] <jolvera>
Domenic i already spent some time trying to do that

[12:26:24.0000] <Domenic>
haha dang I should have asked

[12:26:27.0000] <jolvera>
couldn't figure it out, lol

[12:28:06.0000] <jolvera>
for a style guide, it could be something really simple, e.g. https://github.com/bower/bower/wiki/Style-Guide

[12:28:13.0000] <jolvera>
stating most common use cases

[12:35:46.0000] <Domenic>
I think I got the focus thing

[12:43:21.0000] <Domenic>
jolvera: changes uploaded, would love your review

[12:43:31.0000] <jolvera>
checking now

[12:44:01.0000] <Domenic>
The other thing I'm wondering about is how in Firefox / does not work, hmm

[12:44:40.0000] <Domenic>
On the other hand searching the internet for ways to override reveals at least one user who is frustrated that overriding it is possible

[12:44:56.0000] <Domenic>
Maybe we'll just leave it

[12:45:12.0000] <Domenic>
The alternative is UA sniffing to not install the placeholder="" in Firefox I guess

[12:52:59.0000] <jolvera>
yup

[12:53:21.0000] <jolvera>
what about to add outline: none to the focus element

[12:53:33.0000] <jolvera>
it looks weird with the blue box-shadow on chrome and the green background

[12:53:46.0000] <Domenic>
I am not a big fan of doing that as it apparently makes it inaccessible

[12:54:42.0000] <Domenic>
We maybe could color it green?

[12:55:17.0000] <jolvera>
maybe, i mean, is not big deal

[12:55:48.0000] <Domenic>
https://www.tjvantoll.com/2013/01/28/stop-messing-with-the-browsers-default-focus-outline/

[12:56:09.0000] <Domenic>
Hmm I guess we have alternative styles so maybe it's fine

[12:57:22.0000] <Domenic>
I am leaning toward leaving it

[13:15:45.0000] <jolvera>
yeah, just leave it as is

[13:15:50.0000] <jolvera>
s/lets just/just/

[13:16:14.0000] <jolvera>
Domenic everything else looks good!

[13:17:23.0000] <wanderview>
Domenic: do you agree with my review of changes to response-stream-disturbed-5.html here? https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1128959&attachment=8885814

[13:26:08.0000] <Domenic>
wanderview: yes, agreed

[13:51:38.0000] <wanderview>
thanks

[16:57:23.0000] <MikeSmith>
TabAtkins: should I add support to the HTML checker for the 'hover' media feature?

[16:57:32.0000] <MikeSmith>
https://github.com/validator/validator/issues/536

[16:58:24.0000] <MikeSmith>
and if so, should I also add support for 'any-hover', 'pointer', and 'any-pointer'?

[16:58:27.0000] <TabAtkins>
Yeah

[16:58:31.0000] <MikeSmith>
OK


2017-07-13
[17:00:21.0000] <MikeSmith>
for the checker we are unfortunately still using a custom media-condition/media-query parser

[17:00:24.0000] <MikeSmith>
https://github.com/validator/validator/blob/master/src/nu/validator/datatype/MediaQuery.java#L116

[17:00:28.0000] <MikeSmith>
really need to replace that

[17:00:34.0000] <MikeSmith>
...but not this week

[19:00:12.0000] <kochi>
who is the person that is knowledgeable about querySelector() API?

[19:00:31.0000] <kochi>
I want to consult someone about https://github.com/whatwg/dom/issues/463

[19:17:55.0000] <MikeSmith>
kochi: TabAtkins I would think

[19:18:38.0000] <MikeSmith>
or else depending on specifics, he could point you to somebody who knows more-particular details

[19:18:48.0000] <kochi>
MikeSmith: thanks for suggestion.

[19:19:34.0000] <kochi>
I'm not familiar with the birth of querySelector() in the DOM spec after jQuery.

[19:19:36.0000] <TabAtkins>
I'll respond tomorrow

[19:19:43.0000] <kochi>
Oh, thanks!

[19:19:49.0000] <TabAtkins>
Off work right now 😀

[19:19:58.0000] <kochi>
good night!

[19:21:17.0000] <MikeSmith>
kochi: also from Chrome team I wonder if Dan Beam might have suggestions (but reckon he’s away now too)

[19:25:19.0000] <kochi>
MikeSmith: thx, I feel strange I got advice about colleagues from outside the company :)

[19:25:29.0000] <MikeSmith>
haha

[19:39:06.0000] <domfarolino>
For someone who knows very little about political tension with W3C and EME could I get a little clarification on what is happening with DRM stuff? Random tweet indicate that EME is being baked into the official W3C HTML spec yet it is clearly getting a ton of pushback

[19:39:27.0000] <domfarolino>
Will we be seeing changes to the whatwg/html spec as a result of this EME DRM stuff? orrr.....?

[19:40:32.0000] <domfarolino>
apologies if that all sounds real naive..admittedly I have little context

[20:36:38.0000] <kochi>
I'm wondering who is managing whatwg.org...  according to whois.net, its Registry Expiry Date is 2016-03-09T02:01:33Z, though it is Domain Status: clientTransferProhibited

[20:37:00.0000] <kochi>
and is autoRenewPeriod -

[21:11:29.0000] <MikeSmith>
kochi: Ian is

[21:11:33.0000] <MikeSmith>
Hixie

[21:11:54.0000] <kochi>
will ping him.

[21:16:41.0000] <MikeSmith>
I just now did

[21:16:49.0000] <MikeSmith>
but feel free to ping him directly too

[01:20:27.0000] <annevk>
domfarolino: thus far EME is a standalone specification

[01:20:38.0000] <annevk>
domfarolino: which extends HTML

[01:21:12.0000] <annevk>
domfarolino: I doubt it would ever merge into the main spec

[01:23:35.0000] <domfarolino>
annevk: ok thanks. Lotta controversy around it, is it something WHATWG doesn't really support? Again, I don't know much about it all but I've almost exclusively heard negative things lol

[01:24:28.0000] <annevk>
domfarolino: not sure WHATWG has a position, but a couple of us did publish https://blog.whatwg.org/drm-and-web-security

[01:25:11.0000] <annevk>
domfarolino: which is also negative btw

[01:25:11.0000] <botie>
okay, annevk.

[01:25:20.0000] <annevk>
botie: yw

[01:25:20.0000] <botie>
annevk: what?

[01:25:30.0000] <annevk>
botie: shrug

[01:25:31.0000] <botie>
annevk: excuse me?

[01:26:42.0000] <annevk>
domfarolino: the positive spin afaict is basically that it's better than plugins and there's more sandboxing opportunity, but that never really addresses that plugins were on their way out anyway and that sandboxing is not guaranteed whatsoever by the EME specification

[01:27:11.0000] <annevk>
domfarolino: or that now more so than with plugins we've enshrined platform-specific solutions

[01:40:19.0000] <domfarolino>
annevk: thanks I'll read that post. Ah ok. Thanks for the context, appreciated. Yeah from what I can tell it seems largely corporation-backed which is...interesting.

[01:44:42.0000] <annevk>
domfarolino: the whole thing is very much Hollywood-driven, by proxy

[01:46:51.0000] <annevk>
domfarolino: that's why you get Comcast praising W3C and the EFF being appalled

[01:51:10.0000] <domfarolino>
annevk: Ah yeah I think I read something about their strong opposition, yet the spec being approved anyways etc.

[01:55:35.0000] <annevk>
domfarolino: if you want to learn more about what it actually is https://hsivonen.fi/eme/ is good

[05:53:21.0000] <MikeSmith>
JakeA: thanks for https://stackoverflow.com/questions/44800431/caching-effect-on-cors-no-access-control-allow-origin-header-is-present-on-th/45081016#45081016

[05:53:52.0000] <JakeA>
no problem!

[05:53:59.0000] <MikeSmith>
annevk: ⬆️  💫

[05:55:24.0000] <MikeSmith>
JakeA: I wonder if https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches should be updated to reflect that guidance?

[05:55:59.0000] <MikeSmith>
specifically, to say to use Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method

[05:56:07.0000] <MikeSmith>
instead of use Vary: Origin

[05:57:24.0000] <JakeA>
I think that makes sense

[05:58:39.0000] <MikeSmith>
OK will create a PR

[06:24:28.0000] <MikeSmith>
JakeA: https://github.com/whatwg/fetch/pull/564

[06:25:22.0000] <JakeA>
MikeSmith: +1, thanks!

[06:28:18.0000] <ytrezq>
Hello, which image format I should use in order to display stereoscopic pictures on stereoscopic capable monitor ?

[08:53:58.0000] <Domenic>
jolvera: it's live!!

[08:54:08.0000] <jolvera>
what what

[08:54:42.0000] <jolvera>
oh nice!

[08:56:36.0000] <gsnedders>
https://github.com/w3c/WebPlatformWG/issues/86 — marking old W3C HTML RECs as Obsolete (per the 2017 process)

[08:58:25.0000] <Domenic>
"A good start"

[09:37:42.0000] <domfarolino>
annevk: thanks for the info/link!


2017-07-14
[17:13:57.0000] <samtoday1>
Hey is there a list of advisory comittee members anywhere?

[17:53:27.0000] <astearns>
samtoday1: there is, but access to it is restricted to w3c member accounts

[17:53:40.0000] <astearns>
https://www.w3.org/Member/ACList.php

[18:24:12.0000] <MikeSmith>
kochi: about whatwg.org domain-name registration, Ian says he renewed it in March already, so everything’s good

[18:24:39.0000] <MikeSmith>
dunno what lookup told you otherwise but I guess it’s got stale data

[18:25:13.0000] <kochi>
MikeSmith: thanks for checking!

[18:25:20.0000] <MikeSmith>
cheers

[18:25:25.0000] <MikeSmith>
thanks for the heads-up

[19:05:22.0000] <a-ja>
MikeSmith, noticed your validator changes over the w/e

[19:06:23.0000] <a-ja>
MikeSmith, know if script nomodule is supported? haven't checked yet

[19:14:22.0000] <samtoday1>
astearns: why is it restricted?

[19:15:31.0000] <astearns>
samtoday1: dunno

[19:15:47.0000] <samtoday1>
iiinteresting

[23:45:16.0000] <yhirano__>
annevk: yt?

[23:53:37.0000] <yoav>
JakeA: Service worker question. Does SW has visibility into request bodies of third party requests? (via formData() or otherwise)

[23:55:14.0000] <JakeA>
yoav: yep! As long as it isn't a navigation request (which form submission is)

[23:55:27.0000] <JakeA>
Navigation requests go to the service worker at the destination

[23:56:19.0000] <yoav>
Thanks! I'm not clear on what's a third party navigation request...

[23:56:25.0000] <yoav>
iframe?

[00:13:59.0000] <annevk>
yhirano__: am now

[00:15:04.0000] <annevk>
yoav: or top-level

[00:15:25.0000] <annevk>
yoav: navigation to a different origin or different scope

[00:15:27.0000] <yhirano__>
annevk: we are porting some chrome xhr layout tests to wpt. It is good to review it on chromium review site, or is it better to review it on github?

[00:15:57.0000] <yoav>
annevk: OK, thanks

[00:16:01.0000] <annevk>
yhirano__: if you review them against the spec it's fine to do it yourself

[00:16:24.0000] <annevk>
yhirano__: once they're synced I might have another look I suppose

[00:18:13.0000] <yhirano__>
annevk: thanks! we'll add you to the cc list in the chromium review anyway

[00:18:27.0000] <yoav>
annevk: not sure it's the right forum but do you know of Firefox plans regarding https://w3c.github.io/webappsec-clear-site-data/

[00:18:31.0000] <yoav>
?

[00:19:59.0000] <annevk>
yoav: maybe next year

[00:20:23.0000] <yoav>
cool, thanks

[00:20:28.0000] <annevk>
yoav: but thanks for mentioning that, I should probably get it tracked somehow

[00:37:51.0000] <yoav>
mkwst: Speaking of Clear-Site-Data, which part of it can be used to nuke a SW?

[00:37:57.0000] <yoav>
Is it https://w3c.github.io/webappsec-clear-site-data/#clear-cache ?

[00:46:44.0000] <annevk>
yoav: storage + executionContexts

[00:47:33.0000] <yoav>
thanks, missed that

[01:22:38.0000] <JakeA>
yoav: <form action="other-origin" method="POST"> - a submit button in here would initiate a POST request with a body to another origin as part of a navigation

[01:23:29.0000] <yoav>
oooh, that changes everything! (or some things)

[01:23:53.0000] <JakeA>
I'm assuming third party and other origin are the same thing

[01:24:03.0000] <yoav>
yeah

[03:03:34.0000] <IamnotBot>
JOIN

[03:04:29.0000] <IamnotBot>
hello!

[03:05:56.0000] <IamnotBot>
hello!

[06:28:38.0000] <annevk>
Yay, <isindex> is gone from Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1266495

[06:32:32.0000] <Domenic>
\o/


2017-07-15
[01:08:08.0000] <KiChjang>
is a blob url same-origin to its request's origin?

[01:08:31.0000] <KiChjang>
if so, how can you make that comparison programmatically?


2017-07-17
[03:00:58.0000] <annevk>
JakeA: I'm still trying to wrap my head around this cancelation stuff

[03:01:22.0000] <JakeA>
annevk: what's the blocker?

[03:01:54.0000] <annevk>
JakeA: basically fetch is some kind of thread, but then there's further threads for the async calls fetch has to do, such as pushing and receiving bytes

[03:02:28.0000] <annevk>
JakeA: just trying to figure out if we can have some kind of generic framework for this kind of cancelation handling

[03:02:44.0000] <JakeA>
annevk: I thought we hand-wave through all the threads stuff with "in parallel"?

[03:02:46.0000] <annevk>
JakeA: navigation in HTML has the same problem where we're really hand-wavy about what cancelation means

[03:03:01.0000] <annevk>
JakeA: yeah, I really don't like "in parallel"

[03:03:24.0000] <annevk>
JakeA: I mean, it's better than what we had before, but it leaves many things undefined

[03:03:41.0000] <JakeA>
annevk: we have "add the following abort steps to signal" which acts as a kinda callback, is that not sufficient?

[03:03:54.0000] <annevk>
JakeA: not saying any of this is a blocker btw, just trying to figure out what the eventual goal should be

[03:04:43.0000] <annevk>
JakeA: yeah, I think what you have is probably reasonable for the "subthreads" and stuff

[03:05:18.0000] <annevk>
JakeA: I think implementers might be a little bit confused though with the usage of JavaScript objects to explain low-level primitives (that's also a problem with how we do streams)

[03:05:32.0000] <JakeA>
annevk: I tried to treat the signal's abort steps as a callback. You end up changing that callback frequently throughout the life of something like fetch (during the request vs during the response). However, Domenic didn't think that would work well for implementers.

[03:05:32.0000] <annevk>
JakeA: but maybe that's not a big deal

[03:06:06.0000] <annevk>
JakeA: wanderview said he'd effectively just use the tests...

[03:06:12.0000] <JakeA>
annevk: Hmm, yeah, I ran into the same problem when I started trying to figure out how downloads should be spec'd. I was using JS streams for internal things

[03:07:15.0000] <annevk>
JakeA: the other thing I was wondering about is how much work it would be for you to give a high-level description of the cancelation design

[03:07:25.0000] <annevk>
JakeA: with enough detail to cover whether signals get copied and such

[03:07:35.0000] <annevk>
JakeA: effectively a detailed summary of the proposed change

[03:08:10.0000] <JakeA>
annevk: I can do that. Who's the audience?

[03:08:11.0000] <annevk>
JakeA: that should make review a little easier and might also help to get everyone on the same page (although I doubt there's much disagreement as engagement is rather low)

[03:08:22.0000] <annevk>
JakeA: maybe just me and Domenic

[03:08:30.0000] <annevk>
JakeA: but I suspect also the implementers

[03:08:38.0000] <JakeA>
annevk: ok, I'll throw that together today

[03:08:53.0000] <annevk>
JakeA: you could maybe make a blog post out of it later on

[03:09:20.0000] <annevk>
JakeA: might be nice for blog.whatwg.org

[03:09:40.0000] <JakeA>
annevk: yeah, once we start landing stuff I want to do an update blog post including a bit of history and the API we landed on, and future plans for observing fetch

[03:09:49.0000] <JakeA>
yeah, happy to do it for blog.whatwg.org

[03:10:01.0000] <annevk>
note that DOM landed already

[03:10:08.0000] <JakeA>
Oh cool!

[03:10:24.0000] <annevk>
https://dom.spec.whatwg.org/#aborting-ongoing-activities

[05:19:22.0000] <annevk>
JakeA: I read through all the tests btw and they look good

[05:19:34.0000] <annevk>
JakeA: my main issue there too was lack of a high-level overview

[05:20:41.0000] <annevk>
JakeA: but I think if we have spec text and some high-level agreement we can just land it all and get another good review when wanderview et al implement/review things

[05:20:42.0000] <JakeA>
annevk: I was going to write the overview on the test PR. That ok?

[05:20:47.0000] <annevk>
JakeA: sure

[05:21:06.0000] <annevk>
JakeA: let me know if there's something more I can do, I just pinged Domenic in the specification PR

[05:38:02.0000] <JakeA>
annevk: a tangent, but I scribbled down some ideas for a low-level byte store https://github.com/jakearchibald/byte-storage/blob/master/README.md

[05:45:15.0000] <annevk>
JakeA: main comments I have is that 1) I'd want to make sure that all existing storage stuff can be layered on top and 2) We should make sure it plays well with boxes if we want to go in that direction

[05:47:17.0000] <JakeA>
annevk: Yeah, 1 is absolutely my intention, but I don't know if I've achieved that. I think a good test would be showing you can implement sqllite on top of it

[05:51:17.0000] <annevk>
JakeA: for localStorage you need some kind of "sync await", but I think it's fine for that to exist spec-wise

[05:52:02.0000] <annevk>
JakeA: and there's a couple of things that go beyond origins that might need something special as well

[05:52:43.0000] <JakeA>
annevk: like cookies? We could ignore that as legacy?

[05:53:35.0000] <annevk>
JakeA: yeah; dunno if we could just ignore it, but we probably also don't have to account for it too much

[05:54:24.0000] <JakeA>
annevk: should we even be speccing idb down to its byte serialisation?

[05:54:24.0000] <annevk>
JakeA: in part the goal is that these various APIs are rewritten in terms of a shared storage API so it's clear how they relate when it comes to quota and locks and such

[05:54:43.0000] <annevk>
JakeA: no, some of that needs to be opaque

[05:54:56.0000] <annevk>
JakeA: but we should say where the bytes go

[05:54:59.0000] <JakeA>
annevk: yeah, speccing locking definitely makes sense. It might be one of the weak points in my doc

[05:55:02.0000] <JakeA>
true

[05:55:28.0000] <annevk>
for now that mostly means what box they end up in I suppose

[05:55:37.0000] <JakeA>
yeah

[05:55:41.0000] <annevk>
or if they don't end up in one

[07:26:54.0000] <majidvp>
smaug: birtles: FYI just filed a bug on Firefox implementation of Event.timeStamp https://bugzilla.mozilla.org/show_bug.cgi?id=1381492

[07:40:04.0000] <JakeA>
annevk: Is https://github.com/w3c/web-platform-tests/pull/6484#issuecomment-315775251 useful?

[07:56:57.0000] <smaug>
majidvp: yup, thanks

[08:03:25.0000] <annevk>
JakeA: yeah, that looks great

[08:03:46.0000] <annevk>
JakeA: much more elaborate than I expected 😊

[08:04:34.0000] <JakeA>
it helped me to write it all down, I think

[08:05:57.0000] <annevk>
Gotta go now unfortunately, might try to make some time later but otherwise first thing tomorrow

[09:08:26.0000] <annevk>
JakeA: reading through it now, I don't see request.body covered

[09:08:54.0000] <annevk>
JakeA: we don't have the infrastructure to test this scenario, but you could have a request.body and a response.body streaming at the same time and both getting aborted

[09:09:36.0000] <annevk>
JakeA: what we can test however is that request.body gets aborted (or maybe that's not considered because that's not in the spec yet? I have forgotten the state of request streams)

[09:33:50.0000] <annevk>
JakeA: looks good apart from that, though I wonder if we need to do extra work to make the service worker thing work

[09:36:33.0000] <JakeA>
annevk: yeah, I avoided request.body due to a lack of implementation. I think it'd be pretty easy to test, I just wasn't confident my test would be right

[09:37:03.0000] <annevk>
JakeA: Chrome has a cancelable impl somehow?

[09:37:13.0000] <JakeA>
I can't remember the conditions around request streams, as in preventing them being consumed up-front

[09:37:14.0000] <annevk>
JakeA: or that part you tested through console.log or some such?

[09:38:12.0000] <JakeA>
annevk: I tested for silly mistakes in the current tests using XHR & an awful AbortController & AbortSignal polyfill

[09:38:26.0000] <annevk>
oh fun

[09:39:26.0000] <annevk>
JakeA: I guess I'd be okay with postponing request stream tests but we'll need a tracking issue somewhere, prolly against WPT

[09:42:03.0000] <JakeA>
annevk: agreed. I guess I should just take a stab at the tests and get Domenic to suffer through correcting me

[09:43:43.0000] <annevk>
JakeA: that'd be great, I'm sure implementers are happy to help debug them too

[09:51:48.0000] <annevk>
JakeA: also raised a new issue in your byte repo thingy

[09:52:15.0000] <annevk>
JakeA: for context, Luke works on wasm

[11:22:36.0000] <JakeA>
annevk: ta! Keen to hear from wasm folks.

[12:19:23.0000] <smaug>
NavidZ: dsf?

[12:20:11.0000] <smaug>
and I'm trying to find some old bug related to this


2017-07-18
[18:01:13.0000] <NavidZ>
smaug: Sorry for the ambiguous acronym. I meant device scale factor

[19:32:40.0000] <Domenic>
Oh, I didn't realize Gecko was going to use rust-url. That'd make two browsers attempting to follow the spec closely; major progress. https://bugzilla.mozilla.org/show_bug.cgi?id=url-oxidation

[19:38:51.0000] <wanderview>
Domenic: I don't think that is 100% decided... our URL situation is... difficult

[19:49:15.0000] <Domenic>
Oh :(

[23:57:06.0000] <annevk>
I think that's the plan from talking to valentin, but rust-url is dated

[01:12:21.0000] <annevk>
JakeA: https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191 might of interest btw

[01:13:30.0000] <JakeA>
annevk: interesting! I wasn't aware of this

[01:16:54.0000] <annevk>
JakeA: you should probably chat with jsbell when you have the chance, he thought quite a bit about primitives in this area I think

[01:18:04.0000] <JakeA>
annevk: yeah, the whole proposal came about from a chat I had with him back at the start of the year. I've sent him the proposal, which seems to be way off in the wrong direction, but hey at least it might get things started

[03:20:31.0000] <nox>
annevk: What do you mean that rust-url is dated?

[03:30:28.0000] <annevk>
nox: https://github.com/servo/rust-url/issues/163

[11:21:54.0000] <wanderview>
annevk: JakeA: a new lock proposal?

[12:13:16.0000] <Domenic>
annevk: did you want to review https://github.com/whatwg/html/pull/2843, or shall I land it with bz's lgtm?

[13:55:13.0000] <Domenic>
MikeSmith: you figured out try/except thing it seems?

[14:32:37.0000] <MikeSmith>
Domenic: yeah, just dropped it

[14:33:00.0000] <MikeSmith>
thanks for calling me on that

[14:33:27.0000] <MikeSmith>
it otherwise would have just ended up being unnecessary cruft left around

[14:34:30.0000] <Domenic>
MikeSmith: did you see my latest on Text vs. File? Happy to make the tweak myself and merge, just want to get your take

[14:35:31.0000] <MikeSmith>
yeah making the change now, from SearchIndexJsonText back to SearchIndexJsonFile

[14:35:54.0000] <MikeSmith>
so my answer there is that it’s just a file handle

[14:36:09.0000] <Domenic>
OK, so the : Text was just a mistake?

[14:36:25.0000] <MikeSmith>
no, that’s a weird thing of Pascal

[14:36:30.0000] <MikeSmith>
as far as I have gleaned

[14:36:46.0000] <MikeSmith>
: Text just means it’s a text file

[14:36:52.0000] <MikeSmith>
files can have types

[14:37:16.0000] <Domenic>
Ohhhhh

[14:37:23.0000] <Domenic>
Welp OK sorry about that

[14:37:23.0000] <MikeSmith>
yeah, as in data types

[14:37:29.0000] <MikeSmith>
no it is weird

[14:37:46.0000] <MikeSmith>
I think you can actually make a file that is type-whatever

[14:37:55.0000] <MikeSmith>
like Cardinal type

[14:38:08.0000] <MikeSmith>
and then you can only write Cardinal data to it

[14:38:26.0000] <MikeSmith>
why you would ever want that I don’t know

[14:38:47.0000] <MikeSmith>
but otherwise it seems like you always want : Text

[14:39:38.0000] <MikeSmith>
but anyway I guess Pascal doesn’t use the jargon of “file handle”

[14:40:34.0000] <MikeSmith>
and it seems from the existing code that Ian has followed a convention of naming the identifiers for those file-handle-like things just *File

[14:40:54.0000] <MikeSmith>
compared to *Filename for actually filesystem filenames

[14:41:22.0000] <MikeSmith>
e.g., kIndexFilename = 'index.html'

[14:41:39.0000] <MikeSmith>
oh

[14:41:43.0000] <MikeSmith>
even better example:

[14:41:44.0000] <MikeSmith>
Assign(BugsFile, BugsFilename);

[14:52:19.0000] <MikeSmith>
w00t merged

[14:52:23.0000] <MikeSmith>
thanks much Domenic

[14:52:42.0000] <Domenic>
Thank _you_, it's so great that the TODO of converting that to Wattsi didn't languish

[14:52:56.0000] <Domenic>
And it'll be nice to get rid of the Python dependency again

[14:53:55.0000] <MikeSmith>
yeah glad I could help with that

[14:54:08.0000] <MikeSmith>
and always fun to work on the wattsi code

[14:54:45.0000] <MikeSmith>
though a bit painful

[14:55:19.0000] <MikeSmith>
lots of opportunity to learn something new there

[14:55:33.0000] <Domenic>
Haha yeah I definitely learned things from the code review

[14:56:13.0000] <MikeSmith>
yeah I remain impressed with Ian’s coding there

[14:56:17.0000] <MikeSmith>
he should write more code

[14:56:19.0000] <MikeSmith>
oh

[14:56:28.0000] <MikeSmith>
well I guess he does now actually


2017-07-19
[17:44:43.0000] <wanderview>
Domenic: does streams API spec anything related to cross-global stuff?  like ReadableStream created in one global, then added as body of Response with a different glkobal, and then put into Cache with a third global?  which global would the ReadableStream callbacks fire in when Cache starts draining the stream?

[17:44:53.0000] <wanderview>
I assume its the ReadableStream global?

[17:56:46.0000] <wanderview>
or what if a script in another global does the read() directly

[20:36:34.0000] <Domenic>
wanderview: what does "callbacks fire in" mean?

[21:04:56.0000] <MikeSmith>
Domenic: TabAtkins about https://github.com/whatwg/html-build/issues/113 (Add built-time syntax highlighting) for now when I can make time I can figure out how to make wattsi take the contents of each pre and shell out to send those to whatever external script to run them on, and get the results back into the wattsi DOM(ish) thing

[21:05:42.0000] <TabAtkins>
MikeSmith: Cool. I've got the code almost completely written to take some JSON-HTML in and spit highlighted JSON-HTML out.

[21:05:51.0000] <MikeSmith>
super

[21:07:12.0000] <MikeSmith>
well in the mean time even if that’s not completely ready yet I could just first write the wattsi shell-out stuff, and just test it with some simple script that returns whatever I feed to it

[21:08:15.0000] <MikeSmith>
anyway I reckon I would not be able to make the time til the weekend, so couldn’t have any thing to try to beginning of next week regardless

[21:09:01.0000] <MikeSmith>
unless I surprise myself with finding out that part ends up being simple to do in wattsi

[01:54:10.0000] <benjamingr_>
Hey, is there anything in the Timers spec that deals with values over Int32? https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#

[02:32:03.0000] <annevk>
benjamingr_: IDL

[02:32:44.0000] <annevk>
benjamingr_: https://heycam.github.io/webidl/#es-long in particular

[02:34:16.0000] <benjamingr_>
@annevk got it, thanks!

[03:30:49.0000] <jgraham>
annevk: Thanks!

[03:31:00.0000] <jgraham>
Now if only the tree would reopen :)

[05:04:44.0000] <annevk>
Domenic: I prefer landing WPT first to make sure there's no gotcha there

[05:23:23.0000] <Domenic>
annevk: hmm ok, well as long as they both land around the same time, I guess it's fine

[05:24:17.0000] <annevk>
Domenic: in this case the spec was ready but I wasn't sure whether the tests were ready

[05:24:32.0000] <annevk>
Domenic: yeah, I guess they mostly just need to land around the same time and have pointers to each other

[10:06:12.0000] <TabAtkins>
MikeSmith: Interestingly, the thing that's slowing me down is the idl highlighter. I can get pigments to feed me a good text format I can transform into HTML, but I'm having to trick widlparser into doing the same.

[10:07:09.0000] <TabAtkins>
(Abusing some pua characters to turn the "HTML" it emits into a de facto stack-based text format.)

[10:09:43.0000] <MikeSmith>
why I am not suprised to see “the thing that's slowing me down” and “idl” in teh same sentence

[10:12:13.0000] <MikeSmith>
TabAtkins: from my side I find the shell/process interaction stuff for Free Pascal is well documented, so no problem there. The thing that I still have no clue about with wattsi yet is how to serialize out from its DOM or get sometihng back into/replace in its DOM

[10:12:35.0000] <MikeSmith>
that may turn out to be easy, I dunno. JUst have never needed to do it for anything yet

[10:13:48.0000] <TabAtkins>
Serialize out should be a relatively simple walk over the structure, building json as you go. Getting something back in has to exist, Wattsi generates HTML in some of its processes, but don't how easy it would be.

[10:15:31.0000] <MikeSmith>
yeah

[11:41:32.0000] <wanderview>
Domenic: I think "callbacks fires in" means what global self is and maybe permissions associated with the global...

[11:42:03.0000] <Domenic>
Yeah, I got an email I should respond to... unsure why it's an email not an issue though.

[11:46:07.0000] <wanderview>
Domenic: from baku or bz?>

[11:46:12.0000] <Domenic>
baku

[11:48:23.0000] <wanderview>
Domenic: yea, I think sorting out how we should handle this might be one of the last issues before we can r+ all the streams patches (on the DOM side anyway)

[11:48:41.0000] <Domenic>
I guess, seems like a tiny thing to hold up over

[11:49:12.0000] <wanderview>
Domenic: since we have script globals with super power privs I think it can be a security problem if we get it wrong

[11:49:23.0000] <Domenic>
Hmm I see

[11:50:15.0000] <wanderview>
Domenic: we probably don't need to block on getting it landed in spec, but at least make sure we're on the same page as to where we want to be

[11:50:44.0000] <Domenic>
I unfortunately don't know myself; both ECMAScript and Streams suffer from not doing incumbent/entry correctly

[11:50:48.0000] <Domenic>
Solving that is pretty hard

[11:51:57.0000] <wanderview>
Domenic: IMO it seems it should just be bound to whatever global was present when the function passed to ReadableStream() constructor...  it shouldn't change based on who it reading from the stream

[11:52:13.0000] <wanderview>
Domenic: not sure what that means in spec language, though... maybe we need to loop bz into the email if he isn't already

[11:52:25.0000] <Domenic>
He is yeah; maybe I should have +ed you in

[11:52:31.0000] <Domenic>
Again, email = :(, GitHub issues = :)

[11:52:36.0000] <wanderview>
yea

[11:52:46.0000] <wanderview>
technically I am on PTO and shouldn't be worrying about this

[11:52:55.0000] <Domenic>
Ah I see :)

[11:53:00.0000] <wanderview>
but trying to get streams through this month before baku goes on PTO

[12:39:41.0000] <weinig>
Domenic: I have a dumb question for you. Since DOMException is defined as a terminal in the grammar, is the new DOMException definition https://heycam.github.io/webidl/#idl-DOMException valid WebIDL (e.g. is it ok for a terminal symbol to be an identifier here)?

[12:40:05.0000] <Domenic>
weinig: haha probably not. It should have been removed from the grammar.

[12:40:26.0000] <weinig>
Domenic: ok, cool, I’m not going crazy then

[12:40:29.0000] <weinig>
phew

[12:40:33.0000] <weinig>
I’ll file an issue

[12:40:38.0000] <Domenic>
Cool, I'll file a PR :)


2017-07-20
[01:30:23.0000] <annevk>
wanderview: if you read IRC, which you shouldn't since you're on PTO, don't read my email (since you're on PTO)

[01:30:47.0000] <annevk>
wanderview: also, happy PTO

[01:31:15.0000] <kochi>
what does PTO mean here?

[01:31:37.0000] <annevk>
kochi: paid time off

[01:32:44.0000] <kochi>
annevk: ic, I've never heard it :)

[01:32:46.0000] <annevk>
I guess it's Mozilla specific? I found it rather weird when I first encountered it

[01:33:04.0000] <JakeA>
I haven't heard it around these parts

[01:33:58.0000] <annevk>
Need those TLAs to keep the new people at bay

[02:43:47.0000] <gsnedders>
I've heard it at other places, all US admittedly

[03:01:11.0000] <jgraham>
annevk: FWIW I saw some of the demo run of the travel booking training, and it's didn't seem like worse UI than the current system or you would expect. I think "training" is just a checkbox on the list of things to do for a corp. IT rollout (and maybe needed in this case for people like EAs who might use more advanced features not needed by normal people)

[03:02:00.0000] <annevk>
jgraham: ta

[03:02:53.0000] <jgraham>
(I think PTO is a US thing because it covers sick days and stuff there as well as vacation time)

[03:23:41.0000] <nox>
(Which is quite strange indeed.)

[03:28:16.0000] <jgraham>
Yeah, it's obviously terrible

[06:41:20.0000] <TabAtkins>
Yeah, it's just a blanket term for any of the various things that let you get paid for not working. Includes parental leave, etc

[07:04:35.0000] <nox>
TabAtkins: Because the one paying your salary when ill is still your employer, right?

[07:04:53.0000] <TabAtkins>
Yeah


2017-07-21
[19:17:35.0000] <domfarolino>
since all stylesheets referenced by <link> attributes are downloaded regardless of their media attribute values, can we say the media attribute isn't relevant to the HTML parser, but it is during CSSOM construction?

[20:22:11.0000] <GPHemsley>
this channel is always a great source of information about what life is like outside the U.S. :)

[20:48:28.0000] <GPHemsley>
hmm... http://krijnhoetmer.nl/irc-logs/ hasn't been updated in a while, and the search feature is broken

[20:48:40.0000] <GPHemsley>
might be time to remove it from the topic?

[00:00:09.0000] <annevk>
domfarolino: I think that differs per browser

[02:27:24.0000] <annevk>
JakeA: what's the status of https://www.w3.org/Bugs/Public/show_bug.cgi?id=27875?

[03:42:00.0000] <JakeA>
annevk: happy for that to be closed. I can do the PR myself when we need to rework that bit of the spec

[03:45:54.0000] <annevk>
kochi: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24379 seems relevant to your interests

[03:46:08.0000] <annevk>
kochi: do you think we still need that bug?

[04:05:21.0000] <annevk>
MikeSmith: there's a series of HTML checker related bugs https://www.w3.org/Bugs/Public/show_bug.cgi?id=25552 filed by zcorpan

[04:05:31.0000] <annevk>
MikeSmith: it'd be interesting to know if you think those are worth fixing

[04:05:47.0000] <annevk>
MikeSmith: feel free to close them if not

[06:16:44.0000] <wanderview>
JakeA: btw, I had another bikeshed idea for isReload and maybe the client id attributes... https://pastebin.mozilla.org/9027718

[06:18:04.0000] <wanderview>
JakeA: wondering if it made sense at all to move all navigation related data into a sub-object... if its not a navigation then that whole thing is null... otherwise its all there

[06:18:18.0000] <wanderview>
maybe too annoying without a ?. operator in js

[07:20:36.0000] <JakeA>
wanderview: reservedClientId is also a thing for workers

[07:20:50.0000] <JakeA>
which isn't a navigation as such

[07:21:11.0000] <wanderview>
JakeA: ah, maybe I was thinking of "non-subresource"

[07:22:25.0000] <JakeA>
wanderview: I can't think of a good name for it… event.nextClient? But then you've got .trigger which is only navigations, not workers

[07:24:15.0000] <annevk>
JakeA: is trigger an enum?

[07:24:23.0000] <annevk>
JakeA: just make it the empty string or some such for workers?

[07:24:46.0000] <JakeA>
annevk: the current plan is for it to be an empty string for non-navigations, yeah

[07:25:36.0000] <wanderview>
yea, I was just bikeshedding another idea to make a data object for navigator/non-subresource requests

[07:25:41.0000] <JakeA>
annevk: the question is whether we want to group all these things in some kind of potentially-client-creating object

[07:25:45.0000] <wanderview>
since we have a collection of things that don't apply to subresource requests

[07:25:46.0000] <annevk>
<100 legacy HTML bugs (mostly closing stuff as WONTFIX though)

[07:26:00.0000] <JakeA>
but within that .trigger would still be an empty string for non-navigations

[07:26:33.0000] <annevk>
it seems somewhat reasonable, although tearoff objects can be annoying lifetime-wise

[07:26:50.0000] <wanderview>
JakeA: it may be annoying for devs if they have to check evt.request.navigation && evt.request.navigation.trigger == 'reload'

[07:27:02.0000] <wanderview>
since we don't have evt.request?.navigation.trigger

[07:27:06.0000] <wanderview>
or is it .?

[07:27:59.0000] <wanderview>
anyway, it was just a thought

[07:29:15.0000] <JakeA>
I don't have particularly strong feels, but yeah, the nesting would be annoying in JS. That may be solved at some point though.

[07:30:57.0000] <wanderview>
JakeA: I'm not sure we really need a video call on this issue... the other ones, though, I don't really have anything to add at the next f2f unless we brainstorm some more solutions to talk about

[07:31:19.0000] <wanderview>
which is why I nudged the list

[07:34:51.0000] <JakeA>
wanderview: yeah, that multi instance one especially :(

[07:35:28.0000] <JakeA>
I'll try and have a suggestion before we jump on the call. I think I've been avoiding it because it's hard :D

[07:36:57.0000] <wanderview>
JakeA: I can send you my thoughts in email if it would help...

[07:37:22.0000] <JakeA>
wanderview: ohhh do you have some ideas?

[07:37:50.0000] <wanderview>
JakeA: not necessarily solutions, no...  I more just some thoughts

[07:38:00.0000] <wanderview>
nothing *actually useful*

[07:38:26.0000] <wanderview>
but I think we can approach it from a couple different angles

[07:40:48.0000] <JakeA>
would love to hear it anyway. Might spark something.

[07:42:55.0000] <JakeA>
Or post it to https://github.com/w3c/ServiceWorker/issues/756

[07:47:34.0000] <wanderview>
ok

[10:46:09.0000] <MikeSmith>
annevk: changed all those bugs to resolved=wontfix with a note that they should be re-opened in the github issue tracker if needed

[10:46:17.0000] <MikeSmith>
not sure any of them need to be

[10:48:53.0000] <MikeSmith>
down to only 85 open bugs at https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML&list_id=67580&product=WHATWG&resolution=---

[14:57:35.0000] <jimklo>
greetings. I've got what seems to be a performance issue with the getter for TextTrack.activeCues in Electron (which would map to some version of Chromium). Can someone here point me to where I might go to seek help/assistance? Thanks.

[14:58:37.0000] <Domenic>
jimklo: I'd first test it in Chrome itself, preferably Canary. If the issue persists, then file on crbug.com. Otherwise, file on the electron issue tracker.

[15:00:36.0000] <jimklo>
Domenic: thanks! it just seems odd that reading from that getter should take > .6 secs.


2017-07-22
[21:13:01.0000] <samtoday1>
Hey, does anybody know who the Alalot University w3c advisory committee member is?

[21:23:18.0000] <samtoday1>
Hell, I have tonnes of heartfelt messages that people want delivered to advisory committee members.  (to 143 unique members)  Is there a list of the member for each org?

[21:31:08.0000] <samtoday1>
*Aalto University

[00:36:34.0000] <annevk>
samtoday1: https://www.w3.org/Member/ACList

[03:41:27.0000] <samtoday1>
annevk: thanks for the list, but it doesn't allow me to view it

[03:42:06.0000] <samtoday1>
I thought that W3C was an open org about an open internet, but the list doesn't seem to be open

[05:25:30.0000] <annevk>
samtoday1: you need to be a member to see the other members

[05:25:53.0000] <samtoday1>
annevk: so which people from member orgs would have access to that list?

[05:26:04.0000] <annevk>
samtoday1: all

[05:27:07.0000] <samtoday1>
annevk: thanks.  So I just need to convince like 1 googler to gimme a squint at the list?

[13:28:57.0000] <TabAtkins>
It's not kosher, in general, to share Member-only information with non-members. Please don't ask someone to do something unethical.

[16:28:47.0000] <MikeSmith>
TabAtkins: so I figured out how to get wattsi to serialize all the <pre> elements in the spec, and how to send those and whatever else out to be run through an external script

[16:29:18.0000] <MikeSmith>
so my question now is what else I need to send other than the <pre> contents themselves

[16:29:58.0000] <MikeSmith>
you mentioned something about also feeding some JSON to the syntax-highlighting script?

[16:54:24.0000] <Domenic>
MikeSmith: from https://github.com/whatwg/html-build/issues/113#issue-240822527 I think the desired format is [tagname, {attrs}, ...contents]

[16:55:09.0000] <Domenic>
So e.g. I'm guessing ["pre", { "class": "idl" }, "some text", ["mark", {}, "marked text"], "more text"]

[16:55:54.0000] <Domenic>
The idea being TabAtkins will write a script which accepts that as stdin and will output ... something ... on stdout, either in that format or as actual HTML. (I hope actual HTML.)


2017-07-23
[17:03:17.0000] <MikeSmith>
Domenic: Oh, so in the wattsi code I basically need to add some additional markup to all the pre contents?

[17:04:52.0000] <MikeSmith>
and I need to send this JSON structure and not the serialized HTML?

[17:05:33.0000] <MikeSmith>
or I guess I wrap the serialized HTML in this JSON

[17:09:47.0000] <MikeSmith>
I guess I can just make a modified version of the existing wattsi serializer code that generates whatever format we need, rather than HTML

[17:16:03.0000] <Domenic>
Right, TabAtkins doesn't want to include a HTML parser in his tool, so he wants this JSON as the input

[17:16:13.0000] <Domenic>
I don't think we need to add additional markup

[18:09:03.0000] <MikeSmith>
Domenic: OK thanks, so I guess for now I’ll take a shot at adding the serializer code to spit some form of JSON, and we can tweak it as needed later

[19:17:22.0000] <TabAtkins>
Yes to all of this. I can output either json or a string of HTML, whichever you want.

[19:17:36.0000] <TabAtkins>
Dunno which is easier for y'all's pipeline.

[19:57:13.0000] <Domenic>
almost certainly string of HTML

[19:57:17.0000] <Domenic>
but MikeSmith can confirm

[22:22:31.0000] <MikeSmith>
TabAtkins: yeah getting back a string of HTML would be easier

[22:22:57.0000] <TabAtkins>
Kk

[12:25:07.0000] <GPHemsley>
Domenic: is http://w3c-test.org/html/semantics/interactive-elements/contextmenu-historical.html missing a test for onhide?

[12:35:38.0000] <Domenic>
GPHemsley: I don't believe onhide was ever in the spec

[12:35:54.0000] <GPHemsley>
ah, ok

[12:36:02.0000] <GPHemsley>
it's mentioned in obsolete attributes

[12:36:16.0000] <Domenic>
Oh, I guess that's a bug

[12:36:50.0000] <Domenic>
Filing

[12:37:08.0000] <GPHemsley>
mmkay

[12:38:44.0000] <Domenic>
https://github.com/whatwg/html/issues/2860

[12:41:33.0000] <GPHemsley>
cool, thanks


2017-07-24
[21:02:40.0000] <GPHemsley>
Domenic: Chrome seems to implement the onshow event?

[21:02:48.0000] <Domenic>
GPHemsley: check canary

[21:03:09.0000] <Domenic>
It was left in for like one release longer than the context menu code

[21:03:33.0000] <GPHemsley>
oh, oops, didn't realize I was running stock

[03:31:44.0000] <molsson>
I created a bare bones polyfill for AbortController+fetch, PRs welcome if I screwed it up somehow --> https://git.io/v7Loc

[03:40:25.0000] <annevk>
molsson: FWIW, the idea behind AbortController is also that it spreads to all kinds of APIs

[03:41:12.0000] <annevk>
molsson: so it'll be either that or the TC39 proposal that will eventually be used

[03:42:48.0000] <molsson>
if the TC39 proposal takes hold, will the DOM implement that as well then?

[03:44:48.0000] <annevk>
molsson: yeah, I'd expect some changes in that case, seems a bit unlikely given how long we've waited on TC39, but who knows, should know more at the end of this week

[03:45:15.0000] <molsson>
right

[03:49:45.0000] <JakeA>
It'd need to be clonable across workers for instance, which the doc doesn't seem to cover

[03:50:05.0000] <JakeA>
Seems like it's a long time away in TC39 terms

[04:10:52.0000] <kochi>
annevk: thanks for the heads-up (re https://www.w3.org/Bugs/Public/show_bug.cgi?id=24379)

[06:45:18.0000] <wanderview>
annevk: yes, lets not wait on tc39 for canceling again

[07:22:48.0000] <wanderview>
Domenic: in spec language, does resolving or rejecting a promise implicitly queue a task to the correct target realm thread?

[07:23:01.0000] <wanderview>
if you are in a parallel section, etc

[07:29:15.0000] <annevk>
wanderview: in theory, but it's very poorly defined since it doesn't define the task source and such

[07:29:42.0000] <annevk>
wanderview: there's some language to that effect in the promises guide which should be uplifted to HTML/IDL and then appropriately refactored to also take a source into account

[07:30:21.0000] <wanderview>
annevk: ok, it might be confusing since accessing other js objects in parallel sections I guess is bad

[07:30:49.0000] <annevk>
wanderview: yeah, I don't think it's good practice

[07:31:03.0000] <annevk>
wanderview: I think folks should always queue a task and resolve/reject from that task

[07:31:33.0000] <annevk>
wanderview: then it's also clear you need to define a task source

[08:33:02.0000] <wanderview>
rbyers: I know its out of your hands, but its kind of frustrating to do spec work to make stuff feature detectable and then have one of the spec participants still use UA sniffing instead... in reference to https://bugzilla.mozilla.org/show_bug.cgi?id=1128959#c140

[08:41:55.0000] <wanderview>
rbyers: also, I'm curious how the site can't support firefox at all without streams API

[09:06:42.0000] <rbyers>
wanderview: I totally understand, I'm frustrated to.  dknox and I are increasing investments to try to improve things here within Google.

[09:09:06.0000] <rbyers>
... related: you're not too far from Toronto IIRC, right?

[09:09:35.0000] <rbyers>
... Mike Taylor is bringing a couple Mozilla folks to Google Waterloo in a couple weeks to do a web compat hackathon, you might be interested in joining: https://docs.google.com/document/d/1FIUk5Y5_VmZ8rqHEsFEoXaysJUCRzf3RbvcyuYpim9c/edit

[09:15:23.0000] <rbyers>
And FWIW it's probably the case that the  site in question _could_ support Firefox without streams, it's high on their list of reasons why supporting Firefox with high quality is too expensive to currently be worth it for them.  I see it as part of my job to help eliminate all such reasons :-)

[09:26:57.0000] <wanderview>
rbyers: is this streams within service workers?

[09:27:47.0000] <wanderview>
rbyers: waterloo is about a 3 hour drive (depending on the bridge)... I could run it by my wife

[09:28:21.0000] <rbyers>
wanderview: I don't think so, just fetch API.  I don't actually know details myself (just trying to relay discussions I'm following).

[09:29:35.0000] <rbyers>
... Your call on the compat hackathon.  I'm convinced we can make the web work better for everyone through more Mozilla/Google collaboration (eg. shifting more of the burden from Gecko to chromium engineers as we're working to do with our web-platform-test requirements).

[09:32:48.0000] <rbyers>
... But I don't know concretely what things will have the biggest impact.

[10:49:16.0000] <wanderview>
rbyers: fwiw, I am doubtful streams will hit release channel until september or november... we're close, but have some thorny details to iron out

[10:50:08.0000] <wanderview>
rbyers: although we will probably have a configuration someone could use to test with before then... install nightly and flip a pref... if that would allow your web devs to enable FF UA with feature detection

[11:09:43.0000] <rbyers>
wanderview: Thanks.  I'll mention that to them.

[11:11:38.0000] <rbyers>
wanderview: Are there specific spec/test quality issues that you wish Google folks were more engaged in addressing?

[12:15:11.0000] <wanderview>
rbyers: bz might have more answers to that question

[13:13:21.0000] <wanderview>
rbyers: the work on WPT tests recently has been very helpful... and fixing problems those have revealed... so that is good

[13:14:28.0000] <wanderview>
rbyers: I think it would be great if blink implementors and reviewers were more keyed into when the spec is missing information... if you are implementing something and the spec doesn't actually say what to do, then please file an issue... I feel like we uncover this kind of thing all the time as the second implementor

[13:48:17.0000] <rbyers>
wanderview: Thanks.  Yeah I don't know how to systematize and scale more spec-conformance diligence during implementation.  We're trying for sure, but I'm determined to come up with something scalable that relies more on tooling and infrastructure and less on individual heroics.  Making WPT first-class in our engineering processes is our primary strategy (glad to hear you're feeling the improvements) but it's definitely

[13:48:17.0000] <rbyers>
not enough on it's own...

[13:50:19.0000] <wanderview>
rbyers: IMO, the code review process is the easiest place to inject this sort of thing... but I guess I don't know what that looks like in blink

[14:21:30.0000] <Mek>
I find it pretty hard when reviewing somebodies code to figure out how hard to push back on the "the spec you're implementing doesn't seem to actually describe any of the behavior you're implementing in enough detail to figure out if the code you wrote matches the spec"

[14:22:15.0000] <Mek>
ultimately it's not (just) the code author's fault that the spec they're implementing isn't anywhere near a state where it is implementable, and I can see how trying to implement something can be valuable in actually figuring out these gaps in the specs

[14:22:51.0000] <Mek>
so I'm often not sure what the right balance is between "fix the spec before you land this code" and "as long as the spec and implementation match before shipping, it's probably okay to land this"

[14:24:46.0000] <wanderview>
Mek: its important to file a spec issue and note what your internal decision for now is... the spec doesn't have to block moving forward, but filing a spec allows it to get visibility

[14:25:04.0000] <wanderview>
IMO, anyway

[14:25:30.0000] <wanderview>
I often write review comments like "write a spec issue, link to it here in a comment", etc

[14:25:45.0000] <Mek>
yeah, that's what I generally end up doing as well (or filing some spec issues myself...)

[14:25:55.0000] <Mek>
and I actually came here to rant and wonder what it means when a spec says "When X happens the user agent MUST run the Foo algorithm. The exact defails of the Foo algorithm are left to implementers." How can running a completely unspecified algorithm be a MUST requirement...

[14:26:12.0000] <wanderview>
pretty sure that means to wipe the hard drive

[14:27:00.0000] <gsnedders>
well, you must run an undefined algorithm

[14:27:17.0000] <gsnedders>
and we can test that you run an unspecified algorthim by observing that you do… something

[14:27:26.0000] <wanderview>
undefined is not a function

[14:27:50.0000] <gsnedders>
Including crashing, I guess. An algorithm could just be the ud2 instruction, after all.


2017-07-25
[19:07:35.0000] <Domenic>
wanderview: in this case, a large part of the issue is that only in Gecko do these ambiguities cause crashes... so omitting those spec steps does not pose a problem for other browsers, so it's just a matter of superhuman diligence to remember "gecko doesn't have a fallback if you combine the code you're implementing with multiple globals in certain ways". That isn't something you can catch during code review easily.

[19:08:48.0000] <Domenic>
In other words, it's not a straightforward "the spec says to do X, but X is undefined."

[19:09:47.0000] <wanderview>
Domenic: I'm not just talking about this global issue

[19:10:55.0000] <Domenic>
Fair.

[21:33:27.0000] <hendry>
Are we just missing browser support for input type=date and min? Use case: Age validation https://jsfiddle.net/kaihendry/r97gpgmn/

[00:47:37.0000] <JakeA>
annevk: was going to ask tc39 to fast track CancelError or whatever they're calling it, and we'll use it instead of DOMException AbortError. Any objections?

[00:48:01.0000] <JakeA>
Gives us compatibility with whatever they come up with, if they get anywhere

[00:50:13.0000] <annevk>
JakeA: I'm not sure

[00:50:21.0000] <JakeA>
Compatibility as in promises will reject with the same error

[00:51:05.0000] <annevk>
JakeA: if what they're doing has buy-in from everyone we should just use that I guess

[00:51:12.0000] <annevk>
JakeA: and not pick bits and pieces

[00:53:08.0000] <JakeA>
annevk: pretty sure their thing is a year away at least. No discussion of sending signals into workers for instance. Whereas a JavaScript CancelError seems useful in other places, such as streams

[00:54:02.0000] <JakeA>
If their thing happens, I'm worried about devs having to check for both AbortError and CancelError in promise rejections

[00:54:11.0000] <JakeA>
And stream errors for that matter

[00:54:12.0000] <annevk>
JakeA: we'd have to define the serialization/deserialization for any kind of object they come up with

[00:54:23.0000] <annevk>
JakeA: ECMAScript doesn't cover that

[00:54:51.0000] <annevk>
JakeA: Domenic has a PR for using "AbortError" in Streams

[00:55:13.0000] <annevk>
JakeA: do you know what Domenic thinks?

[00:55:26.0000] <annevk>
JakeA: it also seems rather ugly naming-wise

[00:55:44.0000] <annevk>
JakeA: having just named everything Abort, or would we swap all that back to Cancel?

[00:58:02.0000] <JakeA>
annevk: wasn't aware that AbortError was going into streams already. Maybe what I'm worried about would be better fixed with a isAbortError() helper somewhere.

[00:58:18.0000] <JakeA>
Which would include any new abort/cancel thing tc39 ship

[00:58:30.0000] <annevk>
JakeA: will they actually ship though?

[00:58:37.0000] <annevk>
JakeA: I mean, we could object

[00:58:53.0000] <annevk>
JakeA: it's just a proposal at this point

[00:59:06.0000] <annevk>
JakeA: I suggest you discuss with Domenic

[01:01:42.0000] <Domenic>
JakeA: our plan is to ask them to use AbortError.

[01:02:14.0000] <JakeA>
Domenic: as in DOMException?

[01:02:32.0000] <Domenic>
Yes.

[01:03:09.0000] <JakeA>
Huh, ok

[01:03:31.0000] <JakeA>
/me crawls back in his cave

[01:06:10.0000] <JakeA>
Domenic: are you on travels, or up at silly-oclock?

[01:06:24.0000] <annevk>
Domenic: it's a little frustrating though that we now have to wait and see again since we were pretty close to shipping abortable fetch

[01:06:45.0000] <Domenic>
annevk: no waiting, at least, none from us.

[01:06:56.0000] <Domenic>
Please ship.

[01:07:13.0000] <Domenic>
We will object to anything that causes shipping delays.

[01:07:23.0000] <Domenic>
JakeA: 7:30am flight.

[01:08:14.0000] <JakeA>
Oof

[01:08:41.0000] <annevk>
Domenic: oh wow, good morning!

[01:08:52.0000] <annevk>
Domenic: enjoy your extremely long day

[01:09:36.0000] <Domenic>
Yeah, it was either this or miss Japanese class last night, haha.

[01:10:46.0000] <Domenic>
Anyway, bbiab

[01:55:14.0000] <Domenic>
annevk: JakeA: when is aborting fetch landing in the spec, anyway?

[01:56:50.0000] <JakeA>
Domenic: I'm not sure about the spec, but Mozilla are going to implement based off https://github.com/w3c/web-platform-tests/pull/6484

[01:57:02.0000] <annevk>
Domenic: I think JakeA's been busy with other things?

[01:57:29.0000] <annevk>
Domenic: I've been meaning to look at it to see if there's some kind of language that can work, but haven't made the time thus far

[01:58:17.0000] <JakeA>
Yeah I'm hoping to get back to fix the test nits later this week. But I think the spec is kinda blocked on finding a language we can agree on.

[01:59:02.0000] <annevk>
Domenic: fetch being partially async from the main thread and then fetch itself doing async things from the perspective of itself and then the main thread being able to cancel all is just rather hard to wrap my head around still

[01:59:33.0000] <annevk>
Domenic: we don't really have good language available either for these things, just "in parallel" which is a rather poor primitive

[02:00:11.0000] <Domenic>
I am not yet convinced "in parallel" is problematic, but happy to defer... I think ideally we should be able to write something that works and iterate later though.

[02:05:33.0000] <annevk>
Domenic: if inside "in parallel" you use "in parallel" again. How do you message between those?

[02:05:51.0000] <Domenic>
annevk: it's not allowed to use in parallel from inside in parallel

[02:05:53.0000] <annevk>
Domenic: how do you message from the main thread to something that happens "in parallel"?

[02:06:00.0000] <annevk>
Domenic: then it's already not suitable for fetch!

[02:06:08.0000] <Domenic>
I don't see how

[02:06:51.0000] <Domenic>
You can still do things concurrently

[02:06:55.0000] <Domenic>
Just not "in parallel"

[02:06:56.0000] <annevk>
Domenic: in impls fetch is a thread that itself does other async work, such as reading from disk

[02:07:05.0000] <Domenic>
Concurrent things can just operate on shared objects

[02:07:15.0000] <Domenic>
Well, shared infra structures

[02:07:18.0000] <annevk>
Domenic: what's a concurrent thing?

[02:07:30.0000] <Domenic>
Two processes taking place concurrently

[02:07:32.0000] <Domenic>
Like two fetches

[02:07:36.0000] <Domenic>
We do this all the time

[02:07:49.0000] <annevk>
Domenic: how is that different from in parallel?

[02:08:11.0000] <Domenic>
Because "in parallel" is an invocation that takes you from the main thread to the pool of stuff running in parallel to the main thread

[02:08:17.0000] <Domenic>
If you're already in that pool of stuff you can just do more stuff

[02:08:29.0000] <annevk>
Domenic: with what language?

[02:08:45.0000] <Domenic>
"Do X", "Do X without blocking Y", "Also do X"...

[02:08:53.0000] <Domenic>
Just English suffices

[02:10:06.0000] <annevk>
Domenic: that seems very imprecise

[02:10:29.0000] <Domenic>
I mean, it purposefully is, to allow implementations freedom to implement whichever concurrency model or threading choices they want

[02:10:33.0000] <annevk>
Domenic: it also still doesn't address how the main thread talks to the in parallel pool after it's created

[02:10:48.0000] <Domenic>
Yeah, that's an interesting one

[02:11:08.0000] <annevk>
Domenic: I think if we had explicit threads and messaging impls could still do whatever

[02:11:11.0000] <Domenic>
Currently I think we just queue a task back on the main thread to check some state, before going back to in-parallel

[02:11:29.0000] <Domenic>
I think it'd be harder to ensure we don't constrain observable things

[02:11:58.0000] <annevk>
In some cases that would actually be good

[02:12:09.0000] <annevk>
E.g., it would eliminate some racing stuff with cookies and such

[02:12:23.0000] <annevk>
Sometimes we need the in parallel stuff to be a queue

[02:12:49.0000] <Domenic>
I guess I just haven't seen that yet, but you've done this more

[02:13:38.0000] <annevk>
The idea is partially from Jeffrey Yasskin

[02:14:15.0000] <annevk>
And also how I'm told storage gets synchronized and updated across the various processes that might need to access it

[02:14:49.0000] <annevk>
If you just have "in parallel" you get races between processes and you can't really define shared workers or service workers well

[02:15:00.0000] <annevk>
Those need a "named" thread to keep things in order

[02:15:29.0000] <annevk>
And so in effect while we're not constraining impls, we're allowing freedom they don't really have if they want something robust

[02:16:03.0000] <Domenic>
I guess I don't understand why these races are bad, instead of good. Between multiple processes seems like a perfectly fine way to race.

[02:17:41.0000] <annevk>
Domenic: maybe it's different, it's that the spec can't describe something that has to exist

[02:18:03.0000] <annevk>
Domenic: you need a central place to ask for service workers

[02:18:19.0000] <annevk>
Domenic: if that's just "in parallel", it's not really defined

[05:23:59.0000] <annevk>
JakeA: looking at the Fetch PR again and the Fetch Standard

[05:24:17.0000] <annevk>
JakeA: we already have language such as "If at any point fetch is terminated with reason reason, run these subsubsteps"

[05:24:30.0000] <annevk>
JakeA: it seems that only addresses responses, but not requests

[05:24:41.0000] <annevk>
JakeA: must have been an oversight when adding request ReadableStream

[05:25:05.0000] <annevk>
JakeA: I think if we just used that language here and there it's probably good enough for v1

[05:25:35.0000] <annevk>
JakeA: just make it clear what the observable effects will be of fetch being terminated

[05:25:54.0000] <annevk>
JakeA: seems okay?

[05:26:23.0000] <JakeA>
annevk: so we either end up with a single "If at any point fetch is terminated…" set of steps, that has to express all the possible points it could be at, or lots of small "if during these steps the signal aborts…" at the various points where abort is handled differently

[05:27:02.0000] <JakeA>
I was looking into the latter, but Domenic didn't think it matched how it would be implemented.

[05:27:19.0000] <JakeA>
I'm happy with the former, it'll just be hand-wavey in terms of references

[05:29:52.0000] <annevk>
JakeA: I'd like the latter, but I don't want to go down the signal route

[05:30:02.0000] <annevk>
JakeA: well, except for the signal being "terminate the fetch"

[05:32:18.0000] <annevk>
JakeA: so rather than invent a new way, just extend the existing technique to cover all cases

[05:33:35.0000] <JakeA>
annevk: I'm not sure I understand. As in, have steps like "if the fetch is terminated during these steps, run the following steps:" throughout fetch, and make the signal "terminate the fetch:?

[05:34:40.0000] <annevk>
JakeA: yes

[05:35:00.0000] <annevk>
JakeA: basically extend what's there now

[05:36:43.0000] <JakeA>
annevk: but right now there's only one point that says how to terminate right? It's at https://fetch.spec.whatwg.org/#concept-fetch-terminate

[05:37:49.0000] <annevk>
JakeA: "terminated" is referenced from various places in the algorithm

[05:37:54.0000] <annevk>
JakeA: e.g., "Wait until all the headers are transmitted or fetch is being terminated with reason reason. If fetch is being terminated, then set response’s termination reason to reason."

[05:38:29.0000] <annevk>
JakeA: it also errors a response body using that kind of language

[05:38:39.0000] <annevk>
JakeA: it's just that request bodies are not covered due to oversight

[05:38:56.0000] <JakeA>
annevk: gotcha. Yeah, that seems like a good way to continue

[05:43:21.0000] <JakeA>
annevk: https://github.com/whatwg/fetch/pull/523#issuecomment-317725255 are we on the same page?

[05:44:48.0000] <annevk>
JakeA: yeah, although I want to stop using the substeps language if possible, just have "steps"

[05:46:31.0000] <JakeA>
cool, cheers!

[09:55:14.0000] <smaug>
annevk: has all the interesting bits moved from Shadow DOM spec to DOM and HTML ?

[10:02:09.0000] <annevk>
smaug: I think the main things lacking are focus (but that's always been vague) and maybe some UI events stuff

[10:02:59.0000] <annevk>
smaug: I guess I should create some kind of tracker issue for the remaining bits


2017-07-26
[01:35:06.0000] <kochi>
smaug: I will work on upstreaming focus stuff to HTML & DOM

[01:35:21.0000] <smaug>
great

[02:02:02.0000] <kochi>
probably mostly to HTML

[08:05:52.0000] <gsnedders>
annevk, Domenic: what's the status of sync XHR? do we think it's actually ever going to be killed?

[08:08:48.0000] <wanderview>
JakeA: how are you trying to measure memory in this test? https://cache-memory-test.glitch.me/

[08:08:51.0000] <wanderview>
memory vs disk

[08:09:57.0000] <JakeA>
wanderview: poorly, unfortunately. I was taking processing time as an indication of what was being brought into JS. Chrome's memory devtools don't appear to be working as advertised here

[08:10:18.0000] <wanderview>
JakeA: I'm being told in moz irc that we probably do have said magic to put back on disk

[08:10:37.0000] <JakeA>
Although I was told by our engineers at blob remains disk-backed in this case, and Andew said the same happens in moz

[08:11:27.0000] <wanderview>
JakeA: yea, I'm wrong... https://searchfox.org/mozilla-central/source/dom/fetch/FetchConsumer.cpp#485

[08:11:56.0000] <wanderview>
JakeA: I thought we only did that for IDB... we grew this "spill to file" thing at some point in the last year or so I feel like

[08:12:31.0000] <wanderview>
JakeA: I don't understand why its a spec violation, though

[08:13:54.0000] <JakeA>
wanderview: Does "read all the bytes" not suggest that? https://fetch.spec.whatwg.org/#concept-body-consume-body

[08:14:26.0000] <wanderview>
JakeA: it suggests it will drain the source body stream... it doesn't say where they are read too

[08:15:02.0000] <wanderview>
apparently we implemented the blob temp file thing for fetch in FF52 https://bugzilla.mozilla.org/show_bug.cgi?id=1312410

[08:16:00.0000] <JakeA>
wanderview: https://fetch.spec.whatwg.org/#concept-read-all-bytes-from-readablestream - that would suggest that the "bytes" variable here is on disk, is that ok?

[08:16:58.0000] <wanderview>
JakeA: I mean, we can debate spec word smithing... but why is it a functional problem in practice?

[08:17:24.0000] <wanderview>
JakeA: I think our impression was that this was a non-observable thing that made the browser less crashy... win-win

[08:18:37.0000] <wanderview>
JakeA: and for what its worth, we *do* read it into a memory buffer, and we put it back on disk at the "package data" stage: https://fetch.spec.whatwg.org/#concept-body-package-data

[08:18:54.0000] <JakeA>
wanderview: I want to make sure that you can get the final byte of a 1gb resource without bringing the 1gb into memory

[08:19:08.0000] <JakeA>
wanderview: ohhh, so Firefox will use 1gb of memory in this case?

[08:19:18.0000] <wanderview>
JakeA: I think we probably stream to disk

[08:19:23.0000] <wanderview>
but I'm not sure

[08:23:19.0000] <wanderview>
JakeA: looks like we read into memory until we hit 1MB and then start streaming to disk

[08:23:47.0000] <wanderview>
JakeA: so some amount of in-memory buffering will happen depending on read-speed vs write-speed, etc

[08:23:57.0000] <wanderview>
but we should not use the full 1GB

[08:24:23.0000] <wanderview>
JakeA: its a bit sub-optimal that we read out of Cache API just to put back on disk... but Cache API does other things like decompressing, etc

[08:24:27.0000] <wanderview>
in our implementation

[08:25:50.0000] <JakeA>
wanderview: I think Chrome just points the blob at the same disk entry that the cache uses. I guess that means it can't really compress cache entries.

[08:26:17.0000] <wanderview>
JakeA: it can, its just more complicated... pretty sure we do that for IDB

[08:27:28.0000] <JakeA>
wanderview: yeah, I was thinking of the amount of reading required to do blob.slice() in that case

[08:27:35.0000] <wanderview>
JakeA: we could probably figure out how to let the blob adopt the Cache API body stream... maybe I should file a bug on that

[08:28:08.0000] <JakeA>
wanderview: do you reckon this is just an implementation detail then, and not worth speccing?

[08:28:13.0000] <JakeA>
That's where I'm leaning

[08:28:21.0000] <wanderview>
JakeA: sure, it would trigger a sequential read of the compressed stream which might spill back to disk... but you could avoid that until slice is called

[08:29:16.0000] <JakeA>
I guess you don't need to do anything until the blob is read

[08:29:21.0000] <wanderview>
JakeA: I think so?  although the difference between file- and memory-backed blobs has been confusing for a while... it would be nice if Blob at least had a getter to say which it was

[08:29:58.0000] <wanderview>
but I think that is more of a Blob issue

[08:34:14.0000] <wanderview>
JakeA: anyway, thanks for raising this... learned more about blobs

[08:35:15.0000] <JakeA>
wanderview: I was thinking about polyfilling partial responses from the cache. I guess it's possible to polyfill without crashing the browser, it just may involve some disk copying

[08:56:28.0000] <wanderview>
JakeA: is this just because we don't have ReadableStream yet?

[08:57:59.0000] <JakeA>
wanderview: no, it seems like blob.slice() is a better way to handle this than streams. Eg, if I wanted to get the last 50k of a 1gb resource, it'd be inefficient to do that with streams

[08:58:25.0000] <wanderview>
JakeA: we should really add a skip() operation to ReadableStream

[08:59:17.0000] <JakeA>
wanderview: agreed. Or maybe add a seekable stream type

[08:59:30.0000] <JakeA>
If it's disk-backed

[08:59:45.0000] <JakeA>
But yeah, anything can have skip(bytes)

[09:00:12.0000] <wanderview>
JakeA: I think trying to make ReadableStream have a backwards-capable seek would be too breaking at this point

[09:00:24.0000] <wanderview>
there is some value in restricting the capabilities of the interface

[09:24:53.0000] <wanderview>
something you don't hear often... "Which is to say, IDB is the best and everyone should use it for everything."

[09:29:36.0000] <JakeA>
hahaha

[09:30:17.0000] <JakeA>
I've promised to write a guide to IDB for years now and I will get to it at some point. It's really not that bad once you promisify it

[09:51:18.0000] <wanderview>
JakeA: sadly... https://bugzilla.mozilla.org/show_bug.cgi?id=1383029

[09:56:46.0000] <JakeA>
wanderview: yeah, this is down to https://bugzilla.mozilla.org/show_bug.cgi?id=1193394#c1

[09:56:56.0000] <wanderview>
yea

[09:57:10.0000] <wanderview>
sadly we have a lot of dumb internal tests that depend on our current broken behavior

[09:57:19.0000] <JakeA>
You can still do the promises thing if you're only doing one thing per transaction

[10:11:37.0000] <annevk>
gsnedders: seems unlikely, but who knows

[10:12:16.0000] <gsnedders>
annevk: just, like, the text in the spec makes it sound like it will be removed

[10:12:55.0000] <annevk>
gsnedders: it's a bad enough feature for such a warning I think

[10:13:05.0000] <gsnedders>
/me now can't find the warning again

[10:13:30.0000] <annevk>
gsnedders: https://xhr.spec.whatwg.org/#the-open()-method second box

[10:13:44.0000] <gsnedders>
yeah, found it now

[10:13:50.0000] <gsnedders>
for some reason thought that XHR was now in Fetch

[10:21:43.0000] <annevk>
gsnedders: that was a plan I had, but I never did it

[13:33:57.0000] <jyasskin>
TabAtkins: Does `Assume Explicit For` prevent `link-for-hint` from working? I'd expected that combination to make [=foo=] look for [=hint/foo=], then [=/foo=] and then stop, but it seems to be searching for only [=/foo=].

[13:34:15.0000] <TabAtkins>
I don't know, I'd have to check.

[13:34:23.0000] <TabAtkins>
It probably does prevent it tho.

[13:34:41.0000] <TabAtkins>
But you're right, it makes more sense for it to work.

[13:34:41.0000] <jyasskin>
Should I file a bug, or did I just get what I deserve? ;)

[13:34:46.0000] <jyasskin>
Cool. I'll file it.

[13:50:00.0000] <jyasskin>
Fetch has "user agents may, and are even encouraged to". ... isn't that "should"?

[14:30:07.0000] <gsnedders>
jyasskin: I'd interpret SHOULD as a stronger statement than "encouraged to"


2017-07-27
[00:02:09.0000] <annevk>
jyasskin: what gsnedders said; SHOULD means you MUST, unless you have a very compelling reason not to

[03:10:13.0000] <tobie>
annevk: should infra define what it means for a string to be equal to another string or is that too obvious?

[03:11:43.0000] <tobie>
annevk: WebIDL uses  "=" and "≠" in some places for that, which I find sort of weird.

[03:13:04.0000] <annevk>
tobie: there's an issue on defining "is" I think, we haven't really made up our minds

[03:13:32.0000] <annevk>
tobie: I do think it would be good, since it gets more complicated as the types get more complicated

[03:13:57.0000] <tobie>
annevk: agreed

[03:14:10.0000] <tobie>
annevk: did you get my hangout answers now?

[03:19:25.0000] <annevk>
tobie: I replied 13min ago, nothing after that

[06:00:03.0000] <GPHemsley>
why did Chromium just merge in a wpt test for HTMLMenuItemElement.label? o_0 https://github.com/w3c/web-platform-tests/pull/6608

[06:03:07.0000] <annevk>
GPHemsley: it seems from https://github.com/w3c/web-platform-tests/pull/6608#issuecomment-317548169 that this was something old?

[06:03:13.0000] <annevk>
GPHemsley: and indeed probably obsolete now

[06:03:46.0000] <annevk>
GPHemsley: email https://lists.w3.org/Archives/Public/public-test-infra/ or file an issue?

[06:08:52.0000] <GPHemsley>
ah

[06:35:10.0000] <tobie>
GPHemsley: file an issue

[09:46:43.0000] <a-ja>
is <script nomodule> stable-ish?

[10:05:55.0000] <annevk>
a-ja: should be

[10:06:42.0000] <annevk>
a-ja: https://github.com/whatwg/html/issues?q=is%3Aopen%20nomodule confirms

[10:06:47.0000] <a-ja>
annevk: tks

[10:09:40.0000] <a-ja>
annevk: i found it a convenient place to stuff html5shim, rather than in IE conditional comments

[10:10:09.0000] <a-ja>
makes IE11 Emulation Mode happy :)

[12:27:57.0000] <tobie>
WebIDL uses a bunch of lists expressed as |list|<sub>0..|n|−1</sub>. Should this notation (or a variation of it) make its way into infra somehow?

[12:28:33.0000] <Domenic>
No, I hate that notation

[12:28:57.0000] <Domenic>
We should use |list|[|x|] as infra defines, instead of |list|<sub>|x|</sub>

[12:34:03.0000] <tobie>
Domenic, so I agree on the latter.

[12:34:29.0000] <tobie>
(Well the former too, I find it really hard to read)

[12:42:01.0000] <tobie>
Domenic: Oh wait, just realized the 0..n-1 notation is actually just a basic list. Had somehow assumed it was used to take a slice of the list without the last item.

[12:42:25.0000] <tobie>
Domenic: that totally proves your point. :D

[12:43:22.0000] <Domenic>
:)

[12:50:50.0000] <tobie>
Domenic: wow some bits are not trivial to change to a more readable notation

[12:51:59.0000] <tobie>
e.g. 5.5.1 of https://heycam.github.io/webidl/#dfn-effective-overload-set

[12:52:55.0000] <Domenic>
tobie: add a step, let m be list's size?

[12:54:03.0000] <tobie>
Domenic: now I actually have to understand what the algorithm does.

[15:35:29.0000] <weinig>
Domenic: tobie: Do either of you know if it is valid / meaningful for the Body interface in Fetch to reference ReadableStream in IDL, even thought ReadableStream has no IDL interface (as far as I can tell)?

[15:45:29.0000] <Domenic>
weinig: it is not really valid or meaningful; we are being sketchy about it.

[15:45:37.0000] <weinig>
Domenic: ok

[15:45:51.0000] <weinig>
Domenic: it’s gunking up my processor, but it’s cool

[15:46:12.0000] <Domenic>
weinig: I think in Chrome we did typedef object ReadableStream (or the other way around, I always forget which order typedef works in)

[15:46:30.0000] <weinig>
Domenic: seems fair

[15:47:03.0000] <weinig>
Domenic: is there a long term goal of having ES pick up Streams or something?

[15:47:37.0000] <weinig>
Domenic: it’s a bit odd that it doesn’t use WebIDL

[15:48:26.0000] <Domenic>
weinig: more a goal of staying environment agnostic, but since it was conceived I am no longer sure that choosing ES spec style was the right way to do it.

[15:48:37.0000] <MikeSmith>
botie, inform novalinium here now

[15:48:38.0000] <botie>
will do

[15:49:02.0000] <weinig>
interesting background, thanks

[15:49:42.0000] <Domenic>
weinig: https://github.com/whatwg/streams/issues/732 and https://github.com/whatwg/streams/issues/45 have more... yeah, still not really sure what the correct path was here


2017-07-28
[23:08:11.0000] <GPHemsley>
Domenic: Did you miss a few onshow wpt tests?

[23:08:45.0000] <Domenic>
GPHemsley: it's possible, although they would have to be ones Chrome is not running

[23:14:49.0000] <GPHemsley>
oh, you're here

[23:14:54.0000] <GPHemsley>
was expecting async :)

[23:15:20.0000] <GPHemsley>
just trying to make sure I didn't rip out too much code

[23:15:21.0000] <GPHemsley>
https://github.com/w3c/web-platform-tests/blob/master/html/semantics/forms/the-button-element/button-events.html

[23:15:33.0000] <GPHemsley>
https://github.com/w3c/web-platform-tests/blob/master/html/browsers/the-window-object/security-window/window-security.html

[23:15:43.0000] <GPHemsley>
https://github.com/w3c/web-platform-tests/blob/master/html/browsers/the-window-object/window-properties.html

[23:16:18.0000] <Domenic>
Hmm, yeah, those look bad. The first especially needs a decent bit of removal.

[23:16:39.0000] <GPHemsley>
alright, cool, that's good news for me :)

[23:17:08.0000] <GPHemsley>
/me heads to bed

[02:00:54.0000] <Sebmaster>
annevk: Currently implementing UTS46 proper with all validation rules into whatwg-url and I think the w3c toAscii.json tests are wrong (or impl is wrong, of course). For example, https://github.com/w3c/web-platform-tests/blob/ded8ffe86722118bf035cf2e48c9dbf199aa1f92/url/toascii.json#L16-L20 fails on BiDi rules, since - is neither an L, nor R, nor AL bidi char, I think?

[02:03:42.0000] <annevk>
Sebmaster: I don't have the bidi rules in my head

[02:03:57.0000] <Sebmaster>
annevk: https://tools.ietf.org/html/rfc5893#section-2

[02:05:32.0000] <annevk>
Sebmaster: right and what table should I consult for the hyphen again?

[02:06:03.0000] <annevk>
Sebmaster: I guess this is further fallout from browsers having an ASCII fast path sigh

[02:07:51.0000] <annevk>
Sebmaster: if you want me to do the research the best way forward would be to file a bug I think

[02:08:05.0000] <Sebmaster>
http://www.fileformat.info/info/unicode/char/2D/index.htm says it's in the EN class? I'm not sure if it can be in multiple classes and the site only lists one though

[02:09:47.0000] <Sebmaster>
Alright, I'll file a bug

[02:11:13.0000] <annevk>
Sebmaster: looking at http://www.unicode.org/reports/tr9/#Bidirectional_Character_Types the classes due to seem exclusive

[02:11:31.0000] <annevk>
Sebmaster: but it also almost reads as if www.9.com would fail then?

[02:12:54.0000] <Sebmaster>
That is correct. I can probably test that out real quick

[02:15:02.0000] <annevk>
http://www.unicode.org/Public/UNIDATA/UnicodeData.txt is the canonical thing here I think and would indeed classify 9.com as an error

[02:15:25.0000] <annevk>
I suspect we must be missing something or none of this makes sense

[02:16:07.0000] <Sebmaster>
Can confirm. Definitely a failing url...

[02:17:08.0000] <annevk>
Sebmaster: ooh wait

[02:17:19.0000] <annevk>
Sebmaster: I think you're not doing the "is a bidi domain" check

[02:17:55.0000] <annevk>
Sebmaster: "A Bidi domain name is a domain name containing at least one character with Bidi_Class R, AL, or AN."

[02:18:08.0000] <Sebmaster>
You are correct

[02:18:09.0000] <Sebmaster>
Thanks!

[02:46:14.0000] <Sebmaster>
doing the is a bidi domain check makes idnatest.txt fail, of course :(

[04:00:39.0000] <annevk>
Sebmaster: FWIW, I really appreciate you doing an independent implementation

[04:00:48.0000] <annevk>
Sebmaster: all browser vendors have been rather lame thus far

[04:01:25.0000] <Sebmaster>
Heh, definitely

[06:03:15.0000] <GPHemsley>
Domenic: Filed https://github.com/w3c/web-platform-tests/issues/6652

[07:11:05.0000] <annevk>
JakeA: seems like Firefox perceives the results as intermittent

[07:11:09.0000] <annevk>
JakeA: I restarted that job

[07:17:49.0000] <JakeA>
Cheers!

[07:18:42.0000] <wanderview>
JakeA:  do you know of any other sites besides your blog using streams in service workers?

[07:19:01.0000] <wanderview>
not that your blog isn't great, just looking for more sites to test with

[07:19:32.0000] <wanderview>
maybe I already asked you this... my brain is not working great lately

[07:20:21.0000] <JakeA>
wanderview: I'm not aware of any. It's something Facebook are experimenting with, but nothing public

[07:20:46.0000] <wanderview>
JakeA: I guess rbyers hinted at some streaming google site that is coming, but maybe not with service workers

[07:21:47.0000] <rbyers>
JakeA I can forward you the doc I saw on this, don't know exact details.

[07:21:57.0000] <JakeA>
Please!

[07:22:00.0000] <JakeA>
Thanks

[07:23:05.0000] <wanderview>
rbyers: I think we will soon have nightly builds with stream built, but turned off behind a pref... hoping the folks building this google site can test with that

[07:23:35.0000] <rbyers>
wanderview: It's Jake's team that has apparently been working with the site in question, so I hope he can help.

[07:24:11.0000] <wanderview>
rbyers: orly?  maybe I can convince him to tell my why it can't work without streams at all

[07:24:47.0000] <JakeA>
Streams are usually way faster

[07:25:04.0000] <rbyers>
... Jake, it looks like Surma has been working with them?

[07:25:36.0000] <JakeA>
rbyers: Ohhh ok. I guess I'm out of the loop

[07:25:40.0000] <JakeA>
or my brain's fading

[07:26:10.0000] <wanderview>
JakeA: yea, but what site makes it a *requirement*?  It seems you could polyfil a slower, but functional path instead of blocking current firefox like rbyers said was going to happen

[07:26:45.0000] <annevk>
jgraham: can you help analyze https://travis-ci.org/w3c/web-platform-tests/jobs/258559653?

[07:27:43.0000] <annevk>
jgraham: it seems like the Firefox bot doesn't have enough time to run all the tests or some such and just calls it quits?

[07:27:44.0000] <rbyers>
... To be clear though, I didn't mean to imply that streams is definitely the reason the site is launching initially Chrome-only (didn't mean to cause you to feel undue pressure wnaderview).  In their long list of "features we need" it was the only one I saw that Firefox didn't have yet.  It's possible they have other reasons not stated in the doc I read for choosing to launch Chrome-only.

[07:27:50.0000] <JakeA>
wanderview: I guess I'd need to see what they're using it for

[07:29:29.0000] <wanderview>
rbyers: I guess I didn't know it was chrome-only... I assumed it was not since other browsers have streams API

[07:29:47.0000] <annevk>
jgraham: FWIW, the only Fx developer that could look into it will be gone until end of August

[07:29:50.0000] <rbyers>
I'm just working to understand and reduce all the legitimate technical obsticals that Google teams face when trying to make their sites work great across browsers.

[07:29:55.0000] <annevk>
jgraham: would not be fun to block the tests on that

[07:30:16.0000] <rbyers>
wanderview: Yeah they have other features on their list for other browsers, eg. WebP for Edge.

[07:31:38.0000] <wanderview>
rbyers: well, the cynical folks would argue its not technical reasons why google sites end up chrome-only...

[07:31:56.0000] <wanderview>
rbyers: streams, webp... really?  how are those functional blockers?  they are optimizations in most cases I am aware of

[07:32:01.0000] <wanderview>
I guess I don't understand

[07:36:14.0000] <annevk>
wanderview: you're not alone

[07:51:30.0000] <jgraham>
annevk: The problem isn't that the tests don't finish. It's that it seems to get 3 results per test

[07:53:42.0000] <annevk>
jgraham: how is that possible though?

[07:56:28.0000] <jgraham>
annevk: fetch/api/abort/general.html runs the tests once in window, once in a worker and once in a shared worker without distiniguishing them by names

[07:56:41.0000] <jgraham>
You can't do that, so the travis failure is a legit bug

[07:56:44.0000] <jgraham>
In the tests

[07:57:24.0000] <wanderview>
hooray for travis!

[07:57:55.0000] <JakeA>
jgraham: ohh, is there a best-practice way to work around that?

[07:58:25.0000] <JakeA>
Or shall I just add Worker: to the start of the test name if I detect that global?

[07:59:50.0000] <annevk>
JakeA: yeah, just giving them different names is a good way to go

[08:00:04.0000] <annevk>
jgraham: ta!

[08:00:06.0000] <jgraham>
JakeA: Yeah, that would work

[08:00:16.0000] <JakeA>
Cool, cheers!

[08:09:52.0000] <wanderview>
JakeA: I think there is some existing prior art for this kind of stuff in fetch and cachestorage WPT tests

[08:10:38.0000] <rbyers>
wanderview: Yes, lot's of non-technical reasons people could speculate.  But there are _some_ legitimate technical reasons (biggest one IMHO is the cost of additional testing given all the little interop bugs between browsers) and those act as barriers to efforts to try to solve the larger problem (eg. muddy the debate especially for leaders/execs who lack deep technical context).

[08:12:12.0000] <wanderview>
rbyers: isn't testing/supporting across "the lumpy web" part of web development?  if a company like google says they aren't going to do that what message does it send to web community in general?

[08:13:04.0000] <rbyers>
... So it's my goal to be able to show compelling concrete data about how modern browsers are more interoperable than ever and continuously getting closer, making a compelling argument for why browser-specific-web-design is a relic from the past and today when you build for any modern browser you should assume (except when shown otherwise) your code works for all of them.

[08:13:43.0000] <rbyers>
wanderview: Of course I agree.  I personally HATE the idea that anyone (let alone Google) would think it's OK to release a web product for a single browser.

[08:14:19.0000] <rbyers>
... You're preaching to the choir (I wouldn't be devoting my career to this web predictability thing otherwise).

[08:15:13.0000] <wanderview>
rbyers: I kind of understand realities around things like google earth... but when you tell me that google won't support edge because they don't have webp... honestly that just sounds lazy at best and anti-competitive at worst

[08:15:40.0000] <wanderview>
rbyers: I appreciate your efforts, sorry if I'm frustrated

[08:16:13.0000] <rbyers>
... That said, I don't think the problem is as bad as "google says they aren't going to do that".  Most Google properties invest a ton in this, and actually those are the ones (not exceptions like Inbox that start off Chrome-only) where I'm trying to invest most of my time - they're already motivated but still struggling.  Eg. google search puts a ton of resources into understand behavior on dozens of different weird

[08:16:13.0000] <rbyers>
browsers, eg. all the UC browsers of the developing world that have all sorts of site-specific hacks built into them.

[08:18:06.0000] <rbyers>
wanderview: This isn't "Google", this is one particular product that historically has so far been native-mobile-only and is finally adding _some_ desktop web support.

[08:18:58.0000] <rbyers>
... And I totally understand your frustration, definitely feel free to continue venting to me.  I see it as part of my job (because you can sure as hell bet that the product teams in question aren't themselves out here in #whatwg talking about it <grin>).

[08:20:59.0000] <wanderview>
rbyers: people within google like to point out there are separate teams, etc... those of us on the outside have to deal with the reality google is a single company and what it means when it ships sites that are chrome-only...

[08:21:30.0000] <wanderview>
I'm thankful all google services are not chrome-only... that is great... but if things like "doesn't have my favorite image format" are reasons for chrome-only now it seems like we're moving in the wrong direction

[08:21:38.0000] <wanderview>
unless you are building a webp manipulation site or something

[08:22:14.0000] <rbyers>
wanderview: Sure, I'm just saying just because one product makes bad choices doesn't mean it's hopeless for all of them...

[08:22:21.0000] <jgraham>
Changing culture is hard. Even when the culture change is beneficial to the org in question. When it's not so clear cut… well I hope this is a fight we can win.

[08:22:42.0000] <rbyers>
As proof of this, we've got at least one engineer from the Google search team excited enough to fly to Waterloo in a couple weeks to do the compat hackathon with Mike Taylor and other mozillians.

[08:23:08.0000] <wanderview>
something like "what browsers must we support" is not a cultural question, IMO... that is something that could pretty clearly be set as policy if google cared to

[08:23:23.0000] <jgraham>
Right, but policy is part of culture

[08:23:27.0000] <wanderview>
someone at a certain level in google could say "don't ship chrome-only sites"

[08:23:30.0000] <wanderview>
but they choose not to

[08:23:45.0000] <jgraham>
Right, I agree. I would like them to do that :)

[08:23:54.0000] <rbyers>
Right and the question "should we have a company wide policy for what browser we should support" is absolutely a culture question to which Google would strongly say "NO, that's a product question for each team to decide".

[08:24:38.0000] <wanderview>
rbyers: then I think its fair to say *google* does not necessarily have a culture that values web compat

[08:24:59.0000] <jgraham>
But from the other side, someone at Mozilla could declare that we have to put additional effort into compat despite short term cost (e.g. stop writing non-web-platform-tests for platform features) and they don't

[08:25:48.0000] <wanderview>
jgraham: we have shifted most testing to WPT, though

[08:25:55.0000] <jgraham>
wanderview: Hah

[08:26:02.0000] <wanderview>
jgraham: is WPT running on android yet?

[08:26:05.0000] <rbyers>
Yeah frankly I'm kind of surprised that Mozilla of all browsers doesn't yet have an interop testing policy a least as strong as our current (temporarily weak one).

[08:26:15.0000] <jgraham>
wanderview: That is true of certain engineers on certain teams, but not in general

[08:26:29.0000] <jgraham>
wanderview: No

[08:27:21.0000] <rbyers>
wanderview: To be fair, we don't run WPT on Android yet either.  But in practice our web platform code is nearly identical on Linux so we haven't seen that cause much problem in practice so I'm OK with it as a temporary pragmatic tradeoff.

[08:27:42.0000] <rbyers>
... But if we start seeing Android-specific issues slip through at a non-trivial rate, then I'll definitely get it fixed somehow.

[08:28:31.0000] <wanderview>
my point is WPT integration is progressing, but there are still some coverage gaps, etc...  we have largely moved to WPT tests for webapi related stuff AFAIK

[08:28:34.0000] <jgraham>
Yeah, we could get it working on android too. The pieces are there, what's needed is maybe a quater of effort to wire it all up and deal with the inevitable horrorshow of intermittents

[08:28:47.0000] <rbyers>
For context: our requirements for shipping any newly exposed web feature include describing why it isn't yet fully tested with web-platform-tests: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#bookmark=id.w8j30a6lypz0.

[08:28:56.0000] <wanderview>
jgraham: if there are teams not writing WPT tests let me know... I think it works well enough now we should ask them to switch

[08:30:30.0000] <rbyers>
wanderview: I've seen plenty of examples of new features that shipped in Firefox without web platform tests, I could dig some up if you like.  position:sticky is one recent one that comes to mind.

[08:32:18.0000] <jgraham>
wanderview: Well the observed reality is that stylo didn't add wpt testing until I fixed that, even though it was trivial. And if you look at the tests we write there are still lots of mochitest-plain and reftests. Which is partially to do with coverage gaps, but if someone decreed we were only going to do wpt and committed more people to the effort, those gaps could be fixed a lot faster

[08:32:58.0000] <wanderview>
jgraham: I still write mochitests when I am testing things that require superPowers, weird crash regressions that aren't really about web compat, etc

[08:33:11.0000] <bloopletech>
I'm playing around with some JS and was looking to see what the specification is around 'expando' properties on DOM/HTML Nodes, but I can't seem to find any info in the HTML, DOM or ECMA-262 specs. It's quite possible it's there and I missed it, but I can't think of the right search terms

[08:33:12.0000] <wanderview>
rbyers: I think we just got CSS WPT tests running

[08:34:19.0000] <jgraham>
Anyway, to get back to my original point, I think Google products only supporting Chrome is a medium-term threat to the multi-vendor open web. But I think that the kind of cultural change that would be required to prevent it ever happening is really hard to achieve.

[08:35:01.0000] <jgraham>
So I am at least very glad that rbyers is trying. I hope it's enough.

[08:35:27.0000] <wanderview>
jgraham: I'm worried about the trend... missing features requiring native plugins is one thing... rbyers is now warning us of a new product that is making that decision with a *much* lower bar (webp missing in edge, etc)

[08:36:10.0000] <wanderview>
and I know rbyers did not intend to apply pressure on our streams implementation... but clearly it does actually apply pressure when a company with sites as big as google say they are going to block your browser

[08:36:58.0000] <jgraham>
wanderview: I share your worry. I don't know what to do about it except trying to remove the technical hurdles by e.g. having good cross-browser testing and having a good way of running tests for the sites themselves that works cross-browser.

[08:37:23.0000] <bloopletech>
even though what I'm talking about is probably obvious to most, I did a example JSfiddle: https://jsfiddle.net/ohzuz1hc/

[08:37:23.0000] <wanderview>
trying not to be cynical, but its a short jump to "implement html imports or we can't support firefox, sorry... chrome-only"

[08:37:44.0000] <rbyers>
jgraham: Thanks, I'm certainly trying - and it's not just me, lots of people on the web platform team.

[08:38:00.0000] <wanderview>
thank you rbyers

[08:38:58.0000] <bloopletech>
side note as I'm joining in this conversation late, but strategically doesn't Apple's strong presence in mobile mean that any Google property has to work in Safari/WebKit?

[08:40:28.0000] <bloopletech>
On my original question: the fact that you can set a new property on a JS object is just normal, but the fact that you can set the property, then retrieve the Node from the DOM and the new property (or a copy) is still there is the interesting part

[08:40:54.0000] <wanderview>
bloopletech: maybe the expando info you are looking for is covered by webidl [SameObject] and then its use in various other specs? https://heycam.github.io/webidl/#SameObject

[08:40:55.0000] <rbyers>
I think the issue is not specific features like WebP or streams.  I think we can all agree that would be stupid.  But there is a larger legitimate issue here that's more abstract: the cost of building a rich powerful web product that works really great across all browsers is a lot higher than the cost of building the same product for any one browser.  It's on us (the web browser/standards community) to reduce this cost.

[08:43:27.0000] <bloopletech>
rbyers: that statement has been true for the entire time I've been involved with web development (so about 2003 onwards ;))

[08:43:41.0000] <rbyers>
Frankly I think we've been too complacent on this front historically.  We solve this problem by first looking really critically at ourselves and how we can do better (since we can control that directly).  IMHO It is an absolute embarrassment that the single most popular computing platform in the world doesn't yet really evolve with a good level of software engineering discipline.

[08:45:02.0000] <bloopletech>
isn't the lack of 'discipline' the exact same reason the web exploded and became a platform in the first place?

[08:45:49.0000] <tobie>
rbyers: what's interesting from the examples (streams, WebP) is those are new features which have precisely been added with the intent to improve the platform and make it more competitive. And yet, because vendors don't sync shippung new features it has a tendency to provoke the opposite, at least during a certain time.

[08:46:03.0000] <rbyers>
bloopletech: Perhaps, there's certainly a tension between innovation and careful engineering discipline ;-).  Eg. we could be much more "disciplined" about interop by never shipping any feature in Chrome that wasn't also shipping in another browser, but we're not willing to slow down web evolution to that extent.

[08:46:26.0000] <bloopletech>
yes that is an awesome ideal

[08:47:01.0000] <tobie>
This tension is the crux of the problem, right?

[08:47:56.0000] <bloopletech>
but I think the W3C requiring 2 competing implementations before standardisation is what killed a number of specs and begat WHATWG in the first place right?

[08:48:09.0000] <bloopletech>
well that and xhtml

[08:48:25.0000] <rbyers>
tobie: Perhaps, it's certainly important.  But just the progress we've made in web predictability on the past year in Chrome suggests there was a lot of win-win value available that we were just missing somehow...

[08:48:51.0000] <wanderview>
that's why we work to make APIs feature detectable, etc.  So sites can be Progressive... (something I think google coined an acronym about or something)

[08:49:29.0000] <tobie>
wanderview: sure, but that's still extra work.

[08:49:46.0000] <jgraham>
YEah, so I certainly agree that we haven't got to the stage where we can't do better just by solving engineering problems

[08:49:53.0000] <wanderview>
welcome to shipping on the platform with the greatest reach that isn't owned by a single company?

[08:50:01.0000] <tobie>
rbyers: that's a good point. All the investment in wpt for example, increases velocity for everyone and thus tends to reduce that gap.

[08:50:20.0000] <wanderview>
I mean, this isn't new... we want to improve it over time... but some of this is unavoidable due to the decentralized nature of the web and the fact no one entity controls it

[08:50:40.0000] <jgraham>
But it might also be true that just solving eningeering problems isn't enough in the face of a large power imbalance

[08:54:26.0000] <tobie>
The other question is whether there's still a long term value today in having multiple browser engines, when they're open source and effectively a commodity.

[08:54:31.0000] <tobie>
/me ducks

[08:54:55.0000] <bloopletech>
I've actually had the same thought privately

[08:55:37.0000] <bloopletech>
but the popular opinion re cathedral vs bazaar is that the bazaar is a priori better

[08:55:43.0000] <tobie>
phrased differently, does open source trump standardisation at some point or not?

[08:57:29.0000] <jgraham>
tobie: I think that servo is an existence proof of the value of having >1 engine, even though it's not yet viable as a standalone product

[08:57:29.0000] <bloopletech>
in DOM, Element certainly has "[SameObject] readonly attribute NamedNodeMap attributes;" and there's certainly descriptions of how to get and set the attributes etc but AFAICT nothing explicit that the attributes are accessible on the Element itself

[08:57:40.0000] <bloopletech>
good point

[08:58:40.0000] <wanderview>
bloopletech: I think from spec perspective its just a js object... so you can set properties on it... the [SameObject] is what guarantees those properties will persist across API getter calls

[08:58:50.0000] <wanderview>
bloopletech: but maybe Domenic knows better here

[08:59:17.0000] <tobie>
bloopletech: I'm not sure I understand the question

[08:59:47.0000] <bloopletech>
yeah I am being pedantic for sure, but element.potato is different from element.attributes.potato right? and having just checked the fact that the newly-created property is JS-side only is worth mentioning

[09:00:44.0000] <bloopletech>
tobie: in this fiddle, you can see one can create a new property on an element dynamically in JS and then later retrieve the property on a new 'instance' of the same Node: https://jsfiddle.net/ohzuz1hc/

[09:01:02.0000] <bloopletech>
I just cant' find anything spec-wise that explicitly describes the process

[09:01:42.0000] <tobie>
that's just JS

[09:02:29.0000] <tobie>
bloopletech: and it has no relation to the attributes attribute.

[09:04:47.0000] <bloopletech>
ok sure... but the fact that the Element you get back from querySelector has the extra property is because it's literally the same object in memory or whatever?

[09:04:57.0000] <tobie>
bloopletech: yes

[09:05:12.0000] <tobie>
bloopletech: it's the same object

[09:06:01.0000] <bloopletech>
sure. empirically that's obvious, just didn't realise that was guaranteed. but tbh I didn't even look at the spec of querySelector till now

[09:06:30.0000] <tobie>
bloopletech: that's irrelevant to querySelector

[09:07:06.0000] <tobie>
bloopletech: the DOM tree is constructed at load time and then just sits there.

[09:07:44.0000] <tobie>
bloopletech: querySelector is just a way to easily traverse it.

[09:09:35.0000] <bloopletech>
tobie: yeah now you mention it that's obvious. Because everything is defined as IDL and interfaces, I didn't realise it was spec that there is only one instance of the Node object in the tree for a particular element

[09:11:48.0000] <bloopletech>
the cool part is that I can definitely abuse this; as opposed to dataset where the values are coerced to strings, I can whack in whatever object I want

[09:13:28.0000] <tobie>
bloopletech: the reason this is avoided is it tends to create references which prevent GC when the nodes are subsequently removed.

[09:14:13.0000] <bloopletech>
ah ok, interesting. I mean the other reason is because whatever property name you choose might be clobbered in the future by the spec

[09:16:27.0000] <jgraham>
JakeA: I'm happy with the fetch abort tests now, but you should get approval from someone who understands the spec :)

[09:18:04.0000] <JakeA>
jgraham: cheers!

[09:44:07.0000] <tobie>
How is CSSOMString a thing?

[09:44:43.0000] <annevk>
tobie: Rust

[09:44:57.0000] <tobie>
annevk: sure, but what does it even mean?

[09:45:13.0000] <annevk>
tobie: it means USVString in Rust and likely DOMString everywhere else

[09:45:26.0000] <tobie>
annevk: isn't that an implementation detail, though?

[09:45:36.0000] <annevk>
tobie: it's observable with lone surrogates

[09:47:00.0000] <tobie>
annevk: where is it defined?

[09:47:19.0000] <tobie>
annevk: and how is it defined?

[09:48:00.0000] <tobie>
oh, CSSOM

[09:49:26.0000] <tobie>
https://drafts.csswg.org/cssom/#cssomstring-type

[09:50:00.0000] <TabAtkins>
Yup, Rust wanted USVString because it better matches their internals, other browsers wanted DOMString for the same reason, the difference is tiny, so we just used both.

[09:54:02.0000] <tobie>
I see. Isn't this something that's going to permeate other bits of the platform at some point?

[10:23:54.0000] <annevk>
tobie: it might, hsivonen wants to do it for DOM too

[10:24:29.0000] <annevk>
tobie: once we get there we can revisit the name and place of definition

[10:24:44.0000] <tobie>
annevk: sure. No hurries.

[10:25:20.0000] <tobie>
annevk: I was looking at the string stuff and got carried away into this rabbit hole

[12:40:55.0000] <wanderview>
annevk: JakeA: did the fetch cancelation WPT tests land?

[12:43:10.0000] <JakeA>
wanderview: are we allowed to land them before spec?

[12:43:22.0000] <wanderview>
I guess not

[12:51:37.0000] <wanderview>
JakeA: I got some more fetch cancel patches from baku and was hoping the spec/tests were finalish

[12:58:28.0000] <JakeA>
wanderview: the tests in that branch are good to go

[12:59:23.0000] <wanderview>
ok, thanks


2017-07-29
[23:21:18.0000] <annevk>
JakeA: wanderview: I'd be okay with landing the tests early

[23:21:31.0000] <annevk>
JakeA: wanderview: just make sure the commit points to the relevant Fetch PR

[23:22:28.0000] <annevk>
JakeA: wanderview: and maybe start filing bugs against all the browsers too? Tests first doesn't seem too bad, since we all agree on the specifics

[13:27:55.0000] <timwis>
Hey folks, we've been thinking about using custom elements for our component library (standards.phila.gov), and are thinking about possible issues.. one that came to mind that's hopefully simple is how to provide the benefit of encapsulated css but not have to import our CSS framework repeatedly -- ie. once foundation.css is imported, reuse it next time it's imported rather than load it to memory twice. is that

[13:27:55.0000] <timwis>
possible?

[15:08:33.0000] <MikeSmith>
timwis: TabAtkins would be one of the best people to get insight from on that I think

[15:08:40.0000] <MikeSmith>
if/when he’s around

[15:12:54.0000] <MikeSmith>
timwis: nice site by the way

[15:13:24.0000] <MikeSmith>
design and all the docs too

[15:57:01.0000] <Domenic>
timwis: have you done measurements? My understanding is that browsers don't duplicate <link rel=stylesheet>s in memory if they go to the same URL.


2017-07-30
[08:05:35.0000] <timwis>
thanks MikeSmith!

[08:07:24.0000] <timwis>
Domenic: I haven't done measurements; that's a good point. I wasn't thinking of <link> tags; I guess that's enabled by using the new HTML imports part of the web components spec (as opposed to just registering the component via JS)

[10:03:13.0000] <Domenic>
timwis: no, just inserting the same link tag in the component, e.g. when using shadow DOM

[10:03:24.0000] <Domenic>
I hear some browsers even cache <style> tags if their textContent is identical


2017-07-31
[19:16:18.0000] <Yuhong>
https://twitter.com/yuhong2/status/887556849246945281

[19:16:31.0000] <Yuhong>
emember https://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F

[19:16:36.0000] <Yuhong>
Web developer edition would be far shorter and easier.

[22:49:52.0000] <GPHemsley>
hmm... example.com is all sorts of broken in its 404 pages

[22:51:16.0000] <GPHemsley>
it sends back the value of the request's Accept header as its Content-Type response header, which Firefox parses in all sorts of different wrong ways

[22:51:30.0000] <GPHemsley>
http://example.com/bla

[22:52:43.0000] <GPHemsley>
(parsed as APNG)

[22:52:46.0000] <GPHemsley>
http://example.com/bla%20http://example.com/fla

[22:52:50.0000] <GPHemsley>
(parsed as XML)

[23:08:52.0000] <Zegnat>
Am I reading the spec wrong, or are the HTML validators wrong when they tell me <main> isn’t allowed within <article>? The spec specifically calls out that “a page with multiple article elements might need to indicate the dominant contents of each” in a note for <main>, but when doing so throws errors in both validators linked on https://whatwg.org

[23:08:53.0000] <Zegnat>
/validator/

[23:19:28.0000] <TabAtkins>
Domenic, timwis: Yeah, Chrome at least does identical-text caching; I think everyone does? Not sure about that.

[00:06:55.0000] <annevk>
Zegnat: sounds like there's some kind of mismatch at least, MikeSmith probably knows

[00:10:28.0000] <Zegnat>
Should I send the question somewhere specific, or is it fine to just have it here on IRC and wait for someone (possible MikeSmith) to read it?

[00:17:44.0000] <annevk>
Zegnat: from a brief look it looks like you're running into https://github.com/validator/validator/issues/200

[00:17:51.0000] <annevk>
Zegnat: waiting for MikeSmith is probably easiest

[00:18:23.0000] <annevk>
Zegnat: having said that, he might be out for a couple of weeks or more

[00:19:17.0000] <annevk>
(afaik he's currently the sole mostly active maintainer so there's no other course of action)

[00:23:51.0000] <benjamingr_>
Hey, I want to make a `fetch` forwarding the request body to the response body. I expected the following to work but it doesn't - and I couldn't find anything in the spec. I realize this is still experimental on the Chrome side - but I promise to give some consumer feedback :)

[00:23:52.0000] <benjamingr_>
fetch("./someUrl").then(someUrlReply => { var r = new Request("./postApi", { method: "POST", body: someUrlReply.body }); return fetch(r); })

[00:24:17.0000] <benjamingr_>
I expected it to work since the body is a `ReadableStream` and the body argument of `Request` accepts a `ReadableStream`. Am I reading it wrong or is it just not implemented yet?

[00:32:04.0000] <benjamingr_>
cc JakeA

[00:32:48.0000] <benjamingr_>
Found https://github.com/whatwg/fetch/pull/425

[00:35:28.0000] <JakeA>
benjamingr_: that's a response body going to a request body

[00:37:13.0000] <benjamingr_>
Right, I want to "proxy" a request from one server to another

[00:37:47.0000] <benjamingr_>
Basically, I want to 'forward' a request from the frontend without ever reading it into JavaScript, and hopefully I'd like to stream it so it's never even read into memory at once

[00:38:41.0000] <benjamingr_>
If you're interested - I can get into what's my motivation and why I need to be able to do this. Coincidentally, I'm also giving a "why use fetch" talk in a meetup in a few weeks and I wanted to brag about being able to do it. I actually do need it for real code though.

[00:39:24.0000] <JakeA>
benjamingr_: https://bugs.chromium.org/p/chromium/issues/detail?id=688906

[00:45:28.0000] <annevk>
benjamingr_: request body streams are not implemented

[00:45:34.0000] <benjamingr_>
Thanks <3 Any ETA on that?

[00:50:03.0000] <annevk>
benjamingr_: for Fx I think it'll be 2018

[00:50:11.0000] <annevk>
benjamingr_: not sure about Chrome

[00:50:54.0000] <annevk>
benjamingr_: cancelable fetch will be in nightlies in a month or two though, if that's any consolation

[00:51:02.0000] <tobie>
Shouldn't vars be given a little bit of breathing room in the stylesheets? |foo|[|bar|] looks cramped-up all the time.

[00:52:36.0000] <annevk>
tobie: we could also allow spaces around [ and ]

[00:53:01.0000] <benjamingr_>
Wow, that's very encouraging actually - with the fetchController API we discussed in that meeting?

[00:56:33.0000] <annevk>
benjamingr_: https://github.com/w3c/web-platform-tests/pull/6484#issuecomment-315775251 has a good v1 summary

[00:56:46.0000] <benjamingr_>
Thanks, I remember that meeting

[00:56:59.0000] <annevk>
benjamingr_: we ended up generalizing a little bit to AbortController/AbortSignal since more APIs are interested

[00:57:21.0000] <benjamingr_>
Oh yeah, I saw the .signal API, it looked very handy, I can't wait to try these out in real code.

[00:57:26.0000] <annevk>
benjamingr_: we might still get Fetch* subclasses down the line though for the Fetch-specific stuff

[01:03:56.0000] <Zegnat>
annevk, thanks for the info and the validator link, it does look like that issue also addresses the <main> problem. I am not in a hurry and I am fine with shipping with validation errors in place, knowing that I am following spec regardless. Thanks.

[01:10:26.0000] <tobie>
annevk: so a padding-right of 0.1em is subtle but seems to help quite a bit already

[01:20:07.0000] <tobie>
Filed https://github.com/w3c/tr-design/issues/123

[01:50:50.0000] <MikeSmith>
Zegnat: if you don’t get the same error with https://checker.html5.org/ I recommend you just use that instead

[01:51:52.0000] <annevk>
MikeSmith: they got the error on both validators linked from https://whatwg.org/validator/

[01:51:58.0000] <MikeSmith>
oh

[01:52:36.0000] <MikeSmith>
well if it’s about <main> I’m not terrifically enthusiastic about sinking more time into checking related to <main>

[01:52:56.0000] <MikeSmith>
I think the best way to avoid errors about <main> is just to not use <main>

[01:53:44.0000] <MikeSmith>
but anyway I respond to github issues with specifics if there is a case where the checker is not conforming to the spec

[01:54:13.0000] <MikeSmith>
if it’s about <main> inside <article> then the core problem is that Ian specced it wrong

[01:54:43.0000] <MikeSmith>
he specced it in a way that nobody had asked for but that the thought himself was best

[01:54:59.0000] <MikeSmith>
so I would rather the spec be changed to not allow that

[01:56:32.0000] <MikeSmith>
/me reads more of scrollback

[01:57:10.0000] <annevk>
MikeSmith: I think Domenic agreed with Ian in some whatwg/html <main> issue

[01:57:28.0000] <MikeSmith>
yeah if so Domenic was wrong about it too

[01:57:51.0000] <MikeSmith>
but I don’t have any energy left for that perma-argument

[01:58:01.0000] <annevk>
Yeah

[01:58:30.0000] <MikeSmith>
anyway Zegnat if you file a bug at https://github.com/validator/validator/issues I’ll fix it to conform to the spec

[02:01:05.0000] <annevk>
MikeSmith: there's https://github.com/validator/validator/issues/200

[06:03:13.0000] <annevk>
MikeSmith: https://github.com/w3c/web-platform-tests/pull/6595 can land now I think

[06:09:14.0000] <jgraham>
annevk: Done

[06:11:59.0000] <annevk>
ta

[07:06:17.0000] <annevk>
tobie: hope GH sends some money your way for that

[07:07:15.0000] <tobie>
annevk: :D. As long as it solves our problem, I'm fine the current outcome.

[07:32:16.0000] <bttf>
recently published this, would appreciate any feedback: http://blog.88mph.io/2017/07/28/understanding-service-workers/

[10:30:58.0000] <wanderview>
JakeA: if we choose "friday" on the doodle... does that mean asia time zone folks are attending on Saturday morning?

[10:34:07.0000] <JakeA>
wanderview: yeahhhh Jungkee spotted that too. Fill it in for the day from your pov, and I'll take that into account when picking the actual day

[10:36:10.0000] <wanderview>
ok

[10:37:33.0000] <wanderview>
JakeA: oh, I guess we are talking tomorrow or Wednesday then if we want n8s to attend

[12:41:48.0000] <jgraham>
Oh look, Ms2ger

[16:13:05.0000] <MikeSmith>
bttf: http://blog.88mph.io/2017/07/28/understanding-service-workers/ is awesome

[16:14:00.0000] <bttf>
thanks!

[16:14:23.0000] <MikeSmith>
https://twitter.com/_adnanchowdhury/status/882713554427666432 is pretty awesome too :)

[16:14:58.0000] <bttf>
haha, yeah

[16:22:10.0000] <MikeSmith>
bttf: I add a link to your article in https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#See_also

[16:24:04.0000] <bttf>
MikeSmith oh wow, thank you! i appreciate it

[16:24:53.0000] <MikeSmith>
if/when you have time you might consider reviewing those SW docs there and improving them

[16:25:17.0000] <MikeSmith>
mainly it’s just https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers at this point and that’s pretty slim

[16:25:35.0000] <MikeSmith>
you could hoist some details from your article into that

[16:25:45.0000] <MikeSmith>
just a suggestion

[16:26:15.0000] <bttf>
ah ok, definitely. just created my MDN acct now

[16:26:18.0000] <MikeSmith>
I been meaning to go in there and make some updates myself, but not sure when I will get time soon

[16:26:21.0000] <MikeSmith>
super