2015-04-01
[17:27:36.0000] <GPHemsley>
annevk: Really? There are *more* contexts?

[23:38:37.0000] <TheSuoX>
hey all, what's new?

[23:43:09.0000] <annevk>
GPHemsley: https://fetch.spec.whatwg.org/#concept-request-context

[00:39:03.0000] <zcorpan>
https://lists.w3.org/Archives/Public/public-whatwg-archive/ doesn't have messages from before 2012? :-(

[00:47:25.0000] <annevk>
zcorpan: it does

[00:47:33.0000] <annevk>
zcorpan: for some reason those months are not listed

[00:47:36.0000] <annevk>
MikeSmith: ^

[00:48:03.0000] <annevk>
zcorpan: but you can browse to e.g. https://lists.w3.org/Archives/Public/public-whatwg-archive/2004May/ and find the first set of messages

[00:48:10.0000] <zcorpan>
annevk: thx

[00:52:42.0000] <frivoal>
annevk http://dev.w3.org/csswg/css-egg/ is up, with a nice reference to https://fetch.spec.whatwg.org/#unicorn

[01:04:12.0000] <zcorpan>
MikeSmith: ok went through my bugs. closed most of them. feel free to reopen any INTENTIONAL if you want to fix them

[02:18:20.0000] <MikeSmith>
zcorpan: thanks

[02:19:57.0000] <MikeSmith>
zcorpan: would love to fix them all but right now just trying to figure out which of the long-open bugs might still be a priority for any odd the original commenters

[02:21:54.0000] <MikeSmith>
I think the biggest open issue that the most people care about is the error reported for ampersands in URLs

[02:22:37.0000] <MikeSmith>
which, were still not conforming to the spec there

[02:23:22.0000] <MikeSmith>
but that's complicated by the fact it's actually a parser issue

[02:25:28.0000] <MikeSmith>
hsivonen: it'd be nice if we could get that error-reported-for-ampersand thing resolved; last I recall I had a parser patch out top you for review

[02:26:50.0000] <MikeSmith>
annevk: I'll open a sysreq for that mailing-list archive index-page problem

[02:42:27.0000] <MikeSmith>
frivoal++

[02:57:12.0000] <roc>
how I loathe April 1

[02:59:24.0000] <annevk>
I would actually like to see about:unicorn irrespective of April 1, it's been a comment in the source of the specification for ages

[03:02:46.0000] <jgraham>
roc++

[03:05:05.0000] <roc>
it doesn't help that April 1 effectively lasts for two days for me

[03:08:46.0000] <annevk>
roc: are we working on http://dev.w3.org/csswg/css-containment/#containment ?

[03:09:05.0000] <annevk>
roc: Firefox OS devs wants it, reportedly

[03:09:07.0000] <annevk>
want*

[03:09:42.0000] <annevk>
/me enjoys April 1, playing Pac Man on Google Maps is rather fun

[03:22:01.0000] <roc>
annevk: no

[03:22:05.0000] <roc>
what for?

[03:23:12.0000] <annevk>
roc: it allows you to give elements the same kind of isolation <iframe>s have and thereby improving perf (is the hope)

[03:23:28.0000] <annevk>
roc: and it would allow for resize events for those elements most likely

[03:26:14.0000] <roc>
I know what it does

[03:26:20.0000] <roc>
but what do they want it for?

[03:26:26.0000] <roc>
any specific case?

[03:27:00.0000] <annevk>
Probably best to ask Wilson Page directly, I suspect for the various components they create

[03:27:33.0000] <annevk>
He doesn't seem to be online atm :/

[03:32:00.0000] <annevk>
roc: I'll find out and have him file a bug

[04:17:55.0000] <annevk>
JakeA: the links at the end of https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0003.html do suggest that we need to think harder about these permission requests we keep asking for

[04:18:54.0000] <annevk>
JakeA: we also got feedback from the game community that even by giving users incentive to e.g. grant the game fullscreen permission or some such, users end up ignoring the dialogs

[04:19:22.0000] <annevk>
JakeA: unfortunately I still don't have any great ideas, the bundling that some seem to argue for only seems to make things worse

[04:22:15.0000] <JakeA>
annevk: yeah, I'm nervous about bundling given the situation on Android

[04:22:37.0000] <JakeA>
Although Chrome bundles push messaging & notifications, which I think is fine

[04:23:39.0000] <JakeA>
annevk: I like your idea on the one-off sync thing (although it could get a bit onbeforeunload), but it's not what I was getting at in that thread

[04:24:34.0000] <annevk>
I don't like the way Chrome bundles push and notifications, since push really ought to be a distinct thing from displaying notifications

[04:25:31.0000] <annevk>
Well, I can see allowing push would also allow for notifications I guess. I don't like that it's currently required to show a notification.

[04:26:05.0000] <beverloo>
What we shipped is a first step, we're fully committed to getting "silent" push out of the door as well

[04:26:12.0000] <beverloo>
it's just much harder to convey to users what's going on

[04:26:15.0000] <annevk>
JakeA: my idea is that whenever you want to do synchronization traffic you'd request a one-off sync and do it from there

[04:26:23.0000] <annevk>
JakeA: that would avoid any kind of racing

[04:26:33.0000] <JakeA>
annevk: yeah, will reply to the thread

[04:26:33.0000] <beverloo>
so rather than making all kinds of decisions based on hunches, we may as well gather data and learn from developers about how they want to use the features

[04:27:26.0000] <annevk>
beverloo: so mt gave me the impression that Google's UX ideas influenced the spec, but maybe that's not really the case?

[04:27:57.0000] <beverloo>
The ideas were mostly driven by my team, but definitely influenced by UX as well

[04:28:33.0000] <annevk>
beverloo: I mean, in a way that prevents others from not having that coupling

[04:29:00.0000] <beverloo>
we worked that out with Martin / slightlyoff last week

[04:29:10.0000] <beverloo>
also, doug mentioned it wasn't completely crazy based on his firefox implementation :)

[04:29:23.0000] <annevk>
okay

[04:29:26.0000] <annevk>
ta

[04:40:57.0000] <JakeA>
annevk: Any idea why errors aren't structured-clonable?

[04:42:01.0000] <annevk>
JakeA: seems worth filing a bug on

[04:49:20.0000] <annevk>
So I tried requesting a resource of which the status was 101 and it seems what happens is that the browser just does another request hoping to get something back that is not 101

[04:49:28.0000] <annevk>
Though I'm not entirely sure

[04:52:49.0000] <annevk>
Hmm actually, XMLHttpRequest towards it seems to work fine

[04:53:00.0000] <annevk>
And you get back the 101 etc.

[04:53:05.0000] <annevk>
But no body

[05:09:46.0000] <GPHemsley>
annevk: Oh my... And those are all necessarily distinct?

[05:32:27.0000] <annevk>
GPHemsley: yep

[05:34:47.0000] <GPHemsley>
annevk: Are their uses defined somewhere?

[05:35:56.0000] <annevk>
GPHemsley: not really, just the examples for now, until specs are updated to use Fetch

[05:36:29.0000] <annevk>
Hmm, 103 response results in a network error afaict

[05:36:45.0000] <GPHemsley>
annevk: Hmm... do you have notes as to why you split up ones that I had grouped together?

[05:37:26.0000] <annevk>
GPHemsley: basically we want all contexts to be unique, more or less

[05:37:44.0000] <annevk>
GPHemsley: for service workers, CSP, and Mixed Content

[05:37:54.0000] <annevk>
and anything else that might come along at some point

[05:37:57.0000] <GPHemsley>
hmm

[05:42:37.0000] <annevk>
GPHemsley: your grouping might still be adequate for sniffing purposes btw

[05:43:37.0000] <annevk>
GPHemsley: we don't necessarily want to have different handling for all of these contexts, we just want to allow for it and give a very granular context to developers

[05:46:15.0000] <GPHemsley>
sure

[05:46:33.0000] <GPHemsley>
for some reason, favicon keeps sticking out to me

[05:46:39.0000] <GPHemsley>
IDK if that's rational

[06:15:02.0000] <annevk>
zcorpan: what happens with a stylesheet if Content-Type is missing

[06:19:07.0000] <zcorpan>
annevk: the spec doesn't seem to be obviously clear about that

[06:19:53.0000] <zcorpan>
annevk: i seem to recall that missing content-type or content-type without a slash should mean text/css, but not sure

[06:20:13.0000] <zcorpan>
annevk: i'll file a bug to look into it

[06:22:03.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28391

[07:02:32.0000] <wilsonpage>
roc ping

[07:03:02.0000] <jgraham>
wilsonpage: I think it's like 3am for roc

[07:03:13.0000] <bradleymeck>
/me is confused and interested that fet has a read stream but not the streams API full in Chrome Canary

[07:03:17.0000] <bradleymeck>
fetch*

[07:03:25.0000] <wilsonpage>
jgraham oh, thanks

[07:03:47.0000] <wilsonpage>
jgraham what time-zone is he on?

[07:03:54.0000] <jgraham>
He's in NZ

[07:03:56.0000] <jgraham>
Usually

[07:04:02.0000] <wilsonpage>
Ah ok

[07:04:36.0000] <jgraham>
So NZDT apparently

[07:13:27.0000] <wanderview>
JakeA: can I have a ServiceWorker registered for scope ./a perform a network requests to ./b/foo.html and have that intercepted by a separate ServiceWorker registered for scope ./b?

[07:14:11.0000] <wanderview>
/me will probably be claiming "not enough coffee" shortly...

[07:14:28.0000] <JakeA>
wanderview: nah, requests from a page go through the serviceworker at navigator.serviceWorker.controller only

[07:14:42.0000] <wanderview>
right

[07:14:51.0000] <JakeA>
Which is registration.active on the registration that covers that scope

[07:15:01.0000] <wanderview>
JakeA: oh... but what about if the first ServiceWorker was only spawned to handle a background sync?

[07:15:37.0000] <annevk>
wilsonpage: did you get my email?

[07:15:52.0000] <wanderview>
JakeA: the background sync SW is not controlling the page, right?

[07:16:05.0000] <wanderview>
"the page" doesn't exist I guess

[07:16:20.0000] <wanderview>
JakeA: trying to think of a way to spawn a secondary SW for this issue: https://github.com/slightlyoff/BackgroundSync/issues/70

[07:17:02.0000] <wanderview>
JakeA: this might be a good case for just having a ServiceWorker constructor... times when you want a SharedWorker like thing, but no document exists

[07:17:44.0000] <JakeA>
wanderview: the SW spawns in time to receive events such as "fetch", "sync", "push", "install" etc

[07:17:54.0000] <JakeA>
It can already spawn without a document

[07:18:19.0000] <JakeA>
Eg, browser receives a push message, it spins up the related SW & fires the push event

[07:18:26.0000] <wanderview>
JakeA: right... but in this case the web dev needs to do large amounts of sync work in response to the "sync" event... where should they do that?  they cannot spawn a worker

[07:19:01.0000] <JakeA>
/me goes to read the issue

[07:19:24.0000] <wanderview>
wanderview: I guess if they just have a separate SW registration for the "sync" and a separate SW registration for "fetch", then they could just do all the synchronous work inline and not delay fetch events

[07:22:38.0000] <wanderview>
/me steps away for a bit

[07:37:04.0000] <JakeA>
wanderview: I don't think doing the email work in there is going to be a problem for fetches

[07:37:08.0000] <JakeA>
in the SW I mean

[08:05:07.0000] <wanderview>
JakeA: it does a lot of synchronous, blocking work to merge snippets together... on low end devices

[08:05:20.0000] <wanderview>
it was moved to a Worker previously due to jank

[08:05:57.0000] <JakeA>
wanderview: shouldn't it defer that until first view?

[08:06:21.0000] <wanderview>
JakeA: well... I guess that would jank the user experience

[08:06:36.0000] <wanderview>
or doing it earlier would help avoid janking user experence

[08:07:20.0000] <wanderview>
JakeA: its basically a pre-render thing, right?

[08:07:41.0000] <JakeA>
wanderview: hm, I guess I'm worried about sync being used for heavy processing due to battery. But yeah, it should be possible to create workers or connect to shared workers in a serviceworker. The

[08:08:17.0000] <wanderview>
JakeA: I don't know how creating a worker from ServiceWorker would work (alliteration!)...  there is no document and other worker types require a document

[08:09:30.0000] <wanderview>
JakeA: I think the only worker type a ServiceWorker could reliably use is another ServiceWorker

[08:10:04.0000] <wanderview>
also, I thought chrome did not have nested workers implemented

[08:10:15.0000] <JakeA>
we don't

[08:11:06.0000] <JakeA>
wanderview: but I want to be able to get a request for an image, fetch it, create a worker, send the image into the worker, create a canvas worker, so some sync pixel work, send the result back, resolve respondWith

[08:11:21.0000] <JakeA>
If we can't have workers in SW, we should fix that

[08:11:48.0000] <wanderview>
JakeA: for fetch event the document exists... thats easier to handle I think... but for BG sync there is no document

[08:12:33.0000] <JakeA>
wanderview: why does a document need to exist? Couldn't the ServiceWorker itself (or any environment settings object) do the job?

[08:13:58.0000] <wanderview>
JakeA: if we can have a separate bg sync SW than the fetch event SW, then I think that is fine... but if they must be the same (I'm unsure of the API), then this would introduce network jank

[08:14:11.0000] <wanderview>
if fetch events start happening while the bgsync work is still being performed

[08:16:11.0000] <JakeA>
Although separate SWs are possible today, I really think workers within a single SW is the better approach for the edge cases where there's sync processing

[08:16:13.0000] <wanderview>
JakeA: I say we need a document for other Worker types because the spec says "Document"

[08:16:38.0000] <wanderview>
maybe that can be changed... but I bet it has all kinds of implications

[08:16:39.0000] <JakeA>
wanderview: The HTML spec has been fixed before :D

[08:17:07.0000] <wanderview>
JakeA: if we change SharedWorker not to need a Document... why do we have a ServiceWorker type? :-)

[08:18:30.0000] <JakeA>
wanderview: because .port doesn't make sense on ServiceWorker due to the lifecycle

[08:20:01.0000] <wanderview>
JakeA: well... there is gunk the ServiceWorker inherits from Worker now that we just throw in... seems similar... the distinguishing feature of ServiceWorker in my mind was "doesn't need a document"

[08:24:45.0000] <JakeA>
wanderview: looking through the spec, it seems like the document dependency is used to decide the worker's lifecycle. Seems like this should be allowed to include serviceworker clients, or be made to be client-generic. What do you think annevk?

[08:25:12.0000] <annevk>
JakeA: I agree, document is already pretty much irrelevant except for a few things

[08:25:15.0000] <wanderview>
JakeA: I think it will be easier to fix in the spec than the implementation

[08:27:02.0000] <JakeA>
Given that Chrome doesn't allow workers in workers, I imagine it's true there too

[08:27:03.0000] <wanderview>
JakeA: annevk: I think we should asking sicking about this... I believe he has opinions on ServiceWorker vs SharedWorker

[08:29:12.0000] <wanderview>
annevk: what do you think about my question above regarding why ServiceWorker type at all if SharedWorker won't need a Document any more?

[08:31:58.0000] <annevk>
wanderview: I think we discussed that

[08:32:24.0000] <annevk>
wanderview: I think the primary motivation is lifetime and persistence

[08:33:10.0000] <annevk>
wanderview: but they are very close

[08:33:12.0000] <wanderview>
the persistence seems a property of the registration to me

[08:33:30.0000] <annevk>
wanderview: I don't think we should have had both, but I don't really see a way out now

[08:33:30.0000] <wanderview>
and lifetime can be described via references to the SharedWorker (like it is today)

[08:33:39.0000] <annevk>
wanderview: only to perhaps deprecate SharedWorker over time

[08:34:14.0000] <wanderview>
like "FetchEvent holds a reference to the SharedWorker until respondWith() is called, etc."

[08:34:58.0000] <wanderview>
annevk: why deprecate SharedWorker?  wouldn't it deprecate ServiceWorker?

[08:35:38.0000] <annevk>
wanderview: I don't think we can kill ServiceWorker

[08:40:35.0000] <wanderview>
JakeA: can you explain the problems you are worried about when you wrote: "Although separate SWs are possible today, I really think workers within a single SW is the better approach for the edge cases where there's sync processing"

[08:41:41.0000] <JakeA>
wanderview: To have two service workers you need separate registrations, you'll need to keep their updates in sync etc

[08:42:44.0000] <JakeA>
Btw, I'm open to the idea of allowing the browser to spin up multiple instances of the same serviceworker if there's a performance benefit, but I imagine that being difficult to debug.

[08:43:25.0000] <JakeA>
As in, in the same way a server will spin up multiple instances of node for multi-core concurrency

[08:43:45.0000] <wanderview>
JakeA: personally I'm coming around to having an API like new ServiceWorker() for spinning up an extra worker-without-document...

[08:45:16.0000] <wanderview>
JakeA: I don't think having the exact same SW script is important in this case... it seems you could have one script install call .update() on the other registrations

[08:46:02.0000] <wanderview>
or just make SharedWorker accessible without a document I guess...

[08:46:26.0000] <wanderview>
this API mismatch between ServiceWorker and other worker types seems more obvious to me now

[08:48:09.0000] <JakeA>
wanderview: I kinda like the idea of new ServiceWorker(). Bascially like SharedWorker but with the lifecycle of ServiceWorker

[08:49:25.0000] <JakeA>
So new ServiceWorker() couldn't open a websocket and monitor it in the way SharedWorker can, but it's more memory efficient than a sharedworker

[08:50:38.0000] <wanderview>
JakeA: sorry if this is obvious, but what makes a ServiceWorker more memory efficient than a SharedWorker?

[08:50:59.0000] <JakeA>
wanderview: it shuts down when it isn't in use

[08:51:17.0000] <JakeA>
whereas a sharedworker is alive while the parent document is alive

[08:51:46.0000] <wanderview>
JakeA: so holding the var sw = new ServiceWorker() would not hold it alive?

[08:52:00.0000] <wanderview>
in this hypothetical future universe

[08:52:10.0000] <JakeA>
well, that's the case today

[08:52:36.0000] <JakeA>
Having a reference to navigator.serviceWorker.controller does not stop it terminating

[08:52:40.0000] <wanderview>
JakeA: I guess it comes down to what event is firing in the ServiceWorker when you ask it do something... onmessage?

[08:52:59.0000] <JakeA>
wanderview: yeah, it'd absolutely be postMessage and onmessage

[08:53:01.0000] <wanderview>
so it would spin up for the onmessage event?

[08:53:14.0000] <JakeA>
wanderview: yep, that's what happens today

[08:53:44.0000] <wanderview>
JakeA: would the message event have waitUntil() as well?

[08:53:53.0000] <wanderview>
when waitUntil() is spec'd for fetch event

[08:54:44.0000] <wanderview>
or maybe it exists for message event already... I'm obviously ignorant of this part of the spec

[08:55:27.0000] <JakeA>
wanderview: it doesn't exist yet, but good point, it should. Or we have a global self.waitUntil - that's been suggested a couple of times

[08:55:48.0000] <wanderview>
yea, that would be more future proof as features are added

[08:57:03.0000] <JakeA>
wanderview: https://github.com/slightlyoff/ServiceWorker/issues/400

[08:57:50.0000] <JakeA>
although it's confusing. If you do waitUntil(stuff) instead of event.waitUntil(stuff) in your install event, it appears to work, but if 'stuff' fails your serviceworker will still install

[08:59:34.0000] <wanderview>
JakeA: the name could be changed to disambiguate with the event.waitUntil()

[08:59:45.0000] <JakeA>
true

[09:00:01.0000] <zcorpan>
gsnedders: cssom specifies el.style.background http://dev.w3.org/csswg/cssom/#dom-cssstyledeclaration-_camel_cased_attribute

[09:00:26.0000] <wanderview>
JakeA: I don't understand slightlyoff's "it creates more questions than it answers" in that issue... it seemed most of the issues were around naming or method-vs-function...  were there more serious internal google concerns?

[09:00:47.0000] <JakeA>
Not that I'm aware of

[09:01:54.0000] <wanderview>
JakeA: also, the event-specific waitUntil could be spec'd such that it uses the global wait-until-thing... but also mix in its extra install success/failure logic

[09:03:46.0000] <JakeA>
wanderview: https://github.com/slightlyoff/ServiceWorker/issues/669

[09:03:59.0000] <JakeA>
wanderview: gotta run

[09:05:04.0000] <wanderview>
thanks!

[09:05:26.0000] <gsnedders>
zcorpan: oh that's just weird

[09:05:59.0000] <gsnedders>
zcorpan: like, in how it's spec'd, having IDL like that

[09:06:25.0000] <zcorpan>
gsnedders: yeah it's a bit weird. dunno how to make it less so

[09:07:54.0000] <gsnedders>
zcorpan: can you not just used named property getters/setters per WebIDL and then have a separate bit of magic?

[09:07:59.0000] <gsnedders>
makes the IDL less weird

[09:08:38.0000] <zcorpan>
gsnedders: is it black box equivalent?

[09:08:45.0000] <gsnedders>
zcorpan: I think it should be

[09:08:52.0000] <gsnedders>
zcorpan: will check once I get home

[09:08:54.0000] <gsnedders>
/me -> home

[09:09:01.0000] <zcorpan>
k

[09:11:39.0000] <gsnedders>
zcorpan: what level of black-box equiv. do we need? inc. whether the properties are data properties or getter/setter pairs?

[09:14:02.0000] <zcorpan>
gsnedders: getter/setter on the prototype i think. it's not strictly necessary for web compat but i think it's what we wanted to have here

[09:14:32.0000] <bradleymeck>
getters and setter :(

[09:15:06.0000] <gsnedders>
zcorpan: because oddly the catch-all getters/setters in WebIDL expose themselves as data properties. weird.

[09:33:33.0000] <zcorpan>
gsnedders: i would expect an implementation to just have a webidl file with all the css properties dumped, rather than magic like the spec

[09:44:58.0000] <JonathanNeal>
Standalone, which HTML element best represents a physical location?

[09:45:51.0000] <zcorpan>
JonathanNeal: <p>?

[09:48:49.0000] <JonathanNeal>
zcorpan: I wonder. <p> represents a run of text with one or more sentences that discuss a particular topic. It’s usually distinguished from labeling content.

[09:49:51.0000] <JonathanNeal>
I wish we had something like <location>, in the same way we have <time>.

[09:54:47.0000] <Domenic>
Why? What difference would it make? Is this about a hypothetical world where we have software that's interested in finding all web pages that have physical locations, but is not smart enough to do its own text parsing?

[09:56:32.0000] <zcorpan>
i wish we had <banana> to mark up physical bananas :-)

[09:58:15.0000] <jgraham>
Dammit zcorpan now I'm hungry

[09:58:30.0000] <zcorpan>
mohahaha

[10:03:56.0000] <annevk>
zcorpan: btw, I'll test that stylesheet thing for you

[10:04:19.0000] <zcorpan>
annevk: thanks!

[10:04:28.0000] <annevk>
/me is trying to figure out nosniff

[10:04:46.0000] <JonathanNeal>
Domenic, zcorpan: is this a minimalist argument? Like, why even have a <time> element?

[10:05:04.0000] <zcorpan>
JonathanNeal: we don't add anything without a compelling use case

[10:05:17.0000] <zcorpan>
JonathanNeal: "i want X" is not good enough

[10:05:44.0000] <zcorpan>
JonathanNeal: see https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

[10:05:44.0000] <annevk>
JonathanNeal: in particular, don't forget about step 1 https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

[10:05:47.0000] <annevk>
maha

[10:05:57.0000] <zcorpan>
/me win

[10:06:05.0000] <JonathanNeal>
We redefined <address> to the point that it can almost never represent a physical location.

[10:06:25.0000] <JonathanNeal>
Now we’re missing the ability to markup a location associated with content.

[10:06:34.0000] <Ms2ger>
Microformats

[10:06:35.0000] <botie>
Microformats is fairly focused around the development of microformats (specs) and everything related - so you're likely right there

[10:06:51.0000] <zcorpan>
<address> was never a location

[10:06:57.0000] <annevk>
HTML6

[10:07:03.0000] <annevk>
/me would have expected an entry

[10:07:11.0000] <jgraham>
XHTML!

[10:07:29.0000] <annevk>
Looks like Ms2ger has some work to do

[10:07:31.0000] <jgraham>
<JonathanNeal:location>

[10:07:42.0000] <JonathanNeal>
I believe the answer is found later in that faq, zcorpan: “In the future, it is expected that the <time> element will be dropped.”

[10:07:47.0000] <Ms2ger>
Lol

[10:08:11.0000] <zcorpan>
when the <time> is right

[10:08:37.0000] <Ms2ger>
When <plaintext> is gone

[10:09:38.0000] <zcorpan>
that section can probably be removed, i think it's basically fixed now

[10:09:44.0000] <JonathanNeal>
zcorpan: <address> very name suggests a physical location, and it’s original definition was ambigiously against such a definition at best http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.5.3

[10:10:35.0000] <zcorpan>
JonathanNeal: the tag name is irrelevant, it's the element's definition that defines what the element means

[10:11:11.0000] <JonathanNeal>
zcorpan: which is why I shared that definition for you.

[10:11:41.0000] <zcorpan>
TODO(zcorpan): clean up FAQ, removing old stuff

[10:12:18.0000] <zcorpan>
JonathanNeal: "contains such information as address, signature and authorship" - ok, i stand corrected

[10:12:52.0000] <JonathanNeal>
I’m fine with the minimalist argument. I reject the idea that <time> is somehow valid but location is not. We have an API for time and location. We markup time and location as it results to a document or a section within a document. We even had an element, <address>, that was often used to markup location, and allowed for this in its original definition,

[10:12:52.0000] <JonathanNeal>
by the account I’ve shared above.

[10:13:04.0000] <zcorpan>
but in html4 it's not an address

[10:14:08.0000] <zcorpan>
/me gotta go

[10:14:22.0000] <JonathanNeal>
Its definition changes often. Even HTML5 Doctor has an outdated, vague definition and it claims to be for HTML5 http://html5doctor.com/the-address-element/


2015-04-02
[21:03:17.0000] <_1_tima>
I am here: http://maps.google.com/maps?q=26.891408333333334,80.93088833333333

[00:22:46.0000] <annevk>
jgraham: what's an easy way to generate an image with wptserve?

[00:23:04.0000] <annevk>
jgraham: I want to control the headers and have something that resembles a valid image in the response

[00:23:11.0000] <annevk>
jgraham: do we have a pattern for that?

[00:23:25.0000] <Ms2ger>
A .headers file?

[01:02:34.0000] <Ms2ger>
Lovely, now people are coming into #servo wanting to implement css-egg

[01:18:04.0000] <annevk>
Ms2ger: is the magic of .headers defined somewhere?

[01:20:28.0000] <Ms2ger>
http://wptserve.readthedocs.org/en/latest/handlers.html#file-handlers

[02:36:47.0000] <jgraham>
annevk: Yeah, what Ms2ger said as long as you are happy to serve a static image

[02:37:09.0000] <jgraham>
If you really mean "generate an image" you will need to write some python code

[02:39:06.0000] <annevk>
jgraham: yeah so the problem is that I don't want static headers

[02:39:40.0000] <jgraham>
What do you want them to depend on?

[02:40:00.0000] <annevk>
jgraham: some GET parameters

[02:40:11.0000] <jgraham>
Then you need some python code

[02:40:21.0000] <jgraham>
def main(request, response):

[02:40:25.0000] <jgraham>
    headers = []

[02:40:43.0000] <jgraham>
    body = open("/path/to/image").read()

[02:41:23.0000] <jgraham>
    if "type" in request.GET:

[02:41:48.0000] <jgraham>
        headers.append(("Content-Type", request.GET["type"]))

[02:41:50.0000] <annevk>
thanks, reading the image in seems reasonable

[02:41:58.0000] <jgraham>
    return headers, body

[02:50:06.0000] <annevk>
jgraham: what's the current path for these Python scripts?

[02:51:15.0000] <jgraham>
annevk: I was just thinking that I'm not sure :)

[02:52:38.0000] <jgraham>
annevk: __file__ as a global variable should exist and be the absolute path to the the script, so you can use that to resolve paths without caring about the pwd

[02:54:34.0000] <annevk>
jgraham: can I assume os.path.relpath is supported?

[02:54:55.0000] <annevk>
jgraham: so e.g. os.path.relpath("image.gif", __file__) ?

[02:55:35.0000] <jgraham>
Well that wouldn't do what you want

[02:55:38.0000] <jgraham>
I would

[02:55:40.0000] <jgraham>
import os

[02:55:59.0000] <jgraham>
os.path.join(os.path.dirname(__file__), "image.gif")

[02:57:15.0000] <annevk>
thanks

[03:05:34.0000] <annevk>
So this is fun. IE11 successfully loads both image/png and image/gif, but only successfully decodes the latter...

[03:06:09.0000] <annevk>
I sort of thought both should work

[03:17:06.0000] <philipj>
caitp, zcorpan, yes, I added the [LenientThis] FIXME (we have now switched to TODO(name))

[03:18:07.0000] <Ms2ger>
I never saw the point of (name)

[03:27:28.0000] <annevk>
jgraham: we don't have global image/video/audio resources that would be good to reuse?

[03:27:54.0000] <annevk>
I guess video/audio is hard given that browsers suck at having one format that works everywhere

[03:27:59.0000] <jgraham>
annevk: There are some… try /common or /media (off the top of my head)

[03:29:02.0000] <annevk>
ah yeah /media and /images

[03:29:36.0000] <annevk>
jgraham: my tentative location has been http/nosniff

[03:29:58.0000] <annevk>
jgraham: though I'm also considering fetch/nosniff since I might write this down as a subsection of Fetch

[03:30:57.0000] <jgraham>
annevk: Yeah, I don't have a strong opinion about where, and we can always move things later

[03:32:19.0000] <Ms2ger>
I'm leaning towards fetch, but either way

[05:36:56.0000] <annevk>
Where can I find out whether WebVTT is sniffed or not?

[05:51:00.0000] <annevk>
jgraham: I have more questions

[05:51:11.0000] <annevk>
jgraham: if I append a <script> as part of an asynchronous test

[05:51:17.0000] <annevk>
jgraham: how do I assert things from there?

[05:51:57.0000] <annevk>
jgraham: also currently I have this rather inelegant code:

[05:51:59.0000] <annevk>
script.onerror = t.step_func_done(function() { assert_true(true) })

[05:52:04.0000] <annevk>
script.onload = t.step_func_done(function() { assert_true(false) })

[05:52:10.0000] <annevk>
is there something better for that?

[05:54:29.0000] <jgraham>
annevk: Listening to clytn talk about hosting events at the moment, I might not be able to give a coherent answer :)

[05:55:34.0000] <jgraham>
annevk: If you only have one test in a file, you don't need the async_test() stuff at all, you can just use raw asserts()

[05:55:46.0000] <annevk>
jgraham: I have a couple

[05:55:54.0000] <jgraham>
If you just want to test the things you said above, there are easier ways

[05:56:14.0000] <jgraham>
script.onerror = t.step_func_done(function(){})

[05:56:39.0000] <jgraham>
script.onload=t.unreached_func("Should not get a load event")

[05:56:42.0000] <annevk>
jgraham: I want to create a sequence of script elements and for each script element assert its events (either positive or negative) and let them execute something that is also an assert

[05:57:56.0000] <jgraham>
annevk: That doesn't seem too hard; what's the problem?

[05:58:23.0000] <jgraham>
I mean if you insert a script you can just call t.step_func or whatever from that script

[05:58:31.0000] <annevk>
jgraham: I'm not sure how to tie what the script executes with the async_test

[05:58:42.0000] <annevk>
jgraham: doesn't that require t to be a global?

[05:59:24.0000] <zcorpan>
jgraham: Ms2ger: help. my brain stopped working trying to figure this out from the spec. what should happen for onclick = 1; alert(onclick); onclick = {}; alert(onclick) ?

[06:00:07.0000] <Ms2ger>
I knew this once

[06:00:24.0000] <Ms2ger>
It's TreatNonObjectAsNull, no?

[06:00:44.0000] <zcorpan>
ah. yes it is

[06:00:46.0000] <Ms2ger>
So alert(null), alert({})

[06:01:09.0000] <zcorpan>
i totally missed the extended attribute

[06:01:15.0000] <zcorpan>
thx

[06:01:26.0000] <Ms2ger>
Np

[06:01:32.0000] <jgraham>
annevk: Well yeah it requires it to be global. If it's not you would have to pass it in somehow. Not sure how else it coulf work?

[06:01:55.0000] <darobin>
globals in tests aren't particularly frowned upon

[06:02:08.0000] <darobin>
you don't expect to be able to run a bunch of them in the same context

[06:02:19.0000] <darobin>
that would lead to a lot of weirdness

[06:03:00.0000] <darobin>
/me wonders if we could try that then drink a last beer as we watch the world 'splode

[06:07:57.0000] <annevk>
jgraham: that also seems racy, would need a unique global per script...

[06:09:48.0000] <jgraham>
annevk: I don't understand what you're trying to do here

[06:10:34.0000] <jgraham>
If you want a test to contain some asserts in script A and some in inserted script B then you need some way to reference that test from B

[06:10:50.0000] <jgraham>
Making the test a global seems like the easiest way to do that

[06:11:09.0000] <jgraham>
But please give me an example to look at

[06:11:53.0000] <annevk>
I'm creating the scripts asynchronously

[06:12:20.0000] <jgraham>
Right, but as long as the test can't end before the script has run, what's the problem?

[06:14:47.0000] <annevk>
There's not necessarily a problem, it's just that I can't use a single variable

[06:21:01.0000] <annevk>
Although actually, a problem might be that I don't know when all scripts will have executed...

[06:21:57.0000] <jgraham>
Do you need to know that?

[06:22:35.0000] <annevk>
jgraham: not sure where else to run .done()

[06:22:53.0000] <jgraham>
One test, multiple scripts?

[06:23:16.0000] <annevk>
jgraham: the script may or may not execute

[06:24:15.0000] <jgraham>
Depending on what?

[06:24:21.0000] <annevk>
nosniff

[06:24:33.0000] <jgraham>
So one way is a pass and the other is a fail?

[06:25:29.0000] <annevk>
I can load a script in a execute or non-execute way. If I load it in an execute way I want to see that it actually executed and that load is dispatched. If I load it in a non-execute way I want to make sure it did not actually execute and that error is dispatched.

[06:25:32.0000] <jgraham>
If you expect the script to not execute and not executing is the pass condition there's pretty much no choice but to use a timer to say "if it didn't execute in X time, it's a PASS"

[06:25:50.0000] <zcorpan>
Ms2ger: shouldn't html/dom/interfaces.html have Blob defined somewhere?

[06:56:54.0000] <wanderview>
annevk: Request.clone() is not an adequate sanitize step, right?  we need to use the constructor to sanitize I think

[06:57:34.0000] <annevk>
wanderview: correct

[06:57:55.0000] <annevk>
wanderview: clone() just creates a clone

[06:57:56.0000] <wanderview>
thanks

[06:57:59.0000] <wanderview>
yea

[06:58:11.0000] <wanderview>
annevk: the cache sanitize language uses a mix of clone and constructor right now

[06:58:40.0000] <annevk>
wanderview: interesting

[06:59:00.0000] <annevk>
wanderview: cloning seems bad per definition

[06:59:15.0000] <annevk>
wanderview: e.g. the stream just needs to be moved, not tee'd

[06:59:18.0000] <wanderview>
probably worried about draining the body... but Requests with bodies cannot be put into cache any more (because we only accept GET)

[06:59:35.0000] <annevk>
wanderview: also, I thought that if you did put them in, the body should be drained...

[07:00:00.0000] <wanderview>
annevk: I think clone is being used for places we don't want to drain... like cache.match()

[07:00:25.0000] <annevk>
wanderview: shouldn't match just read out the variables?

[07:00:32.0000] <annevk>
wanderview: why would that even clone?

[07:00:45.0000] <wanderview>
annevk: should .match() need a sanitize step?

[07:00:52.0000] <annevk>
wanderview: I don't really see why

[07:00:52.0000] <wanderview>
annevk: or do you only want to sanitize on putting in?

[07:01:01.0000] <annevk>
wanderview: I want sanitize when fetching

[07:01:15.0000] <wanderview>
annevk: so just .add() and .addAll()?

[07:01:16.0000] <annevk>
wanderview: ehsan convinced me that putting it in should just put it in

[07:01:33.0000] <wanderview>
ok

[07:01:57.0000] <annevk>
At some point I'll have free time to move Cache into Fetch and make it all nice and consistent...

[07:04:11.0000] <Ms2ger>
zcorpan, I don't think it's strictly necessary

[07:04:44.0000] <zcorpan>
Ms2ger: ok

[07:06:47.0000] <zcorpan>
annevk: shouldn't we make fetches in general be reliable wrt cookies though?

[07:06:48.0000] <wanderview>
annevk: you want Cache in Fetch just because of the dependency?

[07:07:17.0000] <annevk>
wanderview: the other bit of rationale was that Cache is bigger than SW

[07:07:36.0000] <wanderview>
annevk: I guess I'm wondering if Cache should just be its own spec at this point

[07:07:45.0000] <annevk>
wanderview: different idea I had was to create storage.spec.whatwg.org and put it there along with new storage features

[07:09:03.0000] <annevk>
zcorpan: are implementers interested?

[07:09:25.0000] <zcorpan>
annevk: don't know

[07:09:59.0000] <wanderview>
annevk: not sure I have enough experience with spec stuff to really say which would be better... the OCD person inside me says Cache should be its own spec and depend on Fetch and storage specs

[07:12:48.0000] <annevk>
wanderview: yeah, if setting up a spec had no costs that might be "better"

[07:13:21.0000] <annevk>
zcorpan: that would be my main worry if we wanted to architect something a bit more predictable

[07:16:04.0000] <Domenic>
annevk: what "new storage features"?

[07:17:01.0000] <annevk>
Domenic: see whatwg⊙wo and e.g. https://wiki.whatwg.org/wiki/Storage

[07:17:35.0000] <Domenic>
ah, that one

[07:17:44.0000] <annevk>
It's time to define the storage architecture...

[07:18:02.0000] <annevk>
And expose some of its primitives yadayada

[08:00:42.0000] <zcorpan>
opinions, people who care about readonly attributes on window? https://www.w3.org/Bugs/Public/show_bug.cgi?id=24160 (cssom-view)

[08:04:03.0000] <caitp>
don't readonly attributes on window run the risk of breaking old sloppy mode JS?

[08:05:25.0000] <zcorpan>
caitp: in strict mode you get TypeError. non-strict is like no-op setter

[08:05:53.0000] <caitp>
yeah, but if people expect the setter to not be no-op, then it's a problem :x

[08:06:44.0000] <zcorpan>
yes

[08:06:51.0000] <zcorpan>
[Replaceable] solves that

[08:11:28.0000] <caitp>
the hacks people come up with to make sense of this platform:>

[08:14:56.0000] <zcorpan>
there is no sense :-)

[08:17:47.0000] <jgraham>
Like nonsense?

[08:26:21.0000] <wanderview>
annevk: looking at https://wiki.whatwg.org/wiki/Storage... why put StorageManager on Navigator?

[08:26:44.0000] <wanderview>
how does a Worker access it?  (I thought navigator was window only)

[08:27:18.0000] <annevk>
wanderview: workers have navigator

[08:27:23.0000] <wanderview>
oh, ok

[08:29:36.0000] <wanderview>
annevk: I like that API for v1... I imagine some people will want finer grained estimates, but doing the whole origin/storage area seems a good start

[08:30:52.0000] <annevk>
yeah, if we can get the UX/UI sorted I'm pretty happy with this too

[08:58:43.0000] <JakeA>
Domenic: annevk: thoughts on cancellable promises vs cancellable tokens https://gist.github.com/jakearchibald/9a24f3c06f06b9c06a1e

[10:20:26.0000] <annevk>
JakeA: that issue... also, we should probably start using "cancelable" (see color and other American spelled terms)

[10:20:44.0000] <annevk>
JakeA: will try to review tomorrow

[10:31:30.0000] <annevk>
jgraham: https://github.com/w3c/web-platform-tests/pull/1715#commitcomment-10548986 given that, it's reviewed, right?

[10:31:49.0000] <annevk>
jgraham: also, did critic disappear?

[10:51:35.0000] <Domenic>
annevk: JakeA: yeah, like Event.prototype.cancelable

[11:09:07.0000] <Domenic>
JakeA: left comments

[11:11:49.0000] <JakeA>
Domenic: annevk: ah, sorry, didn't realise the UK thing

[11:12:16.0000] <Domenic>
It's OK, I didn't actually know which was American vs. UK, I just sometimes spell it one way and sometimes another.

[11:12:46.0000] <Domenic>
That's one argument in favor of abort, but then again I'm not looking forward to the html5rocks article on promise abortions

[11:12:51.0000] <boogyman>
finally{}.  is not an "oncancelled", it is "always execute when complete" workflow, unless i am mistaken @ Domenic

[11:13:04.0000] <Domenic>
boogyman: yes, exactly, that was my point.

[11:34:12.0000] <benjamingr>
lol, promise abortions sounds like something that'd spur public debate in the us

[11:34:33.0000] <benjamingr>
Promise cancellation really confuses me :D

[11:58:31.0000] <JakeA>
Promises are way more complicated than they look, but you can get most stuff done knowing 90%. I think cancellable promises will be the same

[12:00:01.0000] <JakeA>
Although most of the people I meet who make a living from JS don't know how to create one object that extends another

[12:00:19.0000] <JakeA>
That's why I like the class syntax sugar

[12:02:05.0000] <Ms2ger>
Damn object-orientation

[12:32:21.0000] <jgraham>
annevk: Yes. Critic may have got a bit behind which can happen sometimes.

[12:35:14.0000] <bradleymeck>
sweet delicious finally

[12:36:13.0000] <bradleymeck>
so many memory leaks when you aren't sure if something is done, guarantees are nice. I am still sad that generators don't have a way to invoke finally if they go into the GC

[12:38:37.0000] <annevk>
jgraham: anyway, I got review on GitHub so can I merge or someone else?

[12:39:08.0000] <annevk>
jgraham: never mind, Mike already did it :-)


2015-04-03
[20:47:50.0000] <mnot1>
annvk — looking at URL spec

[20:47:59.0000] <mnot1>
It doesn't appear to account for http://tools.ietf.org/html/rfc6874

[20:48:15.0000] <mnot1>
Not sure how common that is, but it is coming out of Apple...

[23:12:42.0000] <annevk>
jgraham: I still have "Subproject commit 8ce47687cbbfff6b249bbaf189f096869286c677-dirty" as a change to tools in web-platform-tests

[23:16:54.0000] <annevk>
/me replied to mnot1 on Twitter

[00:39:23.0000] <annevk>
In HTTP ABNF, "text", how do you indicate text cannot appear in quoted form?

[00:40:20.0000] <annevk>
I see, you need quoted-string for that

[02:12:27.0000] <jgraham>
annevk: You can probably ignore that

[02:13:00.0000] <annevk>
jgraham: yeah, it seems like it doesn't matter much in terms of getting updates and doing commits, but it's still a bit annoying that it shows up

[02:13:41.0000] <jgraham>
annevk: Right, it should be possible to make it not say that… I'll investigate

[02:32:35.0000] <Ms2ger>
jgraham, I believe you need to add *.pyc to the gitignore, if you haven't figured that out yet :)

[02:34:47.0000] <jgraham>
Ms2ger: Looking at a problem with my servo PR instead :)

[03:32:28.0000] <jgraham>
OK, added a .gitignore file

[04:22:33.0000] <annevk>
JakeA: it seems you're making good progress on cancelation with Domenic so unless I hear otherwise I'll just wait on the outcome of your research

[04:23:03.0000] <annevk>
JakeA: I also tried to reply to all the BackgroundSync things

[04:27:16.0000] <annevk>
JakeA: I have to say by the way that I have "Background App Refresh" (as Apple calls it) disabled and have advised others with battery problems to do the same. In that light I'm still not really comfortable with the period synchronization feature...

[04:29:12.0000] <rcombs>
anyone around willing to take a look at an HTTP I-D and comment? https://datatracker.ietf.org/doc/draft-combs-http-indeterminate-range/

[04:56:42.0000] <annevk>
rcombs: maybe reuse an existing header to advertise the feature?

[04:58:22.0000] <rcombs>
annevk: I considered extending Accept-Ranges

[04:58:46.0000] <rcombs>
annevk: but there's a decent chance that existing implementations just look for the exact string "bytes" in there

[05:00:23.0000] <annevk>
rcombs: there's Prefer, bunch of client hints headers I believe

[05:01:02.0000] <annevk>
rcombs: I don't know, just seems like adding a new header for each new thing doesn't really scale

[05:03:27.0000] <rcombs>
eh, it's not like you pay per header, or like there's a significant performance penalty for parsing a new one over parsing a variant of an existing one

[05:04:39.0000] <rcombs>
I'd have preferred to have something like `Accept-Ranges: bytes, bytes-indeterminate`, but the existing spec isn't clear on multiple values being allowed for that header

[05:07:27.0000] <annevk>
rcombs: 1#range-unit seems quite clear

[05:10:22.0000] <rcombs>
I actually don't know for sure what that syntax means (is that valid (E|A)BNF?), but assuming it means "exactly 1 of <range-unit>", then yeah, that'd be clearly not allowing multiple values

[05:12:05.0000] <annevk>
rcombs: it means one or more comma-separated values

[05:12:12.0000] <annevk>
rcombs: it's HTTP ABNF

[05:12:29.0000] <rcombs>
oh, of course it has its own dialect

[05:12:37.0000] <rcombs>
that I did not know

[05:12:43.0000] <annevk>
rcombs: https://tools.ietf.org/html/rfc7230#section-7

[05:13:06.0000] <rcombs>
thanks

[05:21:43.0000] <rcombs>
hmm, libavformat checks if the first 5 characters of the header are "bytes", Chromium checks if the string "bytes" appears at all, WebKit just checks if it's not equal to "none", and Firefox checks if it's exactly equal to "bytes"

[05:21:49.0000] <rcombs>
that last one is what I was afraid of

[05:38:46.0000] <annevk>
wow

[05:38:50.0000] <annevk>
that's pretty terrible

[05:38:59.0000] <annevk>
it's almost as if the HTTP WG doesn't really test things

[05:43:39.0000] <annevk>
philipj: do you know the details about MIME types and <audio>, <video>, and <track>?

[05:43:54.0000] <annevk>
philipj: I want to fill out https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?

[05:44:42.0000] <Ms2ger>
Tests? What's that?

[05:45:04.0000] <darobin>
HTTP 1.x did great without

[05:46:45.0000] <rcombs>
if the vast majority of uses of a field have a single value, you can bet at least one implementation will check for that value exactly and fail on all others

[05:48:08.0000] <rcombs>
or otherwise check it lazily, and just make sure it works with existing servers (or files or implementations or whatever) then assume it's fine

[05:48:50.0000] <rcombs>
hi I'm rcombs and I'm cynical about tech

[05:49:12.0000] <Ms2ger>
That's why we have test suites on this side

[07:18:47.0000] <wanderview>
JakeA: is this how Cache add/addAll/put are supposed to work?  it seems confusing to me...  https://github.com/slightlyoff/ServiceWorker/issues/665#issuecomment-89216340

[07:56:49.0000] <caitp>
hm, jhusain isn't big on fetch either

[08:02:59.0000] <caitp>
why do the cancellation semantics need to be tied to the promise? why not response objects?

[08:10:17.0000] <wanderview>
caitp: because you need to be able to cancel before the network headers are available and don't have a Response object yet

[08:39:39.0000] <annevk>
caitp: too late?

[08:43:07.0000] <caitp>
fine, fetch.abort(thePromise) then :p

[08:43:12.0000] <caitp>
but I mean

[08:43:22.0000] <caitp>
it doesn't solve how you'd encode cancellation and avoid deadlocks

[08:43:42.0000] <annevk>
Deadlocks?

[08:44:26.0000] <caitp>
well you wouldn't resolve or reject the promise

[08:45:18.0000] <annevk>
Oh, with your proposal

[08:47:03.0000] <bradleymeck>
unlimited pending also causes some odd things since you can't do a finally style cleanup

[08:47:23.0000] <caitp>
yes, that

[08:47:27.0000] <caitp>
er, that's the proble

[08:47:28.0000] <caitp>
m

[08:47:31.0000] <caitp>
this keyboard is really hard to type on

[08:49:37.0000] <bradleymeck>
/me is still upset that finally is no longer 100% guaranteed in generators

[08:54:19.0000] <annevk>
bradleymeck: JakeA and Domenic have an idea of making .finally work for cancelable promises

[08:54:33.0000] <annevk>
bradleymeck: but not .catch, which seems okayish

[08:55:38.0000] <bradleymeck>
uggggg

[08:55:58.0000] <bradleymeck>
finally, except not like try catch finally

[08:56:41.0000] <bradleymeck>
we use finally to cleanup steps in both cases, since we keep pushing cleanup steps as we perform them

[08:57:07.0000] <bradleymeck>
so if there is an error we would need to always add a .catch to do cleanup?

[08:58:10.0000] <caitp>
`

[08:58:16.0000] <annevk>
bradleymeck: not like that

[08:58:49.0000] <annevk>
bradleymeck: cancelation would trigger finally only, catch/finally still work per usual otherwise

[08:59:11.0000] <bradleymeck>
seems sane, as cancelation is closer to return than throw

[08:59:24.0000] <bradleymeck>
at least we are using .return for cancellation on generators

[10:15:43.0000] <Domenic>
yeah, that was the inspiration

[10:16:06.0000] <Domenic>
not sure it's actually workable or ergonomic yet, but seems theoretically sound-ish

[10:48:07.0000] <Domenic>
JakeA: I think I like the onCancelled-handler-chooses approach. That way you get forever-pending by default but the creator can choose.

[10:48:33.0000] <Domenic>
JakeA: you *could* even extend it so that .cancel(x) passes x to onCanceled, which would allow .cancel({ rejectWith: e }) if the promise-creator was set up to handle that.

[12:24:10.0000] <caitp>
does it really make sense to use promises at all for something that is more complicated than a success/error response?

[12:29:39.0000] <jsbell_gardener>
caitp: if "it" was synchronous, would it make sense as function that returns a value or throws?

[12:30:37.0000] <caitp>
right, but this is re: fetch

[12:30:48.0000] <caitp>
there are more possible outcomes and no real synchronous analog

[12:31:29.0000] <jsbell_gardener>
ah, missed the context above

[12:44:55.0000] <Domenic>
caitp: I think it does.

[12:45:56.0000] <Domenic>
caitp: you can think about it in a few ways. One is that a promise is an async extension of "completion values" and there are more completion types than just normal and throw.

[12:47:59.0000] <caitp>
well jhusain was saying "we escaped the land of errnos and sentinel values for a reason, lets not go back!" well, in addition to other things

[12:48:06.0000] <caitp>
and with the current promise design, how else would you do it?

[13:01:23.0000] <Domenic>
You wouldn't use the current promise design, you'd use a cancellable promise design

[13:03:30.0000] <caitp>
Promise.all([ fetchThing1(), fetchThing2(), fetchThing3() ]).ohWaitIDontNeedTheseWhatNow()

[13:03:44.0000] <caitp>
it doesn't "really" work

[13:04:59.0000] <Domenic>
I don't really understand either of those two sentences

[13:05:33.0000] <caitp>
I mean, if cancellable promises can interact with regular promises, then you can lose the cancelable-ness

[13:05:43.0000] <Domenic>
for sure, that's kind of explicitly the point

[13:05:43.0000] <caitp>
which is confusing and notgood

[13:05:51.0000] <Domenic>
if you downcast to a regular promise you're removing the cancel-ability

[13:06:07.0000] <Domenic>
Kind of like downcasting from v8::Value to v8::Handle :P

[13:07:33.0000] <caitp>
I dunno, seems like a lot of headaches waiting to happen

[13:08:37.0000] <wanderview>
Domenic: do you envision a Promise.allCancellable() that would keep the all() behavior and cancellable type?

[13:08:51.0000] <Domenic>
wanderview: CancelablePromise.all([...])

[13:08:59.0000] <Domenic>
base Promise type should be entirely undisturbed

[13:09:12.0000] <wanderview>
Domenic: and does that throw if passed a non-cancellable promise or something?

[13:09:32.0000] <Domenic>
wanderview: nah it just converts them to cancelable promises which a no-op cancelation action

[13:09:47.0000] <Domenic>
wanderview: similarly to how Promise.all converts non-promises to fulfilled promises

[13:10:01.0000] <caitp>
I know fetch has shipped and all, but it's young and could probably be unshipped in order to fix the design

[13:10:32.0000] <wanderview>
Domenic: so as a developer, I would just use CancelablePromise.all() all the time right?  why would I ever use Promise.all() any more?

[13:10:47.0000] <wanderview>
in case someone gave me a cancellable promise

[13:11:03.0000] <wanderview>
or needed to consume my promise as cancellable

[13:11:22.0000] <Domenic>
caitp: you really have drunk the kool-aid of that thread ... there's nothing wrong with the fetch design.

[13:11:43.0000] <Domenic>
wanderview: you would use CancelablePromise.all if you wanted the result to be cancelable. But that's pretty rare. Most of the time you don't want to give people the ability to cancel.

[13:12:01.0000] <caitp>
i am not really following that thread closely, but we're looking at the design for angular's new http abstraction, and jafar husain brought the points there

[13:12:41.0000] <Domenic>
ah yes, he is everywhere bad-mouthing other peoples' work.

[13:13:12.0000] <caitp>
i don't know if he's been impolite about it, but he does raise some good points

[13:13:27.0000] <Domenic>
i really just disagree with them. he's pretty colored by his observable-philia

[13:14:08.0000] <Domenic>
sour grapes that the platform includes promises and not observables, is what i've seen

[13:14:43.0000] <caitp>
i mean, I think the platform does get pretty close to observables with DOM events

[13:14:47.0000] <caitp>
"pretty" close

[13:15:02.0000] <JakeA>
Domenic: not sure I like the "perma-hang as a default" idea, especially as a chain can cancel without oncancel being called on any promise

[13:15:21.0000] <Domenic>
caitp: heh. I mean, they are both vaguely event-like.

[13:15:25.0000] <JakeA>
I think reject or some third state needs to be default

[13:16:17.0000] <Domenic>
JakeA: hmm. I think the question is, what is the use case for observing cancellation.

[13:16:46.0000] <JakeA>
Domenic: cancelling spinners for one

[13:16:51.0000] <Domenic>
JakeA: if we had better answers for that, we could see if e.g. a .finally version is reasonable

[13:17:05.0000] <Domenic>
OK, cool, that does sound finally-friendly

[13:17:23.0000] <Domenic>
doAsyncThing().catch(showError).finally(removeSpinner)

[13:18:07.0000] <JakeA>
Domenic: agreed

[13:18:27.0000] <Domenic>
This is gonna be a bitch to spec the backend of :P

[13:18:57.0000] <caitp>
it's probably not a good idea to have a new class of promise in addition to existing promises

[13:19:05.0000] <Domenic>
I disagree

[13:19:30.0000] <Domenic>
JakeA: I think I'll revive promises-unwrapping, update it to the latest spec. Then we can use it as a base for CancelablePromise.

[13:20:32.0000] <caitp>
no, it's a really bad idea, from a web developer's PoV and from a browser vendor's PoV

[13:20:38.0000] <Domenic>
I disagree.

[13:20:45.0000] <wanderview>
Domenic: I guess it just seems weird to me that if you use a legacy library in your Promise chain that does not return CancellablePromise, then you can no longer cancel the source of the chain...

[13:21:08.0000] <Domenic>
wanderview: yeah but the legacy library produces promises that are not meant to be cancelable

[13:21:43.0000] <caitp>
why not just propose an extension to the promise api for es7?

[13:21:59.0000] <Domenic>
caitp: because not all promises should be cancelable. That's a capability leak to make them so.

[13:22:12.0000] <wanderview>
Domenic: but if the source hasn't finished yet, why does the cancellability of the later processing prevent me from cancelling the source?

[13:22:35.0000] <caitp>
Domenic, they might not all be cancellable, but "finally" surely makes sense for all promises

[13:22:52.0000] <Domenic>
caitp: oh, yeah, definitely. That was the plan.

[13:23:11.0000] <caitp>
if you have a single class, you make life much easier for devs

[13:23:19.0000] <wanderview>
Domenic: it just seems its going to make it harder to glue different modules in the promise ecosystem together... basically creating separate class of modules

[13:23:25.0000] <caitp>
if they all have a cancel method which may or may not do anything, you make life easier

[13:23:44.0000] <Domenic>
wanderview: I think that's intended though. You should explicitly opt-in to cancelability.

[13:24:00.0000] <Domenic>
caitp: I don't think silent failure like that makes anyone's life easier.

[13:24:18.0000] <caitp>
where's the silent failure

[13:24:22.0000] <wanderview>
Domenic: I don't see how that jives with CancellablePromise.all() wrapping non-cancellable promises with a no-op cancel()... if thats safe... just give them all a no-op cancel by default

[13:24:50.0000] <Domenic>
caitp: canceling something that's not actually cancelable is a logic error. Better to get that error than silently doing nothing.

[13:25:41.0000] <Domenic>
wanderview: it's a shorthand for CancellablePromise.all(mapIterable(i, x => CancelablePromise.resolve(x)))

[13:26:09.0000] <Domenic>
wanderview: just like Promise.all is a shorthand for Promise.all(mapIterable(i, x => Promise.resolve(x)))

[13:27:02.0000] <wanderview>
Domenic: I don't see how that behavior is consistent with your statement "canceling something that's not actually cancelable is a logic error"

[13:27:13.0000] <wanderview>
but I am probably just bikeshedding at this point

[13:27:22.0000] <wanderview>
/me gets out of the way.

[13:28:21.0000] <Domenic>
wanderview: I see what you're saying. It's an implicit part of the .all contract that you up-cast though. Whereas it's not an implicit part of the anyValue.anyMethod() contract that you up-cast, IMO. So if anyValue does not have a behavior for anyMethod then it seems better to throw.

[13:28:56.0000] <Domenic>
I dunno, these kind of things make me want to go back to tokens, but then I see how painful they are to use.

[13:29:14.0000] <Domenic>
I am 100% sure by this point though that CancelablePromise is much better than Task

[13:29:36.0000] <wanderview>
Domenic: I guess I would argue there is a net benefit to the ecosystem to providing a single Promise class with a default no-op vs. splitting the ecosystem into separate classes with more strictly defined throw-if-not-really-cancelable policy

[13:29:44.0000] <caitp>
i think it's worth entertaining the guy's ideas a bit, it's not like he doesn't have a clue about api design

[13:29:55.0000] <Domenic>
caitp: I've been down that road.

[13:30:04.0000] <Domenic>
caitp: not my first rodeo with Jafar :)

[13:30:47.0000] <caitp>
so what is the big selling point for sticking with promises, other than "we already shipped"

[13:31:40.0000] <Domenic>
they're a good abstraction. maybe not what you're used to if you come from C# and Rx.NET, but for people coming from many other languages, and from JavaScript itself, they're quite suitable.

[13:32:10.0000] <caitp>
buuuut you admit that you need to invent a new variant of them which actually covers all the use cases

[13:32:15.0000] <caitp>
which doesn't seem very good

[13:32:37.0000] <Domenic>
why? why is it bad to extend something that exists instead of creating a whole new paradigm people have to learn and choose between?

[13:33:13.0000] <Domenic>
sometimes you want an array, sometimes you want a map, sometimes you want a set

[13:33:28.0000] <caitp>
I think because you're still creating a new paradigm, it's just that people will confuse one for the other inadvertently

[13:33:32.0000] <Domenic>
Doesn't mean arrays suck and when we "invented" maps/sets that means arrays are not very good

[13:33:58.0000] <Domenic>
analogy is imprecise since maps/sets are not a superset of arrays ... should have probably used iterables in there somewhere... but you get the idea.

[13:34:22.0000] <Domenic>
It's OK for multiple different-but-related things, with different powers, to exist to suit different use cases

[13:34:22.0000] <caitp>
it's closer to the ImmutableMap vs Map discussion

[13:34:34.0000] <caitp>
if people use ImmutableMap and Map interchangeably, they might have a problem

[13:34:35.0000] <Domenic>
Sure, that's pretty good, I agree.

[13:34:48.0000] <wanderview>
to be honest, there seemed many similarities between the Task and CancellablePromise concepts... they both ref counted users, etc

[13:35:06.0000] <Domenic>
Not quite a superset relation, but the different-but-similar tools for different situations is analogous

[13:35:12.0000] <Domenic>
wanderview: oh? last I saw tasks refused to be called more than once

[13:36:00.0000] <wanderview>
Domenic: I'm sure there are differences... but the promise extension being discussed seem closer to the Task thing

[13:36:16.0000] <Domenic>
wanderview: ah I see, they've changed since proposed at TC39 last week

[13:36:22.0000] <Domenic>
"proposed"

[13:37:09.0000] <Domenic>
I agree they seem to have coevolved

[13:38:06.0000] <Domenic>
The main difference at this point seems to be the C#-style separation between operation and subscription rather than the JavaScript-style both-in-one-object. Jafar is indeed not a fan of the JS style, whether it be for generators, iterators, or promises.

[13:38:16.0000] <Domenic>
I think if we take his Task thing and adapt it to JS style it does end up being CancelablePromise.

[13:38:48.0000] <wanderview>
Domenic: maybe just call it something completely different and split the difference :-)  Its an Activity!  and an Activity is a Promise

[13:38:55.0000] <Domenic>
haha

[13:39:05.0000] <Domenic>
haven't heard Activity before, that's fun :)

[13:39:29.0000] <wanderview>
Domenic: oh... or its a Suggestion which extends Promise... Suggestions can be ignored

[13:39:47.0000] <Domenic>
ah yes, the promises ecosystem needs more puns, definitely let's do that

[13:39:58.0000] <wanderview>
/me stops "helping".

[13:40:00.0000] <Domenic>
/me is still sad it ended up being "fulfilled" and "rejected" instead of "kept" and "broken"

[13:40:10.0000] <caitp>
heh

[13:40:43.0000] <Domenic>
new Promise((keep, break) => { /* oops SyntaxError :( */ })

[13:41:14.0000] <JakeA>
It all started with stringify. That was the start of the namepocalypse

[13:42:32.0000] <wanderview>
its a sad truth that bikeshedding names is more fun than c++


2015-04-04
[20:06:38.0000] <GPHemsley>
annevk: Are you aware of this? https://mimesniff.spec.whatwg.org/#mime-type-groups

[22:10:11.0000] <annevk>
GPHemsley: I wasn't, that looks interesting

[22:11:44.0000] <annevk>
GPHemsley: not really clear whether MIME sniff should be the keeper of that data though

[22:12:04.0000] <annevk>
but maybe

[06:13:40.0000] <GPHemsley>
annevk: See also: https://mimesniff.spec.whatwg.org/#understanding-mime-types

[09:37:03.0000] <annevk>
GPH: that looks like a pretty good start for MIME type terminology

[09:37:48.0000] <annevk>
GPH: at some point you should get someone to organize a test suite for that whole thing

[09:37:55.0000] <annevk>
GPH: then we can maybe move it forward a bit


2015-04-05
[04:11:49.0000] <annevk>
JakeA: I'm cleaning up the SW issue list a bit

[04:12:06.0000] <annevk>
JakeA: in particular those issues referenced from Fetch that should probably move elsewhere

[04:30:14.0000] <JakeA>
annevk: cool, will have a crawl through them on Tuesday too

[05:29:58.0000] <annevk>
/me is trying to figure out IRC urls... irc://freenode.net:6697/whatwg look good?

[05:30:35.0000] <annevk>
I sort of want to encourage SSL, but there doesn't seem to be ircs...

[05:32:13.0000] <annevk>
Hmm, there's a draft https://tools.ietf.org/html/draft-butcher-irc-url-04#section-2.1 that does define "ircs", but nothing that's an RFC afaict

[05:51:33.0000] <Krinkle>
annevk: Freenode has SSL on port 7000

[05:54:11.0000] <Krinkle>
https://en.wikipedia.org/wiki/Template:Freenode#Example

[05:54:17.0000] <Krinkle>
irc://irc.freenode.net/#wikipedia-en

[05:54:26.0000] <Krinkle>
Looks right yeah

[07:10:54.0000] <annevk>
Krinkle: yeah, except ircs:// doesn't work :-(

[07:11:23.0000] <annevk>
Krinkle: btw, did my reply to your storage email help?

[07:11:33.0000] <Krinkle>
Right. When opening it in an IRC client you'd need a way to tell the app to use SSL.

[07:11:42.0000] <Krinkle>
In LimeChat there's a checkbox for it.

[07:11:57.0000] <Krinkle>
I don't think there's a way to programmatically set that based on a url.

[07:12:03.0000] <Krinkle>
ircs makes sense.

[07:12:07.0000] <Krinkle>
annevk: Yep.

[07:12:21.0000] <annevk>
Krinkle: https://wiki.whatwg.org/wiki/Storage has some v2 markers now, planning on elaborating a bit in the next couple weeks

[07:13:09.0000] <annevk>
The current situation is indeed rather messy and if we want to be competitive we should address that

[07:13:34.0000] <Krinkle>
Yeah, our native app doesn't have these issues for instance.

[07:13:49.0000] <Krinkle>
Not that that's really a solution either. But from a dev perspective it's great

[07:13:56.0000] <Krinkle>
not have to deal with a limit

[07:15:15.0000] <annevk>
Krinkle: another thing I was interested in is how Wikipedia plans on addressing its issues with having multiple origins for locales

[07:15:42.0000] <Krinkle>
At the moment that's not really a concern to us.

[07:15:43.0000] <annevk>
Krinkle: it seems like if e.g. Wikipedia gets a location-based service of sorts you'd want users to have to opt into that only once

[07:15:47.0000] <Krinkle>
They're independent websites.

[07:16:00.0000] <Krinkle>
separate content, communities and user priviledges.

[07:16:03.0000] <Krinkle>
not translations.

[07:16:19.0000] <annevk>
Krinkle: nothing is automated between them?

[07:16:25.0000] <annevk>
okay

[07:16:32.0000] <Krinkle>
Of course, they're all hosted by the same foundation. And we share the source code (differnet configuration loads based on http hostname).

[07:17:08.0000] <Krinkle>
But lots of version and plugin differences do exist, so we currently dont' share anything client-side.

[07:17:27.0000] <Krinkle>
Many modules (e.g. jquery ui) can vary based on language and skin.

[07:17:38.0000] <annevk>
Interesting

[07:17:55.0000] <Krinkle>
The cookieless domain bits.wikimedia.org is what serves most static resources from a hostname subdirectory.

[07:18:00.0000] <Krinkle>
virtual, not on disk.

[07:18:41.0000] <Krinkle>
But the localStorage system is indeed occopying the actual userfacing website origin (e.g. en.wikipedia.org, not bits.wm.o)

[07:19:07.0000] <Krinkle>
Which causes other plugins and power-user apps to fail sometimes due to space conflicts.

[07:19:12.0000] <Krinkle>
We have not solved this as of yet.

[07:20:23.0000] <Krinkle>
Other than to basically reject anything that uses localStorage and defer to other storage areas instead, which sucks.

[07:20:47.0000] <Krinkle>
We even had to revert some code that switches from cookies to localstorage  where it made sense. But didn't work (e.g. hide-banner and boolean stuff like that)

[07:20:59.0000] <Krinkle>
so those are back in cookies at the moment.

[07:21:19.0000] <Krinkle>
We'll probably move a the js/css module storage  to IndexDB which nobody uses.

[07:21:36.0000] <Krinkle>
:-)

[07:22:28.0000] <annevk>
Krinkle: so we are planning on putting all storage APIs into the same bucket so that might not help you much

[07:22:51.0000] <annevk>
Krinkle: but maybe having multiple buckets per site will help

[07:22:55.0000] <Krinkle>
There would have to be some way to limit the size or priority of a sub-bucket.

[07:23:09.0000] <Krinkle>
like a namespace of sorts

[07:23:38.0000] <Krinkle>
storage = Storage.instance('<rfee key>', { prio: -2 });

[07:23:42.0000] <Krinkle>
just thinking out loud

[07:23:48.0000] <annevk>
Yeah, the idea is to have names that you can use with IDB and the Cache API (not sure it can work for localStorage)

[07:23:49.0000] <Krinkle>
it would create it ondemand, and re-configure if pre-existing.

[07:24:35.0000] <annevk>
And yeah, then use LRU across all buckets meaning often used buckets get cleared less

[07:25:05.0000] <Krinkle>
ideally we'd have LRU within a bucket as well.

[07:25:25.0000] <annevk>
And the other idea is having an LRU variant of the Cache API. Allowing you to store static resources there. And then the browser could do global reasoning about all LRU Cache APIs...

[07:25:31.0000] <Krinkle>
So that if a user visited the patrol app once but never comes back, it'll drop off eventually

[07:25:53.0000] <annevk>
Yeah, basically that

[07:26:38.0000] <Krinkle>
is there actually structure between origins recognised? I forget.

[07:26:50.0000] <Krinkle>
e.g. could we hack up a modules.en.wikipedia.org and access that from en.wikipedia.org

[07:26:50.0000] <Krinkle>
:P

[07:27:00.0000] <Krinkle>
for storage only

[07:27:11.0000] <annevk>
Through an <iframe>

[07:27:16.0000] <Krinkle>
Right

[07:27:25.0000] <annevk>
If the user doesn't disable third-party cookies...

[07:27:32.0000] <Krinkle>
"cookies"

[07:28:07.0000] <annevk>
Well yeah, again that's something we don't do well currently, but cookies need to be grouped together with all the other storage bits for these settings to have the effect the user expects

[07:28:18.0000] <Krinkle>
pumping 4-10 MB of serialised js/css/images through an iframe doesn't sound great though :D

[07:28:36.0000] <Krinkle>
Yeah

[07:28:42.0000] <Krinkle>
cookies is what users know

[07:28:48.0000] <Krinkle>
at least the few users that are aware of it

[07:28:53.0000] <Krinkle>
that's the customer facing term

[07:28:59.0000] <annevk>
The one other thing that's a bit unclear still is what the scope of storage is. eTLD+1 or origin. And we might want to make it different for "best effort" vs "persistent"...

[07:29:07.0000] <annevk>
Yup

[07:30:30.0000] <annevk>
Yeah, so tentative plan is persistent, multiple buckets, and a LRU API, and then see if that works...

[07:30:46.0000] <annevk>
an LRU I guess?

[07:33:39.0000] <Krinkle>
LRU cache is what I tend to say

[07:34:01.0000] <Krinkle>
Though it'd be interesting to see if there is usecase for multiple cache algorythms.

[07:34:11.0000] <Krinkle>
But I guess it's best to not bloat

[07:34:23.0000] <Krinkle>
instead provide a way for users to build their own if needed.

[07:35:07.0000] <Krinkle>
perhaps service worker can be authorised to routinely kick in and evaluate cache content based on some logic.

[07:35:50.0000] <Krinkle>
with native being told it's "persistent" but it will loop through and clear things based on its own logic

[07:35:53.0000] <annevk>
There's a proposal for an eviction event of sorts, but based on other systems that tried you probably want something like /tmp instead

[07:36:48.0000] <annevk>
At the moment you need to clear having to ask a dozen apps is not deal

[07:36:52.0000] <annevk>
ideal*

[07:38:19.0000] <Krinkle>
yeah

[07:38:42.0000] <Krinkle>
definitely not on the main thread synchronous

[08:07:23.0000] <zewt>
also evictable storage might be managed by something outside of the browser, eg. on mobile

[10:09:46.0000] <wanderview>
annevk: instead of a storage pressure event, what do you think about at least exposing a "systemStoragePressure" boolean attribute on StorageManager.

[10:10:17.0000] <annevk>
wanderview: what does that mean?

[10:10:54.0000] <wanderview>
annevk: instead of firing storage pressure events at origins... allow the origin to opt-in, check that storage pressure state, and manually free stuff when its running anyway

[10:11:13.0000] <wanderview>
I dunno... it was just an idea I had the other day

[10:11:18.0000] <wanderview>
not sure it makes sense

[10:11:54.0000] <wanderview>
the app might just want to do something different if the overall system disk is almost full to avoid having itself get deleted

[10:12:14.0000] <wanderview>
but we don't spin up the app automatically to handle it, etc

[10:12:26.0000] <wanderview>
its probably a bad idea

[10:14:50.0000] <annevk>
wanderview: I would imagine a sensible application would already do everything it can to keep storage low

[10:15:13.0000] <annevk>
wanderview: that's another reason I'm somewhat skeptical about this event

[10:15:50.0000] <annevk>
wanderview: gigantic apps will be at the top of the list for the user to remove, you'd try hard not to end up there

[10:15:55.0000] <wanderview>
annevk: I guess I was more observing that the current "getEstimate" API we have only provides info on the origin's quota/storage vs overall system state...  might be nice to include something about if the system is under pressure there

[10:16:46.0000] <annevk>
wanderview: telling the app about the user's hard drive might be tricky, but maybe if the user opts into persistent mode we could expose a bit more stuff?

[10:17:27.0000] <wanderview>
annevk: I'm not talking about exact amounts for the system... just a "system low on disk space" signal

[10:17:42.0000] <wanderview>
I'm happy to leave that off for now

[10:18:17.0000] <annevk>
wanderview: yeah might be interesting to have a 80%-90% full indication

[10:18:44.0000] <annevk>
wanderview: though with persistent you'd probably get to see that amount anyway unless the user agent caps it, we haven't really discussed the finer details of that

[10:18:59.0000] <wanderview>
annevk: if nothing else, this could be a compromise with people who want a storage pressure event

[10:19:31.0000] <annevk>
wanderview: my plan is to write a slightly more detailed model of the existing and proposed architecture somewhere next week

[10:20:06.0000] <wanderview>
cool

[10:20:14.0000] <wanderview>
I'm going to be focusing on streams this week, I think

[10:22:06.0000] <annevk>
yay

[10:22:28.0000] <annevk>
wanderview: quite happy you're reviewing the proposed Fetch integration

[10:22:57.0000] <wanderview>
annevk: wish I had time to do it earlier!

[10:23:11.0000] <wanderview>
annevk: are there existing cases of that GC behavior that is proposed?

[10:23:28.0000] <wanderview>
make some DOM call, and then system resources are potentially leaked forever

[10:24:18.0000] <annevk>
wanderview: I missed that, does forever mean until you close the tab?

[10:24:42.0000] <annevk>
(there's a lot of that)

[10:24:48.0000] <wanderview>
annevk: it explicitly says if you do response.body.getReadable() then the UA cannot terminate the fetch

[10:24:59.0000] <wanderview>
cannot terminate the fetch due to GC

[10:25:26.0000] <annevk>
wanderview: oh that makes sense, but closing the tab would not be GC

[10:25:57.0000] <annevk>
wanderview: closing the tab is akin to "end-user abort"

[10:26:27.0000] <wanderview>
annevk: I guess I'm worried on the stream just blocking on back pressure (because no one is actually reading) and then it just doesn't close until the tab closes

[10:26:31.0000] <annevk>
wanderview: I think WebSocket has a similar thing about not allowing the connection to be closed due to GC

[10:26:53.0000] <annevk>
wanderview: and actually, even XMLHttpRequest has that: https://xhr.spec.whatwg.org/#garbage-collection

[10:27:04.0000] <annevk>
wanderview: anything to avoid exposing GC

[10:28:55.0000] <annevk>
Granted that this case is a little different, but still similar enough

[10:29:27.0000] <wanderview>
annevk: hmm... but what if there was no close handler registered.... seems like it should be GC'able then

[10:29:31.0000] <annevk>
/me was afraid momentarily that they were exposing GC

[10:29:46.0000] <wanderview>
annevk: good to know that there is precedent, though

[10:30:15.0000] <annevk>
wanderview: if there are no handlers that might be okay, though I think jsbell has a trick for that case

[10:34:06.0000] <wanderview>
annevk: it seems the XHR spec says it must not be GC'd only if it has an event handler set

[10:35:02.0000] <annevk>
wanderview: yeah, I think jsbell's argument was that you could detect GC in such a case by having a side-channel open and logging the TCP closing time on the server

[10:35:23.0000] <annevk>
wanderview: but I don't think any specification is concerned with that trick at the moment, not even WebSocket

[10:35:34.0000] <wanderview>
annevk: uh... that sounds akin to saying "you can detect GC by attaching with a debugger"

[10:35:34.0000] <annevk>
wanderview: so presumably streams shouldn't either

[10:35:51.0000] <annevk>
wanderview: well except there's no debugger

[10:37:11.0000] <wanderview>
annevk: do you know what Domenic meant by:   It's the same as if you allocate a large array buffer and then don't clean it up. You've manually said "I want this potentially-large resource to stick around."

[10:37:16.0000] <wanderview>
do ArrayBuffers not GC??

[10:37:48.0000] <annevk>
wanderview: I would expect them to GC just fine

[10:38:14.0000] <annevk>
wanderview: I've never heard anyone talk about magic GC abilities of ArrayBuffer

[11:01:04.0000] <wanderview>
annevk: I don't understand the opaque response stuff well enough to comment on https://github.com/slightlyoff/ServiceWorker/issues/590#issuecomment-89757518

[11:52:27.0000] <wanderview>
Domenic: ping

[11:52:55.0000] <Domenic>
wanderview: pong

[11:53:30.0000] <wanderview>
Domenic: hi! I was reading this, but have a question https://github.com/yutakahirano/fetch-with-streams/issues/15

[11:54:00.0000] <wanderview>
there you wrote: "The graph in this scenario is: resolve -> foo.closedPromise. So even if author code stops using foo and we GC foo, foo.closedPromise is not GCed until the UA code frees resolve."

[11:54:15.0000] <annevk>
wanderview: do you know who else I could ping?

[11:54:31.0000] <wanderview>
Domenic: doesn't the graph go the other way? foo.closePromise -> resolve?  I don't see how resolve holds a ref to the promise

[11:54:43.0000] <wanderview>
annevk: nsm is probably good

[11:54:52.0000] <Domenic>
wanderview: no, resolve holds the ability to change the state of closePromise

[11:54:59.0000] <annevk>
ta

[11:55:03.0000] <Domenic>
assume a function ResolvePromise(p, value)

[11:55:10.0000] <Domenic>
then resolve = ResolvePromise.bind(foo.closePromise)

[11:55:22.0000] <Domenic>
or, resolve = function (value) { ResolvePromise(foo.closePromise, value); }

[11:55:29.0000] <wanderview>
oh... resolve is set to a function, ok

[11:55:39.0000] <Domenic>
right, yeah

[11:55:44.0000] <wanderview>
Domenic: this is pretty different from the c++ :-)

[11:55:50.0000] <Domenic>
welp :P

[11:55:59.0000] <Domenic>
In C++ I guess it would be a PromiseResolver object?

[11:56:08.0000] <Domenic>
with resolve and reject methods, and a promise private field?

[11:56:14.0000] <wanderview>
Domenic: I think what you are saying is we can GC the stream, but hold the promise alive

[11:56:24.0000] <wanderview>
Domenic: is that accurate?

[11:56:38.0000] <Domenic>
wanderview: right, I think that is what I am saying :P

[11:56:43.0000] <Domenic>
this stuff gets confusing...

[11:57:03.0000] <wanderview>
/me tries to find the point in the streams spec that says to resolve one of these promises.

[11:57:57.0000] <Domenic>
Ctrl+F "Resolve reader@[[closedPromise]]"

[11:59:06.0000] <Domenic>
Oh hey, found some dead code -_-

[11:59:34.0000] <wanderview>
Domenic: yea... CloseReadableStreamReader is not used any more?

[11:59:43.0000] <Domenic>
yep X_X

[11:59:45.0000] <Domenic>
killing it with fire

[11:59:56.0000] <Domenic>
wow it's even gone from the reference impl

[12:00:55.0000] <Domenic>
I was like ... this code looks pretty similar ... couldn't I refactor it out into a shared operation? And then I saw why it was similar ... I already factored it elsewhere and forgot to delete the old one.

[12:01:53.0000] <wanderview>
Domenic: so... it seems to me the spec requires doing other things with the stream when that promise is resolved... I don't see anything that lets us handle it separately from the stream object for when the socket closes

[12:02:18.0000] <Domenic>
wanderview: not sure I understand the question/dillema...

[12:03:06.0000] <wanderview>
Domenic: I don't see anything that says "when the socket closes, resolve the promise"... the streams spec has us modifying state variables and other stuff on the stream object... which implies we cannot GC the stream object

[12:03:59.0000] <Domenic>
wanderview: Right. You can close the socket and not call close(), i.e. not signal to the stream implementation that the stream itself should start acting closed

[12:04:05.0000] <wanderview>
Domenic: maybe its also just a conceptual issue for me... feels weird to say "here is an object that represents the stream", but that object can be destroyed without actually closing the underlying stream

[12:04:12.0000] <Domenic>
hmm

[12:04:31.0000] <Domenic>
So my take is that this underlying source object is adapting the socket or whatever into a stream object that reflects the state of the socket

[12:05:00.0000] <Domenic>
If the object goes away that doesn't necessarily mean the socket does, but it could if you want to set up a weak reference thingy to do so

[12:05:06.0000] <wanderview>
Domenic: but the fetch-with-streams doesn't define this "socket or whatever", but implies we have to give the promise to it directly

[12:05:33.0000] <Domenic>
right ... i'm getting confused now :(

[12:05:53.0000] <wanderview>
I have to go in a few minutes

[12:06:12.0000] <Domenic>
ok, i probably should too. (why are we working on sunday? :P)

[12:06:34.0000] <Domenic>
we can pick this up later ... i agree it's confusing and probably can be made clearer in fetch-with-streams

[12:06:38.0000] <wanderview>
Domenic: this is why I find it easier to define it as a ref holding the stream alive... and GC causes abort

[12:06:50.0000] <wanderview>
ok, have a good Easter!

[12:06:52.0000] <wanderview>
byte

[12:06:54.0000] <wanderview>
bye

[12:07:25.0000] <Domenic>
later!

[12:39:06.0000] <annevk>
Wait, we're allowed breaks on Sunday?

[16:22:51.0000] <wanderview>
annevk: only easter sunday

[16:41:04.0000] <gsnedders>
A properly defined grammar for the html5lib test format would be great, because dear god trying to parse this

[16:42:07.0000] <gsnedders>
Pretty sure we're LR(2)

[16:42:16.0000] <gsnedders>
At least in the simple definition


2015-04-06
[23:44:39.0000] <annevk>
JakeA: is it not inconvenient that the Cache API does not allow things like .match(url, {headers:{x:"y"}})?

[00:29:06.0000] <annevk>
JakeA: wanderview: was it considered to allow more than http/https URLs in caches?

[00:36:52.0000] <JakeA>
annevk: that stuff can be added. What use cases are you thinking? Are those matching request or response headers?

[00:37:39.0000] <annevk>
JakeA: I mean constructing Request objects in the same way that fetch() allows for

[00:37:45.0000] <JakeA>
annevk: nah, it follows http caching rules so it's pretty restricted to http

[00:38:26.0000] <annevk>
JakeA: it doesn't really follow HTTP cache rules

[00:38:33.0000] <annevk>
JakeA: perhaps HTTP cache matching rules

[00:39:17.0000] <annevk>
JakeA: but we use HTTP headers and such for other schemes too, and if we allowed other schemes you could more easily abuse it as a key/value store

[00:39:18.0000] <JakeA>
annevk: Ohh, so the API would be .match(url, requestOpt, queryOpts)?

[00:39:37.0000] <annevk>
JakeA: yeah, I was wondering why that wasn't done

[00:40:05.0000] <JakeA>
Having to include an empty object just to get at the query options sounds bad

[00:41:20.0000] <annevk>
I guess it doesn't matter so much here to have an easy way to construct a Request object

[00:41:58.0000] <JakeA>
annevk: if there's a way to add non-http in there, I'm cool with it. The way caching is designed is to ensure every item in the cache is matchable

[00:43:13.0000] <JakeA>
Other than http/https, what were you thinking?

[00:44:35.0000] <annevk>
I was initially thinking everything, but that doesn't work well. So maybe something like cachekey URLs (cachekey:item1)... Anyway, later seems fine

[00:46:12.0000] <annevk>
What might also be cool is having a way to refer to Cache API objects from content without having to go through a service worker, but that might be harder for objects that require more than a URL to match on

[00:47:02.0000] <annevk>
Or maybe it could be something like <script src=url from=cache>

[00:48:07.0000] <annevk>
But that's also awfully similar to the static routes stuff so I'll stop brainstorming now :-)

[01:35:12.0000] <JakeA>
annevk: what about allowing URL.createObjectURL to take a response object? It'd need to consume the stream potentially into memory through

[01:36:15.0000] <JakeA>
Hmm, going off that idea already

[01:37:32.0000] <JakeA>
Maybe createCallbackURL(func), which returns a url, and when that url is loaded it calls the callback which returns a promise for a response

[01:38:21.0000] <JakeA>
That callback could be _=> caches.match("/whatever")

[01:39:43.0000] <JakeA>
But you could also create your own stream

[02:24:57.0000] <annevk>
JakeA: either a one-time Response -> URL mapping or supporting Response objects for all possible networking features makes a lot of sense to me

[02:26:12.0000] <annevk>
JakeA: from past experience I'd prefer starting out with <img>.objectSrc = response over <img>.src = createURLFrom(response) given that the latter has all kinds of warts

[02:26:22.0000] <annevk>
JakeA: but the latter is more portable...

[02:28:46.0000] <annevk>
JakeA: and the latter could probably work fine since you just acquire a lock on the stream meaning subsequent use would fail anyway

[02:34:01.0000] <annevk>
I wonder what zewt thinks about introducing URLs for Response objects with the same guarantees as blob URLs (except reuse not being possible at all). I'm kind of warming up to the idea since it would be much simpler to roll out across existing features...

[03:08:25.0000] <annevk>
Ooh exciting, it seems we can let sites control User-Agent soonish :-)

[03:38:01.0000] <annevk>
wanderview: JakeA: Krinkle|detached: I came up with some better terminology for this whole storage thing: https://etherpad.mozilla.org/storage

[03:38:16.0000] <annevk>
wanderview: JakeA: Krinkle|detached: will likely update the wiki later

[03:45:23.0000] <JakeA>
annevk: the benefit of a callback is it'd vend a new response each time, so it can be used more than once. But if that's not useful, it isn't needed

[03:49:33.0000] <annevk>
JakeA: it does seem like it might be more convenient not to have to .then() to get hold of the Response...

[03:50:36.0000] <annevk>
So you get code akin to <img>.src = toURL(fetch(...))

[04:03:11.0000] <annevk>
The only weird thing with that is that you invoke all of Fetch twice, once for the URL inside fetch(), and once for the URL returned by toURL()...

[04:38:11.0000] <MikeSmith>
would be great if somebody could post a status report of some kind for the Service Workers specーwhere things are at, what the major remaining issues are

[04:39:03.0000] <MikeSmith>
the traffic on the SW issues tracker is a lot to try to keep up with, and the volume of open issues is pretty high

[04:45:58.0000] <annevk>
MikeSmith: I think it's mostly just cleaning up

[04:46:24.0000] <annevk>
MikeSmith: we don't have specification blockers for implementing anyway

[04:48:03.0000] <MikeSmith>
annevk: ok

[04:49:09.0000] <MikeSmith>
I'd volunteer to try to write something up myself based on what I've managed to keep up with from the discussions but I don't reckon I'd do a great job of it

[04:49:54.0000] <MikeSmith>
in other news https://github.com/whatwg/fetch/issues/27 is epic

[04:51:03.0000] <MikeSmith>
and I wonder how long that guy will keep on at https://github.com/whatwg/fetch/issues/28

[04:51:25.0000] <annevk>
MikeSmith: so yeah, if you count fetch() as part of service workers I'd mention that as something we need to address

[04:52:15.0000] <annevk>
MikeSmith: but I still think that can be additive, and JakeA and Domenic seem to agree

[04:52:16.0000] <MikeSmith>
annevk: well it seems like the dependency should count

[04:52:21.0000] <MikeSmith>
ok

[04:54:29.0000] <MikeSmith>
on another meta-note I wonder how many people are paying attention to the discussions

[04:55:20.0000] <MikeSmith>
looking at https://github.com/whatwg/fetch/issues/27 I see in all that traffic over the last week or whatever it's been, there's just 14 people who have commented

[04:55:33.0000] <MikeSmith>
or maybe that's relatively a lot of commentors, I dunno

[04:56:48.0000] <MikeSmith>
but even then there's only 32 people watching the fetch repo and reckon quite a few of the people watching don't actually read a lot of the messages

[04:59:11.0000] <MikeSmith>
anyway, that's sorta why I suggested some occasional summaries would be nice to haveーto give others a heads-up about what's being discussed and why they should care

[05:35:20.0000] <annevk>
MikeSmith: there's not a lot of signal in that thread

[05:35:45.0000] <annevk>
MikeSmith: the gist is still that we don't really know how we want to do cancelation

[05:35:55.0000] <MikeSmith>
annevk: OK, it's good to know that at least

[05:36:07.0000] <MikeSmith>
I thought I must be missing something

[05:58:58.0000] <annevk>
MikeSmith: I'm happy to help btw if anything is unclear

[05:59:11.0000] <annevk>
MikeSmith: but afaict some v1 of all these features is being shipped by vendors

[06:00:00.0000] <annevk>
MikeSmith: just a bit unclear how to summarize all the minutiae

[06:01:49.0000] <JakeA>
annevk: MikeSmith: there's been some progress at https://gist.github.com/jakearchibald/9a24f3c06f06b9c06a1e

[06:02:44.0000] <MikeSmith>
annevk: occasional stuff like https://annevankesteren.nl/2015/02/cancelable-promises is nice

[06:02:59.0000] <MikeSmith>
/me looks at https://gist.github.com/jakearchibald/9a24f3c06f06b9c06a1e

[06:03:21.0000] <MikeSmith>
serendipity :-)

[06:04:39.0000] <annevk>
MikeSmith: that's effectively still where we are at :-)

[06:04:43.0000] <MikeSmith>
JakeA: nice

[06:05:03.0000] <annevk>
(at a summary level, anyway, JakeA is making progress)

[06:05:41.0000] <JakeA>
MikeSmith: the bit I'm most worried about is the "gotcha" bit, but maybe Domenic can find something under the hood that makes it not a problem (I couldn't quite get my head around the spec)

[06:05:49.0000] <JakeA>
Next step is to build a prototype

[06:05:54.0000] <MikeSmith>
annevk: yeah https://gist.github.com/jakearchibald/9a24f3c06f06b9c06a1e seems somewhere beyond where it was at at the time you wrote that blog post

[06:06:24.0000] <MikeSmith>
JakeA: you mean the resolved-but-unsettled promises part?

[06:06:31.0000] <JakeA>
yeah

[06:09:02.0000] <MikeSmith>
I see Domenic didn't respond about that part yet

[06:09:19.0000] <MikeSmith>
man this stuff is hairy

[06:09:19.0000] <JakeA>
MikeSmith: I only made those edits a couple of days ago

[06:09:23.0000] <MikeSmith>
ah ok

[07:02:31.0000] <wanderview>
annevk: JakeA: we would have some implementation headaches if we allow "non-standard" schemes in Cache...  gecko's requirement to do full url parsing on the main thread is a major pain

[07:02:39.0000] <wanderview>
I get around that by leaning on the http/https only requirement

[07:03:38.0000] <wanderview>
we only check the request url, though... so a SW could always load from some other URL scheme and then manually cache.put() it in with an http request

[07:12:31.0000] <wanderview>
annevk: JakeA: it seems referring to resources in a Cache directly from static content would need something extra logic to try to fetch if not present in cache...  basically what http cache does today, but it ends up in a named Cache object

[07:21:19.0000] <annevk>
wanderview: yeah, I think that's why I prefer URLs from Response objects and leave that use case to "static routing"

[07:21:39.0000] <annevk>
wanderview: as for non-standard schemes, we could just allow for one to keep things straightforward

[07:21:42.0000] <wanderview>
annevk: I guess I didn't understand the Response URL thing

[07:21:56.0000] <wanderview>
oh, you mean like a URL that says "load this from a Cache"?

[07:24:06.0000] <annevk>
wanderview: a URL that says read this from this Response

[07:24:35.0000] <wanderview>
annevk: oh, so I still have to have js in the loop... I thought you were trying to allow the page to load from Cache without js

[07:25:40.0000] <wanderview>
annevk: but yea, the Response URL could be nice for non-SW stuff... I could see things like firefoxos photo gallery using that, etc

[07:25:50.0000] <wanderview>
although they've implemented it all as blobs in IDB right now

[07:26:05.0000] <Ms2ger>
Fun

[07:26:30.0000] <Ms2ger>
importScripts says "Resolve<#resolve-a-url> each argument."

[07:26:42.0000] <Ms2ger>
#resolve-a-url says "let base be the element's base URL."

[07:27:06.0000] <annevk>
wanderview: yeah the without JavaScript use case is probably best done using static routes for service workers, something we never ended up specifying since we didn't know what the perf hit of service workers was going to be in the first place

[07:29:19.0000] <wanderview>
annevk: it seems now that Cache is on window we don't really need the SW to run in the non-js world...  maybe I don't understand what you mean by "static routes for service workers"

[07:31:31.0000] <annevk>
wanderview: well unless you want to change how you load images (and you might, and for that we have the URL for Response object idea), I'm not sure that Cache available from window will help

[07:31:59.0000] <wanderview>
well... images are a special case it seems

[07:46:33.0000] <annevk>
Ms2ger: file a bug?

[07:46:44.0000] <Ms2ger>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28411

[07:50:14.0000] <MikeSmith>
annevk: gotta appreciate the humor of http://www.w3.org/mid/4q03ia5cpqt5m0q867fffniqd6ma20f7qs⊙hbhd

[07:51:28.0000] <MikeSmith>
or at least I assume he was sorta trying to be humorous there (by not directly pointing out that you were the one he was quoting)

[07:51:43.0000] <annevk>
MikeSmith: I was about to own up to my past mistake for not addressing the problem until I found sicking's reply and remembered that being the reason

[07:52:11.0000] <annevk>
MikeSmith: it was kind of funny I guess, but not super helpful

[07:52:21.0000] <MikeSmith>
yeah saw your reply after that

[07:54:04.0000] <MikeSmith>
yeah, not helpful and not sure he actually meant it to be good-naturedly funny instead of just obnoxious

[07:55:20.0000] <MikeSmith>
anyway, I think I'll take a break for now from pushing my e-mail inbox boulder up the hill, and go to the sento

[08:04:39.0000] <annevk>
nice

[09:56:30.0000] <wanderview>
Domenic: I thought you didn't like magic in your APIs :-)

[10:26:57.0000] <Domenic>
wanderview: not sure what's magical here... a Request/Response can do exactly three things: be written to disk (cache), be written socket (upload), or be read from by script.

[10:27:24.0000] <Domenic>
I guess now we need to figure out what the APIs are for writing to cache and uploading

[10:28:42.0000] <wanderview>
Domenic: I want to understand more why we need to expose the underlying writer for fetch and cache... I mean, are there reasons beyond progress?

[10:28:59.0000] <Domenic>
wanderview: did you see my reply?

[10:29:21.0000] <wanderview>
Domenic: I'm also curious if browsers today report progress for "bytes actually written on tcp connection"...

[10:31:04.0000] <wanderview>
Domenic: implementing that requires a lot more IPC traffic vs just "progress based on stuff read from the buffer"

[10:31:41.0000] <Domenic>
wanderview: maybe I'm too Node-influenced... but there, write(chunk, cb) will only call cb when the OS has accepted the chunk

[10:31:51.0000] <Domenic>
that's important for program guarantees

[10:32:08.0000] <Domenic>
E.g. where you need to re-try from if there's a failure

[10:32:39.0000] <wanderview>
Domenic: I think that is harder to guarantee in multi-process architectures where networking is actually done in a separate process... it also doesn't really make any guarantee about it reaching the server

[10:32:41.0000] <Domenic>
or if you're sending important messages to a server, it helps you maintain invariants

[10:32:48.0000] <terinjokes>
Domenic: well, that still doesn't give complete guarantees that the receiving end got it

[10:32:52.0000] <Domenic>
sure

[10:32:54.0000] <Domenic>
just helps

[10:33:17.0000] <Domenic>
e.g. you would base your UI off of it, but you would still validate on the server

[10:33:35.0000] <wanderview>
Domenic: I guess I'm curious what we do today... I would be surprised if gecko provided this kind of progress now... no idea what chrome does

[10:33:59.0000] <Domenic>
wanderview: yeah, maybe we just say that this is not information we think is important to expose to web platform authors?

[10:34:21.0000] <Domenic>
i mean, not doing it today isn't necessarily an argument against it. but on the other hand i haven't heard people agitating for it.

[10:35:10.0000] <wanderview>
Domenic: I've asked in our network channel... no responses yet

[10:36:30.0000] <Domenic>
Fetch/XHR spec is a bit ambiguous... it says "Whenever one or more bytes are transmitted" ... do a bunch of steps then eventually fire a progress event

[10:37:03.0000] <Domenic>
Not sure if "transmitted" here means "transmitted to the OS" or...

[10:37:26.0000] <caitp->
probably read from socket or sent to socket

[10:37:48.0000] <caitp->
no, sent to socket wouldn't make sense for upload progress

[10:38:45.0000] <wanderview>
/me is annoyed we have two XHR classes.

[10:38:52.0000] <Domenic>
Gecko does?

[10:39:26.0000] <wanderview>
Domenic: yea, one for main thread and one for workers

[10:39:46.0000] <Domenic>
Good times.

[10:40:39.0000] <wanderview>
Domenic: does XHR provide upload progress?  the code I am looking at mainly seems to do download progress

[10:40:53.0000] <wanderview>
oh, nm

[10:40:57.0000] <wanderview>
sorry

[10:43:11.0000] <annevk>
Domenic: Fetch accepts patches

[10:43:39.0000] <wanderview>
Domenic: I stand correct, gecko's XHR reports progress on bytes pushed to the kernel

[10:43:43.0000] <wanderview>
corrected

[10:44:59.0000] <caitp->
it's hard to tell what blink's does without opening an actual text editor, too hard to follow the didSendData() / dataSent() code paths through mxr --- but it's probably sent to kernel

[10:46:07.0000] <wanderview>
its still a bit lame, though, since the kernel is going to buffer all but the largest uploads anyway

[10:47:01.0000] <Domenic>
yeah, but it at least gives you a guarantee the socket is still alive, I assume

[10:47:27.0000] <caitp->
but it's not really "upload progress"

[10:47:59.0000] <wanderview>
its admittedly better than "bytes read in a child process in the browser", though

[10:48:58.0000] <caitp->
well I mean, from a developer pov, you probably expect upload progress to indicate the amount of data the recipient has received so far

[10:49:14.0000] <caitp->
which is harder

[10:49:40.0000] <Domenic>
i dunno, maybe at first, but if you thought about that for a few seconds you'd realize it makes no real sense

[10:49:53.0000] <Domenic>
or does it ... TCP has ACKs...

[10:49:55.0000] <caitp->
it doesn't make any sense

[10:50:26.0000] <Domenic>
/me plans more blog posts, this time on "byte sinks"

[10:51:30.0000] <Domenic>
tangent: do TCP ACKs get exposed in syscalls at all?

[10:51:54.0000] <Domenic>
not that we should try to expose those (at least not in a HTTP API), but now I'm curious

[10:52:10.0000] <wanderview>
Domenic: I think trying to return a promise for every chunk written in a stream is going to be pretty heavyweight from an impl point of view... thinking about what that would mean for my Cache implementation... its not just the cost of a promise... its the promise plus IPC traffic for each chunk... and a lot of added code complexity

[10:52:16.0000] <caitp->
well like

[10:52:35.0000] <caitp->
*looks at libc code :>*

[10:52:56.0000] <wanderview>
Domenic: I think you have to look at the window on the TCP stream

[10:53:30.0000] <Domenic>
wanderview: that's good implementer feedback I guess... although you're already doing that for XHR?

[10:53:53.0000] <wanderview>
Domenic: yes, for XHR... but not for Cache

[10:54:39.0000] <Domenic>
wanderview: i see... so you wouldn't be able to signal completion of a write to the filesystem? I mean libuv definitely does this, although they do use threads instead of processes, it's true.

[10:54:45.0000] <wanderview>
Domenic: on the flip side... being able to see stream progress would help let us resolve a cache.put() when headers are available, but then stream to disk in the background... stream progress could be observed to detect errors in body streaming

[10:55:09.0000] <wanderview>
Domenic: today cache.put() is spec'd not to resolve its Promise until all the bytes are on disk

[10:55:24.0000] <Domenic>
wanderview: honestly as a developer i'd be surprised if cache.put() fulfilled earlier

[10:55:26.0000] <wanderview>
which is a bit of a wart

[10:55:38.0000] <Domenic>
wanderview: I'd definitely want a promise that gets fulfilled only when hte cache successfully has had my thing put in it

[10:56:09.0000] <Domenic>
wanderview: so if you think there's some value in streaming in the background, I'd do something like cache.put() -> { headersDone, allDone } (two promises)

[10:56:45.0000] <wanderview>
Domenic: I think the spec is a bit confusing on this point now... it currently says you can commit to the Cache before the body is complete... but resolves when the body is complete... so some other cache.match() can get the thing you just put in before your first promise resolves... I haven't implemented any of that because it seems not quite right to me

[10:57:05.0000] <Domenic>
("there is no mechanism in Linux to wait for a TCP ACK to be received" http://stackoverflow.com/a/12528808/31910

[10:57:18.0000] <Domenic>
wanderview: I see, yeah...

[10:57:30.0000] <Domenic>
that'd be weird...

[10:57:54.0000] <wanderview>
Domenic: so if we expose some other WritableStream interface on fetch... what does that mean for Request objects with a body buffer?

[10:57:56.0000] <Domenic>
imagine writing half a stream to disk, calling cache.match to get it, then ... reading half the stream? you're now talking to yourself?

[10:58:33.0000] <wanderview>
Domenic: an optimized implementation would stream it off disk as its written to disk... but thats a bit hard I think

[10:58:37.0000] <Domenic>
wanderview: not sure at all... I guess we'd build those on top? So fetch(req) does `req.body.pipeTo(getMeAWritableStreamFor(req.url))`?

[10:59:04.0000] <tyoshino________>
Even TCP ack tells you only that a data has successfully delivered to the destination kernel. It's unknown whether the data has been successfully accepted by the application layer or not without involving app layer ack.

[10:59:11.0000] <Domenic>
wanderview: wait I think what I just wrote is wrong

[10:59:34.0000] <caitp->
tyoshino________, that's fine I think --- but it's a moot point if you have to write your own tcp stack to figure out when you get an ACK

[10:59:54.0000] <Domenic>
ok so the primitive is ... some kind of httpConnection object per request, with httpConnection.ws being something you can call .write() on.

[11:00:30.0000] <Domenic>
so fetch(req) creates a httpConnection for req.url, and does req.body.pipeTo(httpConnection.writable) [changing name to avoid auto-linking in IRCcloud]

[11:00:45.0000] <wanderview>
Domenic: what about a compromise where you can pass a ReadableStream to Request() as the body or provide a bodyFactory function that operates on a WritableStream... by default the WritableStream goes to a pipe... but there is a SetWriterableStream() that can be called to override this... must be set before the body is ever read

[11:01:01.0000] <Domenic>
whereas cache.add(req) creates a fsWriteStream for a "file" whose name is determined by req.url etc., and calls req.body.pipeTo(fsWriteStream)

[11:01:33.0000] <Domenic>
wanderview: that sounds intriguing; what is SetWritableStream? Spec-only operation, or user-exposed?

[11:01:33.0000] <tyoshino________>
right. posix socket API doesnt'

[11:02:09.0000] <Domenic>
tyoshino________: out of curiousity what APIs do we use in Chrome/Blink? POSIX socket ones, or something more sophisticated?

[11:02:16.0000] <wanderview>
Domenic: user exposed so js library consumers can call it... if its never updated then the bodyFactory is triggered on first body access

[11:02:49.0000] <wanderview>
Domenic: would be nice to provide a progress thing for fixed bodies like ArrayBuffers, though

[11:02:54.0000] <Domenic>
wanderview: hmmmmm this might be something we can work out ... we say that fetch(req) calls req.setWritableStream(httpConnection.writable) or something...

[11:03:06.0000] <wanderview>
Domenic: exactly, yes

[11:03:10.0000] <Domenic>
wanderview: sure, can definitely do once we figure out streams

[11:03:30.0000] <tyoshino________>
Domenic: For Linux, yes, read(2)

[11:03:31.0000] <Domenic>
wanderview: I guess the question is then whether we want to spec out httpConnection.writable as something people can access somehow

[11:03:51.0000] <boogyman>
Domenic: i would think that's something for the implementors, not something defined in the spec.

[11:04:00.0000] <Domenic>
boogyman: why?

[11:04:06.0000] <tyoshino________>
ah, sorry. write()

[11:04:21.0000] <wanderview>
Domenic: I don't see how we can do that without tackling the promise extension for fetch or a controller object for fetch... leads us to the abortable fetch thing

[11:04:24.0000] <tyoshino________>
I mean write(2)

[11:04:38.0000] <Domenic>
tyoshino________: any ideas on windows or mac? :P

[11:04:46.0000] <boogyman>
it may be a suggestion, but why should a spec dictate how something is implemented at that level?

[11:04:55.0000] <boogyman>
s/?/.

[11:04:57.0000] <Domenic>
wanderview: hmm don't see how they're related... I mean in theory it could be like a new fetchUpload API.

[11:05:18.0000] <Domenic>
boogyman: sorry, maybe I missed what you were referring to? Are you saying we shouldn't expose a writable stream for HTTP connections?

[11:05:26.0000] <wanderview>
Domenic: oh... i thought we wanted to maintain fetch() as a function... I guess we need to talk to annevk

[11:05:37.0000] <Domenic>
wanderview: well I'm just going crazy here in this channel, who knows

[11:05:53.0000] <wanderview>
Domenic: I can try to sketch out the setWritableStream thing in the issue... I have to head to the airport in a little bit, though

[11:06:00.0000] <Domenic>
wanderview: no problem, I can do it

[11:06:02.0000] <tyoshino________>
Not familiar but quick codesearch tells me that WSASend for Win, and POSIX for Mac

[11:06:22.0000] <Domenic>
wanderview: but the question is where do these writable streams come from, that people (who are not UAs) pass to setWritableStream()

[11:06:31.0000] <Domenic>
tyoshino________: cool, thanks ^_^

[11:06:41.0000] <wanderview>
Domenic: WritableStream has a constructor, no?

[11:06:55.0000] <Domenic>
wanderview: sure. But why can't you get a writable stream for HTTP uploads?

[11:07:04.0000] <Domenic>
wanderview: I mean a direct one, not a pipe

[11:07:06.0000] <wanderview>
Domenic: I still think we want some pipe construct as well that people could use for this

[11:07:13.0000] <boogyman>
Domenic: no, i'm saying that the spec should not dictate how that stream is exposed, just that one is exposed

[11:07:32.0000] <Domenic>
boogyman: oh, sure. not sure what i said that contradicts that.

[11:07:46.0000] <wanderview>
Domenic: I don't understand what a "HTTP uploads" stream would do without the rest of the network stack behind it

[11:08:01.0000] <Domenic>
wanderview: why wouldn't it have the rest of the network stack behind it?

[11:08:09.0000] <boogyman>
Domenic	wanderview: hmmmmm this might be something we can work out ... we say that fetch(req) calls req.setWritableStream(httpConnection.writable) or something...

[11:08:16.0000] <boogyman>
unless i misread

[11:08:32.0000] <wanderview>
Domenic: how do you get a TCP connection without doing a fetch()?

[11:08:35.0000] <Domenic>
boogyman: maybe, don't take the code too literally  I guess

[11:08:49.0000] <Domenic>
wanderview: ah, you wouldn't, you definitely would need some new API that gets a TCP connection

[11:08:56.0000] <Domenic>
wanderview: the trick is this API can't involve Request since Request is too generic

[11:09:18.0000] <boogyman>
okay, that was intended as pseudo-code. carry on.

[11:09:33.0000] <Domenic>
wanderview: strawperson: fetch.upload(url, method, headers) -> Promise<WritableStream>?

[11:09:40.0000] <caitp->
does webrtc use tcp for networking?

[11:09:46.0000] <caitp->
(off-topic, just wondering)

[11:10:10.0000] <Domenic>
caitp-: probably UDP? video/audio is generally cited as something that doesn't need reliabiity and hates latency

[11:10:12.0000] <caitp->
stackoverflow says it can be but doesn't need to be

[11:10:21.0000] <caitp->
yeah, that's why I was wondering

[11:10:44.0000] <wanderview>
Domenic: but not a Request object?

[11:11:25.0000] <Domenic>
wanderview: well Request has the problem that people could put it in a cache or something instead of just writing to it, right? that's how we got started here...

[11:12:11.0000] <wanderview>
Domenic: I thought one of the goals was to provide primitives like Request which could be used throughout many APIs

[11:12:21.0000] <wanderview>
routing around the primitive seems a step backwards

[11:12:26.0000] <Domenic>
wanderview: me too, but it sounds like Request was not primitive enough :(

[11:13:11.0000] <tyoshino>
a queue with readable side and writable side?

[11:13:15.0000] <Domenic>
if it can be read by anyone (cache, author code, etc.), it can't represent the primitive operation of an actual ongoing HTTP request (whose body can only be read by the UA/OS)

[11:14:01.0000] <Domenic>
tyoshino: that doesn't really solve things though. Authors write into the writable side, the UA reads from the readable side, and does ... what? Magic that writes to the TCP socket?

[11:14:13.0000] <Domenic>
tyoshino: I'm trying to say there should be a writable stream authors can get to that represents that TCP socket

[11:15:00.0000] <caitp->
so, fetch() is being used primarily for pretty high-level operations, this isn't something that emscripten would want to use for a pretend posix socket api

[11:15:06.0000] <caitp->
why does it need to be so primitive?

[11:15:13.0000] <caitp->
authors aren't going to want to be writing libc code in js

[11:15:22.0000] <Domenic>
BTW just as a general sentiment check: I am feeling positive and the last 30 minutes have gotten ideas flowing :). If I seem like I'm pushing against things I'm really just trying to explore the spaces and make sure we're doing the right thing.

[11:15:45.0000] <Domenic>
caitp-: fetch was/is supposed to be a low-level primitive

[11:15:54.0000] <Domenic>
caitp-: library authors will in general want control

[11:16:17.0000] <caitp->
i think library authors are generally pretty happy with what XHR gives them

[11:16:23.0000] <Domenic>
O_O

[11:16:35.0000] <wanderview>
Domenic: I think there is an inherent mismatch with your writer-per-active-operation goal and the operation-as-object-concept of Request... let me gist something...

[11:17:03.0000] <Domenic>
wanderview: agree.

[11:20:34.0000] <tyoshino>
hmm, the key point of the discussion is the meaning of write() completion?

[11:21:17.0000] <tyoshino>
sorry. i haven't caught up with the log. I was watching only the issue.

[11:23:26.0000] <wanderview>
Domenic: something like this? https://gist.github.com/wanderview/ac6052184c62d2f165ee

[11:23:37.0000] <wanderview>
maybe lose the bodyAsWriter

[11:24:29.0000] <wanderview>
not sure if consumers of Request should be required to call setWriter or not

[11:25:14.0000] <boogyman>
is req.body.closed  a promise?

[11:25:36.0000] <wanderview>
boogyman: I was thinking it was something that existed as a promise... but I could be wrong

[11:25:46.0000] <tyoshino>
yes, it's a promise

[11:26:00.0000] <tyoshino>
a getter of a promise

[11:26:51.0000] <caitp->
new Request(url, { body (String | Stream | ArrayBuffer | ...) }) --- different behaviour depending on what type Body is

[11:27:05.0000] <caitp->
would make more sense to most people, tbh

[11:27:13.0000] <tyoshino>
though it's gone from body now and lives only on reader

[11:27:57.0000] <wanderview>
caitp-: is that "Stream" a ReadableStream or a WritableStream?

[11:28:05.0000] <caitp->
well it has to be readable

[11:28:08.0000] <Domenic>
wanderview: that looks more or less good, I have some cosmetic comments. But my question is, when fetch calls setWriter, what argument does it use?

[11:28:13.0000] <caitp->
but you probably want it to be writable too

[11:28:47.0000] <wanderview>
caitp-: thats what I want... pass ReadableStream to constructor... but to get the progress semantics Domenic wants and XHR currently provides, we need to allow access to a consumer-specific WritableStream

[11:29:12.0000] <caitp->
I don't think that's really true

[11:29:13.0000] <wanderview>
Domenic: a private implementation of WritableStream

[11:29:20.0000] <Domenic>
wanderview: OK. Why is it private?

[11:29:42.0000] <Domenic>
wanderview: why does only the UA get to create WritableStreams representing sockets?

[11:29:46.0000] <caitp->
you don't really get progress semantics from the number of bytes you've pushed to a writable stream

[11:29:57.0000] <wanderview>
Domenic: because it could be c++ and it will depend on internal implementation details that can't be spec'd?

[11:30:16.0000] <wanderview>
caitp-: Domenic wants the consumer stream to not resolve the write() promises until its pushed to the kernel

[11:30:29.0000] <wanderview>
caitp-: which is why a pipe primitive is not adequate here

[11:30:47.0000] <Domenic>
wanderview: nah :P. its observable behavior should be interoperable. it could be C++ sure, but it could be exposed to JS if we wanted it to.

[11:30:54.0000] <wanderview>
Domenic: because its not safe to expose sockets on the web?  or are we doing the TCP spec now? :-)

[11:30:57.0000] <Domenic>
s/should be/could be specced to be/

[11:31:06.0000] <caitp->
what if --- and hear me out here --- what if pushing to a writable stream was not related to progress at all

[11:31:09.0000] <Domenic>
wanderview: haha, well, http://www.w3.org/2012/sysapps/tcp-udp-sockets/, but leaving that aside

[11:31:21.0000] <wanderview>
Domenic: we have one for firefoxos, too

[11:31:23.0000] <Domenic>
wanderview: it's not a socket though, it's just a writable stream with HTTP semantics

[11:31:25.0000] <caitp->
what if you had some kind of, I don't know, upload event tied to actually pushing the data to the kernel

[11:31:31.0000] <caitp->
sort of like what already exists

[11:31:34.0000] <wanderview>
caitp-: I would be quite happy with a progress notifier separate from the stream

[11:31:47.0000] <Domenic>
wanderview: maybe the API is something like new HttpUploadStream(url, method, headers)

[11:32:26.0000] <Domenic>
caitp-: we probably want that too. but it should be explicable in terms of the stream primitive. i.e., when you drop down to the stream level, you shouldn't lose power. we should layer things appropriately.

[11:32:27.0000] <wanderview>
Domenic: what does it do if you don't attach it to a fetch() call?

[11:32:51.0000] <caitp->
what is the thing gained from explaining it in terms of the stream, other than making the stream interface more complicated?

[11:33:02.0000] <Domenic>
wanderview: just waving my hands here, but you don't need to fetch() a HttpUploadStream. fetch() is explained in terms of HttpUploadStream, not the other way around.

[11:34:11.0000] <Domenic>
wanderview: similar to how, say, cache.add could be explained in terms of a WritableFileStream or maybe WritableDatabaseEntryStream

[11:35:46.0000] <wanderview>
Domenic: so you are talking about blowing up all the stuff coming from ServiceWorker effort and replacing it with a streams foundation, no?  this seems like a huge undertaking

[11:36:06.0000] <Domenic>
wanderview: it's fine if HttpUploadStream is private for now. Maybe it stays private forever. But I want us to kind of acknowledge that our mental model includes more capabilities for the UA than the script, and then question whether we expose them

[11:36:11.0000] <wanderview>
and in theory these specs tried to accomodate streams being added

[11:36:20.0000] <tyoshino>
operation stream is one possible solution. it can propagate written-to-kernel event.

[11:36:37.0000] <Domenic>
wanderview: no, not at all! I'm saying that we're continuing to do archeology, and we have to ask at each layer whether we've gotten to the bedrock or not

[11:37:08.0000] <wanderview>
Domenic: I have to admit I actually said "dear god no" when I read "WritableDatabaseEntryStream" :-)

[11:37:16.0000] <Domenic>
wanderview: what we're discovering is that the SW APIs are not bedrockey---Request/Response especially, since they abstract multiple things: writing to a cache, uploading, and being able to be read from user code

[11:37:33.0000] <wanderview>
Domenic: doing this kind of thing adds a lot of complexity and constrain on the implementation... I would want to see huge benefits before agreeing to that

[11:37:35.0000] <Domenic>
wanderview: hmmmm but don't you want the ability to do streaming writes to IndexedDB at some point in the future?

[11:37:53.0000] <caitp->
> IndexedDB

[11:38:11.0000] <Domenic>
wanderview: that makes sense, it's a reasonable argument for keeping HttpUploadStream private for now until someone clamors for it.

[11:38:31.0000] <Domenic>
wanderview: although I'd be curious how much extra work/constraints it adds to wrap up the code you were going to use anyway into a writable stream.

[11:38:37.0000] <wanderview>
Domenic: solve abortable fetch and promise extension first?  because what you really are asking for is rich promises of future behavior... say activities or maybes tasks...

[11:38:40.0000] <wanderview>
/me ducks

[11:38:54.0000] <Domenic>
wanderview: totally fair to solve those first :)

[11:39:07.0000] <Domenic>
wanderview: I am reasonably happy with this mental model at least

[11:39:24.0000] <wanderview>
Domenic: the problem is when the spec assumes a particular implementation that cannot be easily mapped to all vendors

[11:39:27.0000] <Domenic>
wanderview: as long as we are OK with authors not getting good progress event semantics out of the pipe model that we'd start with

[11:39:44.0000] <wanderview>
going to low risks making things "assuming its implemented like chrome, then its easy...", etc

[11:40:02.0000] <Domenic>
wanderview: well it probably helps that I don't know too much about Chrome's implementation and make unreasonable demands of everyone :)

[11:40:40.0000] <wanderview>
Domenic: and I do think we want streams to IDB... but I don't know we need an abstract "DatabaseEntry" interface to do that

[11:40:52.0000] <caitp->
what are the use cases that Fetch (the api, not the XHR backend) has to accomodate?

[11:41:04.0000] <caitp->
is there like an explicit set of requirements that have been figured out?

[11:41:13.0000] <Domenic>
wanderview: haha OK (re IDB)

[11:41:16.0000] <wanderview>
caitp-: probably a question for annevk

[11:42:21.0000] <caitp->
i'm curious where streams need to fit into it at all, since the only thing I can think of would be uploading something that was already cached, or downloading something and using the body stream as an upload to something else

[11:42:44.0000] <jsbell_gardener>
/me tunes into the IDB discussion...

[11:43:46.0000] <Domenic>
caitp-: did you see https://github.com/domenic/streams-demo ? that's another use case that was impossible with XHR/non-streaming approaches

[11:43:58.0000] <Domenic>
caitp-: https://domenic.github.io/streams-demo/ is nicer

[11:45:13.0000] <wanderview>
Domenic: do you anticipate adding a pipe construct to the streams spec?  by which I mean an object type that provides ReadableStream, WritableStream, and a (possibly fixed) buffer

[11:45:18.0000] <annevk>
caitp-: do you agree that we need to expose streams?

[11:45:34.0000] <annevk>
Domenic: I'd like to avoid fetchUpload(), that sounds rather terrible

[11:45:40.0000] <caitp->
I think it would be nice to have, buuuut

[11:45:42.0000] <Domenic>
wanderview: yes, definitely. Although I'd probably call it "Identity Transform Stream"

[11:45:49.0000] <caitp->
i'm not totally convinced by the use cases

[11:46:02.0000] <wanderview>
Domenic: I can't tell if you are just messing with me now :-)

[11:46:27.0000] <wanderview>
but I shall not object over names :-)

[11:46:33.0000] <Domenic>
wanderview: no, I'm not, I promise! We even have a prototype (which suffers from a number of issues related to nobody giving it any love in a while): https://github.com/whatwg/streams/blob/master/reference-implementation/lib/transform-stream.js

[11:46:36.0000] <caitp->
if it's not something that authors are asking for, why make an api complicated just to accomodate it?

[11:46:45.0000] <caitp->
simpler is better :>

[11:46:52.0000] <annevk>
caitp-: developers have been asking for streams for ages

[11:47:00.0000] <caitp->
to accomodate what, though

[11:47:02.0000] <Domenic>
caitp-: did you not see the huge twitter blow-up about devs asking for streams just two weeks ago?

[11:47:14.0000] <annevk>
caitp-: we've wanted to add this to XMLHttpRequest since 2008 or so

[11:47:59.0000] <caitp->
what I'm asking is, what problem is it actually solving for them, and could that problem be solved in a nicer way

[11:48:15.0000] <wanderview>
Domenic: ok... so like node's Transform

[11:48:33.0000] <annevk>
caitp-: the ability to process data in chunks rather than having it all buffered or written to disk

[11:48:39.0000] <Domenic>
wanderview: yes, but without the silly squash-everything-into-one-object issue

[11:49:24.0000] <Domenic>
/me shudders ... node transform streams prototypally inherit from readable stream, then copy over all the writable stream methods and private state, and then they get confused because e.g. an "error" event can come from either side...

[11:51:09.0000] <caitp->
annevk I'm primarily talking about the upload stream though

[11:51:57.0000] <wanderview>
Domenic: I guess I worry that progress via WritableStream makes it kind of hard for people to get progress... I mean... it seems like there should be an easier way if you wouldn't have been going the WritableStream route to begin with

[11:53:42.0000] <annevk>
caitp-: if you want a simple one-way channel that seems ideal

[11:53:53.0000] <wanderview>
Domenic: maybe there could be a request.bodyWritten promise which is the value returned from ws.write(body).... or could we set it as the value of body.pipeTo(ws)? does that promise reflect actual written status?

[11:54:38.0000] <Domenic>
wanderview: I agree we should add an easy progress API on top. Is that related to the request.bodyWritten promise?

[11:54:38.0000] <wanderview>
/me starts packing up to go to the airport.

[11:55:08.0000] <wanderview>
Domenic: yea... I meant a simple promise they could resolve when the bytes from a fixed or ReadableStream body have been written to the consumer-specific WritableStream

[11:55:26.0000] <wanderview>
or that WritableStream resolves and says the bytes are at the kernel, I mean

[11:55:27.0000] <Domenic>
body.pipeTo(ws) ... currently that will fulfill early if ws buffers some writes ... that seems wrong though, we should fix that to fulfill only after all writes and the close complete. Or maybe it already does and I'm confused.

[11:55:54.0000] <wanderview>
Domenic: it seems the WritableStream implementation could make that determination by setting its internal buffer to "zero" effectively?

[11:55:57.0000] <Domenic>
wanderview: I don't know if that's as useful as just progress events or similar on the Request object...

[11:56:01.0000] <wanderview>
or just lying

[11:56:07.0000] <wanderview>
Domenic: ok

[11:56:08.0000] <Domenic>
wanderview: yeah I think so.

[11:56:36.0000] <wanderview>
Domenic: ok, I'll stop pestering you with this stuff now :-) later

[11:57:15.0000] <annevk>
Domenic: not sure how much wiggle room there still is, but if we need to redesign certain pieces it'd be good to raise an issue on them

[12:00:37.0000] <Domenic>
wanderview: no problem! this was pretty great I think. Have a good flight!

[12:00:59.0000] <Domenic>
annevk: yeah... I think the setWritable idea is pretty reasonable now that I keep turning it over in my head. I tried to outline it more in the issue.

[12:01:33.0000] <tyoshino>
Domenic: pipeTo() promise fulfills once the source is done and dest.ready fulfills

[12:01:42.0000] <tyoshino>
currently.

[12:01:51.0000] <Domenic>
tyoshino: that seems bad, hmm, we should wait for dest.closed I think

[12:02:31.0000] <Domenic>
on the other hand it has the flavor of something i already thought about and put the current behavior in for a good reason... darn past-Domenic.

[12:02:34.0000] <annevk>
Domenic: looks reasonable

[12:02:42.0000] <Domenic>
annevk: \o/

[12:02:59.0000] <annevk>
Domenic: though I also got excited by the redesign everything ideas :p

[12:03:48.0000] <Domenic>
hahaha

[12:06:15.0000] <wanderview>
annevk: I'm leaving... but it occurs to me... will the fetch() sanitize step play havoc with this setWriter() plan?  since fetch is operating on a copy of the request?

[12:07:49.0000] <tyoshino>
Domenic: Yes. It was discussed in past at https://github.com/whatwg/streams/issues/236#issue-46428456

[12:08:11.0000] <annevk>
wanderview: no, the stream is carefully moved

[12:08:20.0000] <wanderview>
cool

[12:08:22.0000] <wanderview>
ok, nye

[12:08:23.0000] <wanderview>
bye

[12:08:25.0000] <annevk>
wanderview: sort of akin to Domenic's design

[12:08:30.0000] <annevk>
wanderview: safe travels

[12:08:57.0000] <Domenic>
annevk: wanderview should get most of the credit for that design (if you're referring to the one I just left a comment about on GitHub)

[12:11:45.0000] <Domenic>
tyoshino: it seems like where we ended up in that thread was that it should wait for the write (and close?) to complete, but we forgot to implement that

[12:12:19.0000] <Domenic>
tyoshino: no, wait, we did implement it. dest.close().then(resolvePipeToPromise, rejectPipeToPromise)

[12:12:56.0000] <tyoshino>
ah. preventClose == false

[12:13:32.0000] <Domenic>
right, I see. In the preventClose === true case our semantics are perhaps unexpected

[12:13:39.0000] <Domenic>
I will open an issue

[12:15:37.0000] <tyoshino>
Domenic: BTW, I'd like to get your comment on what I was suggesting.

[12:15:53.0000] <Domenic>
tyoshino: operationstream as a solution, you mean?

[12:15:57.0000] <tyoshino>
Yes

[12:16:15.0000] <tyoshino>
It was basically

[12:16:20.0000] <tyoshino>
sorry I was unclear

[12:16:23.0000] <tyoshino>
but it's

[12:16:48.0000] <tyoshino>
Request/Response has an extended ReadableStream side (possible hidden)

[12:17:15.0000] <tyoshino>
fetch(), cache.put(), etc. pipes the extended ReadableStream and WritableStream (CacheWritableStream, etc.)

[12:17:37.0000] <tyoshino>
CacheWritableStream (possibly hidden or public)

[12:18:22.0000] <tyoshino>
The extended ReadableStream can propagate completion of consumption to the Readable side of Request/Response

[12:18:48.0000] <tyoshino>
e.g. written to the kernel, that is represented by write() completion of CacheWritableStream, HttpUploadWritableStream

[12:19:46.0000] <Domenic>
right ... I guess I am still cautious about conflating enqueuing into a readable stream's with writing to a writable stream, and thus indirectly to an underlying sink.

[12:19:58.0000] <Domenic>
also, i can't imagine a non-awkward API for acknowledging reads

[12:20:25.0000] <tyoshino>
I'm concerned, if

[12:20:33.0000] <tyoshino>
We want to build longer chain

[12:21:43.0000] <tyoshino>
if the idea of setWriter that is kinda propagating the sink itself to left

[12:21:52.0000] <tyoshino>
is better or not

[12:22:36.0000] <Domenic>
"propagating the sink itself to left"?

[12:22:44.0000] <tyoshino>
Hmm. I don't know if we really want to create such a longer chain

[12:23:10.0000] <tyoshino>
left of the chain

[12:23:12.0000] <tyoshino>
a -> b -> c

[12:24:07.0000] <Domenic>
still a bit confused ... let's say I have res1.body -> transform1 -> transform2 -> res2.bodyWriter (a HttpUploadStream). What are you worried about?

[12:24:17.0000] <tyoshino>
setWriter is kinda collapsing Request and fetch(). right?

[12:24:51.0000] <Domenic>
It's saying "this Request now represents a fetch, not a cache write or anything else", is how I think of it.

[12:26:54.0000] <tyoshino>
In that chain, can res1.body know when a chunk it generated has been successfully uploaded?

[12:27:03.0000] <annevk>
Does it need to be this Request or can it be that the stream is now associated with a fetch?

[12:27:29.0000] <annevk>
Because it's more like we discard the Request and use its stream...

[12:28:09.0000] <Domenic>
annevk: well wanderview's gist makes it so you keep using the Request object ... do you think that's unworkable?

[12:28:33.0000] <Domenic>
wanderview: currently no ... pipe discards write() return values and only reacts to errors and backpressure

[12:28:42.0000] <Domenic>
sorry, s/wanderview/tyoshino/

[12:29:28.0000] <tyoshino>
Domenic: Right. And my understanding is the goal of that is making the promise returned by write() to represent commit to file, DB, network, etc.?

[12:29:34.0000] <Domenic>
tyoshino: yeah

[12:29:41.0000] <annevk>
Domenic: not sure

[12:29:57.0000] <annevk>
Domenic: see step 2 of https://fetch.spec.whatwg.org/#dom-global-fetch

[12:30:26.0000] <Domenic>
annevk: hmm I see

[12:31:14.0000] <Domenic>
annevk: I would imagine it could be made to work. But the question is, what do we want developers to be doing. We could also do const upload = fetch(request); upload.bodyWriter.write() with a promise subclass, I guess.

[12:31:35.0000] <tyoshino>
OK. So, we can know at each point of the chain that the right half of the chain has finished consumption via write() promise

[12:32:17.0000] <Domenic>
tyoshino: we could, yeah, although we currently don't, hmm.

[12:32:34.0000] <Domenic>
tyoshino: the complicating factor here is that we generally anticipate some queues being introduced in each intermediate step

[12:32:51.0000] <tyoshino>
i'm basically trying investigate if this appraoch works well with BYOB streaming

[12:32:59.0000] <Domenic>
Ah, good question

[12:33:26.0000] <annevk>
Domenic: I think for developers the easiest would be to pass a writable to Request or fetch() and have that just work

[12:33:38.0000] <tyoshino>
maybe i'm too pessimistic

[12:33:40.0000] <annevk>
Domenic: regardless of who reads

[12:33:42.0000] <tyoshino>
but to make sure...

[12:34:03.0000] <Domenic>
annevk: how do they create the writable? they can't create HttpUploadStreams...

[12:34:13.0000] <tyoshino>
maybe in general transformation consumes data and generate something new to the left

[12:34:17.0000] <tyoshino>
s/left/right/

[12:34:57.0000] <annevk>
Domenic: body: ws => ... or some such?

[12:35:24.0000] <annevk>
Domenic: the moment you start the operation the callback gets invoked and hands you a writeable

[12:35:44.0000] <Domenic>
annevk: right, that was where we started, but wanderview didn't like it :)

[12:36:00.0000] <tyoshino>
so, for most of transform, whether transformX has consumed the ArrayBufferView passed to transformX is meaningful

[12:36:05.0000] <annevk>
Domenic: this would either be for req = new Req(..., body ...); req.body.getReader(); or when you pass to fetch(), or when you pass to cache

[12:36:05.0000] <tyoshino>
transformX -> transformY

[12:36:11.0000] <annevk>
Domenic: I see

[12:36:14.0000] <Domenic>
tyoshino: that sounds right to me.

[12:36:44.0000] <annevk>
Domenic: well the alternative is to pipe it to HttpUploadStream

[12:36:47.0000] <tyoshino>
ok. then, I think the concern I had only applies to a simple queue.

[12:37:00.0000] <annevk>
Domenic: and maybe the UA can do magic to make the piping disappear

[12:37:42.0000] <Domenic>
annevk: the main arguments against it were in response to https://github.com/yutakahirano/fetch-with-streams/issues/30#issuecomment-90151618 but yeah agreed on pipe to HttpUploadStream

[12:38:49.0000] <annevk>
Domenic: thanks for the pointer, I guess I should talk to wanderview about my concerns

[12:38:59.0000] <annevk>
Domenic: and maybe he can do something even cleverer

[12:39:22.0000] <tyoshino>
You said we may add an identity transform to address wanderview's needs. We might need to give the identity transform ability to propagate consumption completion signal when we designing BYOB ecosystem.

[12:39:29.0000] <tyoshino>
Not sure now...

[12:40:32.0000] <Domenic>
tyoshino: that's a good test case, very interesting. Existing transform has I believe (enqueue, done, close, error) or something, although that could become promise-returning (enqueue, close, error). Maybe the done() signal is enough to say it's consumed? But, would be worth exploring more.

[12:40:56.0000] <annevk>
tyoshino: are trailers high-priority? I guess we want to do them after streams?

[12:41:03.0000] <tyoshino>
yeah. let's at least investigate

[12:41:12.0000] <tyoshino>
annevk: yeah

[12:41:42.0000] <tyoshino>
annevk: i was requested to bring it up to the standardization body

[12:42:25.0000] <tyoshino>
louiscryan who's on the issue is actual gRPC developer

[12:43:47.0000] <tyoshino>
I don't know exact timeframe yet. But I just thought it's better to think of interference with streams, etc. earlier.

[12:44:00.0000] <annevk>
tyoshino: sgtm

[12:44:02.0000] <tyoshino>
Actual spec-cing may be not so urgent

[12:44:14.0000] <annevk>
tyoshino: also, any thoughts on the HTTP proxy authentication thing from https://github.com/slightlyoff/ServiceWorker/issues/533 ?

[12:44:51.0000] <annevk>
tyoshino: there's a feature to prevent redirects, but HTTP proxy authentication could still require the entire upload stream to be teed

[12:45:26.0000] <annevk>
tyoshino: and while we could indeed invent another server protocol to do some damage control, that hardly seems elegant

[12:46:11.0000] <tyoshino>
nothing new than what i said in the comment so far. i need to learn more about difficulties you described in your comment

[12:46:34.0000] <tyoshino>
yeah

[12:47:03.0000] <annevk>
so basically before Fetch hits the network the request body is teed

[12:47:10.0000] <tyoshino>
i'd basically like to avoid involvement by protocol layer

[12:47:14.0000] <annevk>
this is done for 1) redirects 2) HTTP auth 3) HTTP proxy auth

[12:47:54.0000] <annevk>
automatic HTTP auth is disabled by fetch() so 2 is not relevant, 1 can be disabled using { redirect: "error" }

[12:47:59.0000] <annevk>
leaves 3 :-(

[12:49:03.0000] <tyoshino>
ya...

[12:49:48.0000] <annevk>
if you find anyone within Chrome happy to discuss HTTP proxy auth please send them my way :-)

[12:50:51.0000] <tyoshino>
ok. i'll chime someone

[12:52:05.0000] <tyoshino>
going to bed. ttyl :)

[12:52:42.0000] <annevk>
same here, hope you're not in Tokyo atm :p

[12:57:19.0000] <neonstalwart>
@Domenic - fyi, you may have rushed your description for https://github.com/whatwg/streams/issues/314.  check preventClose: false vs preventClose: true

[13:02:27.0000] <Domenic>
neonstalwart: thanks, fixed!

[13:24:07.0000] <wanderview>
annevk: yes, the fact that fetch throws away the Request was what concerned me...  I think its somewhat mitigated in that you cannot reuse a drained Request

[13:24:20.0000] <wanderview>
but we've been trying to avoid consumer state on the Request

[13:25:51.0000] <wanderview>
annevk: Domenic: I'm ok with new Request(url, { body: ws => blah }) if there is still an option to pass a ReadableStream in the constructor... it would just have to get progress through an alternate path, which I think Domenic said he was ok with...  The WritableStream approach is really only necessary if you need to know when the bytes are written to the

[13:25:51.0000] <wanderview>
kernel

[13:26:41.0000] <Domenic>
(or when you're working with an abstraction or library that expects data sinks to be represented as writable streams!)

[13:26:49.0000] <wanderview>
yes

[13:27:28.0000] <Domenic>
And yeah, I think response.addEventListener("progress", ...), if nothing else, is totally fine to build on top of streams once we know those semantics.

[13:27:56.0000] <Domenic>
oh in this case it would be request though, which brings us back to the is-request-heavy-or-light question

[13:28:29.0000] <wanderview>
Domenic: I think you would have to do fetch(request, {progress: handler});  not sure what annevk feels about that

[13:30:51.0000] <wanderview>
which I like... because I don't want to bite off providing progress from Cache right now

[13:31:49.0000] <wanderview>
Domenic: what happens if someone does var r = new Request(url, { body: ws => blah); r.body.getReader().read()?

[13:32:03.0000] <wanderview>
does it invoke the body function with a pipe just in time?

[13:32:08.0000] <wanderview>
on first getReader()

[13:34:05.0000] <Domenic>
wanderview: my thought was the body() function is always immediately called. Then ws routes to several different possible destinations: r.body, upload, cache, ... per my code sample, which you (rightly) pointed out was not extensible.

[13:34:51.0000] <wanderview>
Domenic: I think you have to wait until a consumer sets the stream... possibly stealing the body at the same time

[13:35:08.0000] <wanderview>
Domenic: maybe setting the stream should be definition mark the bodyUsed flag on the Request

[13:35:15.0000] <wanderview>
actually, it definitely should

[13:35:55.0000] <Domenic>
sets the stream, as in, setWriter? So we are doing a synthesis of setWriter and body: ws => blah?

[13:36:25.0000] <wanderview>
Domenic: I think you can't set the writer until the Request is passed to a consumer... so I don't know how to do it immediately at construction time

[13:36:59.0000] <Domenic>
wanderview: agreed, i was confused and thought going back to body: ws => blah meant going back to my code sketch

[13:37:03.0000] <wanderview>
Domenic: body: ws => blah is essentially a "start pushing the body" function... we don't want to push the body until it has somewhere to go

[13:37:42.0000] <Domenic>
going to have to think about how to implement that then if we want getReader() to be the trigger...

[13:38:32.0000] <wanderview>
Domenic: well... set the writer stream could also trigger the push immediately at that point without getReader()... the .body stream should probably be considered locked at that point

[13:38:59.0000] <wanderview>
because you don't really have a ReadableStream at all

[13:39:29.0000] <wanderview>
I only want to auto-create a pipe if someone is using the body: ws => blah form... but then someone tries to use getReader() instead of setting a writer

[13:39:51.0000] <wanderview>
/me thinks we need a better name than body: ws => blah

[13:39:54.0000] <Domenic>
right, I agree setWriter is a good trigger, but unsure about how to trigger given r.body.getReader()

[13:39:56.0000] <Domenic>
heh

[13:40:04.0000] <Domenic>
ws-revealer?

[13:40:09.0000] <wanderview>
Domenic: body getter?

[13:40:15.0000] <wanderview>
trigger on body getter

[13:40:22.0000] <Domenic>
yeah maybe

[13:40:33.0000] <wanderview>
could play havoc with dev tools, though

[13:40:49.0000] <Domenic>
yeah getters with side effects seems like it would be nice to avoid if possible

[13:41:03.0000] <Domenic>
getReader() seems like the right place for this, just need to make it work in the spec, but that's on me

[13:41:43.0000] <wanderview>
/me will accept ws-revealer although he was angling for the "the blah function".

[13:42:12.0000] <Domenic>
/me the revealer function?

[13:42:36.0000] <wanderview>
ws-revealer works for me

[13:42:46.0000] <Domenic>
Pretty clear instance of http://domenic.me/2014/02/13/the-revealing-constructor-pattern/ is the only reason I keep saying "revealer"

[13:43:12.0000] <Domenic>
Hmm I dislike how Firefox awesomebar keeps old URLs around even though they have redirects that I've visited

[13:43:17.0000] <Domenic>
(should be https://blog.domenic.me/the-revealing-constructor-pattern/ )

[13:44:56.0000] <wanderview>
Domenic: https://bugzilla.mozilla.org/show_bug.cgi?id=922514

[13:45:08.0000] <wanderview>
Domenic: but this unfortunately was marked WONTFIX https://bugzilla.mozilla.org/show_bug.cgi?id=426142

[13:45:22.0000] <Domenic>
wowww it's funny to be reminded that bugzilla has bugs about the actual browser i use not just the web platform :P

[13:45:56.0000] <Domenic>
oooh yeah that latter also sucks

[13:46:41.0000] <wanderview>
Domenic: I guess they don't want to break muscle memory because the site moved the page

[13:47:14.0000] <Domenic>
right. i guess what i find annoying is when both the old and new URLs show up in the search

[13:47:36.0000] <wanderview>
/me boggles as the boarding line form 15 minutes before boarding.

[13:48:02.0000] <wanderview>
Domenic: mostly i just want it to read my mind

[13:48:34.0000] <Domenic>
wanderview: it basically does. it's mind-boggling how often one character is enough for it to go on. soooo much better than chrome.

[13:49:05.0000] <Domenic>
I can't type "streams-demo" into my chrome location bar and get anything, despite visiting that page all the time. "streams d" gets it in Firefox.

[13:49:19.0000] <wanderview>
Domenic: in the Identity Transform stream... can we make a null transform function mean "make a buffered pipe"?

[13:49:43.0000] <Domenic>
wanderview: I think that's the idea, yeah.

[13:49:47.0000] <wanderview>
I'm glad I finally have it trained so "streams" goes to the spec

[13:49:58.0000] <wanderview>
Domenic: in the thing you linked it throws in that case right now

[13:50:25.0000] <Domenic>
wanderview: yeah, as i said, suffering from a lack of love. (Although I do always fix its tests when they break!) Also unsure whether `new TransformStream()` is good or we should do `TransformStream.identity()` or something

[13:51:29.0000] <wanderview>
Domenic: I commented in #20


2015-04-07
[19:02:04.0000] <zewt>
oh jesus

[19:02:12.0000] <zewt>
now nvidia's page is doing clipboard hijacking

[19:02:38.0000] <zewt>
browsers just need to drop copy events and mask copies from pages, it's too abused

[23:09:36.0000] <annevk>
wanderview: reopened that bug

[23:10:49.0000] <annevk>
wanderview: "st" goes to the spec here, Hixie's idea of subdomains for everything works kind of awesome in that respect

[23:47:50.0000] <zcorpan>
flash update is downloaded from fpdownload.macromedia.com ... :-)

[00:26:33.0000] <annevk>
zewt: not providing pages those tools will have them insist on keeping Flash around :-(

[02:53:53.0000] <annevk>
wanderview: put the revised version up on https://wiki.whatwg.org/wiki/Storage and included some examples of how it can be used with IDB and Cache

[04:09:56.0000] <annevk>
Clearly I still fail at GitHub. I downloaded xml5_draft with the GitHub client and created a branch I intended to use for a pull request (also available as option in the client these days), but now it claims I have no permission... I'm guessing that means I didn't actually have permission to create the branch, but the pull request should work I think... At least, the repository seems to allow them.

[04:10:54.0000] <jgraham>
If you don't have permission to access the upstream you have to create a branch in your fork and make the PR from that

[04:13:06.0000] <annevk>
But would the PR button then create a PR on my fork or the original one?

[04:13:35.0000] <annevk>
The UI could do all that for me though if it knows I don't have permission... But I guess we're not quite there yet.

[04:14:45.0000] <jgraham>
Against the original one

[04:15:22.0000] <zcorpan>
trying to spec a DOMMatrixInit where you can use either .a or .m11 but throw if they are both present with different values, becomes a bit messy. maybe i should only support .m11 for the dictionary?

[04:16:18.0000] <zcorpan>
https://gist.github.com/anonymous/a8931b3ebac8a418ca23

[04:17:33.0000] <zcorpan>
to fix https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0119.html

[04:21:50.0000] <annevk>
zcorpan: that email talks about exposing a-f and m11-m44, but more interesting is what internal slots it has I think

[04:22:24.0000] <annevk>
zcorpan: but I guess you might still want to initialize from a-f since it's more convenient

[04:22:34.0000] <zcorpan>
annevk: internal slots is m11-m44

[04:22:53.0000] <zcorpan>
annevk: yeah, that my thinking too

[04:23:07.0000] <zcorpan>
just needs more work for the impl

[04:23:46.0000] <annevk>
zcorpan: https://dom.spec.whatwg.org/#dom-mutationobserver-observe does a bunch of defaulting and throwing as well...

[04:24:08.0000] <annevk>
zcorpan: initialization of an object is not where impl cost is though

[04:24:21.0000] <annevk>
zcorpan: it's somewhat meticulous work, but not exactly hard

[04:24:31.0000] <zcorpan>
annevk: thx

[06:15:44.0000] <zewt>
annevk: and i flashblock by default ... not sure i buy the logic that we should give sites the tools to be obnoxious so they use our thing to be obnoxious instead of flash, heh

[06:17:35.0000] <annevk>
zewt: a lot of the sites that use it do it because users actually want that functionality as I understand it

[06:17:49.0000] <annevk>
zewt: I agree that UAs should offer the ability to block clipboard access

[06:18:24.0000] <zewt>
if I select text and copy it, it should copy what i told it to and not add freaking ads to the end

[06:19:16.0000] <zewt>
even browser vendors don't always seem to understand that (address bar copying in firefox is a nightmare)

[06:19:39.0000] <annevk>
No disagreement there. I'm thinking about YouTube click-to-copy a link, and similar features elsewhere

[06:20:37.0000] <zewt>
the main annoying case is that pages can intercept when I copy selected text

[06:22:19.0000] <zewt>
(which I know is hard to completely prevent, but it's been made easier rather than harder lately iirc)

[06:22:57.0000] <annevk>
I think Firefox offers options to disable that kind of prevention entirely

[06:24:00.0000] <zewt>
i see dom.event.clipboardevents.enabled, but that seems like too big of a hammer

[06:42:40.0000] <annevk>
SimonSapin: what does https://github.com/servo/rust-url/blob/master/src/format.rs#L65 mean?

[06:43:41.0000] <SimonSapin>
annevk: it’s https://url.spec.whatwg.org/#url-serializing with the "exclude fragment flag"

[06:44:07.0000] <annevk>
SimonSapin: ah okay

[06:44:30.0000] <annevk>
SimonSapin: I thought it was talking about URLs which can't have a fragment

[06:44:36.0000] <annevk>
(which don't exist)

[06:44:52.0000] <SimonSapin>
ok

[06:47:18.0000] <annevk>
SimonSapin: if a Rust function lacks an explicit return, is the last line returned?

[06:47:40.0000] <annevk>
SimonSapin: well, last expression looks like

[06:47:42.0000] <SimonSapin>
the last expression, if it doesn’t end with ;

[06:47:59.0000] <SimonSapin>
`if` and `match` are expressions

[06:48:38.0000] <annevk>
Because if it ends with ; I guess the last expression is empty?

[06:48:47.0000] <SimonSapin>
right

[06:49:05.0000] <SimonSapin>
; can be viewed as a separator rather than a terminator

[06:49:25.0000] <annevk>
I'm trying to figure out how to best approach this parser rewrite in a way that also allows me to tackle the issue of handling URLs such as test://relative/something better...

[06:49:25.0000] <SimonSapin>
and the empty expression has type (), the empty tuple aka unit type

[06:49:48.0000] <annevk>
But perhaps rewriting it as functional first and then tackling that would be better

[06:50:00.0000] <SimonSapin>
annevk: that sounds mostly orthogonal

[06:50:35.0000] <SimonSapin>
as in, test://relative/something involves figuring out the data model, independently of the algorithm style

[06:50:36.0000] <annevk>
SimonSapin: maybe, would be nice to have all the facts upfront :-)

[06:51:29.0000] <SimonSapin>
changing fewer things at a time may also be easier both to do and to review

[06:53:09.0000] <annevk>
Yeah, that's certainly true

[06:59:04.0000] <annevk>
SimonSapin: such an interop drama that data model

[06:59:26.0000] <annevk>
SimonSapin: Chrome does resolve x against test://test/test "correctly", but reports a pathname of "//test/x"

[07:00:15.0000] <annevk>
Safari splits it out in host and path

[08:45:39.0000] <wanderview>
annevk: should we maintain the "simple v1" option next to this more complex option?

[08:46:02.0000] <annevk>
wanderview: v1 would be to do less, but nothing that is incompatible I guess

[08:46:22.0000] <annevk>
wanderview: afaict we can ship most of the methods independently

[08:46:53.0000] <wanderview>
annevk: hmm... ok... I guess I just don't want the simple proposal to get caught up in bikeshedding the bigger proposal

[08:47:46.0000] <annevk>
wanderview: what would you consider a reasonable v1? I could add a "Rollout" section that discusses this

[08:47:57.0000] <annevk>
wanderview: v1: these methods; v2: the rest

[08:48:14.0000] <annevk>
wanderview: or do you think we need to present it differently?

[08:48:28.0000] <wanderview>
annevk: I think that would be reasonable... what you had for v1 before?

[08:48:54.0000] <annevk>
wanderview: so everything but boxes?

[08:49:47.0000] <wanderview>
annevk: yea, I think so

[08:53:38.0000] <annevk>
wanderview: https://wiki.whatwg.org/wiki/Storage#Rollout

[10:04:40.0000] <wanderview>
Domenic: annevk: does this address the concerns from yesterday? https://github.com/yutakahirano/fetch-with-streams/issues/30#issuecomment-90647469

[10:05:42.0000] <wanderview>
I think it effectively lets fetch steal the body from the original Request as it does today

[10:09:37.0000] <annevk>
wanderview: you probably want to propose it without the shorthand syntax, or does that enable something that is lost on me?

[10:10:15.0000] <wanderview>
annevk: you mean without Request.pipeTo()?  That is what enables Domenic's approach to see the consumer WritableStream directly

[10:10:24.0000] <wanderview>
its a rename of what we were calling setWriter()

[10:12:48.0000] <wanderview>
annevk: Domenic: I guess the thing I don't know how to handle with the WritableStream revealer function is a tee() or clone() done by fetch in order to handle redirects

[10:14:53.0000] <Domenic>
I haven't had time to read much before heading to lunch but I'll just say that largely the point of separating stream and reader was so we could have this tiered high level/low level access. Building in a third tier seems quite bad from that perspective. Everything body-related should be on the res.body stream.

[10:15:52.0000] <Domenic>
Alternately we could give up on separating the "response" and "response body" concepts and make Response subclass Readable(Byte)Stream

[10:16:00.0000] <wanderview>
Domenic: but... you're explicitly asking for something to bypass a body ReadableStream so you can see the consumer WritableStream directly...

[10:16:25.0000] <Domenic>
But anyway more after lunch

[10:16:28.0000] <wanderview>
Domenic: we don't have to call it pipeTo()... I just thought that accurately described the semantics we talked about yesterday... provide a WritableStream sink and begin pushing data there

[10:16:39.0000] <wanderview>
bye

[10:25:17.0000] <jgraham>
Anyone remember jsbell's GH handle?

[10:25:42.0000] <jgraham>
Oh found it

[10:26:07.0000] <jgraham>
In related news: https://critic.hoppipolla.co.uk/r/4569

[10:26:13.0000] <jgraham>
wanderview: ^

[10:28:56.0000] <wanderview>
jgraham: awesome!

[10:34:14.0000] <annevk>
wanderview: I guess I'll bow out until you guys find something

[10:34:55.0000] <annevk>
I think I share tyoshino's ideas

[11:22:12.0000] <wanderview>
annevk: I'm not sure where my idea conflicts with his... other than trying to do his "operations" ReadableStream idea... but I'm not sure how a wrapper really helps us here

[11:25:38.0000] <annevk>
I wonder where JakeA is

[11:25:57.0000] <annevk>
wanderview: dunno

[11:26:21.0000] <annevk>
wanderview: what do you think of the formalizing of boxes I did? Was that what you had in mind?

[11:26:48.0000] <annevk>
wanderview: I also added the examples you asked for how it would work with IDB and Cache

[11:30:45.0000] <wanderview>
annevk: oh... I started to look at that and then got side-tracked... just a sec

[11:33:19.0000] <wanderview>
annevk: hmm... would it be too magical if the name of a Cache or IDB matches a box name... then it is a box?

[11:33:47.0000] <wanderview>
I guess that would prevent multiple Cache object and IDBs in a single box

[11:34:38.0000] <wanderview>
annevk: did you consider an API like StorageBox.add(caches.open("myCache")) ?

[11:35:31.0000] <wanderview>
or StorageBox.add(indexedDB.open("myDB"))

[11:36:42.0000] <wanderview>
I guess it depends on if we want to be able to move a DB or Cache into a box or not... and if we want to support that from an implementation side

[12:19:02.0000] <TabAtkins>
Domenic: There's a `bikeshed debug --print-exports` command that lists exported vs non-exported terms.  Note that only "dfn" type definition are unexported by default - all the rest automatically export unless you explicitly tell them not to.

[12:25:39.0000] <Domenic>
TabAtkins: do you think it would be useful to have the index section mark exported items somehow?

[12:25:46.0000] <Domenic>
maybe it already adds a class and we just need to style it...

[12:26:47.0000] <TabAtkins>
Domenic: That's not useful information for a spec reader, so no.  I've wanted to expose that more naturally for bikeshed users, but haven't given it enough thought to figure it out.

[12:27:04.0000] <Domenic>
It seems useful information for anyone writing a spec based on yours

[12:34:10.0000] <annevk>
wanderview: the name matching seems too magical, .add() seems somewhat nice

[12:34:49.0000] <annevk>
wanderview: although it requires overloading of sorts on the boxes rather than the other APIs supporting boxes...

[12:35:02.0000] <Domenic>
wanderview: now that i read your thing it feels like it's just renaming .setWriter to .pipeTo, so I am less scared.

[12:35:13.0000] <annevk>
wanderview: but yeah, should probably tweak that

[12:35:21.0000] <annevk>
TabAtkins: any closer to a DOM PR?

[12:35:39.0000] <annevk>
TabAtkins: btw, if it could become a single commit in the end that'd be great

[12:35:47.0000] <TabAtkins>
annevk: I'm like 1 hour of work away. I was just on vacation without internet for a week.

[12:35:51.0000] <annevk>
TabAtkins: that'd avoid spamming Twitter a bunch

[12:35:53.0000] <TabAtkins>
And yeah, no problem squishing the commits.

[12:36:06.0000] <annevk>
TabAtkins: ah hope you had a blast

[12:36:12.0000] <TabAtkins>
I did!

[12:36:21.0000] <TabAtkins>
BOARD GAME CRUISE THROUGH THE CARIBBEAN

[12:37:27.0000] <annevk>
That's a thing? Haha nice

[12:37:31.0000] <jamesr___>
TabAtkins: i forgot to ask - did you play puerto rico?

[12:38:10.0000] <TabAtkins>
jamesr___: No, it wasn't brought on board I think.

[12:38:36.0000] <terinjokes>
i'm now interested in knowing what board games were played

[12:42:07.0000] <TabAtkins>
terinjokes: Tons. There were about 300 on board, chosen by the ~150 people registered for the con. (It was a normal cruise ship, so the other 5k people on board were just normal cruise people.)

[12:42:12.0000] <TabAtkins>
I played, let's see...

[12:43:03.0000] <TabAtkins>
Pandemic: The Cure, Patchwork, Roll For The Galaxy, Caverna, Royals, Mysterium, Lords of Waterdeep, Castles of Burgundy, Far Space Foundry, Fleet, Xia, Key Market, Onirim, Abluxxan, and Istanbul.

[12:43:10.0000] <TabAtkins>
(I wrote down all of them.)

[12:46:44.0000] <terinjokes>
wow. i think of those I've only ever played Pandemic

[12:47:03.0000] <TabAtkins>
terinjokes: Note that Pandemic: The Cure is a fast dice-based version of Pandemic.

[12:47:20.0000] <terinjokes>
been wanting to startup my project of doing a new game on some regular-ish time schedule. i should get back to doing that!

[12:47:28.0000] <terinjokes>
ah, then nope

[12:47:31.0000] <TabAtkins>
(Like Roll For The Galaxy is a fast dice-based version of Race For The Galaxy.)

[12:48:03.0000] <TabAtkins>
All of these were new to me, too, which was part of the point of the cruise. ^_^  We were scoping out a bunch of things we were interested in buying.

[12:51:26.0000] <terinjokes>
nice

[13:00:28.0000] <Krinkle>
annevk: Hm.. just ran into a fun issue with serialising our editor DOM to html. Comments.

[13:00:42.0000] <Krinkle>
createComment results in an invalid/unserializable DOM.

[13:00:49.0000] <Krinkle>
https://gist.github.com/Krinkle/1437de41481789ac6c96

[13:02:58.0000] <Krinkle>
We'll probably run html-escape (in addition to special entity scape for '-' so its xml compliant), and then someone decode that on the client side (using either a static map, or by parsing inside  a detached <textarea> and retreiving textcontent?)

[13:03:11.0000] <Krinkle>
it's weird to html escape a value before passing to createComment though

[13:10:56.0000] <Domenic>
I'm not terribly surprised... just more in the category of mismatches between createXYZ() and the parser

[13:13:29.0000] <Krinkle>
Domenic: One can basically insert arbitrary HTML in there, including <script>

[13:15:08.0000] <Krinkle>
In our case we're not actually appending to innerHTML, that's a terrible practice

[13:15:15.0000] <Krinkle>
Just doing that for simplicity sake

[13:15:24.0000] <Krinkle>
(and destroys references etc.)

[13:19:14.0000] <Krinkle>
having some sort of text accessor on Comment nodes so that we can safely insert arbitrary user input into comment nodes would be useful.

[13:19:26.0000] <Krinkle>
And we'd have to either break createComment or create an alternate constructor.

[13:25:28.0000] <Ms2ger>
Some DOMs aren't serializable, that's not going to change

[13:56:52.0000] <Krinkle>
Ms2ger: Interesting. Any other cases you have in mind?

[14:07:01.0000] <TabAtkins>
Krinkle|detached: there are several ways to use DOM to create unserializable documents.  It's not too strange.

[14:07:32.0000] <TabAtkins>
For example, you can use DOM to insert an <a> child of an <a>, or have lone <tr>s floating around the document.

[14:41:51.0000] <Krinkle>
TabAtkins: <a> inside <a> works fine in parsing though. Especially in XML.

[14:41:52.0000] <Krinkle>
It's not "allowed" but afaik works fine, no?

[14:42:21.0000] <Krinkle>
Ah, interesting. It cuts off

[14:42:29.0000] <TabAtkins>
No, "<a>foo<a>bar</a></a>" parses equivalent to "<a>foo</a><a>bar</a>".

[14:42:31.0000] <TabAtkins>
Yeah.

[14:43:06.0000] <TabAtkins>
XML doesn't have special per-element parsing rules like the HTML parser does.

[14:43:07.0000] <Krinkle>
Our content model ensures that doesn't happen though. We treat anchor links the same way as bold/italic/etc. as annotations instead of elements. Which apply to offsets in text nodes.

[14:43:31.0000] <Krinkle>
The tree is then created based on that.

[14:43:50.0000] <TabAtkins>
Sure, that's reasonable for an editor.

[14:44:15.0000] <TabAtkins>
I was just providing some examples of "the DOM can produce something unserializable".

[14:44:26.0000] <Krinkle>
but we visualise html comments (which some Wiki pages make heavy use of to leave info blurps to other editors) in our editor as <span>.

[14:44:42.0000] <Krinkle>
But ran into this issue where some editors leave comments including "--" in a regular English sentence.

[14:44:57.0000] <Krinkle>
and then subsequently, broke our serialisation :-/

[14:45:09.0000] <TabAtkins>
You can escape all - chars inside of comments, I suppose.

[14:45:28.0000] <TabAtkins>
No, that'll break viewing source.

[14:45:33.0000] <TabAtkins>
Replace them with unicode dashes. ^_^

[14:45:40.0000] <Krinkle>
It needs to round trip :)

[14:46:12.0000] <Krinkle>
downstream reports are https://phabricator.wikimedia.org/T95039 and https://phabricator.wikimedia.org/T95040

[14:46:41.0000] <Krinkle>
It seems we're going to be encoding & - and >

[14:46:45.0000] <TabAtkins>
Replace every -- with an emdash - they can only occur when the user is in your editor, so that's fine, and you can even roundtrip it by translating back. (That'd make actual em-dashes not *quite* roundtrip correctly, but hey, those are rare.)

[14:47:08.0000] <Krinkle>
Not rare if your user is a Wikipedian.

[14:47:12.0000] <Krinkle>
:P

[15:38:26.0000] <wanderview>
Domenic: has the performance impact of always returning a Promise from read() and write() been discussed somewhere?

[15:39:03.0000] <Domenic>
wanderview: yeah. promises are cheap when well-optimized, and certainly cheaper than I/O.

[15:40:26.0000] <wanderview>
Domenic: I guess I'm curious about how one optimizes out the object creation and the required async micro-task cost... it seems those are harder things to optimize out than say the generator object creation

[15:41:26.0000] <Domenic>
wanderview: yeah you don't optimize out object creation, but VMs are good at creating objects. The micro-task cost we discussed and eventually landed on the fact that most reads are going to be async anyway, so the microtask adds no extra overhead.

[15:41:28.0000] <wanderview>
Domenic: I mean.. I'm willing to accept Promise costs periodically... but once every 4096 bytes may be a bit much...

[15:41:59.0000] <wanderview>
Domenic: in the case where you have chunks buffered up... it seems like you would want to be able to get all of them synchronously, though... no?

[15:42:24.0000] <Domenic>
right, that was the original design with while (rs.state === "readable") { rs.read(); }

[15:42:38.0000] <Domenic>
(read() being sync in that case)

[15:42:51.0000] <wanderview>
Domenic: I vaguely remember that... what was the issue that forced the change?

[15:43:58.0000] <Domenic>
wanderview: a combination of wanting rs.readInto(buffer) + non-epoll streams who do their work in a threadpool or similar means you need something like async read(), or setAllocator

[15:44:37.0000] <wanderview>
Domenic: is ReadableByteStream or the new precise-flow-control stuff solving this by letting me say "read up to this much data before resolving"?

[15:44:41.0000] <Domenic>
Unclear how setAllocator would work though given that I/O is IPC though, now that I think about it

[15:45:18.0000] <wanderview>
Domenic: I/O doesn't have to be IPC... you can open a file descriptor in the parent and then dup(2) it to the child process... then file reads are in the child process

[15:45:21.0000] <Domenic>
wanderview: the intent of ReadableByteStream's read(view) is that view.byteLength is at least a hint, although I think we didn't want to make it binding...

[15:45:37.0000] <wanderview>
Domenic: network is probably always in the parent process behind IPC, though (because of http 1.1 channels multiplexed on same socket, etc)

[15:45:39.0000] <Domenic>
wanderview: ah OK, just was thinking of the other day when you were talking about IPC costs...

[15:46:05.0000] <Domenic>
my vision of read(view) was that you'd pass that view pretty directly to read(2)

[15:46:15.0000] <Domenic>
so for socket streams you might get back less than view.byteLength

[15:46:27.0000] <Domenic>
but for file streams, unless you're at end of file, you'll probably get view fully filled

[15:47:00.0000] <Domenic>
IIRC read(2) has an option to not return until the buffer is filled ... but it doesn't work with nonblocking sockets?

[15:47:44.0000] <Domenic>
Ah no, it's recv(2). MSG_WAITALL

[15:49:27.0000] <Domenic>
we could make the implementation concatenate buffers i guess? or let that be an option!? i don't see any reason why it's impossible, I was just going for the more direct mapping

[15:50:49.0000] <Domenic>
it's a latency vs. efficiency thing i guess, which perhaps is best to leave to applications to decide?

[15:51:26.0000] <wanderview>
sorry, on phone

[15:51:40.0000] <Domenic>
np

[15:51:55.0000] <Domenic>
reminds me of this issue https://github.com/whatwg/streams/issues/171

[15:54:45.0000] <Domenic>
It is true in general that browser promise impls are wildly unoptimized. User-land versions regularly achieve 4x performance and 1/4th the memory consumption, and they don't even have access to all the tricks browsers do (like skipping the microtask queue if calling in from C++)

[15:54:55.0000] <wanderview>
Domenic: I wonder if we could do something like .read(numDesiredChunks)

[15:55:04.0000] <wanderview>
and the promise resolves when that many are available

[15:55:30.0000] <Domenic>
wanderview: that seems pretty reasonable. Would kind of want to see data that this was a bottleneck, or a non-performance use case, before doing so.

[15:56:07.0000] <Domenic>
I'll file an issue to track to see if anyone has non-perf use cases

[15:56:24.0000] <wanderview>
Domenic: it seems more appropriate for ReadableByteStream... but might be usable in ReadableStream

[15:57:04.0000] <Domenic>
wanderview: maybe for RBS it's .read(view, { waitUntilFull: true })

[15:57:06.0000] <wanderview>
Domenic: thinking of when you are reading some framed protocol... you probably don't want to get woken up until the next frame is completely there

[15:57:49.0000] <wanderview>
Domenic: I don't think c++ can skip the microtask, can it?  I mean.. it seems like it risks accidentally breaking the micro task guarantee in your API

[15:59:55.0000] <Domenic>
wanderview: it's hard to say precisely what I mean here as the area is so complicated. But the main idea is that C++ always enters back into JS from a clean stack, and that's what microtasks guarantee: a clean stack. One way of seeing this is that the very first thing done after transitioning from C++ to JS is to exhaust the microtask queue. So the very

[15:59:55.0000] <Domenic>
first thing that happens on the JS side, after doing resolve_promise_from_cpp(cpp_p, cpp_v), is calling p's onFulfilled handler with v

[16:00:27.0000] <Domenic>
IIUC SpiderMonkey doesn't actually implement a microtask queue and just uses their task queue, so maybe it is not so efficient in SpiderMonkey.

[16:02:28.0000] <wanderview>
Domenic: right... but its still an async runnable even if it skips to the head of the (micro)task queue

[16:02:46.0000] <othermaciej>
the spec says to drain the microtask queue between every regular task queue item

[16:02:54.0000] <othermaciej>
(if I read it correctly)

[16:03:04.0000] <wanderview>
and I guess unwinding and rewinding the stack has noticeable perf impacts when done in too tight a loop

[16:03:37.0000] <othermaciej>
and after completing execution of a <script> element

[16:03:47.0000] <othermaciej>
I don’t believe it says to do anything on entry from C++ to JS

[16:04:32.0000] <othermaciej>
it might be you can do it like that and have no observable behavior difference but it is not obvious how offhand

[16:05:00.0000] <othermaciej>
in particular, you can exit JS to C++ and re-enter JS sometimes without having performed microtasks

[16:05:01.0000] <Domenic>
othermaciej: hmm, maybe i am confused. But that was my interpretation of the spec, modulo the spec not having any "entry from C++ to JS" concept.

[16:05:21.0000] <Domenic>
Oh, that makes sense

[16:05:23.0000] <othermaciej>
this will occur if you have multiple event handlers for the same event, for instance

[16:05:41.0000] <Domenic>
Or just arr.forEach(cb), where hypothetically forEach is implemented in C++.

[16:06:16.0000] <othermaciej>
the spec is closer to saying that microtasks are run on *exit* from JS to C++, except only if you are on a “clean stack”

[16:06:26.0000] <othermaciej>
where “clean” == in the top level event loop or in the html parser

[16:06:57.0000] <othermaciej>
and also it sometimes drains the queue on times you didn’t just exit from JS, in case right when you exited, you did not have a clean stack

[16:07:02.0000] <othermaciej>
that is how I understand it anyway

[16:08:45.0000] <Domenic>
I guess the point I was really trying to make was: in Node.js, if you do `fs.readFile(..., result => resolvePromise(p, result))`, resolvePromise has to actually schedule a microtask to ensure p's handlers are called with a clean stack. So we wait for all the rest of the JS in that event loop turn to run, then unwind the stack, then run the microtask queue,

[16:08:45.0000] <Domenic>
with several (perf-impacting) C++-to-JS transitions. Whereas in browsers, you don't have to pay that cost.

[16:09:16.0000] <Domenic>
JS environments which try to completely control the event queue, like Angular, do similar optimizations

[16:10:02.0000] <Domenic>
where they technically run their promise handlers "sync" but if you're programming correctly-according-to-Angular, it's unobservable.

[16:25:27.0000] <wanderview>
Domenic: are you trying to add an interface contract definition for ReadableStream and WritableStream in this issue?  https://github.com/whatwg/streams/issues/312

[16:26:09.0000] <Domenic>
wanderview: that thread has lost me a bit tbh...

[16:26:53.0000] <wanderview>
Domenic: I think it would be really helpful to have definitions of ReadableStream and WritableStream separate from the default implementation adapting JS functions

[16:28:04.0000] <Domenic>
wanderview: all ReadableStream instances must necessarily adapt JS functions (or JS manifestations of C++ functions)... other things obeying the "readable stream contract" might work differently though

[16:28:38.0000] <Domenic>
the necessity is because myFetchReadableStream.read === myFileReadableStream.read, if both variables are ReadableStreams.

[16:29:06.0000] <wanderview>
Domenic: so a DOM created ReadableStream representing some C++ implementation like a file stream has to be created through the ReadableStream Constructor?

[16:29:44.0000] <wanderview>
Domenic: why is myFetchReadableStream.read === myFileReadableStream.read a necessity?

[16:29:46.0000] <Domenic>
wanderview: I mean, it has to obey the observable invariants; if there are tricks you have for getting around that, use them, but...

[16:30:00.0000] <Domenic>
wanderview: if they are both ReadableStreams then they have the same prototype and thus the same method

[16:30:10.0000] <Domenic>
wanderview: if one is a FetchReadableStream and another is a FileReadableStream then yeah they can be different

[16:30:18.0000] <Domenic>
wanderview: analogy---promises

[16:30:40.0000] <Domenic>
wanderview: all C++-created promises are, at least in V8/Blink, created "via the Promise constructor"

[16:30:41.0000] <wanderview>
Domenic: I guess what I am saying is, it would be nice if the spec defined the observable invariants instead of making me try to dig them out of a pile of js

[16:31:07.0000] <Domenic>
even though the promises will be backed by very different behavior

[16:31:43.0000] <Domenic>
yeah, agreed on that. We want that anyway so we can say---or better, programatically test---that ReadableByteStream behaves the same as ReadableStream.

[16:31:46.0000] <Domenic>
the templated tests are a start

[16:35:53.0000] <wanderview>
Domenic: so you are saying you want JS-created ReadableStream objects to have exactly the same prototype as DOM API created ReadableStream objects?

[16:36:09.0000] <Domenic>
wanderview: yeah, exactly, just like Promise.

[16:36:22.0000] <wanderview>
Domenic: pretend I don't know much about Promise :-)

[16:37:04.0000] <Domenic>
hmm, well, then, yes. The underlying source is meant to provide the customization hooks

[16:37:32.0000] <Domenic>
The underlying source could be a JS facade over a C++ object, for sure

[16:37:50.0000] <wanderview>
Domenic: I guess then it would be nice to have a source interface definition... and separate out the js-adapter specifics into a separate implementation of that interface

[16:38:10.0000] <Domenic>
hmm what's a "source interface definition"?

[16:38:20.0000] <wanderview>
Domenic: the underlying source

[16:38:37.0000] <Domenic>
https://streams.spec.whatwg.org/#rs-constructor kind of tries

[16:38:57.0000] <Domenic>
what are js-adapter specifics? there are no implementations of the underlying source interface in the streams spec

[16:39:09.0000] <Domenic>
fetch-with-streams has one

[16:39:51.0000] <wanderview>
Domenic: nm... I don't think what I asked makes sense

[16:40:53.0000] <wanderview>
Domenic: do you anticipate things like ReadableStream.pipeTo() operating on the public ws.write() method?  so allowing monkey patching

[16:41:07.0000] <wanderview>
the current text pointing at the ref implementation suggests it does

[16:41:33.0000] <Domenic>
An implementation could always do something like ReadableStream.prototype.read = function () { switch (this@[[hiddenType]]) { case "user-created": return userCreatedImpl(this); case "fetch": return fetchStreamImpl(this); } }; where user-created follows more or less the exact spec algorithm and fetchStreamImpl manages to maintain all its observable invariants

[16:41:33.0000] <Domenic>
but is implemented differently.

[16:42:01.0000] <Domenic>
Then we have to tease out what the observable invariants are. I guess maybe that's what you're asking for.

[16:42:23.0000] <wanderview>
Domenic: I'm asking about monkey-patching .write in this case

[16:42:30.0000] <Domenic>
sorry I was still on the previous subject

[16:42:33.0000] <wanderview>
but I guess .read is the same

[16:43:06.0000] <wanderview>
Domenic: I think the "underlying source" model maps reasonably well to the DOM idiom of having an "inner object"

[16:43:20.0000] <Domenic>
hmm interesting

[16:43:32.0000] <wanderview>
but I guess DOM APIs typically operate explicitly on the inner objects... not on the public APIs

[16:43:45.0000] <Domenic>
Ah interesting

[16:43:55.0000] <wanderview>
so rs.pipe(ws) would do something like "write data to ws's underlying sink" instead of calling ws.write()

[16:44:21.0000] <Domenic>
regarding monkey-patching write and pipeTo... I'm a bit torn on how to handle this. I've probably given up on it using `this.read()` etc.; it can use tamper-proof versions for operating on `this` to reduce complexity. But it seems quite important to allow polymorphic dispatch on the *argument*.

[16:44:51.0000] <wanderview>
Domenic: the polymorphism is achieved in this spec by swapping out the underlying sink, no?

[16:44:53.0000] <Domenic>
That said as we went through in some thread a while ago it's hard to make that work while still allowing unobservable off-main-thread piping

[16:45:04.0000] <Domenic>
wanderview: heh, I guess that is where my argument leads...

[16:45:36.0000] <Domenic>
wanderview: my hope was that you could create structurally similar writable streams that obey the same contract without being exactly WritableStreams

[16:45:37.0000] <wanderview>
Domenic: going to the inner objects is nice for DOM people like me... but I wonder if its not very javascripty

[16:45:50.0000] <Domenic>
Yeah, it's definitely not very JavaScriptey. But neither is off-main-thread piping :P

[16:45:56.0000] <wanderview>
Domenic: that seems at odds with requiring prototypes to be exact matches

[16:46:14.0000] <Domenic>
wanderview: nothing requires the prototypes to be exact matches, I was just saying, if they are, then they need to be the same impl

[16:46:24.0000] <wanderview>
Domenic: if you want pure duck types then I don't think we should require exact prototype matches

[16:46:42.0000] <Domenic>
wanderview: you *could* have separate FetchReadableStream that is written from scratch in its own spec and doesn't reference the stream spec at all, except trying to be duck-compatible.

[16:46:48.0000] <Domenic>
But that seems like a waste of effort.

[16:46:54.0000] <wanderview>
Domenic: like... I think the JS adapter stuff should be in a JSReadableStream that chains from ReadableStream, etc

[16:47:03.0000] <Domenic>
Anyway, my hope might be silly, is where I was going with that.

[16:47:09.0000] <wanderview>
and there is no spec'd concrete implementation of ReadableStream

[16:47:35.0000] <Domenic>
This just feels very silly when you go back to the promise analogy

[16:48:04.0000] <Domenic>
We don't have every promise-returning API on the web platform creating their own version of the Promise class just so they can get different backing behavior

[16:48:08.0000] <wanderview>
Domenic: I don't think we have the optimization concerns with off-main-thread piping, etc, with Promises that we do here...

[16:48:55.0000] <wanderview>
something has to give here :-) I don't think all these requirements are compatible

[16:49:13.0000] <Domenic>
I am leaning toward abandoning duck-compatibility for writable streams

[16:49:31.0000] <wanderview>
Domenic: what about for ReadableStreams?

[16:50:03.0000] <Domenic>
wanderview: unsure, nothing accepts them right now (except their own methods, and JS functions which will operate on a duck level)

[16:50:25.0000] <wanderview>
Domenic: but their own methods will operate directly on underlying source?

[16:50:36.0000] <Domenic>
wanderview: yeah, definitely.

[16:51:21.0000] <wanderview>
Domenic: is there an existing issue for this or shall I write a new one?

[16:51:24.0000] <Domenic>
wanderview: well, I was for a while planning on making pipeTo operate in terms of this.read() and friends, but after doing TeeReadableStream I am leaning away from that.

[16:51:41.0000] <wanderview>
I think it was partially discussed in the transfer issue, but seems it deserves its own issue

[16:51:45.0000] <Domenic>
wanderview: we kind of got sidetracked in the ... web socket issue, was it? into these

[16:51:47.0000] <Domenic>
ah yeah

[16:51:55.0000] <wanderview>
Domenic: I'll write one

[16:51:58.0000] <Domenic>
ok cool

[16:52:51.0000] <Domenic>
Hmm, promises enable duck-compatibility with Promise.resolve casting .then'ables ..... that's a more sound model actually. Also a complicated one that we probably don't need to build in to the platform?

[16:53:18.0000] <Domenic>
It should be pretty straightforward to write a JS function duckReadableStreamToRealReadableStream

[16:53:26.0000] <Domenic>
Then people can use that if they need to

[16:54:03.0000] <wanderview>
Domenic: I do think a ReadableStream wrapper constructor would be nice... making it take a duck typed stream would be reasonably

[16:54:07.0000] <Domenic>
The promise-esque alternative being that we have ReadableStream.cast = duckReadableStreamToRealReadableStream and every ReadableStream-accepting API does ReadableStream.cast first (like all promise-accepting APIs do Promise.resolve first). Really unnecessary.

[16:54:58.0000] <Domenic>
brb cafe closing!!

[16:55:13.0000] <wanderview>
/me forgot he was in pacific time zone.


2015-04-08
[17:15:23.0000] <Domenic>
ok, back, although i should probably head out for the day

[17:16:04.0000] <terinjokes>
Domenic: you should go home

[17:16:04.0000] <Domenic>
this Promise.resolve analogy soothes me greatly

[17:16:19.0000] <Domenic>
(in general any time I can analogy to promises, I feel more confident)

[17:17:23.0000] <Domenic>
we can let pipeTo only accept true WritableStreams, and if in the future that becomes limiting we can add WritableStream.cast or similar as a mechanism for coping

[17:24:38.0000] <wanderview>
Domenic: https://github.com/whatwg/streams/issues/321

[17:24:42.0000] <wanderview>
have a good night!

[23:37:06.0000] <JakeA>
annevk: https://github.com/slightlyoff/ServiceWorker/issues/607#issuecomment-90819078 - I don't understand "wait with overrideRequestURL"

[23:53:25.0000] <annevk>
JakeA: just not implement it

[23:54:54.0000] <annevk>
JakeA: what you argue for would be a new special case that did not exist before; the case the implementers brought up was not considered when we figured it as a shorthand for short-circuiting redirects

[23:58:22.0000] <JakeA>
annevk: we've got some internal customers for this, I'll find out if the API works for them. But yeah, in that case it isn't exactly like a redirect.

[23:58:56.0000] <annevk>
JakeA: it would be interesting to hear why they can't use Response.redirect()

[00:05:13.0000] <JakeA>
annevk: yeah, I'm digging into that and building them an example

[01:00:51.0000] <annevk>
Is anyone using https://atom.io/?

[01:41:34.0000] <philipj>
annevk: I think the general situation is that Content-Type is ignored for both media elements and <track>

[01:42:07.0000] <philipj>
there's a bit of a history, but since Microsoft caved and started ignoring it in IE I think there's no turning back (which I'm happy about)

[01:42:42.0000] <annevk>
philipj: so for X-Content-Type-Options: nosniff we want to give server administrators the feature of enforcing Content-Type for resources so they can't be used in an unexpected context

[01:43:09.0000] <annevk>
philipj: this requires a whitelist of MIME types for audio/video and a separate set for track

[01:43:17.0000] <philipj>
uh, ok, I couldn't say how that currently works

[01:44:10.0000] <annevk>
philipj: it doesn't for those contexts

[01:44:16.0000] <annevk>
philipj: well, it might in IE

[01:44:19.0000] <annevk>
I haven't tested IE yet

[01:44:32.0000] <philipj>
for <track> there's just no code that looks at Content-Type, at least not in Blink, if it's not WebVTT then it won't work

[02:33:12.0000] <annevk>
philipj: okay, so we could just make the whitelist text/webvtt

[02:33:19.0000] <annevk>
philipj: for CSS it's text/css at the moment

[02:33:50.0000] <annevk>
philipj: only unclear thing then is the MIME types for audio/video which is somewhat of a trainwreck

[02:45:47.0000] <annevk>
text/vtt*

[02:57:13.0000] <annevk>
http://w3cdreams.tumblr.com/

[03:01:11.0000] <jgraham>
Wow, well I was enjoying that and then the Service Worker thing guenuninely made me feel ill

[03:10:45.0000] <annevk>
jgraham: hypno cat?

[03:12:39.0000] <jgraham>
Possibly

[03:13:05.0000] <jgraham>
Also made me unable to spell genuinely

[03:17:04.0000] <zcorpan>
just need to let the eyes follow the circles a few laps and then you'll feel better again

[07:52:24.0000] <wanderview>
Domenic: you said there were user space Promise libs that were faster than browser implementations... can you point me at one you recommend for perf?

[07:52:52.0000] <bradleymeck>
wanderview: bluebird

[07:52:59.0000] <Domenic>
yep

[07:56:05.0000] <wanderview>
Domenic: should I just be able to drop this in with the stream reference impl?

[07:57:19.0000] <Domenic>
wanderview: ugh, the reference impl is so un-optimized...

[07:57:38.0000] <Domenic>
wanderview: but, yeah, if you do global.Promise = require('bluebird') it should be drop-in-able

[07:58:11.0000] <Domenic>
But I mean, all the asserts (in loops too!) and try/catches and the hilarious queue-with-sizes implementation will dwarf the performance change I think

[08:01:40.0000] <wanderview>
Domenic: meeting now... but I'll try to describe the case I'm concerned with... I can write something not use ref impl, but just something similar to tease out the Promise impact

[08:03:54.0000] <Domenic>
wanderview: OK cool. Be sure it does actual I/O too :)

[08:04:17.0000] <wanderview>
Domenic: javascript consumers may not do actual I/O

[08:05:50.0000] <Domenic>
Ultimately the stream should be grounded in some I/O, most likely

[08:06:09.0000] <Domenic>
E.g. maybe your stream vends JS objects but it's derived from some stream that read from a file/network

[08:36:48.0000] <wanderview>
Domenic: is it not reasonable for js to do in-memory operations like your stream demo where its searching for a particular value?  that is not I/O related

[08:36:58.0000] <Domenic>
wanderview: how is that no I/O related?

[08:37:09.0000] <Domenic>
wanderview: the stream is a fetch stream

[08:37:35.0000] <wanderview>
Domenic: I thought you meant on the consumption side you wanted it to be I/O

[08:37:51.0000] <Domenic>
wanderview: oh, no, i just meant that each promise produced from the reader should correspond to doing some I/O

[08:38:59.0000] <Domenic>
i.e., don't test for (let i = 0; i < 1000; ++i) { Promise.resolve(5).then(foo); }; test for (let i = 0; i < 1000; ++i) { fs.read(fd, ...).then(foo); })

[08:39:04.0000] <wanderview>
Domenic: the main case I can think of that concerns me is where you write data to a pipe buffer... and then want to read it starting at some later time... in that case the pipe .read() is not related to I/O until the buffer is drained... and draining the buffer will be much slower than with sync .read()

[08:39:39.0000] <Domenic>
"much" slower citation needed... especially since sync read() would need to use async .ready or similar for backpressure signals

[08:39:54.0000] <wanderview>
Domenic: thats why I want to test with real Promises :-)

[08:40:02.0000] <Domenic>
sounds good :)

[08:40:19.0000] <wanderview>
Domenic: I agree at least one async operation is needed... but doing it on every buffered chunk seems potentially not good

[08:41:30.0000] <wanderview>
Domenic: I'm going to put this in the batch read issue... I think some kind of .readAllAvailable() would solve this... give me an array of all available chunks... so you get an array of length 1 or greater

[08:41:48.0000] <wanderview>
for cases where you just want to read as fast as possible

[08:41:52.0000] <Domenic>
wanderview: sounds good, yeah. Or 0 chunks if end of stream.

[08:52:33.0000] <wanderview>
Domenic: I guess my concern here started by looking at the current rs.pipeTo() implementation... since it waits for each .read() to resolve before calling .read() again... you can't get any pipelining going that way... and then I started to wonder if it should do two .read() calls... so while its writing the first its already started the async process to get

[08:52:34.0000] <wanderview>
the next, etc

[08:53:33.0000] <Domenic>
wanderview: right, but that should only delay at most a microtask, and then it will resolve and immediately call read() again, and the stack only has to unwind one frame since we're already in the microtask loop... it's one extra frame per loop iteration basically.

[09:02:55.0000] <JakeA>
wanderview: I've been thinking about cache.add[All]. I've been seeing a lot of examples check the status code of responses before putting them into the cache. Maybe we should revisit the idea of checking response.ok before caching (as an option). This would of course fail on all opaque responses. Do you think it's still useful?

[09:05:48.0000] <wanderview>
JakeA: in a meeting

[09:05:55.0000] <JakeA>
no rush

[10:06:51.0000] <annevk>
JakeA: should it not be added to fetch() then?

[10:15:07.0000] <wanderview>
JakeA: that sounds fine to me... I don't really have an opinion... whatever developers want/expect

[10:15:21.0000] <wanderview>
not sure I understand the opaque response thing, though

[10:15:35.0000] <annevk>
Domenic: the post-ES6 specification plan sounds rather lovely

[10:15:46.0000] <Domenic>
:)

[10:15:51.0000] <Domenic>
we'll see if we can pull it off...

[10:16:05.0000] <annevk>
Domenic: I wonder if WHATWG can gradually convert to that as well

[10:16:15.0000] <wanderview>
what plan?

[10:16:30.0000] <annevk>
wanderview: https://esdiscuss.org/topic/the-great-tooling-revolution

[10:18:13.0000] <Domenic>
annevk: you mean the two-impls thing?

[10:18:29.0000] <annevk>
Domenic: the tooling and writing style

[10:18:43.0000] <Domenic>
annevk: ah interesting.

[10:19:32.0000] <annevk>
having said that, ES6 is rather hard to digest, but some of the algorithm shorthands you're introducing seem nice

[10:19:43.0000] <Domenic>
Yeah, I was going to say, "Ecmaspeak"'s evolution into something more user-friendly is still in progress (cf. https://streams.spec.whatwg.org/#conventions)

[10:19:54.0000] <Domenic>
And it's unclear the value of Ecmaspeak vs. some kind of "spec ES"

[10:20:09.0000] <wanderview>
Domenic: what does chrome's shipping Response body stream do for a Response returned from cache.match()?  does it stream from disk?

[10:20:32.0000] <Domenic>
wanderview: good... question...... tyoshino are you awake perchance?

[10:20:37.0000] <wanderview>
I mean... is that implemented in this first version

[10:20:50.0000] <Domenic>
oh hi yhirano_ is in here too

[10:21:29.0000] <Domenic>
Maybe the thing to do is ask on the blink-dev Intent to Ship thread?

[10:27:18.0000] <wanderview>
Domenic: ok, will do... mainly just curious

[10:28:26.0000] <wanderview>
Domenic: what is WritableStream.getWriter() you to mention in that issue update?  I don;t see that in the spec

[10:59:58.0000] <Domenic>
wanderview: https://github.com/whatwg/streams/issues/319 :-S

[11:00:33.0000] <wanderview>
ok... so not spec'd yet

[11:00:41.0000] <wanderview>
wasn't sure if it was coming or previous-and-gone

[11:01:04.0000] <Domenic>
heh... yeah

[11:01:15.0000] <Domenic>
wanderview: related https://github.com/whatwg/streams/commit/d757e05cf27f73488d13825e51ce5706a759ab27

[11:04:51.0000] <wanderview>
Domenic: I didn't want to bikeshed more in the "getReader is named poorly" issue... but take() is also widely used for locking concepts :-)

[11:09:41.0000] <Domenic>
meeeeeeeeeeehhhhhh

[11:12:32.0000] <wanderview>
Domenic: getReader() does not unlock if the reader gets GC'd right?  or rather, the whole stream has to be GC'd in addition to the reader?

[11:12:48.0000] <Domenic>
wanderview: right. (and in the latter case i'm not sure there's a difference.)

[11:12:58.0000] <Domenic>
wanderview: webkit has a test showing this

[11:13:15.0000] <Domenic>
unsure how/whether to put it in the general suite...

[11:13:58.0000] <wanderview>
Domenic: I really dislike stuff with explicit release like revokeObjectUrl()...  so many leaks in code that use them... the error paths are atrocious

[11:14:27.0000] <wanderview>
from my experience with code in fxos trying to use that kind of API

[11:14:44.0000] <Domenic>
wanderview: well this case is pretty different, since it's not like you could successfully get another reader by waiting for GC of the first one, since that's unreliable

[11:15:00.0000] <Domenic>
that's a fair argument for the lifecycle management thread though

[11:15:01.0000] <wanderview>
yea

[11:15:09.0000] <wanderview>
I think I mentioned it there

[11:16:27.0000] <wanderview>
Domenic: is there a finally thing on promises for people to always return the reader?

[11:16:34.0000] <wanderview>
maybe that makes it less of a problem

[11:17:40.0000] <Domenic>
wanderview: we've been wanting to add finally to promises for a long time, and this cancelable promise stuff might push it over the line.

[11:19:15.0000] <wanderview>
Domenic: I guess its not a huge problem here... since lock is released automatically on close

[11:19:28.0000] <wanderview>
its optimized for single reader case... which is what we want

[11:24:35.0000] <Domenic>
wanderview: yeah, that's kind of the idea. if anyone's doing something tricky like parsing a header portion then passing the partially-read stream on to someone else, they can probably remember to release the lock. Although I agree finally would be nice.

[11:25:33.0000] <wanderview>
Domenic: that seems like something easier down with pipeThrough()... although it would be nice to remove the header transform piece after its done

[11:25:55.0000] <Domenic>
hmm yeah that's true

[11:26:12.0000] <wanderview>
^down^done

[11:26:16.0000] <Domenic>
i guess most uses of readers are hidden behind the higher-level methods like pipe*() and tee()

[11:42:14.0000] <calvaris>
sorry, I just fell and I don't know if you read what I said but

[11:42:21.0000] <calvaris>
wanderview: I have a pull request with that test

[11:42:26.0000] <calvaris>
all custom tests that we had for WK are now there and waiting for Domenic to merge them

[11:43:11.0000] <wanderview>
calvaris: which test?

[11:44:14.0000] <calvaris>
the one for the garbage collection regarding the reader

[11:44:14.0000] <wanderview>
Domenic: btw, we apparently do implement microtask queue in gecko now

[11:44:31.0000] <wanderview>
calvaris: ah, cool

[11:45:13.0000] <Domenic>
wanderview: ah that's excellent

[11:45:44.0000] <wanderview>
Domenic: I still don't think our c++ can optimize around them, though... since js can call into c++ with js still on the stack

[12:59:00.0000] <trevnorris>
Domenic: "Cheaper than I/O" doesn't say a lot and Promise instantiation speed isn't the only thing to consider. It's the complete time from .push() to .read().

[14:23:18.0000] <wanderview>
Domenic: what does it mean for a ReadableStream to .pipeTo() a WritableByteStream... what if the RS produces non-byte things?

[14:23:53.0000] <Domenic>
wanderview: calling .write() (or the equivalent internal operation if we move to that model) will error, causing the pipe to error.

[14:24:46.0000] <wanderview>
Domenic: but if the ReadableStream passes Uint8Array chunks, then its ok?

[14:24:55.0000] <Domenic>
wanderview: yes, I would really like that to work

[14:25:09.0000] <Domenic>
wanderview: maybe allow any of the "BufferView" types

[14:25:37.0000] <wanderview>
or just ArrayBuffer, I presume?

[14:28:29.0000] <Domenic>
wanderview: right, I forgot what the type was called that is a union of all typed arrays + ArrayBuffer + DataView

[14:28:59.0000] <Domenic>
"BufferSource" apparently

[14:30:08.0000] <wanderview>
Domenic: where is the latest ReadableByteStream proposal?

[14:30:37.0000] <Domenic>
wanderview: https://github.com/whatwg/streams/blob/asyncbytestream/BinaryExtension.md

[14:32:25.0000] <wanderview>
Domenic: so... its starting to feel to me like we should not have a ReadableByteStream at all...  if the underlying source of the stream operates on bytes, then the specialization has already occurred... getReader() can just return a ByobReader

[14:32:30.0000] <wanderview>
or am I missing something?

[14:32:43.0000] <TabAtkins>
bring-your-own-beerReader

[14:33:00.0000] <wanderview>
/me didn't name it. :-)

[14:33:11.0000] <wanderview>
ByobByteStreamReader

[14:34:35.0000] <Domenic>
wanderview: hmm, but adding the BYOB layer changes things quite a lot, adding complexity specifically for the byte case. You would advocate building that complexity into the readable stream itself?

[14:35:05.0000] <wanderview>
Domenic: if a view is not passed to .read()... can it not just do a "get me the next chunk" semantics pretty easily?

[14:35:35.0000] <trevnorris>
Domenic: spec probably can't define any implementation details, can it?

[14:35:52.0000] <Domenic>
wanderview: for example the underlying source needs some kind of hook read(view) -> promise that fills view, and inside the stream/reader mechanisms you need something such that byobReader.read(view) transfers view to view2 then passes view2 to the read hook on the source

[14:35:58.0000] <Domenic>
trevnorris: it can define anything observable

[14:36:06.0000] <Domenic>
trevnorris: including creation APIs

[14:36:27.0000] <Domenic>
wanderview: the idea is you should opt in to one mode or the other (BYOB or auto-flowing)

[14:37:08.0000] <wanderview>
Domenic: then keep it getByobReader(), but have it reject on streams that don't have the right underlying source

[14:37:12.0000] <Domenic>
for example BYOB doesn't have a high water mark or queue in general (although it does probably keep one around since kernel buffers are finite... unsure if that's observable to spec or can be part of the underlying source details)

[14:37:35.0000] <Domenic>
wanderview: ick, that's a very bad API. It would be like Node having a tagName that throws an exception when you try to use it on Comment nodes

[14:37:55.0000] <trevnorris>
Domenic: my implementations tie a C++ class to every JS stream, on which a class method can be defined to receive incoming data. .pipe() can detect that and short circuit the JS call by passing from the internal C++ to the implementation defined method.

[14:38:20.0000] <trevnorris>
unfortunately it depends on certain V8-isms that i'm not sure are currently possible in other engines.

[14:38:20.0000] <Domenic>
trevnorris: right, in that case the spec's job is to make your short circuit unobservable

[14:38:45.0000] <Domenic>
trevnorris: and that means completely unobservable, even if someone overwrites dest.write to log when called or similar ;)

[14:38:48.0000] <wanderview>
Domenic: what does ReadableByteStream get you beyond the Byob capacility?  It doesn't seem like anything... so maybe it should be a ByobReadableStream

[14:39:24.0000] <Domenic>
wanderview: yes, that is indeed the real delta. We figured it was a more user-friendly name? But no real opposition to renaming it

[14:39:47.0000] <wanderview>
Domenic: I guess the problem with that is the producer of the stream does not know if the user wants Byob semantics

[14:39:53.0000] <Domenic>
Actually we are kind of hoping not to use the term "BYOB" in public API. The fact that's in tyoshino's doc is largely just as a placeholder :)

[14:39:58.0000] <wanderview>
^user^consumer

[14:40:03.0000] <wanderview>
I know

[14:40:54.0000] <wanderview>
Domenic: it just feels the "type" of the stream is determined by the underlying source... and having to have a special shell around particular underlying sources is clumsy... ReadableStream should just enable the extra features if its constructed with a byte oriented underlying source

[14:40:57.0000] <Domenic>
wanderview: the hope is that it is efficient for streams like fetch/fs/etc. that are bytes-backed to implement ReadableByteStream, and then consumers who want to opt in to BYOB behavior can use .getByobReader(), and normal people (including those agnostic to the chunk type) can just use .getReader()

[14:41:46.0000] <Domenic>
wanderview: I don't agree with that. The logical conclusion of that argument is that streams should be able to bake me a cake if I give them the right underlying source.

[14:42:05.0000] <Domenic>
Adding fundamentally new capabilities, instead of just different behavior, should require a new type.

[14:42:16.0000] <wanderview>
/me likes cake.

[14:42:51.0000] <wanderview>
Domenic: what do you anticipate being different about a WritableByteStream?

[14:43:16.0000] <Domenic>
wanderview: hazy right now, but one big thing is it will need to detach any passed-in buffers since they might be sent off thread

[14:44:14.0000] <wanderview>
Domenic: that... seems hard without including it in the WritableStream contract

[14:44:46.0000] <Domenic>
hmm how so?

[14:45:00.0000] <wanderview>
Domenic: isn't that an optimizaiton that should be negotiated by native underlying source to native underlying sink?

[14:45:44.0000] <Domenic>
wanderview: I am talking about var a = new Uint8Array([5, 10, 15, 20]); fileStream.write(a)

[14:46:01.0000] <Domenic>
I want to send the backing memory of a off into the thread that does file I/O

[14:46:42.0000] <Domenic>
and I am pretty sure we don't want to let people do a[0] = 7 and have that mutate the memory, maybe before the write, maybe after the write

[14:46:48.0000] <wanderview>
Domenic: you're talking about effectively making the chunk disappear from content... if under normal circumstances I can do ws.write(chunk); muchAroundWithChunk(chunk); ... how will code based just on WritableStream know that .write() suddently doesn't work that way because it has a WBS?

[14:47:41.0000] <wanderview>
Domenic: I guess I'm saying WritableStream.write() contract should say "don't expect the chunk to exist in its current form after this call"  regardless of WritableStream vs WritableByteStream

[14:47:46.0000] <Domenic>
wanderview: that's fair, although I'm not sure in practice how worried we should be. But one easy fix is to add .getTransferringWriter() or similar, whereas .getWriter() does copies?? I dunno.

[14:48:06.0000] <Domenic>
wanderview: I just have no idea how to enforce that contract

[14:48:26.0000] <Domenic>
if it's not true for most writable streams, then people might assume it, no matter if the spec has some kind of "don't assume this please" note.

[14:48:27.0000] <wanderview>
Domenic: maybe its not enforceable... but we can at least say "told you so" when people' stuff breaks :-)

[14:48:34.0000] <Domenic>
heh, ok

[14:49:13.0000] <wanderview>
Domenic: it just seems stuff like ByobReader and maybe this TransferringWriter are opportunistic things... optimize in this fashion if its available... otherwise use the lesser stuff

[14:49:48.0000] <wanderview>
Domenic: and I guess in your mind the right way to "check if its available" is to do an instanceof on the prototype?

[14:50:09.0000] <Domenic>
wanderview: I don't see how to make ByobReader opportunistic. E.g. no way to do https://gist.github.com/domenic/65921459ef7a31ec2839#reading-a-file-chunkwise (old API I think) without explicitly doing things with JS

[14:50:20.0000] <Domenic>
wanderview: check if what is available?

[14:50:34.0000] <wanderview>
Domenic: check if ByobReader is available on a RS, for example

[14:50:48.0000] <Domenic>
wanderview: if (rs.getByobReader) { ... }

[14:52:35.0000] <wanderview>
Domenic: can't see much difference between that and getByobReader() returning null if its not supported

[14:53:08.0000] <Domenic>
wanderview: it's just basic API design... we don't add everything onto a single object. New classes of objects get ... new classes.

[14:53:16.0000] <Domenic>
Node vs. Element, etc.

[14:53:39.0000] <wanderview>
Domenic: I think I dislike mixing that with the revealing constructor pattern... the constructor is not revealing all the behavior

[14:53:59.0000] <wanderview>
Domenic: if we had a revealing factory method that could construct the right type... it might seem a bit better to me

[14:54:36.0000] <Domenic>
wanderview: I don't see how they're related. Revealing constructor pattern lets you customize a type's behavior. You can have different revealing constructors for different types. We don't use the same type for Promise and ReadableStream, even though they both have customizable behavior via the revealing constructor pattern.

[14:54:50.0000] <Domenic>
why would you say the constructor is not revealing all the behavior?

[14:55:39.0000] <wanderview>
Domenic: why would you ever do new ReadableStream(myByteSource)?  shouldn't you *always* do new ReadableByteStream(myByteSource)?

[14:55:49.0000] <Domenic>
wanderview: yes?

[14:56:00.0000] <Domenic>
did i say otherwise?

[14:56:15.0000] <wanderview>
Domenic: no... but it feels weird to leave that as a footgun for people

[14:56:30.0000] <Domenic>
it's the same footgun as new Promise(myByteSource) ... not really worried.

[14:56:39.0000] <wanderview>
the type is really associated with the source, not the wrapper object

[14:56:47.0000] <Domenic>
or new WritableStream(myByteSource)

[14:57:06.0000] <wanderview>
Domenic: except those will fail... ReadableStream(myByteSource) will work, but just prevent consumers from optimizing

[14:57:10.0000] <Domenic>
The source is an adapter between the conceptual source and the concrete readable stream type

[14:57:18.0000] <Domenic>
wanderview: why would it work?

[14:58:24.0000] <wanderview>
Domenic: err... from what I can tell new ReadableStream() and new ReadableByteStream() expect the same properties on the passed duck typed source?

[14:58:31.0000] <wanderview>
is that not true?

[14:58:49.0000] <Domenic>
wanderview: the argument for ReadableByteStream() is not specced at all yet :)

[14:59:14.0000] <Domenic>
wanderview: it will probably be something like { start() { }, read(view), cancel(reason) { } }

[15:00:44.0000] <wanderview>
ok

[15:01:55.0000] <wanderview>
Domenic: going back to WritableByteStream... one optimization we have in our native streams is the writing side can pass its destination back into the person doing the write... so in theory this could be passed back to read(view) or something to all a ReadableByteStream to write directly into a WritableByteStream

[15:02:42.0000] <Domenic>
wanderview: good point, i forgot that was also something we definitely want out of ReadableByteStream + WritableByteStream pipes

[15:03:48.0000] <Domenic>
they can set up a small buffer pool and reuse buffers to limit total consumption and GC churn ... it will work beautifully ... /me waves his hands

[15:15:50.0000] <wanderview>
Domenic: sorry... I'm used to the DOM stuff which just enforces types and then says "using X's internal thing, do stuff"

[15:17:53.0000] <Domenic>
wanderview: np, just concerned about the layering in the design. Ideally *ByteStream should be additive and opt-in, both for consumers and from an architectural level.

[15:20:08.0000] <wanderview>
Domenic: to be honest, things like off-main-thread piping are mostly interesting to me for *ByteStream... for streams with potentially arbitrary js objects for chunks... not sure I can safely move those around off-thread

[15:20:18.0000] <wanderview>
not sure if that changes anything

[15:20:38.0000] <Domenic>
wanderview: oh, no, I was never really planning on them being off thread... but i want the model to not change drastically when you move from non-byte to byte streams

[15:21:21.0000] <Domenic>
wanderview: although I guess it could be pretty useful in some cases e.g. if a UA provided stream wants to pass metadata with each chunk like { remotePort, remoteAddress, data } or something instead of just data

[15:22:23.0000] <wanderview>
Domenic: I built a bunch of node stream libs to do that kind of thing before... not sure anyone really liked it much

[15:22:53.0000] <wanderview>
https://blog.wanderview.com/blog/2013/03/01/composable-object-streams/

[15:23:33.0000] <Domenic>
wanderview: do you have a summary of where we are on https://github.com/yutakahirano/fetch-with-streams/issues/30 ? when i went to bed last night i think we were convering on new Request({ body: readableStream }) + fetch(request, wsRevealer) + cache.add(request, wsRevealer) or similar. But then it changed overnight and now I am confused.

[15:24:08.0000] <wanderview>
Domenic: I think DOM APIs would prefer to return a structured webidl object with a stream property (like Response)

[15:24:29.0000] <Domenic>
?

[15:24:52.0000] <wanderview>
Domenic: I objected to putting wsRevealer on the consumer... because Request is no longer representative of the network request

[15:24:54.0000] <Domenic>
(I like the UDP object streams BTW!)

[15:25:05.0000] <Domenic>
Hmm was it ever?

[15:25:26.0000] <Domenic>
Isn't Request more like RequestMetadata?

[15:25:50.0000] <wanderview>
Domenic: no... before streams came into it, it contained all info to perform a network request

[15:25:52.0000] <wanderview>
including the body

[15:26:04.0000] <Domenic>
right, info to perform a network request, but not a network request itself....

[15:26:40.0000] <Domenic>
which is why you can store it in a cache; you can't store a network request in a cache...

[15:27:14.0000] <wanderview>
Domenic: correct... it is a representation of a possible network request... it is not an actual in progress network request... but if you move the body ws-revealer to fetch() then Request no longer fully describes the possible network request

[15:27:24.0000] <Domenic>
hmmm

[15:27:33.0000] <Domenic>
i guess that's true

[15:27:55.0000] <Domenic>
and ws-revealer is really "a sequence of instructions for how to create a body" so it still goes in the category of "representation of a possible network request"

[15:27:58.0000] <wanderview>
Domenic: look at my last proposal... it combines your WritableStream wrapper without the hard coded type switch

[15:28:12.0000] <Domenic>
Although I doubt you'll store the ws-revealer in the cache...

[15:28:39.0000] <Domenic>
Yeah, I liked that, although unsure how it fits with the rest of the discussion up until that point

[15:28:41.0000] <wanderview>
Domenic: well, right now Cache only supports GET... so can't put a body in... but if you could, Cache would trigger ws-revealer to get the body data

[15:29:00.0000] <wanderview>
I still have all the code in gecko to store Request bodies

[15:29:15.0000] <Domenic>
hmm i see

[15:29:24.0000] <Domenic>
yeah i guess that makes sense

[15:29:43.0000] <Domenic>
you reify the body whenever the request gets "committed" somewhere

[15:30:05.0000] <wanderview>
those are fancy words, but I will nod my head

[15:30:16.0000] <Domenic>
:P

[15:30:24.0000] <wanderview>
does reify just mean normalize?

[15:30:47.0000] <Domenic>
nah ... i'm thinking of it as, make a real set of bytes out of a function that represents a way to get bytes

[15:31:06.0000] <wanderview>
ah, ok... serialize then

[15:31:06.0000] <Domenic>
ws-revealer is a "potential body" that gets reified into a real body when you fetch/cache-add

[15:31:12.0000] <Domenic>
yeah that i guess

[15:31:32.0000] <wanderview>
I should look up that term I guess

[15:31:52.0000] <wanderview>
I have more of an EE background so I tend to get lost in the CS theory world

[15:32:13.0000] <Domenic>
might be a mathematician thing, I dunno. Or just a pretentious thing :P

[15:32:55.0000] <Domenic>
so the current proposal is req.{setWriter/pipeTo} plus ... body(ws) { ... } which gets triggered after setWriter/pipeTo plus ... do we allow body: readableStream?

[15:33:27.0000] <wanderview>
Domenic: I still want body: readableStream, yes

[15:33:37.0000] <Domenic>
poor overloaded body: option

[15:34:19.0000] <wanderview>
Domenic: didn't you hear?  fetch is mostly about sugar :-)

[15:35:47.0000] <wanderview>
Domenic: and to be clear... I only think we need this ws-revealer thing because of the desire to have progress notification that a pipe would obfuscate

[15:37:37.0000] <wanderview>
Domenic: btw... resolving the .write() promises when written to the kernel is going to be somewhat challenging... in gecko we get notification from the network code about progress in a different path from where we write... so we have to match that progress back up to the promises to resolve, etc

[15:37:46.0000] <wanderview>
maybe not challenging... but annoying

[15:39:06.0000] <Domenic>
:-S

[15:39:31.0000] <wanderview>
much easier to integrate that with a progress event (which is what it was designed for, of course)

[15:39:31.0000] <Domenic>
Well, there's https://github.com/whatwg/streams/issues/316 ...

[15:39:56.0000] <trevnorris>
wanderview: doubt this'll have any affect on the spec here, but in previous implementations I've had calls like .write() return a request object so you can trace the status at any point in the future.

[15:40:08.0000] <trevnorris>
e.g. .progress() to see how much has been written.

[15:40:21.0000] <trevnorris>
I use that in conjunction with timeouts to cancel writes that are taking too long.

[15:40:41.0000] <wanderview>
Domenic: for example, I think gecko network code throttles progress notifications to once every 50ms or something... so you will see batches of .write() promises resolves at the same time, etc.

[15:41:20.0000] <wanderview>
trevnorris: sounds like you want cancellable promises :-)

[15:41:29.0000] <wanderview>
/me trolls

[15:41:36.0000] <Domenic>
wanderview: lol, because the spec says 50 ms, good times :P

[15:41:41.0000] <trevnorris>
hehe. ;)

[15:45:51.0000] <trevnorris>
wanderview: is it possible to do something like: var req = ws.write(data); setTimeout(function(req) { if (req.status() != 'complete') req.abort(); }, 1000); ?

[15:47:04.0000] <wanderview>
trevnorris: I think you would have to call ws.abort() instead of req.abort()

[15:47:31.0000] <trevnorris>
wanderview: what if you did ws.write(data1) ws.write(data2) and I only wanted to abort writing data1?

[15:47:36.0000] <Domenic>
with cancelable promises you could do `var p = ws.write(data); setTimeout(() => p.cancel(), 1000). (Assuming calling p.cancel() does nothing on an already-settled promise)

[15:48:15.0000] <trevnorris>
already-settled promise?

[15:48:47.0000] <wanderview>
trevnorris: that seems racy to me... you may end up with data1 and data2 or just data2... also, not all write operations are abortable once they start, etc

[15:48:49.0000] <Domenic>
already fulfilled or rejected

[15:49:08.0000] <Domenic>
yeah, how does that work in POSIX?

[15:49:32.0000] <trevnorris>
wanderview: if you've queued up several chunks of data to be written, and only the first has actually been sent to the kernel it should be possible to remove any specific write req from the queue.

[15:50:03.0000] <wanderview>
trevnorris: in a multi-threaded environment... it may have been sent to the kernel and you just haven't been notified of it yet

[15:50:16.0000] <boogyman>
can you elaborate on a scenario where a Promise could be resolved while a "child" Promise has yet to resolve?

[15:50:18.0000] <bradleymeck>
its important to remember cancellation does not mean abrupt termination

[15:50:24.0000] <bradleymeck>
just that it should cancel at the next point

[15:50:44.0000] <Domenic>
boogyman: what is a child promise

[15:50:47.0000] <trevnorris>
wanderview: as soon as the data is handed off to something else I'll consider it unreachable. in the case of Node I know because we make the call to uv_write() directly.

[15:50:47.0000] <bradleymeck>
if there is not a clearly defines point of cancellation, something should not be cancellable

[15:51:03.0000] <bradleymeck>
defined*

[15:51:17.0000] <boogyman>
Domenic: however you define "p.cancel()" on an already resolved p

[15:51:26.0000] <Domenic>
i don't understand

[15:51:43.0000] <Domenic>
please phrase your question using code?

[15:51:45.0000] <wanderview>
trevnorris: "something else" is another thread?  or the kernel?  because in multi-process browsers it goes js->c++->IPC->c++->kernel with thread and process switches in there

[15:51:56.0000] <bradleymeck>
if cancellation is inteded to be similar to abort()/halting a thread it should be rethought

[15:52:21.0000] <bradleymeck>
/me can't type today

[15:52:24.0000] <wanderview>
right now ws.write() does not return a cancellable promise...

[15:52:29.0000] <wanderview>
this is all hand wving

[15:52:30.0000] <wanderview>
waving

[15:52:34.0000] <trevnorris>
wanderview: anything that takes control away from us over the lifetime of the data. but if I have an array of data chunks and only the first has been sent to uv_write() then the others should be able to be removed from their position in the queue.

[15:52:52.0000] <boogyman>
`var p = ws.write(data); setTimeout(() => p.cancel(), 1000). (Assuming calling p.cancel() does nothing on an already-settled promise) <-- Under what circumstance would be have already been resolved if it is dependent upon ws.write(data)

[15:53:17.0000] <boogyman>
would p.cancel()*

[15:53:42.0000] <wanderview>
trevnorris: does uv_write() do file writing on a separate IO thread or the main thread?

[15:53:48.0000] <Domenic>
boogyman: the adjective "resolved" does not apply to the function call p.cancel(), nor to its return value (which is undefined)

[15:53:52.0000] <trevnorris>
wanderview: main thread.

[15:53:57.0000] <bradleymeck>
wanderview: but I think at that point the cancellation point would be if the kernel gets it still, once it gets to the kernel it cannot be stopped, so attempts at cancellation would need to propagate to the C++ that flushes to the kernel, and if it has started flushing it is in an uncancellable state

[15:53:58.0000] <Domenic>
trevnorris: false?

[15:54:12.0000] <trevnorris>
wanderview: though I agree that if the data chunks were immediately sent to another thread to be written then we would have "lost control". thus cancel would only be a notification that we no longer need to be notified of its completion.

[15:54:14.0000] <trevnorris>
Domenic: eh?

[15:54:29.0000] <Domenic>
trevnorris: fs writes in io are done in a threadpool?

[15:54:44.0000] <wanderview>
trevnorris: ok, then you don't have to deal with the races I do... trying to pick out a single buffer to cancel is going to be hit or miss in browsers or other multi-threaded environments

[15:54:46.0000] <bradleymeck>
they are queued on the main thread though

[15:54:55.0000] <trevnorris>
Domenic: they're a special case. uv_wirte() and uv_try_write() is always done on the main thread.

[15:55:01.0000] <trevnorris>
*uv_write()

[15:55:05.0000] <bradleymeck>
?

[15:55:29.0000] <Domenic>
trevnorris: ah, I thought we were talking about file I/O since wanderview asked "does uv_write() do file writing". I guess uv_write is for sockets?

[15:55:44.0000] <trevnorris>
yes. sorry I missed that. uv_write() is only for sockets.

[15:56:00.0000] <trevnorris>
filesystem I/O is a pain thanks to kernel incompatibilities.

[15:56:00.0000] <Domenic>
gotcha

[15:56:02.0000] <wanderview>
Domenic: what I am getting is they treat the "write is complete" state when it leaves main thread... which might not quite be to kernel

[15:56:13.0000] <Domenic>
yeah

[15:56:16.0000] <wanderview>
Domenic: which is different from your goal of "bytes written to kernel"

[15:56:48.0000] <wanderview>
I'm not sure to-kernel is all that much better than an app internal checkpoint

[15:56:52.0000] <Domenic>
if you are sure that writes respect backpressure, maybe "accepted and queued" is a good enough proxy for upload progress...

[15:56:56.0000] <wanderview>
but willing to try to support it

[15:57:05.0000] <trevnorris>
it's possible to share memory on the req across threads so read-only fields can be used to check its status.

[15:57:39.0000] <wanderview>
trevnorris: you have an atomic check-and-set for cancellation across threads?

[15:57:53.0000] <bradleymeck>
wanderview: I think at either point cancellation is a suggestion to w/e you handed it off to

[15:58:08.0000] <bradleymeck>
it needs to be able to continue the work if it has started side effects already

[15:58:25.0000] <bradleymeck>
no real need for locking to my knowledge

[15:58:29.0000] <wanderview>
bradleymeck: exactly... I guess I was just getting at I find it hard to reason about the need to cancel buffer1 and let buffer2 through... when you cannot know if you got to buffer1 in time

[15:58:44.0000] <trevnorris>
wanderview: right now only have it so if I've queued up many small buffers to be written I can check how many of them have actually been sent to the kernel.

[15:58:54.0000] <bradleymeck>
i don't think you should be allowed to know at the time of cancellation

[15:59:33.0000] <trevnorris>
wanderview: streaming video for example. say you're buffering data to be written. it's better that frames are lost and the data stays current then making sure all the data goes through.

[16:00:30.0000] <bradleymeck>
wanderview: to rephrase, I cannot think of a good reason you should be allowed to know that buffer1 was cancelled before it calls .finally

[16:00:50.0000] <wanderview>
Domenic: I think we are still not on the same page here:  https://github.com/yutakahirano/fetch-with-streams/issues/30#issuecomment-91057900

[16:01:43.0000] <bradleymeck>
which to me resolves the problem of reasoning

[16:01:53.0000] <wanderview>
I guess I'm happy we don't yet allow canceling individual .write() calls... and if we did, I think it would very much have to be a "best effort"

[16:02:17.0000] <wanderview>
bradleymeck: sure... I think I understand better that its a best effort cancel, for example the video streaming case mentioned

[16:02:30.0000] <bradleymeck>
which is good, I want "best effort" and not guaranteed

[16:03:02.0000] <bradleymeck>
cause once side effects start / external systems are involved you need to let them resolve back to valid states (say if you have not finished writing)

[16:03:34.0000] <bradleymeck>
guaranteed cancel would require external systems to stay in valid and buffered states which is a no-no

[16:03:56.0000] <wanderview>
Domenic: I'll respond in bug... but I think very much "setWriter()" should function like a pipeTo()...  we could call it drainToWriter() or something if you want

[16:06:11.0000] <trevnorris>
wanderview: doing an atomic field set so the writing thread can check if the queue from another thread is still needed is very much possible.


2015-04-09
[17:25:44.0000] <wanderview>
Domenic: ok... I have data that shows multiple read() calls with a promise each is much slower than being able to read buffered chunks synchronously

[17:28:18.0000] <wanderview>
Domenic: talking 30x slower and up... thats with bluebird promises (SM promises are worse, as expected)

[17:30:54.0000] <wanderview>
Domenic: open this and look in your console: https://blog.wanderview.com/streams-promise-read/bluebird.html

[17:31:39.0000] <wanderview>
code is here: https://github.com/wanderview/streams-promise-read

[17:37:04.0000] <Domenic>
wanderview: needs I/O to be a real test

[17:37:16.0000] <Domenic>
 All you are testing there is promises vs. loops

[17:38:19.0000] <Domenic>
Not the impact of promises on streams

[17:42:31.0000] <zewt>
i wonder what middle-managery person at mozilla thought having a "start a conversation" button in the toolbar was a cool idea

[17:53:36.0000] <wanderview>
Domenic: its the case I described before... the I/O was done previously and written to a pipe... now a consumer is reading from a pipe to process it (perhaps all in memory)

[17:53:50.0000] <wanderview>
Domenic: this is the case you said "needs citation" above

[17:55:31.0000] <wanderview>
Domenic: from here:  http://logs.glob.uno/?c=freenode%23whatwg&s=8+Apr+2015&e=8+Apr+2015&h=citation#c944489

[18:11:59.0000] <Domenic>
wanderview: I must have misinterpreted. That's not streaming at all... Just buffering.

[18:12:55.0000] <wanderview>
Domenic: so buffering is not supported in this stream model?

[18:13:02.0000] <Domenic>
wanderview: a 1000-chunk high water Mark is unrealistic

[18:13:26.0000] <Domenic>
of course it is, but you shouldn't use a stream when you're just buffering all data in memory anyway

[18:13:51.0000] <wanderview>
Domenic: I'm not saying 1000 is realistic... but 10 chunks is a realistic bugger

[18:13:53.0000] <wanderview>
buffer

[18:14:09.0000] <Domenic>
A pipe should terminate in I/O on one side or the other

[18:14:32.0000] <wanderview>
Domenic: I thought you were gone for the evening so I wrote my thoughts here: https://github.com/whatwg/streams/issues/320#issuecomment-91083647

[18:15:19.0000] <Domenic>
If it takes x time to read from the pipe with promises, 0.04x time with batch, and 1000x time to put data in the pipe in the first place, I'm not too concerned.

[18:15:51.0000] <Domenic>
I kind of am gone, should probably turn off notifications :p

[18:16:03.0000] <wanderview>
Domenic: I feel like we've pessimized a common case in order to allow an optimization in obscure case later

[18:16:30.0000] <Domenic>
I do not think chunks being synchronously generated in a batch is common.

[18:17:12.0000] <Domenic>
Chunks come from somewhere, ultimately, perhaps after several transforms, but ultimately from I/O. This example does not show that.

[18:19:36.0000] <Domenic>
Just read your comment... 6 ms is a lot... Absolute numbers help.

[18:21:03.0000] <Domenic>
Except... 625 microseconds is actually 0.6 ms

[18:21:54.0000] <Domenic>
Oh, it's per chunk

[18:22:45.0000] <wanderview>
Domenic: yea, sorry... I was trying to make the number easier to compare... so I normalized per chunk

[18:22:52.0000] <Domenic>
Although I wonder if the code is just not hot enough for the optimizer to kick in for 10 chunks

[18:23:02.0000] <Domenic>
Maybe do 10 chunks in a loop or something

[18:23:26.0000] <wanderview>
Domenic: well, the higher number loops suggest the sync loop optimizes much better than the promise loop can be optimized... not surprising

[18:23:35.0000] <Domenic>
Or ten chunks every requestAnimationFrame, since eating the frame budget is the real concern

[18:23:49.0000] <TabAtkins>
Domenic: Yo, sorry for the digression, but random help here: it's a bad idea for an attribute to sometimes be updated sync and sometimes async, according to unknowable impl-specific criteria, right?

[18:24:17.0000] <Domenic>
I'm not concerned about the relative numbers (see my "x" comment above), but about eating 6 ms of frame budget

[18:24:50.0000] <Domenic>
TabAtkins: sounds bad, although I could imagine cases that fit that description which are probably ok?

[18:25:45.0000] <wanderview>
Domenic: if we expect this only to happen for modest buffer sizes... I don't see how we can expect the loop to get super hot

[18:25:52.0000] <TabAtkins>
Well, the case is whether a FontFace.status is set to "unloaded" or "loading".  Currently it's always async, but jdaggett/heycam want it to be set syncly when possible (font is a data url, a blob url, a cached font, etc)

[18:26:57.0000] <wanderview>
Domenic: anyway, I have to go crash and sleep for 12 hours... talk to you tomorrow!

[18:27:05.0000] <Domenic>
Cached sounds skeevy.... Others sound somewhat reasonable

[18:27:18.0000] <Domenic>
wanderview: ok cool, I'll probably fork your thing and experiment

[18:27:40.0000] <wanderview>
Domenic: please do... just don't judge me by my javascript :-)

[18:29:33.0000] <wanderview>
Domenic: btw... looking at the results I think the jit kicked in at 100 chunks... there was an across the board improvement there... the sync loop got another boost from some optimization going from 1000 chunks to 10,000 chunks... but the promise loop did not

[18:29:43.0000] <wanderview>
in spidermonkey of cours.e.. don't know what chrome does

[18:30:18.0000] <Domenic>
TabAtkins: I think some of the normal zalgo hazards don't apply here because I can't see a way for code to be written that assumes always sync or always async

[18:31:15.0000] <Domenic>
wanderview: yeah, we need to make sure the code is hot before benchmarking. Kinda pointless to measure non hot code since it doesn't need to be fast.

[18:31:39.0000] <TabAtkins>
Cached I definitely see - easy for a dev to accidentally work with cached fonts, and write broken code for users.

[18:32:01.0000] <TabAtkins>
And I can see some browsers considering some types of urls as sync, while others dont'.

[18:32:53.0000] <Domenic>
TabAtkins: but what kind of code would run into this? I would think conditionals on ff.status would work in either case.

[18:35:18.0000] <TabAtkins>
Man, I dunno. It just feels super icky to have a line in a spec that says "If you want you can do this part sync, lol i dunno"

[18:36:41.0000] <Domenic>
Yeah, it would have to be normative which cases are sync

[18:50:50.0000] <wanderview>
Domenic: yea, you are right... let me add a call to the tests to prime the jit

[19:01:45.0000] <wanderview>
Domenic: I think I agree the read() promise is fast enough for browsers... but also agree with trevnorris that its probably inadequate for what node.js needs... not sure we can get something that works perfectly for both

[02:49:39.0000] <zcorpan>
ok any opinions on naming? document.scrollingElement? document.viewportElement? https://lists.w3.org/Archives/Public/www-style/2015Apr/0108.html

[02:55:09.0000] <paul_irish>
document.viewportElement sgtm

[02:56:18.0000] <zcorpan>
thanks paul_irish

[04:12:38.0000] <roc>
scrollingElement

[04:12:52.0000] <roc>
viewportElement isn't correct

[04:17:04.0000] <zcorpan>
roc: it will be correct when webkit/blink have fixed scrollTop, no?

[04:20:57.0000] <zcorpan>
i guess background/overflow have different rules, but i think things would work as intended if this API is used for those also

[06:02:23.0000] <zcorpan>
mathiasbynens: wanna polyfill http://dev.w3.org/csswg/cssom-view/#dom-document-scrollingelement ?

[06:04:45.0000] <mathiasbynens>
zcorpan: sounds like fun! will do

[06:05:02.0000] <zcorpan>
:-)

[08:55:08.0000] <calvaris>
Domenic: I am writing more tests

[08:55:32.0000] <calvaris>
and it seems that I can construct if I pass undefined to the constructor

[08:55:56.0000] <calvaris>
which should be equivalent to pass no arguments, right?

[08:58:04.0000] <Ms2ger>
For optional arguments, yes

[08:58:10.0000] <Ms2ger>
For required arguments, no

[09:08:34.0000] <mcnesium>
my new wordpress does have a valid rss feed but safari on iOS and OSX do not show the "reader" sign. any idea what might be wrong? http://mcnesium.com

[09:37:00.0000] <calvaris>
in this case, the object can be constructed with no arguments, so we can assume argument is optional

[09:37:18.0000] <calvaris>
can't we?

[09:38:00.0000] <wanderview>
Domenic: do you know why the promise cases in the benchmark all take longer to settle than the sync cases?

[09:38:10.0000] <wanderview>
Domenic: is that just variability from runnables in the event queue?

[09:38:36.0000] <calvaris>
Ms2ger: ?

[09:39:57.0000] <calvaris>
I guess it is not

[09:40:53.0000] <calvaris>
because in myFunction(myArgument = {}) {} it is different to call myFunction() than myFunction(undefined)

[09:44:11.0000] <calvaris>
no, it's the same thing

[10:45:51.0000] <wanderview>
Domenic: can you explain again why we need async read() always on getReader()... instead of making getReader().read() sync and getByobReader.read() async?

[10:46:01.0000] <wanderview>
sorry... I know you've explained before

[10:54:26.0000] <caitp->
dunno his reasons, but if it's sometimes sync and sometimes async, that's not great for usability

[11:04:11.0000] <wanderview>
caitp-: no... its only async if you explicitly opt-in to the "bring my own buffer" optimization... and then its always async

[11:04:36.0000] <caitp->
yes, and then if you pass that reader to something that doesn't know you brought your own or not, it may or may not be async

[11:18:35.0000] <wanderview>
caitp-: that reader has its own type... they are not compatible with each other already

[11:39:09.0000] <caitp->
if they can be used the same way, you can probably expect that they would be

[11:49:48.0000] <wanderview>
caitp-: agree in principal, but not sure if its worth baking a performance penalty into getReader() just to satisfy aesthetic similarity to getByobReader()

[11:50:23.0000] <caitp->
i'm sure domenic's reasons are better ones

[11:50:45.0000] <caitp->
or at least, he's probably spending more time thinking about it =p

[14:36:17.0000] <wanderview>
hmm... does chrome has something like URLSearchParams?

[14:39:10.0000] <caitp>
doesn't look like it

[14:39:31.0000] <caitp>
well, "something like", probably just a JSObject

[14:41:38.0000] <caitp>
not even a JSObject

[14:41:48.0000] <caitp>
not exposed on the interface, and no TODO. should file :o

[14:47:19.0000] <caitp>
i guess it is filed

[14:51:22.0000] <wanderview>
yea... I guess that part of the URL spec just needs to be implemented

[14:52:54.0000] <jgraham>
Is there some way to tell if the origin of a page changed at some point (i.e. that document.domain was set)

[14:58:35.0000] <caitp>
there's no event triggered in the setter algorithm, or anything


2015-04-10
[17:15:46.0000] <Domenic>
wanderview: sorry for being afk for the day

[17:16:33.0000] <Domenic>
wanderview: I don't really know why the promises cases take longer to settle, but I could guess that it's more work to JIT through all the extra stuff that's going on.

[17:17:27.0000] <Domenic>
wanderview: I agree that the async read() only on byobReader design would work. I don't think they should have the same method name though... same-named methods on similar classes should behave the same I think.

[17:18:04.0000] <Domenic>
wanderview: but I think it's unfair to say performance penalty, as discussed/benchmarked :)

[17:54:48.0000] <wanderview>
Domenic: I have results that show a more significant perf penalty on mobile devices

[17:55:20.0000] <wanderview>
Domenic: I was trying to understand the FF native results before posting to the issue, but this is what I have so far:  https://docs.google.com/spreadsheets/d/1rl6mbD2z1x1bgJLD6y9KJLYWjppB7BujfiWvUMjYTVs/edit?usp=sharing

[17:56:04.0000] <wanderview>
Domenic: bluebird promises are always at a penalty compared to sync on my nexus5... native promises are also worse than sync for as few as 32 chunks

[17:56:36.0000] <wanderview>
I don't have the results in there, but my firefoxos Flame is even worse (as its a lower spec'd phone)

[17:58:18.0000] <wanderview>
Domenic: btw, the ?chunks= stuff in my test don't work with chrome because it doesn't implement URLSearchParams part of URL spec... do you know of a good alternative?  I'd like to run the test there

[17:58:50.0000] <wanderview>
Domenic: also, I added a size= option to control the size of the chunks... so I can set size=1 to avoid mixing in GC pressure from the buffers

[18:00:42.0000] <caitp>
is anything blocking URLSearchParams? didn't see any mention of blockers on arv's bug. seems like it would be a good gsoc project

[18:01:17.0000] <wanderview>
Domenic: also a chunks=auto to run all those chunk sizes in my google doc

[18:02:05.0000] <caitp>
or maybe too fast for gsoc, but a good starter project maybe

[18:03:49.0000] <wanderview>
I'm going to redo the google doc results with ?chunks=auto&size=1 for consistency

[18:10:00.0000] <wanderview>
hmm... I get different sync results when using native promise vs bluebird... probably from GC/CC differences... I think I will split sync out into a separate test

[18:11:01.0000] <caitp>
not sure how you're doing sync tests at all with promises

[18:11:40.0000] <wanderview>
caitp: its sync test, promise test, sync test, promise test, etc...  interleaved... I think objects left from promise runs are effecting sync runs due to GC

[18:11:53.0000] <caitp>
mm

[18:34:32.0000] <wanderview>
*much* more stable results moving sync and promise tests into separate windows

[20:00:37.0000] <wanderview>
actually... the test results were bogus... many of the results were being limited by setTimeout() clamping at 4ms

[20:31:38.0000] <wanderview>
summarized my profiling results in the issue:  https://github.com/whatwg/streams/issues/320#issuecomment-91418297

[23:43:47.0000] <hsivonen>
annevk: what's the story behind the codepoints of windows-1252 that Unicode.org leaves unassigned getting mapped to controls in the Encoding Standard? Did all browsers already agree to do that instead of U+FFFD?

[00:13:48.0000] <mcnesium>
my new wordpress does have a valid rss feed but safari on iOS and OSX do not show the "reader" sign. any idea what might be wrong? http://mcnesium.com

[01:10:58.0000] <annevk>
hsivonen: several browsers at least, yes

[01:11:32.0000] <annevk>
/me goes back into hiding

[03:53:41.0000] <zcorpan>
mathiasbynens: why recommend before </body> now that it uses a getter?

[03:58:22.0000] <mathiasbynens>
zcorpan: just the general best practice, since <script> blocks

[03:59:16.0000] <zcorpan>
mathiasbynens: k

[04:01:23.0000] <zcorpan>
mathiasbynens: i found http://johndyer.name/native-browser-get-set-properties-in-javascript/

[04:02:58.0000] <mathiasbynens>
zcorpan: In IE8, `Object.defineProperty` only works on DOM objects, so that’s fine in this case. Not sure if it’s worthwhile to add IE < 8 support

[04:06:28.0000] <zcorpan>
mathiasbynens: yeah. maybe not. i can point to that in the blog post if people need IE6-7 support (or other old browsers with __defineGetter__)

[04:07:03.0000] <zcorpan>
mathiasbynens: thanks for doing the polyfill

[09:20:47.0000] <smaug____>
is there some plan or API proposal for animation frame callbacks in workers?

[09:21:09.0000] <smaug____>
for the cases like webgl in workers

[09:43:32.0000] <espadrine>
smaug____: as in, having worker-only canvas contexts?

[09:45:13.0000] <espadrine>
there's this: https://wiki.whatwg.org/wiki/WorkerCanvas

[09:45:21.0000] <espadrine>
no idea what state it is in

[09:47:12.0000] <smaug____>
well, that is the canvas part, but I wonder if there is a plan to expose animation frame callbacks on worker side somehow

[10:06:56.0000] <zcorpan>
smaug____: sounds a bit like the "UI worker" idea

[10:07:45.0000] <zcorpan>
ask rick byers

[11:20:52.0000] <Domenic>
#lazyirc if I dispatch a click event on a radio button or checkbox, that should be the same as .click()ing it, right? and .click() should trigger an event?

[11:22:24.0000] <Domenic>
I guess testing this myself is the easiest thing to do, instead of reading the specs

[11:26:02.0000] <TabAtkins>
Domenic: Indeed. (To just testing it yourself, the specs are a rathole on this kind of thing usually.)

[11:55:45.0000] <Ms2ger>
Domenic, click() triggers event, not the other way around

[11:57:08.0000] <Domenic>
Right, but triggering the event also checks the box

[12:00:25.0000] <Ms2ger>
I don't believe it should

[12:00:27.0000] <Ms2ger>
smaug____, ^

[12:04:07.0000] <smaug____>
click() does trigger the link...

[12:04:58.0000] <smaug____>
in practice implementations dispatch click event and do default handling during the dispathc

[12:05:01.0000] <smaug____>
dispatch

[12:05:07.0000] <smaug____>
the spec has still the different model

[12:08:52.0000] <smaug____>
per spec dispatching click event shouldn't change the checked state, IIRC

[12:09:02.0000] <smaug____>
nor follow <a href="foo">

[12:09:16.0000] <smaug____>
but I think the web disagrees

[12:09:28.0000] <smaug____>
click is one of the special cases

[12:09:43.0000] <smaug____>
usually events must be trusted in order to trigger default action

[12:09:48.0000] <smaug____>
blink has tons of issues with this

[16:21:27.0000] <wanderview>
Domenic: it appears the native chrome promises clamp to 4ms delays like setTimeout... that seems like a pretty bad bug for promises

[16:21:41.0000] <Domenic>
wanderview: no waaaaayyyy

[16:21:55.0000] <wanderview>
I just made the defaults for the benchmark do the automated thing... so running the tests on chrome

[16:22:10.0000] <Domenic>
wanderview: I think benchmarkjs must be screwing us somehow... I trust it less :(

[16:22:40.0000] <wanderview>
Domenic: happy to fix it... but so far the data seems consistent to me

[16:23:13.0000] <Domenic>
wanderview: I am probably going to have to push off working on the benchmark until the weekend/Monday... today is running out of hours

[16:23:30.0000] <Domenic>
I'm excited about this user-space microtask queue idea

[16:23:33.0000] <wanderview>
Domenic: np... I will be offline until Monday... getting on a plane and then family time

[16:24:27.0000] <wanderview>
Domenic: it will be interesting to see the case of the js microtask and a pure js closure per callback.... thats still something to GC, but avoids some of the native promise wackyness

[16:26:48.0000] <wanderview>
Domenic: the reason I say chrome native promises are clamping... the benchmark shows ~210 ops/sec for the sync case with only 1 chunk...

[16:27:51.0000] <Domenic>
wanderview: so my guess is benchmarkjs uses setTimeout and so the most async benchmarkjs cases you can run is 250 ops/sec...

[16:30:08.0000] <wanderview>
Domenic: yes, but the promise.resolve().then(() => deferred.resolve()); should prevent the clamping from occurring, no?

[16:30:41.0000] <wanderview>
maybe we should try benchmark.js 2.0... jdalton indicated the sync deferred.resolve() is not permitted any more

[16:30:43.0000] <Domenic>
wanderview: I don't really understand how setTimeout clamping works so I'm not sure ...

[16:31:02.0000] <Domenic>
I am feeling a desire to go back to your manual tests, but just run them in a loop

[16:31:28.0000] <wanderview>
Domenic: if setTimeout() nests.. so setTimeout(() => setTimeout(() =>setTimeout()));...  if it nests 4 or 5 times it forces the delay to a minimum of 4ms

[16:31:48.0000] <wanderview>
its in the spec

[16:31:49.0000] <Domenic>
I think maybe in Chrome setTimeout() is just always clamped to 4ms

[16:31:58.0000] <Domenic>
I remember bugs

[16:32:10.0000] <wanderview>
in Firefox the microtask schedule breaks the nesting behavior because it forces the stack back to nothing... I think chrome should do the same, but it does not

[16:32:19.0000] <wanderview>
ah

[16:32:23.0000] <wanderview>
yea

[16:33:16.0000] <wanderview>
even with the clamping the benchmark is still useful to see the curve

[16:33:23.0000] <wanderview>
we just can't trust the ~210 values

[16:36:53.0000] <wanderview>
Domenic: I can also see that with chrome the CPU is not maxing out on the low tests... definitely the clamping

[16:38:48.0000] <wanderview>
I wonder if the perf penalty from promises really is GC of objects

[16:41:55.0000] <wanderview>
chrome on android does do better with bluebird promises...


2015-04-11
[17:33:36.0000] <Domenic>
Yeah promises would really benefit from GCs knowing about their existence... V8 is resistant to that idea. Maybe we can create a benchmark for Firefox to beat them on :)

[16:18:42.0000] <_Y_>
hello

[16:18:55.0000] <jgraham>
Why hello! ;)

[16:19:05.0000] <_Y_>
what a surprise  ;)

[16:19:19.0000] <_Y_>
annevk, you there?

[16:19:43.0000] <jgraham>
I expect annevk is asleep at the moment, it being rathter late in Europe

[16:19:56.0000] <_Y_>
oh, right, I forgot

[16:20:23.0000] <jgraham>
But if you ask questions than I think people read the logs / scrollback

[16:20:46.0000] <_Y_>
*nods*

[16:21:49.0000] <_Y_>
Background: I'm writing a parser for a very relaxed XML parser called XML5

[16:22:13.0000] <_Y_>
I'm working on implementing a entity references in attributes

[16:22:41.0000] <_Y_>
attributes can be single-quoted/double-quoted/unquoted

[16:23:52.0000] <_Y_>
So assuming someone wrote something akin to <a link=&foo > and forgot to add semicolon after &foo

[16:24:16.0000] <_Y_>
I want to recover and do something sensible

[16:24:55.0000] <_Y_>
so is it better for entity references to have a set of allowed characters or a set of characters that terminate them?

[16:25:53.0000] <_Y_>
And if so what would preferably this set be?

[16:31:03.0000] <_Y_>
Nvm the last question.

[16:32:36.0000] <_Y_>
spec is currently hosted at: https://ygg01.github.io/xml5_draft/

[16:34:25.0000] <jgraham>
FWIW I wonder if "do what HTML does

[16:34:32.0000] <jgraham>
" is a good enough answer

[16:37:54.0000] <_Y_>
usually it is

[16:38:25.0000] <_Y_>
I think this is complicated in HTML entity refs

[16:39:11.0000] <jgraham>
Well in HTML there's just a fixed list of entities and you find the longest match

[16:39:54.0000] <jgraham>
It's probably the system with the best error recovery

[16:40:44.0000] <_Y_>
right, but theoretically, you could extend the entity references

[16:43:33.0000] <jgraham>
Who could?

[16:43:52.0000] <_Y_>
If we allow a subset of DTD

[16:44:15.0000] <_Y_>
XML author

[16:44:48.0000] <jgraham>
Ah, well I wouldn't allow any of that

[16:44:56.0000] <jgraham>
Far too much trouble for almost no value

[16:46:33.0000] <_Y_>
Hm, so people rarely use DTD to define Entity references?

[16:46:45.0000] <_Y_>
I'm not aware of the use cases

[16:47:16.0000] <jgraham>
See also http://blog.jclark.com/2010/12/more-on-microxml.html which is another post-XML thing that never took off but that also suggests dropping the internal and external subsets

[16:52:17.0000] <jgraham>
I think really the only question here is whether, given some known entity &foo; &foowhatever is equivalent to &foo;whatever or not

[16:57:09.0000] <_Y_>
sounds good


2015-04-12
[17:04:04.0000] <_Y_>
jgraham: Your opinion as well, should I support additional references from HTML/SVG/MathML?

[17:04:18.0000] <_Y_>
In your opinion*

[17:05:04.0000] <_Y_>
should say &dash; and others be recognized in XML5?

[19:07:27.0000] <paul_irish>
I wish we renamed script[defer] back when we discovered it was unusable.

[19:08:18.0000] <paul_irish>
(the impl in IE8 and IE9 is broken such that the attribute cannot be used reliably)

[19:47:23.0000] <paul_irish>
Relatedly, what is the justification for script[async] being unallowed on inline scripts?

[19:52:16.0000] <paul_irish>
Semantics, looks like: https://www.w3.org/Bugs/Public/show_bug.cgi?id=7792 :/

[23:08:35.0000] <annevk>
paul_irish: seems more like hsivonen was concerned for document.write effects

[23:09:44.0000] <annevk>
I wonder if we introduced a sandbox flag for CSP to disable document.write() (either no-op or throw, don't really care) if we could introduce some interesting optimizations

[07:47:04.0000] <ericandrewlewis>
Why does an iframe lose its document when the node moves around in the DOM? (i.e. https://dl.dropboxusercontent.com/u/1062618/document-bye.mp4)

[07:57:51.0000] <jgraham>
Because not doing that isn't web compatible

[07:58:03.0000] <jgraham>
I'm not sure that there's a better answer

[07:58:22.0000] <ericandrewlewis>
I am intrigued by the sound of it - can you go verbose on that?

[07:58:59.0000] <caitp->
on the world wide web, a lot of mistakes were made, and continue to be made, that stick around to haunt you forever and can never be corrected

[07:59:09.0000] <jgraham>
Well I don't remember exactly, I just remember that we had to fix the behaviour for (presto) Opera to match other browsers

[07:59:40.0000] <jgraham>
Which suggests that there was a site that got broken if you didn't do a reload in that case

[08:00:25.0000] <ericandrewlewis>
So this is an implementation detail at the browser level rather than a spec-defined behavior?

[08:01:06.0000] <jgraham>
It will be a spec-defined behaviour now

[08:01:40.0000] <jgraham>
The idea is that there aren't user-observable undefined behaviours on the web-platform

[08:02:19.0000] <ericandrewlewis>
dig it


2015-04-13
[00:10:52.0000] <annevk>
MikeSmith: you around?

[00:11:09.0000] <annevk>
MikeSmith: are you okay with giving @dstorey access to platform.html5.org directly?

[00:28:26.0000] <MikeSmith>
annevk: here now

[00:28:39.0000] <MikeSmith>
yeah David should just have push access

[00:28:58.0000] <MikeSmith>
or even owner perms

[00:31:17.0000] <MikeSmith>
ah but if we give somebody owner perms to one repo then we hit the issue that then have owner perms for everything else in the whole whatwg github org too

[00:31:43.0000] <MikeSmith>
at least that's still the way the github ACLs worked last time I checked

[00:36:44.0000] <annevk>
MikeSmith: I added a team

[00:37:06.0000] <annevk>
MikeSmith: the new policy is that one of the owners creates a team for the repo and just adds people there

[00:37:13.0000] <annevk>
add*

[00:37:15.0000] <MikeSmith>
ok

[00:37:36.0000] <MikeSmith>
that's the best way I think

[01:39:35.0000] <zcorpan_>
hsivonen: your msdn quirks mode link appears broken. i found https://msdn.microsoft.com/en-us/library/gg558056(v=vs.85).aspx , not sure if it's the same as your original link

[01:42:34.0000] <zcorpan_>
hsivonen: or maybe https://msdn.microsoft.com/en-us/library/ff406036(v=vs.85).aspx or https://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx

[01:44:28.0000] <zcorpan_>
/me notes msdn has nice diagrams for this

[01:45:43.0000] <zcorpan_>
........ wat https://msdn.microsoft.com/en-us/library/hh834788(v=vs.85).aspx

[02:19:19.0000] <annevk>
MikeSmith: I also opened issues for whatwg/platform.html5.org

[02:21:09.0000] <pi->
I've been looking at how to handle a click at a particular location on a canvas that has been translated and rotated.  It seems that Canvas's context is lacking a getCurrentTransform().  A bit of googling finds https://bugzilla.mozilla.org/show_bug.cgi?id=408804 then https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/currentTransform

[02:21:37.0000] <pi->
It seems rather scary to me that such a basic thing still hasn't made its way in...

[02:23:58.0000] <pi->
https://html.spec.whatwg.org/multipage/scripting.html#transformations <-- it seems to be in the living standard. But only Chrome has implemented it as far as I can see.

[02:36:06.0000] <MikeSmith>
hsivonen: r? https://bugzilla.mozilla.org/attachment.cgi?id=8591559&action=edit

[02:36:14.0000] <MikeSmith>
annevk: issues? /me looks

[02:37:03.0000] <MikeSmith>
annevk: I guess you mean you enabled the issue tracker for the repo?

[02:37:05.0000] <annevk>
MikeSmith: you couldn't raise issues before, I don't think anyone has raised any yet though in the couple of minutes since I opened them ;-)

[02:37:09.0000] <MikeSmith>
hai

[02:37:26.0000] <MikeSmith>
I didn't know we didn't have it enabled before

[02:37:38.0000] <annevk>
Yeah surprised me too

[02:38:01.0000] <annevk>
In general I'm moving towards GitHub issues for specifications

[02:38:41.0000] <annevk>
Domenic was right

[02:41:36.0000] <MikeSmith>
yeah Github has won

[02:44:59.0000] <MikeSmith>
speaking of Github I wish the http://hg.mozilla.org/projects/htmlparser/ sources had a real home in Github

[02:45:39.0000] <MikeSmith>
I guess mozilla-central is mirrored in Github

[02:45:59.0000] <MikeSmith>
dunno why that projects tree isn't yet

[02:47:00.0000] <jgraham>
Because no one cares about it, I guess

[02:47:10.0000] <MikeSmith>
well that's sad then

[02:47:17.0000] <MikeSmith>
someone should care

[02:47:21.0000] <MikeSmith>
I mean, I care

[02:47:26.0000] <MikeSmith>
others should care like I do

[02:48:15.0000] <jgraham>
I guess there are higher priority things to work on than mirroring little-used trees onto gh

[02:48:41.0000] <MikeSmith>
christ

[02:48:57.0000] <MikeSmith>
yeah, that's the right attitude to have

[02:49:03.0000] <jgraham>
Honestly, you should be glad that no one has managed to get it moved into m-c yet

[02:49:09.0000] <MikeSmith>
heh

[02:49:16.0000] <MikeSmith>
true I guess

[02:49:29.0000] <MikeSmith>
point taken

[02:49:43.0000] <MikeSmith>
/me counts his blessings

[02:49:52.0000] <jgraham>
There's a group of people who believe that having a single repo with all Mozilla-related code in is a great idea because it solves versioning problems

[02:49:58.0000] <MikeSmith>
oh boy

[02:50:15.0000] <jgraham>
The argument is "it works for Facebook and Google, so it must be good"

[02:50:16.0000] <MikeSmith>
sure yeah it solves that one problem of course

[02:50:19.0000] <MikeSmith>
heh

[02:50:24.0000] <jgraham>
Seriously

[02:50:26.0000] <MikeSmith>
yeah I hear that argument a lot

[02:50:28.0000] <MikeSmith>
jesus

[02:50:46.0000] <MikeSmith>
well those people should get re-educated

[02:51:37.0000] <jgraham>
Anyway, I'm hoping that pointing out that Facebook and Google have ~0 external contributers whereas Mozilla has many is enoeugh of a clue that we might have different needs

[02:51:48.0000] <MikeSmith>
bingo

[02:52:13.0000] <annevk>
MikeSmith: you could start a GitHub mirror perhaps?

[02:52:20.0000] <MikeSmith>
jgraham: well please continue to fight the good fight there

[02:52:38.0000] <MikeSmith>
annevk: did already https://github.com/validator/htmlparser/

[02:52:54.0000] <MikeSmith>
I just prefer to make other people do work for me whenever I can

[02:53:44.0000] <MikeSmith>
not that it's a huge amount of work

[02:53:54.0000] <MikeSmith>
but I just don't have it automated

[02:54:21.0000] <MikeSmith>
the mirroring I mean

[02:54:25.0000] <MikeSmith>
I could automate more of it instead of complaining

[02:54:46.0000] <jgraham>
MikeSmith: It's possible that if you file a bug on releng they could add it to the list of repos mirrored on gh

[02:54:54.0000] <MikeSmith>
oh

[02:54:56.0000] <MikeSmith>
ok

[02:55:08.0000] <MikeSmith>
will do that

[04:00:01.0000] <annevk>
JakeA: alternative API would be to expose client request contexts as a static on Request; might also be useful for other things; or we could have both, meh

[04:03:05.0000] <annevk>
Question about English, if you have "the range 0x00 to 0xFF" is that unambiguous or should I really start using "the range 0x00 to 0xFF inclusive"? Does the latter notation require a comma?

[04:03:52.0000] <annevk>
This affects the Encoding Standard the most, but also various other features elsewhere

[04:04:49.0000] <jgraham>
I think people assume inclusive unless otherwise stated, but a mathematician would be annoyed by the lack of specificity

[04:05:43.0000] <annevk>
English or American mathematician?

[04:06:01.0000] <jgraham>
Either?

[04:06:57.0000] <annevk>
It seems ECMAScript uses both styles (with a comma for the latter)

[04:08:58.0000] <annevk>
Hmm, ECMAScript uses a number of styles...

[04:10:52.0000] <annevk>
jgraham: I guess I should start adding ", inclusive" then or use "the inclusive range"...

[04:11:30.0000] <jgraham>
I prefer ", inclusive" fwiw

[04:12:07.0000] <annevk>
jgraham: any particular reason?

[04:12:40.0000] <annevk>
jgraham: so that the word is closer to the actual range?

[04:12:43.0000] <jgraham>
It sounds better

[04:13:34.0000] <Ms2ger>
As a mathematician, this isn't anywhere near the top of my specificity complaints :)

[04:14:09.0000] <annevk>
Are we now talking CSS?

[04:14:34.0000] <Ms2ger>
Ha

[04:15:38.0000] <jgraham>
As a non-mathematician, my top specificity complaint is Ms2ger's lack of specificity about his top specificity complaints

[04:16:28.0000] <Ms2ger>
Go look at dark matter :)

[04:17:31.0000] <jgraham>
The thing about dark matter, it's main distinguishing feature, is that it's dark.

[04:17:58.0000] <MikeSmith>
heh

[04:18:16.0000] <jgraham>
(with apologies to Red Dwarf)

[04:18:45.0000] <jgraham>
Although they probably didn't put in a bogus apostrophy

[04:18:45.0000] <MikeSmith>
https://twitter.com/robinberjon/status/587564856406122496 from darobin

[04:19:17.0000] <MikeSmith>
"Have any of you tried https://reviewable.io/  for GitHub code reviews? I’d love to hear how you feel it compares to Critic for instance."

[04:19:54.0000] <jgraham>
MikeSmith: So would I

[04:20:11.0000] <jgraham>
I imagine it's more polished, at least :)

[04:20:55.0000] <MikeSmith>
that's not stretching your imagination much 😀

[04:21:27.0000] <MikeSmith>
personally I guess I don't care so much about polish

[04:21:37.0000] <MikeSmith>
I think Critic gets the job done pretty well

[04:22:07.0000] <jgraham>
Seems like the sort of thing that is hoping to exit by being bought by Google and then shut down. Or, in the best case, GitHub and then shut down.

[04:22:10.0000] <MikeSmith>
the Critic UX quirks aren't too painful

[04:22:18.0000] <MikeSmith>
yeah maybe so

[04:22:58.0000] <MikeSmith>
anyway I guess I should take a look

[04:23:09.0000] <MikeSmith>
might actually be good

[04:23:30.0000] <jgraham>
Yeah, yeah, I agree, it might be great!

[04:23:46.0000] <jgraham>
I have to say I'm baffled by the UI at first glance though

[04:23:56.0000] <MikeSmith>
yeah?

[04:24:43.0000] <MikeSmith>
I would think for $279 / month you shouldn't be initially baffled by the UI

[04:24:49.0000] <jgraham>
Well https://reviewable.io/reviews/Reviewable/demo/1 has a table with like 3 different barely-distinguishable colours and some eye icons and some brackets that move when you click

[04:24:59.0000] <MikeSmith>
/me looks

[04:25:00.0000] <jgraham>
And I don't know what any of that means :)

[04:25:40.0000] <MikeSmith>
oh man yeah

[04:26:04.0000] <jgraham>
Oh, the brackets seem to be a revision range, but I'm not sure where that applies

[04:26:58.0000] <MikeSmith>
yeah it lets you narrow to the range

[04:27:05.0000] <MikeSmith>
what range I don't know

[04:27:12.0000] <MikeSmith>
are they revision numbers?

[04:27:29.0000] <MikeSmith>
what are r1-r4

[04:28:40.0000] <MikeSmith>
and what is that upside-down T thing

[04:29:19.0000] <MikeSmith>
no tooltips on hover to provide clues

[04:31:03.0000] <jgraham>
MikeSmith: Anyway I would say set it up on some repo and try it out

[04:31:51.0000] <MikeSmith>
I think I will wait for darobin to do that

[04:32:29.0000] <MikeSmith>
my initial reaction is that it's no less unintuitive than Critic is

[04:32:40.0000] <MikeSmith>
and wouldn't seem to have any less of a learning curve

[04:34:45.0000] <JakeA>
annevk: in terms of ranges, I think being specific is best. "You can take between 3 and 5 sweets", I assume taking 3 and 5 is acceptable. "Drinks are cheaper between 15:00-17:00", I assume drinks are more expensive at 17:00.

[05:09:30.0000] <annevk>
jgraham: JakeA: here's Fetch using ", inclusive": https://github.com/whatwg/fetch/commit/6bfbf2c55fe4991bb9b4b2f5c0377fdd626aa58f

[05:10:15.0000] <JakeA>
+1

[05:14:44.0000] <jgraham>
annevk: Looks good.

[05:27:49.0000] <darobin>
MikeSmith, jgraham: part of my interest isn't just the UI (which seems to be more or less on par with Critic except with nicer colours) but also the ease of setting up for new repos

[05:29:37.0000] <jgraham>
darobin: Weirdly (and I never thought I would say this), I dispute the nicer colours :p I acutally found the use of colour hard to understand.

[05:30:52.0000] <darobin>
jgraham: yeah, it's a matter of taste there, I fully agree

[05:32:25.0000] <jgraham>
FWIW, if I were looking for alternatives to critic, "easier to set up" would not be a big deciding factor. I mean critic is not that hard to set up. "Better supported", "more reliable" and "equally good workflow" would be the deciding aspects for me

[05:34:50.0000] <jgraham>
My main concern with using it would be whether it's going to be Yet Another Shortlived-Sharecropping-Startup

[05:58:24.0000] <darobin>
jgraham++ # Galápagos Syndrome

[05:58:48.0000] <darobin>
jgraham: yeah, I just wanted to put it out there as an option for people to experiment with

[05:58:57.0000] <darobin>
if it does get used, we'll need a way to back up the data

[06:00:52.0000] <annevk>
Domenic: any reason streams expose a view rather than the buffer?

[06:00:53.0000] <annevk>
Domenic: https://github.com/yutakahirano/fetch-with-streams/pull/34

[06:43:56.0000] <wanderview>
annevk: my guess is its a convenience

[06:44:02.0000] <wanderview>
but an opinionated one

[06:45:54.0000] <annevk>
wanderview: yeah, it seems you might get network data you want to read as int32 or some such

[06:46:14.0000] <wanderview>
annevk: I wrote in the issue... but you can use .buffer to convert to the other view

[06:46:17.0000] <wanderview>
I believe

[06:46:21.0000] <annevk>
wanderview: sure

[06:46:33.0000] <annevk>
wanderview: but that's still a layer of abstraction added that you might not need/want

[06:46:42.0000] <wanderview>
annevk: I think this is really people saying "I don't like ArrayBuffer" :-)

[06:46:42.0000] <annevk>
wanderview: and an extra object allocation

[06:47:16.0000] <annevk>
wanderview: well, Typed Arrays happened and TC39 let it go

[07:13:52.0000] <wanderview>
Domenic: do envision types like ReadableStream being DOM interfaces or being part of the js engine?

[07:14:21.0000] <wanderview>
Domenic: asking since streams is a whatwg spec... which I guess seems DOM related to me and less a language thing

[07:14:25.0000] <annevk>
wanderview: he prefers that they are indistinguishable

[07:16:02.0000] <wanderview>
annevk: from content sure

[07:36:41.0000] <Ms2ger>
https://github.com/servo/html5ever/pull/125

[07:37:54.0000] <Domenic>
wanderview: this is an area where my view of the world and what is differ enough that my opinion shouldn't be taken too seriously ... IMO I think URL, Encoding, and Streams should all be implemented as part of the JS engine. In reality, V8 at least says they'd rather only have one standards body to look to for consensus on what to implement.

[07:39:12.0000] <Domenic>
annevk: a view gives the tuple (buffer, bytesRead, offset) https://esdiscuss.org/topic/idiomatic-representation-of-buffer-bytesread which is useful when re-using buffers

[07:41:01.0000] <annevk>
Domenic: I see, so we assume some kind of new transfer semantic to appear?

[07:41:12.0000] <annevk>
Domenic: that we don't want developers to use themselves?

[07:41:21.0000] <wanderview>
Domenic: in the long run I probably want the outer stream objects (ReadableStream/WritableStream) in spidermonkey so I can self-host and avoid js->c++->js penalties for pure js streams

[07:42:53.0000] <Domenic>
annevk: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/transfer

[07:43:07.0000] <Domenic>
wanderview: yeah that's what Safari seems to be doing looking at their code

[07:43:27.0000] <annevk>
Domenic: sure, but your proposal is that streams invokes that API rather than the developer, right?

[07:43:58.0000] <Domenic>
annevk: yeah, it hides it from them in general, since it needs to enforce that the buffers get detached.

[07:44:56.0000] <Domenic>
wanderview: and I'm going to Munich in a week to work on self-hosted streams as a "V8 extension"... would still live inside the Blink codebase though

[07:45:31.0000] <annevk>
Domenic: you won't be in SF the week of April 20?

[07:45:35.0000] <wanderview>
Domenic: I think I'm going to try to get some kind of system level test running

[07:45:41.0000] <Domenic>
annevk: only the 24th... regretting it now

[07:46:15.0000] <annevk>
Domenic: say hi to Jochen and Mike :-)

[07:46:34.0000] <Domenic>
annevk: oh yeah don't you live nearby there now?

[07:47:08.0000] <annevk>
Domenic: reasonably but still some mountains away

[07:48:25.0000] <annevk>
/me is trying to digest the ArrayBufferView vs ArrayBuffer arguments

[07:49:41.0000] <caitp>
... is mootools broken by es6 again?

[07:49:57.0000] <caitp>
it never ends :>

[07:50:23.0000] <Domenic>
we must make a pact to no longer implement any es6 features until jsfiddle stops using mootools

[07:50:50.0000] <gsnedders>
caitp: this happened with ES5 too

[07:51:08.0000] <caitp>
yes

[07:53:07.0000] <wanderview>
Domenic: the test I am planning:  node server that constantly sends Message blocks containing a timestamp, fetch() body stream, Transform to parse Message blocks, WritableStream consumer that does fetch() PUT to send timestamp back to server, server compares current time to received timestamp

[07:53:38.0000] <wanderview>
Domenic: then I will measure throughput (messages per second) and latency (timestamp differences)

[07:53:47.0000] <wanderview>
Domenic: is that an adequate system test for you?

[07:54:18.0000] <gsnedders>
It's sad that Mootools is still causing this much in way of problems and didn't fix all the problems when it first happened…

[07:54:35.0000] <wanderview>
maybe an extra Transform in there to trigger .read() on the output of parse Transform

[07:54:38.0000] <Domenic>
wanderview: yes, thank you :). Will you be doing tests of e.g. manually-scheduled microtasks to eliminate impl-specific promise overhead? (I haven't caught up on that thread yet.)

[07:54:41.0000] <wanderview>
or just a manual read loop

[07:54:58.0000] <wanderview>
Domenic: I was not planning to do manually scheduled microtasks, no...

[07:55:32.0000] <wanderview>
Domenic: I was just going to prototype fetch body streams to test possible implementations in the browser...  if I can do it in a day or two

[07:56:13.0000] <Domenic>
wanderview: I think that would be prudent. Unless we believe promises will be forever slow, we shouldn't necessarily draw conclusions from their current performance, but instead look at the performance of lower-level primitives like microtasks.

[07:56:21.0000] <wanderview>
Domenic: the code trevnorris posted suggests to me its not the async schedule that was the problem, but instead the GC/CC

[07:56:59.0000] <Domenic>
wanderview: right, so the question is do we ever believe promises will get good GC support, or do we design against the current landscape?

[07:57:09.0000] <wanderview>
Domenic: its really hard to reason about possible future optimizations...

[07:57:24.0000] <wanderview>
Domenic: unless its a well known optimization as was the case with the "generators make a function each time" thing

[07:57:42.0000] <wanderview>
^function^objet

[07:57:45.0000] <wanderview>
object

[07:57:56.0000] <Domenic>
well, I'm no expert, but it seems like there are two well-known optimizations here that are not being applied (although they might be hard)

[07:58:03.0000] <Domenic>
1) for p.then(), if the return value is not used, don't allocate it

[07:58:50.0000] <Domenic>
2) for var q = p.then(f, r); var w = q.then(f2, r2), since q only lives for one turn, make sure it stays in the young generation

[07:59:18.0000] <wanderview>
Domenic: I asked about (2) today... its unclear if we can do that in gecko any time soon

[08:00:00.0000] <annevk>
Maybe ask Mark Miller? He's been doing research into this for a long time, no?

[08:00:01.0000] <Domenic>
same in V8

[08:00:30.0000] <Domenic>
just unclear we want to design an API to work around it, or we want to use the existence of an API that stress-tests promises to put pressure on the engines to compete on performance

[08:01:17.0000] <wanderview>
Domenic: if we have a real system test we can also more easily profile to see what the bottle neck is... maybe reason about what possible optimizations would do

[08:01:20.0000] <Domenic>
i wonder what chakra does...

[08:01:26.0000] <Domenic>
wanderview: yeah, that's a good point

[08:01:33.0000] <wanderview>
Domenic: if its GC/CC, though... I guess thats hard to predict

[08:01:43.0000] <Domenic>
e.g. sub in a promise implementation that is non-comformant and doesn't return anything from .then

[08:02:00.0000] <wanderview>
Domenic: my gut is that we are unlikely to see 300% improvements... but maybe there is a tipping point for number of objects which would grant that kind of improvement

[08:02:11.0000] <bradleymeck>
Domenic: can you go into a bit more depth on #1 , it seems like it would need to know if the promise will eventually have a .then attached?

[08:02:25.0000] <Domenic>
bradleymeck: I meant in the case where it clearly does not, via escape analysis

[08:02:35.0000] <bradleymeck>
ah

[08:03:03.0000] <wanderview>
Domenic: also, I was going to implement sync, async-with-promise, and async-with-callback if I can

[08:03:08.0000] <wanderview>
if I can without clamping the callback

[08:03:09.0000] <Domenic>
bradleymeck: like the code literally `p.then(f, r)`, the return value is not used (equivalent to `{ let q = p.then(f, r); }`)

[08:03:11.0000] <bradleymeck>
I would love more escape analysis optimizations they are fancy and can do magical things

[08:03:19.0000] <wanderview>
I think I can expose an intrinsic which does that

[08:03:21.0000] <bradleymeck>
yea, that would be nice

[08:03:39.0000] <Domenic>
wanderview: yeah makes sense, the general integration-test-framework seems like a great place to start with and then tweak the guts of.

[08:04:07.0000] <Domenic>
wanderview: also I think we should not trust benchmark.js and just do more manual looping... or at least make it optional... I think it is largely the source of our timer woes

[08:04:08.0000] <wanderview>
Domenic: my only fear is that this may take me a week or so... and the implementation of async read ship is sailing away

[08:04:31.0000] <wanderview>
Domenic: you brought benchmark.js to the party :-)

[08:04:37.0000] <wanderview>
but sure

[08:04:54.0000] <Domenic>
yeah, well we needed something that would run the test more than once to get rid of the crazy variance, but little did i know...

[08:05:14.0000] <wanderview>
Domenic: I'm just going to let this thing run open loop... stream data from server to browser and back to server as fast as possible... then dump latency and throughput number continuously

[08:05:26.0000] <MikeSmith>
annevk: it seems like https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit should have some attribution

[08:05:28.0000] <wanderview>
well... periodically

[08:05:49.0000] <bradleymeck>
wanderview: post it somewhere public? would like other people's benchmarks that aren't from me or trevor

[08:06:12.0000] <MikeSmith>
annevk: somebody just browsing to that URL from somehwere may otherwise have no clue where it came from

[08:06:38.0000] <wanderview>
bradleymeck: of course!  it will be in the github issue once its working

[08:06:45.0000] <bradleymeck>
<3

[08:07:06.0000] <annevk>
MikeSmith: I recommend asking Richard Barnes directly, not sure I have editing rights

[08:07:16.0000] <wanderview>
/me steps away for a bit

[08:07:41.0000] <MikeSmith>
annevk: ok

[09:17:58.0000] <SamB_7>
Is https://whatwg.org/style/specification in a repository somewhere?

[09:18:39.0000] <Domenic>
I really wish it were

[09:20:53.0000] <darobin>
heh

[09:21:19.0000] <zcorpan>
Hixie: ^

[09:21:33.0000] <darobin>
that should really go into https://github.com/whatwg/resources.whatwg.org

[09:21:49.0000] <SamB_7>
you'd think, yeah

[09:30:11.0000] <Domenic>
I think Allen just adopted another piece of https://streams.spec.whatwg.org/#conventions ... ES spec is slowly becoming more readable. https://bugs.ecmascript.org/show_bug.cgi?id=4273

[09:30:27.0000] <Domenic>
(Streams's "call-with-rethrow" => ES's new "Perform")

[09:37:05.0000] <annevk_>
Domenic: maybe not: https://twitter.com/awbjs/status/587654507997167618

[09:37:19.0000] <Domenic>
oh :(

[09:37:51.0000] <Domenic>
I think we have some of those, but honestly I'd rather do something like Assert-does-not-throw

[09:40:16.0000] <wanderview>
Domenic: do you think it would be possible to make the ReadableStream lock a function of the underlying source?

[09:40:25.0000] <Domenic>
wanderview: hmm say more...

[09:41:04.0000] <wanderview>
Domenic: for the case where the underlying source is native... its really the place I want to lock instead of js outer object... for example, to prevent Response.text() which is also implemented in c++

[09:41:40.0000] <wanderview>
I guess I can do this with equivalent magic, but doesn't need to be in the spec

[09:41:43.0000] <Domenic>
wanderview: hmm does this have user-observable implications though?

[09:41:47.0000] <Domenic>
yeah

[09:41:55.0000] <Domenic>
I mean conceptually Response.text() does this.body.getReader()

[09:42:04.0000] <Domenic>
And presumably will be specced that way?

[09:42:32.0000] <Domenic>
But I'm open to ideas here if we can develop them a bit more.

[09:42:34.0000] <wanderview>
Domenic: I don't remember what the fetch-with-streams thing says

[09:43:52.0000] <Domenic>
ah yeah it does. They all indirect through "Response's associated consume body algorithm" which acquires a reader

[09:44:22.0000] <SamB_7>
what is this "lock" of which you speak?

[09:44:32.0000] <Domenic>
It then says "Let chunks be the result of using implementation-specific mechanisms to repeatedly read from stream, using the exclusive access granted by reader, until stream becomes closed or errored." which IMO is a nice turn of phrase.

[09:44:37.0000] <SamB_7>
did JS get threading or something?

[09:44:41.0000] <Domenic>
SamB_7: https://streams.spec.whatwg.org/#locking

[09:44:47.0000] <wanderview>
SamB_7: its a lock on a stream

[10:01:06.0000] <annevk>
Domenic: I don't understand the reusing buffers argument and I'm having trouble finding a good reference for it

[10:01:17.0000] <Domenic>
annevk: let me update one of the old examples

[10:03:49.0000] <wanderview>
Domenic: btw, if you think you will have a self-hosted Transform next week, we could run my integration test in both firefox and chrome... that would help isolate implementation issues

[10:06:11.0000] <wanderview>
Domenic: tyoshino's patch to remove setTimeout from benchmark.js does help a lot, btw... even bluebird avoids the clamping now

[10:09:31.0000] <Domenic>
annevk: https://gist.github.com/domenic/dab9e8da245cb4fe6027

[10:10:09.0000] <Domenic>
wanderview: hmm ok, I can try to do that... hmm.

[10:10:32.0000] <Domenic>
/me lunches

[10:11:13.0000] <annevk>
Domenic: doesn't that reuse the view, not the buffer?

[10:18:30.0000] <annevk>
I think I sort of get it now

[10:20:17.0000] <SamB_7>
/me wonders why the underlying source wouldn't just be locked to the stream itself?

[10:48:50.0000] <Domenic>
annevk: each result.value is a distinct view, backed by the same buffer

[11:50:24.0000] <annevk>
Domenic: but different parts of that buffer?

[11:50:57.0000] <Domenic>
annevk: nah same part, when you're passing it back in to .read() you're saying "I don't want these bytes any more, please overwrite them."

[11:50:57.0000] <annevk>
Domenic: what happens to the old references of the buffer while you write to it asynchronously?

[11:51:25.0000] <Domenic>
annevk: ok, I have to be more careful about what I mean by same "buffer." Different array buffer, same backing memory

[11:51:55.0000] <annevk>
Domenic: so how can that not work if you simply return an ArrayBuffer?

[11:52:07.0000] <Domenic>
annevk: we'd need to return { buffer, bytesRead }

[11:52:42.0000] <annevk>
Domenic: why can't you allocate an ArrayBuffer of the correct size?

[11:53:15.0000] <Domenic>
annevk: because then it will continually shrink as you keep passing it through the funnel...

[11:54:09.0000] <Domenic>
(typing out a scenario here)

[11:54:16.0000] <annevk>
I guess I was imagining you'd have chunk size separate

[11:55:04.0000] <annevk>
and just allocate for whatever you read

[11:55:29.0000] <Domenic>
Allocate 10 MiB ArrayBuffer ab. Pass it into read() which transfers it to a new 10 MiB ArrayBuffer ab2 and then passes that to read(2) or equivalent. read(2) only gets 2 MiB from the socket. So now we transfer the backing memory to a new ArrayBuffer ab3 of size 2 MiB, which we return the user. But what happened to the extra 8 MiB? It was released as free

[11:55:29.0000] <Domenic>
since nobody has an ArrayBuffer that references it anymore.

[11:56:50.0000] <Domenic>
(so now you pass back in ab3 to another call to read(), but the most you can get is 2 MiB... maybe it gives you back 512 KiB, freeing the other 1.5 MiB ... sad times.)

[11:59:21.0000] <Domenic>
If we didn't have to do the transfer thing, we could just return Promise<number of bytes read> and modify the buffer in place

[11:59:56.0000] <Domenic>
Since we have to transfer it becomes Promise<{ newBufferWithSameBackingMemory, bytesRead }>, which we collapse into Promise<ABC>

[12:00:00.0000] <Domenic>
*ABV

[12:01:53.0000] <annevk>
Thanks for going into detail

[12:02:03.0000] <annevk>
Sounds reasonable, will probably have to review tomorrow

[12:02:18.0000] <Domenic>
any time, thanks for the review

[12:40:41.0000] <miketaylr>
zcorpan: too speedy https://cloudup.com/cbFFdNafldu

[12:41:49.0000] <wanderview>
Domenic: I guess I would slice the buffer if the "available bytes" was something huge... cap it some value to avoid blowing up memory with a single contiguous buffer

[12:42:16.0000] <zcorpan>
miketaylr: ba dum tsss

[12:57:58.0000] <Domenic>
TabAtkins: any way to do appendices in Bikeshed?

[12:58:54.0000] <TabAtkins>
Domenic: I mean, you can just add an appendix.  It's a section like any other.  What are you wanting, specifically?

[12:59:46.0000] <Domenic>
TabAtkins: starting with A instead of a number, I guess.

[13:00:01.0000] <TabAtkins>
Nothing special for that, no.

[13:00:11.0000] <TabAtkins>
Just put "Appendix A: Foo" in the title.

[13:00:27.0000] <Domenic>
heh "7: Appendix A: Foo"

[13:00:36.0000] <TabAtkins>
<h2 class="no-num">

[13:00:43.0000] <Domenic>
Right!

[13:40:32.0000] <terinjokes>
what does "These attributes are not intended for use by software that is not known to the administrators of the site that uses the attributes."

[13:40:38.0000] <terinjokes>
mean (from the HTML5 spec)

[13:43:48.0000] <caitp->
i think it means "there are no standard data-* attributes that client software can depend on being there, if you need that, use microdata"

[13:46:05.0000] <terinjokes>
caitp-: so data-* should only be used by JS the client themselves write?

[13:46:14.0000] <caitp->
i guess

[13:46:24.0000] <caitp->
or whatever libraries they want to use

[13:46:32.0000] <caitp->
but not client software

[13:46:34.0000] <terinjokes>
or if they include my script, me using those data attributes are acceptable

[13:47:10.0000] <terinjokes>
cool. we had a small discussion with a customer about what it means

[13:47:33.0000] <caitp->
i'd ask hixie or someone for clarification, maybe they meant something else, but that's how it reads to me

[13:48:12.0000] <caitp->
like, google shouldn't be using data- attributes to help rank a site

[13:49:23.0000] <terinjokes>
right, that makes sense

[13:51:49.0000] <TabAtkins>
That's correct.  data-* aren't meant to be used for standardized markup across unrelated documents.

[13:52:56.0000] <terinjokes>
and i assume that using attributes that do no exist are bad (as they might have future specified manning, ala JavaScript prototype fun)

[13:54:33.0000] <bradleymeck>
terinjokes: you can upgrade from dangerous prefixes to unprefixed (css prefix fiasco), the reverse is more difficult (ala js prototype madness)

[13:55:44.0000] <terinjokes>
bradleymeck: yep, yep

[13:55:51.0000] <terinjokes>
/me spends 5 minutes fixing the bug


2015-04-14
[18:57:01.0000] <MikeSmith>
annevk: systeam updated https://lists.w3.org/Archives/Public/public-whatwg-archive/ to include complete links back to April 2004

[18:57:17.0000] <MikeSmith>
zcorpan: systeam updated https://lists.w3.org/Archives/Public/public-whatwg-archive/ to include complete links back to April 2004

[18:58:14.0000] <MikeSmith>
oh cool, first message ever posted to the liast was from bratell I guess

[19:58:57.0000] <MikeSmith>
hoping gal is actually saying something different than what it sounds like he's saying in http://andreasgal.com/2015/03/30/data-is-at-the-heart-of-search-but-who-has-access-to-it/

[20:00:30.0000] <Domenic>
wow that is an .... interesting ... post

[20:03:47.0000] <MikeSmith>
yeah when I read I thought at first there must be something I was misunderstanding myself

[20:05:58.0000] <MikeSmith>
I think he meant to say, In the long run this is bad for users

[20:06:11.0000] <MikeSmith>
I think that's what he's implying

[20:08:14.0000] <MikeSmith>
that if one search engine dominates, it's ultimately worse for users because their choices have been limited for them

[20:08:51.0000] <MikeSmith>
hopefully maybe he's clarify it to say something like that

[20:09:41.0000] <caitp->
do users really care which search engine they use

[20:21:30.0000] <MikeSmith>
caitp-: point taken but they do care about the quality and relevance of the results they get

[20:21:54.0000] <MikeSmith>
and there are other imaginable ways that search engines can innovate

[20:22:06.0000] <MikeSmith>
if there's competition

[20:22:12.0000] <MikeSmith>
https://twitter.com/andreasgal/status/587682899895263232

[20:22:39.0000] <MikeSmith>
"What's good for privacy is good for Google and bad for competition which is bad for privacy."

[20:22:39.0000] <caitp->
quite honest, google doesn't really do any better than altavista when I search for stuff that's not super-mainstream

[20:22:58.0000] <caitp->
and when you search for stuff that's super mainstream you know what you're gonna find anyways

[20:23:05.0000] <MikeSmith>
sure

[20:23:14.0000] <MikeSmith>
that's the other thing

[20:23:40.0000] <MikeSmith>
it's hard to notice differences like that if you don't have multiple search engines to evaluate results from

[20:24:35.0000] <MikeSmith>
anyway that quote above from gal also seems like a pretty big stretch

[00:18:33.0000] <annevk>
MikeSmith: I didn't really get it either

[00:19:07.0000] <annevk>
MikeSmith: the other search engines, e.g. DuckDuckGo, also use HTTPS

[00:19:25.0000] <MikeSmith>
yeah

[00:19:27.0000] <annevk>
MikeSmith: and advocating MitM attacks on users seems rather weird

[00:20:01.0000] <MikeSmith>
yeah it sure seems at odds with where everything else his headed

[00:20:48.0000] <MikeSmith>
but I think the part about Referer obfuscation is worth discussing

[00:21:12.0000] <annevk>
MikeSmith: there's control over Referer through the Referrer Policy

[00:21:47.0000] <MikeSmith>
not user control, right?

[00:22:33.0000] <MikeSmith>
ah can a site override the Google munging?

[00:22:50.0000] <karlcow>
can someone translate that sentence in Simple English (TM Wikipedia) -> "What's good for privacy is good for Google and bad for competition which is bad for privacy."

[00:23:00.0000] <annevk>
No, but I actually believe that Google should be allowed to control what they leak

[00:23:03.0000] <karlcow>
because I don't get the conclusion or logical statement of it

[00:23:11.0000] <annevk>
It's part of the user's privacy experience on Google

[00:23:16.0000] <MikeSmith>
annevk: ok

[00:25:10.0000] <karlcow>
Maybe I should read http://andreasgal.com/2015/03/30/data-is-at-the-heart-of-search-but-who-has-access-to-it/

[00:25:19.0000] <MikeSmith>
karlcow: I suspect he meant something more like, "What's good for privacy is good for Google. But [practically speaking in terms of the search-engine market] what's good for Google is bad for competition, which [in the long run] is bad for privacy."

[00:25:41.0000] <karlcow>
MikeSmith: ah understood.

[00:25:44.0000] <karlcow>
thanks

[00:26:03.0000] <karlcow>
Yes it's a stretch.

[00:26:20.0000] <karlcow>
It frames Google instead of framing ads industry

[00:27:18.0000] <karlcow>
> For some 90% of searches, a modern search engine analyzes and learns from past queries, rather than searching the Web itself, to deliver the most relevant results.

[00:27:25.0000] <karlcow>
this assertion bothers me a lot

[00:29:00.0000] <karlcow>
I disagree with "most relevant results", or more exactly it is "sport stadium intelligence type". Relevant == Mass here.

[01:30:31.0000] <karlcow>
http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-01

[01:31:45.0000] <karlcow>
The file URI Scheme

[01:32:23.0000] <MikeSmith>
yeah that guy's been working on that for a while I think

[02:09:24.0000] <jgraham>
I think I disagree. It's not just "the ads industry". My feeling is that giving any private institution uncontrolled access to enough private data is bad irrespective of their revenue stream.

[02:11:03.0000] <jgraham>
I think Andreas' point is that the search industry is heading in that direction and, ironically, that efforts to increase the privacy of individual searches set up a catch-22 scenario where disruption becomes impossible and all the data ends up in the hands of a small number of companies

[02:11:30.0000] <jgraham>
I think taking it as a simplistic "https is bad" is missing the point

[02:13:08.0000] <jgraham>
It is very possible to have things that we agree are good at one scale have effects on a different scale that are not good

[02:16:19.0000] <annevk>
I think the problem is with suggesting that mitm would be acceptable disruption.

[02:20:21.0000] <MikeSmith>
jgraham: what annevk said

[02:21:18.0000] <MikeSmith>
I also think Andreas's point probably was that the search industry is heading in that direction and, ironically, that efforts to increase the privacy ofindividual searches set up a catch-22 scenario where disruption becomes impossible and all the data ends up in the hands of a small number of companies

[02:21:30.0000] <MikeSmith>
but that's not what he actually said

[02:22:30.0000] <jgraham>
He didn't say "MITM is acceptable" anywhere that I saw

[02:22:47.0000] <jgraham>
He said that it was a fact and that it helped keep the market competitive

[02:22:48.0000] <MikeSmith>
maybe not but he implied it

[02:22:59.0000] <MikeSmith>
he implies it's good

[02:23:10.0000] <annevk>
"Search engines with small user bases can acquire search traffic by working with large Internet Service providers (also called ISPs, think Comcast, Verizon, etc.) to capture searches that go from users’ browsers to competing search engines."

[02:23:11.0000] <MikeSmith>
as far as I can see

[02:23:13.0000] <jgraham>
He implies that a competitive market is acceptable

[02:23:23.0000] <jgraham>
s/acceptable/good/

[02:23:47.0000] <jgraham>
He states that this was a technique that enabled one to exist

[02:24:34.0000] <jgraham>
there is no rule that says that mechanisms allowing things we like don't have side effects which we dislike

[02:28:10.0000] <MikeSmith>
I guess I would say that anybody who was doing business on the basis of relying on secret deep-packet-inspection of user data by ISPs was doing something bad and harmful to begin with, so they very much deserve for the businesses and revenue streams to end up being wrecked when they can't do that any longer

[02:29:04.0000] <annevk>
Yeah, I take issue with Andreas not taking issue with ISPs meddling with traffic

[02:35:34.0000] <jgraham>
Well I don't care a jot about their business, but I don't think that addresses the fundamental issue at all, which is that this is a case where your near term interests as a consumer are strongly misaligned with your long term interests

[02:35:39.0000] <jgraham>
/me -> train

[02:43:53.0000] <JakeA>
Stupid question that an HTTP expert will know the answer to straight away: With chunked encoding, is each chunk *independently* gzipped? Also, what's the benefit of chunking vs a stream of data?

[02:54:28.0000] <JakeA>
Ok, so the whole body is zipped before chunking. Still not sure on the benefit or reasons for chunking

[03:41:08.0000] <annevk>
JakeA: with chunked you can do trailers. And it allows for streaming content. I thought you needed either chunked or set Content-Length

[03:42:06.0000] <JakeA>
annevk: yeah, you need to use chunking if you don't set content-length. I guess I'm trying to work out the benefit of one large chunk vs many chunks

[03:42:43.0000] <annevk>
JakeA: well if you don't know exactly what you're sending back you'd use it

[03:42:55.0000] <annevk>
JakeA: if you do, you can set Content-Length

[03:45:34.0000] <JakeA>
annevk: yeah, so what's the benefit of each chunk having a local content-length, rather than just streaming the data & having a termination signal

[03:46:04.0000] <JakeA>
(I know the latter isn't possible with HTTP, just working out why it was designed that way)

[03:47:05.0000] <MikeSmith>
so it seems like some people who were involved with the System Apps work where the effort come up with a non-Web different security & runtime model for apps are not proposing that the APIs that would have needed that are instead adding *Permission methods that require users to opt into a higher trust level to grant to particular apps

[03:47:40.0000] <annevk>
JakeA: that's probably for integrity

[03:48:23.0000] <MikeSmith>
I mean what's discussed in https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0092.html (about the *Permission thing)

[03:48:42.0000] <MikeSmith>
and in, e.g., the http://www.w3.org/2012/sysapps/tcp-udp-sockets/ spec

[03:49:46.0000] <MikeSmith>
TCPPermission interface, the allow users to grant an app permission to open a real TCP socket interface

[03:50:00.0000] <MikeSmith>
*TCP socket connection

[03:50:16.0000] <annevk>
JakeA: also, a delimiter would make it impossible to transfer arbitrary data

[03:50:26.0000] <annevk>
JakeA: that is probably the main reason

[03:50:50.0000] <annevk>
I'm really enjoying https://twitter.com/hsivonen/status/587928397881421824

[03:51:26.0000] <MikeSmith>
my question about that permission stuff is, has this been discussed somewhere else (other than just among the SysApps people); e.g., in the WebAppSec group or TAG or somewhere

[03:51:32.0000] <MikeSmith>
/me is way behind on e-mail

[03:51:35.0000] <JakeA>
annevk: is arbitrary data a bad thing? Can you not do that with content-length?

[03:51:45.0000] <annevk>
MikeSmith: there was a discussion in one group for a bit

[03:52:01.0000] <annevk>
JakeA: it's not a bad thing, it's a requirement

[03:52:29.0000] <MikeSmith>
annevk:

[03:52:31.0000] <MikeSmith>
ok

[03:52:33.0000] <annevk>
MikeSmith: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/thread.html#msg1

[03:53:22.0000] <annevk>
MikeSmith: that 0092 email you pointed to was the follow up

[03:54:02.0000] <annevk>
MikeSmith: that whole permission model stinks though, I don't think that would ever ship outside of walled gardens such as the Chrome Store or Firefox OS Store

[03:54:24.0000] <annevk>
MikeSmith: and they already have their own proprietary APIs they probably don't want to replace due to the effort that would require that's better invested elsewhere

[04:08:22.0000] <_1_hozi>
hiii

[05:01:58.0000] <MikeSmith>
annevk: ok I hadn't yet read the part where you'd responded earlier to Claes

[05:03:52.0000] <MikeSmith>
annevk: I have to say that as far as the list of use cases at https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0001.html most of those don't seem to require a TCP socket interface

[05:04:06.0000] <MikeSmith>
e.g., "An email client which communicates with SMTP, POP3 and IMAP servers"

[05:05:24.0000] <MikeSmith>
clearly we already have Web-based e-mail clients that work just fine without needing to implement per-app SMTP, POP3 and IMAP protocol support on the client side

[05:07:44.0000] <MikeSmith>
and "An irc client which communicates with irc servers", we already have Web-based IRC clients and regardless I think going forward we don't really want to do IRC over the Web anyway; instead we want to be creating Web-first ways to do many-to-many real-time chat that takes advantage of the richer features you can have when you do that instead of limiting yourself to what you can do with IRC

[05:08:15.0000] <MikeSmith>
and "Peer-to-peer applications", we have DataConnection in WebRTC

[05:08:18.0000] <MikeSmith>
etc etc

[05:09:34.0000] <MikeSmith>
I thought the original proposal for a TCP socket interface was motivated by the idea that people would be writing system-level apps (as opposed to just userland apps) using Web-platform technologies

[05:10:29.0000] <MikeSmith>
for stuff like FirefoxOS or ChromeOS

[05:11:31.0000] <MikeSmith>
I don't think anybody started out on that with the idea of a way to expose raw TCP connections to apps running on the real Web

[05:12:19.0000] <MikeSmith>
so it kind of seems like some use-case creep has happened here

[05:18:22.0000] <annevk>
MikeSmith: given that to this day we're still connecting to IRC and various other services through native apps there's something to be said for being compatible with "legacy" interfaces

[05:19:29.0000] <annevk>
MikeSmith: however, if a solution does not address the security problems it's obviously not going to get any traction outside walled gardens

[05:22:45.0000] <MikeSmith>
annevk: yeah, sure

[05:23:50.0000] <MikeSmith>
but more and more I'm being really skeptical of use cases of the "this allows connecting to some legacy thing over some legacy protocol" variety

[05:25:04.0000] <MikeSmith>
people should instead by focusing their energy on coming up with new Web-first ways of solving the same problems the legacy application protocols did, but doing it Web-natively

[05:26:17.0000] <MikeSmith>
I really believe in this idea of Tim's that the Web wants to be "the information space that contains all other information spaces"

[05:28:16.0000] <jgraham>
/me thinks of the web more as "the space where we thought information might be, only to find cat pictures"

[05:28:24.0000] <MikeSmith>
heh

[05:28:36.0000] <MikeSmith>
anyway an information space like the IRC space isn't something bound to the IRC protocol or whatever other that was developed a couple dozen years ago before there was a Web

[05:30:56.0000] <MikeSmith>
jgraham: rightly you should just be able to post cat picture right here into this channel where we can all see it

[05:31:49.0000] <MikeSmith>
but you can't because we're our apps are using some protocol here that was invented before the Internet ever had any idea what to do with actual images

[05:33:10.0000] <jgraham>
Well if you were using irccloud and I was the sort of person who posted cat pictures into a channel, I could

[05:33:11.0000] <jgraham>
(other web-based irc clients are available)

[05:33:11.0000] <jgraham>
In fact it doesn't even have to be web-based

[05:35:26.0000] <jgraham>
In general my worry about the web compared to other protocols is that the requirement for a server side strongly encourages the creation of walled gardens, and intermediaries

[05:36:16.0000] <MikeSmith>
jgraham: WebRTC DataConnection doesn't rely on any server side

[05:36:18.0000] <jgraham>
I understand that there are more P2P things coming, but if you compare irc to facebook messanger or whatever it's not clear that the latter's really better for anyone.

[05:36:33.0000] <MikeSmith>
oh, granted that

[05:37:25.0000] <jgraham>
And even with irccloud, it seems like you are adding an extra party who is privy to all your conversations for no real advantage

[05:37:37.0000] <MikeSmith>
but as far as IRC specifically there are things like Slack and Gitter that provide a very good, rich user experience

[05:37:44.0000] <MikeSmith>
yeah, agreed on that

[05:37:45.0000] <jgraham>
Well for the advantage of a nicer UI

[05:39:05.0000] <MikeSmith>
er, btw I guess DataChannel is what the WebRTC thing is called (not DataConnection)

[05:42:48.0000] <annevk>
MikeSmith: be careful now, that's what the XHTML 2.0 guys thought too

[05:43:18.0000] <Ms2ger>
Weren't you one of the XHTML2 guys? :)

[05:43:36.0000] <annevk>
Ms2ger: I was cheering them on, but I guess that's semantics

[05:44:21.0000] <annevk>
Ms2ger: but I did realize at some point that gradual evolution works better

[05:47:04.0000] <MikeSmith>
I'm the guy who thinks it should be pretty obvious that over the long run the Web is going to evolve to assimilate all these things and let people do them better than they did before with the old systems

[05:56:23.0000] <annevk>
Agreed, it's just easier to assimilate if we can remove the friction

[07:00:37.0000] <MikeSmith>
annevk: btw if you find any remaining oddities in https://lists.w3.org/Archives/Public/public-whatwg-archive/ please lemme know

[07:01:11.0000] <MikeSmith>
systeam said that part of the problem was that the mboxes they were given to start from where whacked in various ways

[07:01:21.0000] <MikeSmith>
missing or misplaced stuff

[07:02:14.0000] <MikeSmith>
I think they had to write or revise some scripts of coercing them into some form the archive system could consume as expcted

[07:22:17.0000] <annevk>
Bah

[07:22:27.0000] <annevk>
Please thank them :-)

[08:36:56.0000] <annevk>
JakeA: could you reply to https://github.com/whatwg/fetch/issues/27#issuecomment-92905683 perhaps?

[08:37:23.0000] <annevk>
JakeA: would you mind if I assign that issue to you?

[08:37:33.0000] <JakeA>
annevk: Go for it

[11:13:24.0000] <TabAtkins>
terinjokes: If you *do* want to do something that lets unrelated websites coordinate, publish a vocab and use Microdata.

[12:22:23.0000] <wanderview>
jsbell: ping

[12:44:14.0000] <jsbell>
 wanderview: yo?

[12:44:52.0000] <wanderview>
jsbell: so thanks to jgraham we now have the blink cache tests in wpt and gecko!

[12:44:54.0000] <wanderview>
which is awesome

[12:45:06.0000] <jsbell>
wanderview: w00t!

[12:45:12.0000] <wanderview>
jsbell: however, I believe there are some spec issues with the tests... wondering where you want me to post those?  in wpt?

[12:45:28.0000] <jsbell>
wanderview: sure

[12:45:30.0000] <wanderview>
for example, the spec prohibits putting a POST request in the Cache:  https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/service-workers/cache-storage/script-tests/cache-add.js#30

[12:45:39.0000] <wanderview>
and think some things I wrote blink issues on in the past

[12:45:57.0000] <wanderview>
like requiring object equivalence for subsequent calls to caches.open(), etc

[12:45:59.0000] <wanderview>
jsbell: thanks!

[12:46:13.0000] <jsbell>
wanderview: Cool. I think for POST we have a failing expectation file in chrome, but yeah the test should be updated. so wpt is great

[12:46:24.0000] <wanderview>
yea, the spec changed there

[14:22:24.0000] <jgraham>
jsbell: If we fix test issues in wpt will you be able to merge those fixes to blink?

[14:30:49.0000] <jsbell>
jgraham: yep

[14:31:07.0000] <jsbell>
jgraham: slowly, painfully, and manually if need be, but yep. :)

[14:31:20.0000] <xtrm0>
Hasta lá vista

[14:38:31.0000] <jgraham>
jsbell: Awesome!

[14:42:22.0000] <gsnedders>
jgraham: I presume you'll support getting xfail stuff merged into html5lib ASAP?


2015-04-15
[18:20:21.0000] <MikeSmith>
https://twitter.com/awesomekling/status/588102855019495424

[18:20:37.0000] <MikeSmith>
"DOM attributes on the prototype chain? WebKit did that over a year ago, jeez. We just had to keep some as own properties due to compat."

[18:21:27.0000] <MikeSmith>
last time I ran some web-platform-tests interface/WebIDL tests, I didn't seem to find that to be true for the interfaces I was looking at

[18:21:55.0000] <MikeSmith>
WebKit still seemed to be failing on a lot of those interface tests

[18:30:39.0000] <TabAtkins>
MikeSmith: "some" is technically compatible with "most".  It just means "not all". ^_^

[18:30:59.0000] <MikeSmith>
heh

[18:32:30.0000] <MikeSmith>
TabAtkins: sometimes I think you would make a good lawyer 😀

[18:32:38.0000] <MikeSmith>
or at least you could play one on TV

[18:34:39.0000] <TabAtkins>
Technically correct is the best kind of correct.

[18:36:15.0000] <MikeSmith>
sitcom pilot: "Texan Web developer relocates to wild-and-crazy San Franciso in the 2010s, moonlights as lawyer, fun ensues"

[18:37:08.0000] <TabAtkins>
I'd watch it.

[18:37:10.0000] <TabAtkins>
And star in it.

[18:37:26.0000] <TabAtkins>
Wait no, I need someone else to be me.

[18:39:06.0000] <MikeSmith>
yes!

[18:39:26.0000] <MikeSmith>
now we got to think about who

[18:39:37.0000] <TabAtkins>
Elijah Wood.

[18:39:38.0000] <MikeSmith>
I could play you, then you could play me in my sitcom

[18:39:47.0000] <MikeSmith>
heh

[18:40:11.0000] <MikeSmith>
yeah, the *young* Elijah Wood

[18:40:14.0000] <TabAtkins>
/me is still hung up on when cute senior girls told freshman-Tab that he looked like a young Elijah Wood.

[18:40:22.0000] <MikeSmith>
he's be the 12-year-old version of you

[18:40:26.0000] <TabAtkins>
Yeah.

[18:41:01.0000] <TabAtkins>
That's actually just right for my age at the time.

[18:41:03.0000] <MikeSmith>
like Doogie Howser, except a webdeveloper/lawyer instead of a doctor

[18:42:42.0000] <MikeSmith>
I want Werner Herzog to play me

[18:44:05.0000] <MikeSmith>
and in my sitcom I hang out with Werner Herzog but he's played by Zach Galifianakis

[18:44:46.0000] <TabAtkins>
I like this plan.

[18:45:13.0000] <TabAtkins>
I'll take Zach as my little brother in my sitcom, too.

[18:45:26.0000] <MikeSmith>
that would be great

[18:45:40.0000] <MikeSmith>
we could have some tie-ins where we meet

[18:49:35.0000] <MikeSmith>
anyway, it's nice to have another career to fall back on

[18:50:29.0000] <GPHemsley>
/me wants second chair

[19:06:41.0000] <MikeSmith>
anyway results of tests like http://w3c-test.org/webstorage/idlharness.html and http://w3c-test.org/geolocation-API/interfaces.html seem to indicate WebKit has a lot of properties they need to move still

[19:11:46.0000] <MikeSmith>
makes me wonder what properties they did actually move

[19:33:38.0000] <MikeSmith>
speaking of wonders, they never cease: IETF has moved to using Bootstrap for their site http://tracker.tools.ietf.org/release/about

[20:14:43.0000] <MikeSmith>
does anybody remember what's holding us up from adding "Copy to clipboard" support to the platform?

[20:15:20.0000] <MikeSmith>
I mean to enable the kind of thing in the github UI where it has that "Copy to clipboard" button

[20:15:46.0000] <MikeSmith>
e.g., on a repo home page like https://github.com/w3c/web-platform-tests

[20:15:58.0000] <MikeSmith>
the "clone URL" field

[21:50:09.0000] <caitp->
does the File api suggest upper bounds on the byte size of a file, to be able to read it?

[21:50:59.0000] <caitp->
chrome silently failing to read a1 gig file as text was hard to track down today :l

[22:46:30.0000] <JakeA>
MikeSmith: I think we just added it to Canary

[23:04:50.0000] <MikeSmith>
JakeA: ah cool

[23:30:24.0000] <JakeA>
MikeSmith: I believe it's document.execCommand('copy') from an interaction event

[23:44:50.0000] <MikeSmith>
JakeA: thanks, this is in the Clipboard Ops spec?

[23:44:56.0000] <MikeSmith>
/me looks

[23:45:27.0000] <MikeSmith>
oh that wouldn't be in the clipboard ops spec I guess

[23:52:26.0000] <MikeSmith>
so, still wondering what spec they're implementing from

[23:52:32.0000] <MikeSmith>
I guess https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html but not sure

[23:52:58.0000] <MikeSmith>
botie, inform darobin what's the current spec for document.execCommand('copy') etc

[23:54:28.0000] <MikeSmith>
botie, inform darobin what's the current spec for document.execCommand('copy') etc

[23:54:29.0000] <botie>
will do

[00:25:59.0000] <zcorpan>
can anyone come up with a test case to check https://www.w3.org/Bugs/Public/show_bug.cgi?id=28433 ?

[01:00:08.0000] <botie>
darobin, at 2015-04-15 06:54 UTC, MikeSmith said: what's the current spec for document.execCommand('copy') etc

[01:05:07.0000] <darobin>
MikeSmith: last I checked you still needed a mix of https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html and http://dev.w3.org/2006/webapi/clipops/clipops.html

[01:07:29.0000] <MikeSmith>
darobin: ok

[01:07:59.0000] <darobin>
MikeSmith: there are proposals for intention events to handle that, but nothing actually real

[01:08:01.0000] <MikeSmith>
/me wonders who implemented this is blink

[01:08:24.0000] <darobin>
I don't know what the implementation status for clipops is in general

[01:08:36.0000] <darobin>
execCommand in Blink I would expect dates back to WebKit

[01:08:50.0000] <darobin>
unless it's been redone somehow

[01:08:58.0000] <MikeSmith>
darobin: JakeA said they landed it only recently

[01:09:05.0000] <darobin>
oh?

[01:09:27.0000] <darobin>
hmmm, I guess that might make sense actually, people still overwhelmingly use Flash for copying

[01:09:34.0000] <MikeSmith>
Yeah

[01:09:48.0000] <darobin>
or maybe they landed support for it outside of contentEditable?

[01:09:53.0000] <MikeSmith>
dunno

[01:36:38.0000] <annevk>
wanderview: thanks so much for all the triaging btw

[01:36:55.0000] <annevk>
wanderview: we really need a script to go from GitHub issue to file a bug on browsers to fix something

[01:43:57.0000] <jgraham>
gsnedders: I don't know what you mean?

[02:49:05.0000] <JakeA>
/me stalls for time on the clipboard questions as there's an article coming shortly

[02:49:37.0000] <annevk>
MikeSmith: it should be part of the clipboard spec

[02:49:44.0000] <JakeA>
http://updates.html5rocks.com/2015/04/cut-and-copy-commands

[02:49:50.0000] <JakeA>
agreed

[02:51:39.0000] <annevk>
JakeA: we're tracking this in https://bugzilla.mozilla.org/show_bug.cgi?id=1151429 btw

[03:50:33.0000] <MikeSmith>
does iOS have anything like Chrome Native Messaging?

[03:51:01.0000] <MikeSmith>
https://developer.chrome.com/extensions/nativeMessaging

[04:16:42.0000] <gsnedders>
jgraham: https://github.com/html5lib/html5lib-python/issues/182 — do we merge this in after we have xfails working and a seemingly clean tree or do we wait till everything's done?

[04:16:49.0000] <gsnedders>
jgraham: I would rather merge once the tree is green agai

[04:16:50.0000] <gsnedders>
*again

[04:22:06.0000] <jgraham>
gsnedders: Do you mean "do we finish this before merging anything else"?

[04:28:40.0000] <gsnedders>
jgraham: I'd rather that, as I've said before, but I felt like I lost that argument already. I mean do we finish the subtasks of that completely before merging it or do we just finish those needed to get the tree green?

[04:31:04.0000] <jgraham>
gsnedders: Merge the smallest possible thing at a time seems sensible

[04:31:44.0000] <gsnedders>
jgraham: basically the first 90% of the work to get rid of xfails is now done

[04:34:44.0000] <annevk>
JakeA: wanderview: in https://github.com/whatwg/fetch/issues/43#issuecomment-93176616 we also came up with the need for making a URL from a Response

[06:22:26.0000] <wanderview>
annevk: what exactly does that mean?  the Response.url?  or a URL mapping to the underlying source of that Response (like the Cache API file on disk)?

[06:24:07.0000] <annevk>
wanderview: the latter

[06:24:35.0000] <annevk>
wanderview: e.g. <img src=response:identifier> or some such

[06:25:07.0000] <wanderview>
annevk: does this effectively mean we need a cache:// scheme or something?  or is it just a non-human-readable id?

[06:25:59.0000] <wanderview>
annevk: the life cycle of the URL is a bit scary to me too... if they forget to call revokeObjectUrl()...

[06:26:15.0000] <annevk>
wanderview: non-human-readable

[06:26:26.0000] <annevk>
wanderview: yeah, we'd need to make it a one-time thing

[06:26:37.0000] <annevk>
wanderview: that streams can only be read once helps here of course

[06:26:40.0000] <wanderview>
annevk: well, what if its never read from?

[06:26:52.0000] <wanderview>
annevk: does reading from the URL drain the Response?

[06:26:59.0000] <wanderview>
or is the Response "drained" by creating a URL

[06:26:59.0000] <annevk>
wanderview: yeah

[06:27:07.0000] <wanderview>
I guess I'm asking if creating the URL is effetively a clone

[06:27:08.0000] <wanderview>
ok

[06:27:15.0000] <wanderview>
annevk: I think thats easier to implement, then

[06:27:16.0000] <annevk>
wanderview: I don't think the URL should clone

[06:27:35.0000] <annevk>
wanderview: if you want a clone, use .clone() first

[06:27:38.0000] <annevk>
wanderview: that's the motto

[06:27:41.0000] <wanderview>
we can do this all in the child process without any extra hooks into the back end

[06:27:43.0000] <annevk>
or party line

[06:28:28.0000] <annevk>
I more optimal API would be <img>.srcObject = Response, however, we don't have srcObject on all possible things we want to feed Responses to and for some cases such as CSS it's a bit unlikely

[06:28:40.0000] <wanderview>
annevk: why do this as a function wrapping Response?  why not have a Response.drainToUrl() or something

[06:29:00.0000] <wanderview>
hmm

[06:29:20.0000] <wanderview>
annevk: I guess that half of it (setting it as a .src on arbitrary attributes) may be a lot harder... not sure what we support there

[06:29:28.0000] <zewt>
(does a "one-time url" make sense in general, given that urls today can normally be read multiple times?)

[06:29:48.0000] <zewt>
(assuming GET, which is all you have with a url in isolation)

[06:31:28.0000] <annevk>
zewt: if you have a parser hook one-time URL makes some sense still I think

[06:32:03.0000] <zewt>
but typically that's logically referred to a resource, not an "open unseekable file handle to a resource" or something along those lines

[06:32:16.0000] <zewt>
i suspect it'll work most of the time anyway, just curious about the edge cases

[06:32:41.0000] <wanderview>
I could see people getting bitten by it

[06:32:47.0000] <annevk>
zewt: it doesn't seem different from blob to me, other than Response having headers that might be useful

[06:33:14.0000] <wanderview>
var url = response.drainToUrl(); headerImage.src = url; otherImage.src = url;

[06:33:15.0000] <zewt>
eg. browsers today could discard an image entirely if it's been offscreen for a while, and then redownload it later when needed

[06:33:32.0000] <annevk>
wanderview: the first wins

[06:33:33.0000] <wanderview>
annevk: blob object URLs are reusable, no?

[06:33:59.0000] <wanderview>
I don't think the consumer of a URL should have to know what created it

[06:34:07.0000] <annevk>
wanderview: depends on how you create them

[06:34:29.0000] <zewt>
i guess if the url logically caches the whole response it'd basically be like a blob

[06:35:19.0000] <wanderview>
annevk: so I can't write a generic function loadImageInMultiplePlaces(url) because someone might hand me some strange one-time-use URL?  sounds like bad ergonomics to me

[06:35:20.0000] <zewt>
er, other than the one-time thing

[06:35:34.0000] <wanderview>
annevk: we have no way to inspect if a URL is drained, etc

[06:35:48.0000] <zewt>
wanderview: that was my objection to the old microsoft proposal for auto-revoking blobs, iirc

[06:35:49.0000] <annevk>
wanderview: yeah, server could do the same technically

[06:35:50.0000] <wanderview>
annevk: I think URL might need to imply .clone() for every time its read

[06:35:52.0000] <zewt>
or one of them

[06:36:10.0000] <annevk>
wanderview: I don't really see why

[06:36:34.0000] <wanderview>
if there is precedent, I guess I don't object... just reinforces my existing hatred of createObjectUrl/revokeObjectUrl

[06:36:36.0000] <zewt>
that sounds not great but probably not a dealbreaker

[06:36:45.0000] <zewt>
obviously needs to not repeat the revoke* mistake

[06:36:57.0000] <annevk>
wanderview: srcObject = Response would be better

[06:37:04.0000] <annevk>
no doubt about that

[06:37:17.0000] <annevk>
zewt: right

[06:37:19.0000] <zewt>
err

[06:37:19.0000] <zewt>
<wanderview> annevk: the life cycle of the URL is a bit scary to me too... if they forget to call revokeObjectUrl()...

[06:37:24.0000] <zewt>
^ does this repeat the revoke* mistake? heh

[06:37:44.0000] <annevk>
zewt: there's no proposal for a method that works with Response yet

[06:37:50.0000] <wanderview>
zewt: my experience with working on memory problems in firefoxos gallery app and others... people forget to revokeObjectUrl() all the time

[06:37:55.0000] <annevk>
zewt: but it would definitely not have a revoke thing going on

[06:38:03.0000] <wanderview>
and it creates huge memory pressure when the url is representing an image

[06:38:10.0000] <zewt>
wanderview: yeah, that was a huge screwup with object urls, javascript != manual resource management

[06:38:17.0000] <zewt>
annevk: k

[06:38:43.0000] <wanderview>
zewt: yea... Response drains after first use... so that it better... unless we need to mash it into the manual revokeObjectUrl() scheme

[06:38:57.0000] <zewt>
wanderview: well, blobs are intended to be able to be written to disk even if there's an open url to them

[06:39:40.0000] <zewt>
(still a leak if people don't revoke, of course, but a disk space leak instead of memory)

[06:39:42.0000] <wanderview>
I guess gecko only gives you a file backed blob if you explicitly write it to IDB or something, and then get it back out

[06:39:56.0000] <zewt>
that sounds like an implementation shortcoming rather than blob's

[06:40:08.0000] <zewt>
only as far as the memory thing

[06:40:37.0000] <zewt>
being completely async is one thing blob got right (well, except for the size and mime type, which it screwed up and made sync)

[06:40:37.0000] <wanderview>
zewt: you still have issues with "I spent all the time to read this huge thing from disk... do I waste time reading again later or waste memory holding it in memory"  its a tradeoff thats hard to always get right at the browser

[06:42:53.0000] <zewt>
wanderview: well the idea is that if the data is on disk in the first place, a blob is just a pointer to it and you'd never actually need to read the whole thing (which i know has plenty of other complexities, in particular if the data might change out from under you)

[06:43:20.0000] <zewt>
excess flood of excess flood

[06:43:49.0000] <annevk>
zewt: feedback on https://wiki.whatwg.org/wiki/Storage is welcome too btw

[06:44:46.0000] <zewt>
more unreadable promise ugliness :(

[06:46:34.0000] <zewt>
headed to work, will take a look later

[07:02:48.0000] <MikeSmith>
https://twitter.com/CraigMcPheat/status/588335648987308032

[07:02:55.0000] <MikeSmith>
sounds like a fun place to work

[07:03:53.0000] <MikeSmith>
I wonder if people in his office are also blocked from just using the real Web from their own smartphones

[07:04:06.0000] <MikeSmith>
and what is a "virtualised Chrome"

[07:04:50.0000] <JakeA>
annevk: the only blocked response headers are the cookie ones right? Chrome isn't giving me things like the "date" header for a CORS response, sound like a bug?

[07:05:04.0000] <jgraham>
annevk: It's not clear to me why the default box is atomic

[07:05:09.0000] <annevk>
JakeA: no

[07:05:34.0000] <annevk>
JakeA: did you use access-control-expose-headers?

[07:05:50.0000] <annevk>
jgraham: what else would it be?

[07:06:01.0000] <wanderview>
MikeSmith: probably a virtual desktop thin client

[07:06:20.0000] <JakeA>
omg, sorry about that annevk. You're right of course

[07:06:52.0000] <annevk>
no worries

[07:06:58.0000] <jgraham>
annevk: Well that introduces the requirement that all of indexeddb, cookies, etc. are cleared together. I don't think any requirement like that exists at present

[07:07:55.0000] <jgraham>
It seems like each is a seperate atomic box (although the document should be clear that "cleared" means "cleared through UA", not "cleared through DOM APIs")

[07:09:43.0000] <jgraham>
"global quota" seems like it shouldn't be explained as "free space - constant" unless that's really the only allowed model

[07:11:01.0000] <wanderview>
jgraham: I think pretty much everyone we've talked to favors clearing everything or nothing (aka atomic) to avoid half-broken pages

[07:11:16.0000] <wanderview>
unless there is an explicit way to signal "this part can get cleared without the rest"

[07:11:25.0000] <jgraham>
wanderview: That isn't how UAs work today

[07:11:44.0000] <wanderview>
jgraham: browsers today don't work offline... we're trying to fix that?

[07:13:27.0000] <jgraham>
My point is that a) people will regard this as a functional regression "what do you mean I can't delete a cookie from a site unless I clear all the other data?!", and is likely to interfere with troubleshooting instructions for some sites

[07:14:22.0000] <wanderview>
jgraham: who said you can't delete a cookie?  its just saying the browser can't delete the cookie behind your back without reseting the storage for the whole origin

[07:14:55.0000] <jgraham>
wanderview: Is it?

[07:15:09.0000] <jgraham>
In that case it needs to be phrased to be much clearer

[07:15:24.0000] <wanderview>
jgraham: yes... this is about what the browser can do when the system is under storage-pressure

[07:15:32.0000] <wanderview>
annevk: ^^^

[07:16:11.0000] <jgraham>
wanderview: I assumed that "cleared" would include any browser-initiated clearing including via the UI

[07:16:37.0000] <wanderview>
I guess thats an interesting case

[07:17:31.0000] <wanderview>
jgraham: I guess I would question if most users understand the difference between "cookies" and other data... for example, we are moving to block things like IDB in third-party iframes if the "disallow third-party cookies" pref is set

[07:17:46.0000] <wanderview>
we == gecko

[07:18:03.0000] <jgraham>
wanderview: Well I agree that some users don't. But I can still clear a single cookie from the Fx UI

[07:18:49.0000] <wanderview>
jgraham: I imagine things like that and devtools storage inspector (does it allow modifying?  it could...) would still work

[07:19:47.0000] <jgraham>
Yeah, so it should be clear that these "atomic" boxes are not really atomic in general, but only according to how they react to storage pressure

[07:20:53.0000] <wanderview>
jgraham: the intention is that browsers know they can treat them as atomic... but things like devtools allow you to break the rules... just like changing CSS or js via devtools on a site is not "spec'd" or "normal"

[07:20:54.0000] <Domenic>
+1

[07:21:02.0000] <Domenic>
"atomic" is too strong of a guarantee

[07:21:21.0000] <Domenic>
call it something like "lives and dies together" :P

[07:24:00.0000] <jgraham>
wanderview: They are also not "atomic" from the point of view of creation. You can add or remove data from an "atomic

[07:24:06.0000] <jgraham>
" box using APIs

[07:24:22.0000] <wanderview>
I'm not really interested bikeshedding the name

[07:24:30.0000] <jgraham>
It's really only under storage pressure that they act as atoms

[07:24:46.0000] <jgraham>
OK, but I

[07:24:55.0000] <jgraham>
'm just explaining why the wiki wasn't clear to me

[07:25:31.0000] <wanderview>
jgraham: sure... and that is good feedback... I think annevk will see this and respond eventually

[07:36:18.0000] <Domenic>
I think there are people in this channel very interested in bikeshedding the name :)

[07:43:48.0000] <annevk>
/me wonders if the bikeshedding has concluded

[07:44:06.0000] <annevk>
jgraham: if you have a better term I'd be happy to update the page, though you can too :-)

[07:44:35.0000] <jgraham>
Well just trampling over someone else's proposal seems wrong :)

[07:45:28.0000] <jgraham>
(I'm not sure I have a better term, but someone might. Or it might just need better explaination)

[07:49:41.0000] <annevk>
"atomic under pressure" (could also be a new album title)

[07:54:46.0000] <annevk>
It's somewhat surprising to me we still offer control over individual cookies

[07:57:07.0000] <annevk>
If it was up to me we would have a panel called "Sites" that gives you an overview of sites (ordered by frecency, no typo) where you can get/set permissions and clear storage

[08:00:04.0000] <annevk>
Domenic: are you taking time to review https://w3c.github.io/mediacapture-main/ at some point?

[08:00:18.0000] <Domenic>
annevk: it was on my to do list but keeps slipping downward

[08:01:06.0000] <annevk>
Domenic: they'll play process games on us if we don't do it by May 15

[08:01:23.0000] <annevk>
although they might anyway since I think most of this has shipped

[08:01:30.0000] <Domenic>
Hmm

[09:32:28.0000] <TabAtkins>
Domenic: "life-bonded"

[09:37:35.0000] <TabAtkins>
How do people query that webdevdata these days?  Is it still "download the zip and run grep", or is there something else?

[10:25:13.0000] <annevk>
/me typically asks zcorpan

[10:38:57.0000] <TabAtkins>
Well yeah, but that's not super-scalable. ^_^

[12:11:23.0000] <TabAtkins>
annevk: Finishing up DOM right now.  I'll have a PR for you this afternoon.

[12:31:13.0000] <TabAtkins>
annevk: MouseEvent is no longer defined by UI Events, if I follow the reference in your bibliography.  Where should I point this link?

[12:33:08.0000] <Ms2ger>
Should be in UI Events

[12:34:04.0000] <TabAtkins>
The ED seems super stripped down: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm

[12:34:06.0000] <Ms2ger>
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#interface-MouseEvent

[12:34:28.0000] <TabAtkins>
Ah, the biblio ref in DOM pointed to d4e.

[12:36:54.0000] <TabAtkins>
That url depresses me, though.

[13:37:17.0000] <TabAtkins>
annevk: And DOM is done.  Could use some review, but the changes are extensive enough that doing so will be difficult.  I did my best to make sure things linked correctly, though.

[13:38:21.0000] <TabAtkins>
In particular, everything that linked cross-document, I noted down as I discovered them. After conversion, I verified that they were all failing to link (so they weren't getting grabbed by a local link), and manually specified their target in the anchors block.


2015-04-16
[20:02:13.0000] <wanderview>
Domenic: I don't think I'm going to get to writing that systems benchmark for async read any time soon

[20:06:24.0000] <wanderview>
too many Cache fires to put out

[20:32:18.0000] <annevk_>
TabAtkins: awesome, will review later

[20:39:45.0000] <wanderview>
annevk: you must be up with a baby?

[20:46:01.0000] <annevk>
wanderview: hehe

[20:46:05.0000] <annevk>
wanderview: he is a bit sick

[20:46:13.0000] <wanderview>
ouch :-(

[20:46:21.0000] <wanderview>
thats no fun

[20:46:22.0000] <annevk>
wanderview: but also I'm suffering from some sleeping trouble this week

[20:46:42.0000] <wanderview>
ah... thats no fun either

[20:47:04.0000] <annevk>
wanderview: it's more me than him I think :-) he holds it together pretty well

[20:47:37.0000] <wanderview>
annevk: I've had this thing lately where I can sleep from 9pm to 10pm... then wake up until midnight

[20:47:48.0000] <annevk>
wanderview: anyway, after I took care of him I decided to take a bath and then got a bunch of ideas for work so I decided to write them down

[20:48:03.0000] <annevk>
ugh

[20:48:59.0000] <wanderview>
awesome... new storage features based on dreams!

[20:49:01.0000] <wanderview>
:-)

[20:49:28.0000] <wanderview>
and... my daughter just woke up

[20:49:34.0000] <annevk>
"dream" boxes are fairly magical

[20:59:05.0000] <wanderview>
ok... finally done with this cache mess for the night... g'night

[22:40:16.0000] <Domenic>
annevk: would you be interested in my streams build system that generates commit snapshots, allows you to avoid committing generated output to the repo, and runs bikeshed on a CI server to ensure you always get the latest code?

[22:40:58.0000] <annevk>
Domenic: possibly if you are up for maintaining it

[22:41:17.0000] <annevk>
Domenic: trying to fix the DOM header at the moment

[22:41:25.0000] <Domenic>
annevk: yeah I've been planning to generalize/document it for a while, if I have a customer lined up that'll be extra incentive

[22:41:40.0000] <annevk>
Domenic: both DOM and URL could make use of it

[22:41:44.0000] <Domenic>
annevk: https://github.com/whatwg/streams/blob/master/index.bs#L15-L19 may help

[22:41:47.0000] <annevk>
Domenic: hopefully more down the line

[22:41:55.0000] <Domenic>
Notifications too IIRC

[22:41:58.0000] <annevk>
Domenic: yes

[22:42:01.0000] <annevk>
thanks to Peter

[22:42:48.0000] <annevk>
Domenic: with Fetch I opted to first link to the repo and then have (new issue, open issues) following it

[22:43:15.0000] <Domenic>
Hmm that is kind of nice

[22:45:02.0000] <Domenic>
why does Firefox randomly decide it likes svg favicons... ~1/20 tabs I open to a WHATWG spec have a nice favicon, seemingly at random.

[22:45:31.0000] <Domenic>
Huh there's a whole caniuse for this http://caniuse.com/#feat=link-icon-svg

[22:45:59.0000] <Domenic>
Well I guess that explains it https://bugzilla.mozilla.org/show_bug.cgi?id=366324#c14

[22:46:14.0000] <annevk>
Domenic: do you know why I have to include "URL: https://dom.spec.whatwg.org" to get relative links to DOM definitions?

[22:46:25.0000] <annevk>
Domenic: including that also generates a "This version" field which is pointless

[22:46:51.0000] <annevk>
Domenic: you don't seem to have that at all

[22:47:00.0000] <Domenic>
Yeah was just checking... hmm

[22:47:26.0000] <Domenic>
I don't use {{ microsyntaxes though just <a>term</a>, maybe that's the difference?

[22:47:39.0000] <annevk>
TabAtkins: you awake?

[22:49:12.0000] <TabAtkins>
annevk: What's up?

[22:49:26.0000] <annevk>
TabAtkins: various things it seems

[22:49:46.0000] <annevk>
TabAtkins: why do I need to include URL: ...? I don't want "This version" but I also want relative links

[22:50:03.0000] <annevk>
TabAtkins: Domenic filed various issues on things that are wrongish, e.g. https://github.com/whatwg/dom/issues/22

[22:50:13.0000] <Domenic>
https://github.com/whatwg/dom/issues is mostly me at this point

[22:51:02.0000] <TabAtkins>
Ooh, I wonder if I'm skipping over <code> elements for autolink processing?

[22:53:26.0000] <TabAtkins>
I guess you don't need URL; looks like Streams doesn't have it.

[22:53:45.0000] <MikeSmith>
annevk: https://lists.w3.org/Archives/Public/www-tag/2015Apr/0027.html seems like nice progress

[22:53:47.0000] <annevk>
TabAtkins: if I remove it all fragment-only links get that URL prepended

[22:53:59.0000] <annevk>
MikeSmith: yeah

[22:54:13.0000] <annevk>
MikeSmith: I wonder what happened

[22:54:26.0000] <MikeSmith>
they got smarter?

[22:54:38.0000] <MikeSmith>
they got smarter people in to work on it?

[22:54:56.0000] <TabAtkins>
annevk: URL metadata definitely has zero effect on links, so I dunno what you think is going on.  Gimme a specific element that's being weird, so I can check it out?

[22:55:00.0000] <annevk>
MikeSmith: if I'd be cynical I'd say it's too thwart the competition

[22:55:53.0000] <annevk>
TabAtkins: hmm maybe it was another field I changed

[22:56:03.0000] <MikeSmith>
annevk: maybe you're right https://twitter.com/dakami/status/588548153504239616

[22:56:06.0000] <annevk>
TabAtkins: does Shortname have an effect?

[22:56:15.0000] <annevk>
to*

[22:56:41.0000] <Domenic>
I too find the existence of shortname confusing

[22:56:54.0000] <TabAtkins>
Yes it does; gimme a sec.

[22:57:34.0000] <MikeSmith>
https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf seems like it has some pretty interesting details about their deployment/implementation

[22:57:41.0000] <Domenic>
Oh nice file-issue.js just worked :D

[22:58:35.0000] <annevk>
Domenic: yeah also did for Notifications, very nice

[22:59:24.0000] <TabAtkins>
At minimum, Shortname lets Bikeshed know what definitions in the linking database are for the current spec, so it should ignore them (rather than treating them as ambiguous link targets).

[22:59:38.0000] <TabAtkins>
If you did multiple levels, Shortname+Level helps with that in a similar way.

[23:00:30.0000] <Domenic>
So shortname is an index into the bikeshed linking database?

[23:01:12.0000] <TabAtkins>
It's one of the things that identifies an anchor, yeah.

[23:01:27.0000] <TabAtkins>
When you set a Link Defaults, it's the shortname that you're specifying.

[23:02:17.0000] <Domenic>
then i guess my question is who's squatting on "dom" and forcing "dom-core-ls" on us :P

[23:04:06.0000] <annevk>
TabAtkins: two issues left https://github.com/whatwg/dom/issues and I guess the question who's squatting "dom" :-)

[23:04:33.0000] <TabAtkins>
Looks like nobody - I don't see "dom" in the linking database.

[23:06:40.0000] <TabAtkins>
I'll just need to change it in Shepherd to track the alteration.  Want me to do so?

[23:06:53.0000] <TabAtkins>
(The -ls is the level part; the shortname is dom-core.)

[23:10:24.0000] <annevk>
TabAtkins: so it would be dom-ls?

[23:10:58.0000] <annevk>
TabAtkins: might be nice to just get it over with now

[23:17:34.0000] <TabAtkins>
k, done

[23:17:56.0000] <TabAtkins>
Shortname is now "dom".

[23:18:02.0000] <TabAtkins>
Full levelled name is "dom-ls".

[23:19:02.0000] <TabAtkins>
Oh, and looks like the reason your shortname was set to dom-core is because that was the name of your index file - dom-core.html.

[23:26:46.0000] <annevk>
TabAtkins: looks like https://dom.spec.whatwg.org/#htmlcollection is missing some links too

[23:26:53.0000] <annevk>
TabAtkins: and dfn.js appears broken

[23:27:44.0000] <TabAtkins>
What links do you think it's missing? (Besides the {{}} stuff showing up.)

[23:30:58.0000] <annevk>
TabAtkins: item and namedItem are not clickable

[23:31:21.0000] <annevk>
TabAtkins: and index and name are marked bold while they're really variables

[23:31:34.0000] <annevk>
the latter might be a Bikeshed thing

[23:31:49.0000] <annevk>
(talking about the IDL block)

[23:32:36.0000] <TabAtkins>
Yeah, I see that item/nameditem aren't properly picking up the definitions later.  (They're giving an independent definition, and I'm trying to figure out why.)

[23:33:15.0000] <TabAtkins>
Arguments are marked up/defined in Bikeshed. If you don't want them styled specially, add a `dfn[data-dfn-type=argument]` style rule.

[23:36:15.0000] <TabAtkins>
Ah, I see, I have some lingering hackiness from when I was doing IDL worse.  Hmmm.

[23:46:39.0000] <TabAtkins>
Ugh, it's as I thought. I've got a mutually reinforcing set of legacy hacks from back when I wasn't handling IDL correctly, and fixing them properly will be some work.  I'll get on that tomorrow.

[23:47:06.0000] <TabAtkins>
/me is pretty sure he'll need some extra data files for efficient querying of function overloads.

[23:54:03.0000] <annevk>
TabAtkins: thanks, happy we got this far :-)

[00:14:33.0000] <annevk>
Domenic: if I wanted to fix some things in Streams, should I PR index.bs or just file issues?

[00:16:28.0000] <annevk>
/me will file issues for now

[01:50:23.0000] <zcorpan>
FATAL ERROR: No 'idl' refs found for 'Document' with spec 'dom-core-ls'. -_-

[02:11:26.0000] <zcorpan>
hmm seems it's fine when generated on the server

[02:12:54.0000] <zcorpan>
but i get mail saying to choose between svg2 and html5 for {{Document}}

[02:12:57.0000] <zcorpan>
TabAtkins: ^

[02:25:50.0000] <annevk>
zcorpan: use 'dom' or 'dom-ls' as token

[02:26:56.0000] <zcorpan>
annevk: that still gives fatal error for `Document`. but maybe this will fix itself since it's generated without warnings on csswg server

[02:27:17.0000] <zcorpan>
(and it points to the dom spec)

[02:39:25.0000] <annevk>
zcorpan: TabAtkins did note something about Document not working well

[02:39:57.0000] <annevk>
zcorpan: maybe file an issue against bikeshed?

[02:40:11.0000] <zcorpan>
ok

[02:40:34.0000] <annevk>
zcorpan: hopefully everything WHATWG can be bikeshed by end-of-year (prolly minus HTML)

[02:43:59.0000] <zcorpan>
https://github.com/tabatkins/bikeshed/issues/387

[06:30:48.0000] <mounir_>
Ms2ger: default values for dictionary would allow: dictionary Bar { DOMString[] foo = []; }; ?

[06:30:59.0000] <Ms2ger>
I don't think so

[06:31:24.0000] <mounir_>
Ms2ger: no default values for array or sequences?

[06:32:02.0000] <Ms2ger>
Not that I recall

[07:05:37.0000] <Ms2ger>
TabAtkins, is FileAPI the awful formatting spec?

[07:21:08.0000] <annevk>
mounir_: also, DOMString[] is not valid there

[07:21:12.0000] <annevk>
mounir_: you want sequence

[07:21:58.0000] <Domenic>
How many specs would we have to update to change X[] to LegacyFakeArrayLike<X>, I wonder.

[07:22:37.0000] <mounir_>
annevk: readonly sequence<DOMString> in the Event interface too?

[07:23:56.0000] <annevk>
mounir_: we don't have a good thing for that yet

[07:24:23.0000] <mounir_>
it sounds good to you to have sequence<> in EventInit and DOMString[] in the Event interface?

[07:24:36.0000] <mounir_>
annevk: ^

[07:25:13.0000] <annevk>
mounir_: no, [] is never good

[07:25:35.0000] <annevk>
mounir_: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682

[07:25:45.0000] <annevk>
Domenic: too many

[07:49:34.0000] <TabAtkins>
Ms2ger: Depends on what you mean by "awful formatting".

[07:49:47.0000] <Ms2ger>
What you complained about on twitter :)

[07:51:27.0000] <TabAtkins>
Oh, yeah, it was terrible.

[07:51:41.0000] <TabAtkins>
Some lists had their <li>s indented four or five different ways, for 9 items.

[07:52:45.0000] <TabAtkins>
And, like, the ids for sections dont' follow any pattern. The Blob IDs are totally different structure from the File IDs.

[07:52:54.0000] <TabAtkins>
So much inconsistency laced throughout the entire thing.

[07:53:16.0000] <TabAtkins>
And don't get me started on the spec starting with a 2-space indent, but of course randomly switching to 3 or 4 space in some places.

[07:55:37.0000] <caitp>
i'm surprised nobody came up with a clang-formatter for whatever the spec docs are written in

[07:56:22.0000] <TabAtkins>
I've strongly considered it.

[07:56:27.0000] <TabAtkins>
But it's a lot of work. ^_^

[07:56:49.0000] <caitp>
somewhere out there there's a bored highschool student who'd do it

[07:57:42.0000] <TabAtkins>
Well, who'd do it halfway.

[08:13:33.0000] <jgraham>
So which is the most reusable "file a bug on this bit of spec" script these days?

[08:15:26.0000] <TabAtkins>
Apparently the one DOM/Streams is using just works out of the box pretty good.

[08:15:33.0000] <Domenic>
jgraham: file-bug.js for W3C bugtrackers, file-issue.js for GitHub

[08:15:56.0000] <jgraham>
Domenic: From dom/streams?

[08:18:09.0000] <annevk>
jgraham: it's on resources.whatwg.org

[08:18:12.0000] <jgraham>
Domenic: Right, got it, thanks

[08:18:16.0000] <jgraham>
annevk: Thanks also

[08:18:20.0000] <jgraham>
And also TabAtkins

[08:18:24.0000] <jgraham>
So much thanks!

[08:19:17.0000] <annevk>
TabAtkins: yeah that spec was a bit of a disaster

[08:19:51.0000] <TabAtkins>
annevk: Well Im fixing it, at least.  Since it's a much shorter spec, only ~1900 lines, I can do a thorough reformat without killing myself.

[08:19:58.0000] <TabAtkins>
DOM made me want to die.

[08:20:10.0000] <annevk>
DOM is pretty big

[08:20:10.0000] <TabAtkins>
Which is why it took 3 months to finish. ^_^

[08:20:32.0000] <TabAtkins>
At least you were *extremely* consistent in link formatting, which made things *way* easier.

[08:20:49.0000] <TabAtkins>
I often find a given term linked with four different syntaxes in FileAPI.

[08:21:17.0000] <annevk>
Yeah, I optimize for basic search and replace that doesn't require regular expressions

[08:22:18.0000] <TabAtkins>
My fingers and sanity thank you for it.

[08:22:23.0000] <TabAtkins>
And thank jgraham, while I'm at it.

[08:23:03.0000] <Ms2ger>
?

[08:23:58.0000] <flyrock>
TabAtkins, annevk ! I have only read one book on html/css , no experience , that was responsive web design by ben frain. and i wanna be one of you guys, where to start.

[08:24:18.0000] <TabAtkins>
Ms2ger: Well, he was thanking all of us, so I felt I had to return the favor.

[08:24:30.0000] <Ms2ger>
Ah, heh

[08:25:12.0000] <TabAtkins>
flyrock: My path was to learn web dev, subscribe to the standards mailing lists, gradually learn how things worked (and why they worked the way they did), and then finally find a topic I was passionate about and thought I could improve.

[08:25:52.0000] <TabAtkins>
flyrock: So if you're just starting, you've got a few years of experience-building to go before you should consider trying to work on specs. ^_^

[08:26:57.0000] <flyrock>
TabAtkins,i got it,  thanks for you time, will keep bugging you occasionally !

[08:27:05.0000] <TabAtkins>
np

[08:27:45.0000] <TabAtkins>
(Of course, the topic I thought I could improve I still did a lot of damage to - yay gradients! But the end-result was indeed much better.)

[08:30:15.0000] <flyrock>
i suppose that's you being modest. :)

[08:30:49.0000] <TabAtkins>
No, I really fucked it up and did a lot of damage.  It's all healed over now, but dealing with the four different gradient syntaxes that existed at the same time was hellish.

[08:31:11.0000] <caitp>
you can't accomplish anything without ruining at least one other thing, that's just how it goes

[08:31:26.0000] <TabAtkins>
When god closes a door, he breaks a window.

[08:31:48.0000] <flyrock>
TabAtkins, I think i will take some time to decipher what you explained, but we will sure talk about it.

[08:33:20.0000] <TabAtkins>
flyrock: Just dont' jump ahead of yourself.  Spec work is weird meta-work over webdev.  You need a strong webdev knowledge base to do it well, and even then most people aren't suited for it, and that's fine.

[08:33:47.0000] <TabAtkins>
It requires a bizarre mix of patience and impatience that is intensely frustrating to most people.

[08:34:05.0000] <TabAtkins>
So most newbies to spec stuff only stick around a few months before going back to doing productive work. ^_^

[08:34:59.0000] <TabAtkins>
Heh, my favorite tech reported just faved a "your mom" joke made against me.

[08:36:20.0000] <flyrock>
cool ! I will remember not to jump ahead and the mix of patience and impatience

[08:36:51.0000] <flyrock>
and yeah, webdev  !

[08:38:07.0000] <caitp>
in a few years you can be one of the few, the proud, billionaire lamborghini driving spec editors, with girls chasing you all around the state, if you just remember to keep your patience and impatience in the right balance

[08:38:37.0000] <TabAtkins>
Hey, hey, we don't know what flyrock prefers, they can have boys chasing them around the state if they want.

[08:38:46.0000] <caitp>
well sure

[08:39:44.0000] <flyrock>
lol !

[08:59:23.0000] <jgraham>
More to the point, we don't know why these people are chasing flyrock around. Maybe it's to exact vengance for crimes against spec editing.

[09:44:47.0000] <annevk>
caitp: I'm clearly not a successful spec editor

[09:45:53.0000] <Domenic>
Did you know? Browsers are supposed to implement a JSON-LD API. http://www.w3.org/TR/json-ld-api/#the-application-programming-interface

[09:46:00.0000] <Domenic>
Wonder how that got to REC

[09:46:13.0000] <annevk>
Domenic: you're being sarcastic right?

[09:46:20.0000] <Domenic>
indeeeed

[09:46:41.0000] <annevk>
It's been a long day

[09:47:14.0000] <annevk>
As I said to someone else earlier, it's nice how now it's renamed from RDF to LinkedData or JSON-LD, it still doesn't make much sense

[09:53:44.0000] <jamesr___>
https://dvcs.w3.org/hg/json-ld/raw-file/default/test-suite/reports/cr-20131022.html#test-subjects

[09:54:21.0000] <jamesr___>
two of the "interoperable implementations" are the same javascript library running in a browser and running in node.js

[09:54:50.0000] <annevk>
Is it interoperable because the browsers are different?

[09:55:53.0000] <jamesr___>
afaik running in a browser is 1 and running in node.js is 2

[09:56:05.0000] <jamesr___>
unclear if running in a different browser would count as 3

[09:56:29.0000] <annevk>
That's some creative accounting right there

[09:56:43.0000] <annevk>
MikeSmith: ^^

[10:03:09.0000] <annevk>
Domenic: shall I open an issue for an OpaqueStreamReader class of sorts?

[10:20:23.0000] <annevk>
Domenic: see WHATWG email instead

[10:20:53.0000] <annevk>
flyrock: https://annevankesteren.nl/2014/03/contributing-to-standards has some pointers

[10:25:41.0000] <flyrock>
thanks annevk :)

[10:48:45.0000] <TabAtkins>
That... implementation counting is 100% wrong.  Multiple implementations *by the same person* dont' even count as separate; running the *same code* in two places absolutely doesn't.

[10:48:59.0000] <TabAtkins>
I know, this isn't anything surprising, but this sort of gaming just disappoints me.

[10:49:17.0000] <TabAtkins>
It's like, yeah, I know nobody likes what y'all are doing, but at least have some self-respect. This is sad.

[10:50:55.0000] <jamesr___>
TabAtkins: another one of the impls is a python lib by the same author as the "2" js ones

[10:51:06.0000] <TabAtkins>
Yeah, doesn't count.

[10:51:31.0000] <TabAtkins>
We didn't let Rik's multiple implementations in several browsers count for one of the Adobe-driven CSS specs.

[11:03:35.0000] <gsnedders>
/me wonders what's going to happen to bug tracking for Chromium/Blink when GCode closes

[11:11:21.0000] <TabAtkins>
What kind of monster puts the sentence-ending period *inside of* the <a> element wrapping the last word in the sentence?

[11:17:05.0000] <TabAtkins>
The same kind of monster that eschews the Oxford Comma, that's who.

[11:49:57.0000] <TabAtkins>
The perils of hand-editting a generated file: ToC and headings drift apart.  In https://w3c.github.io/FileAPI/TR.html, "Blob Parameters" (8.3.4.7) is missing from the ToC, the following "Determining Encoding" (8.4) is listed as an h3 but styled as an h4, and the following "Events" section is either 8.5 or 8.5.10, depending on whether you believe the heading

[11:49:57.0000] <TabAtkins>
or the ToC.

[12:42:06.0000] <MikeSmith>
annevk: seems legit

[12:42:26.0000] <MikeSmith>
will find out who Director'ed that

[12:52:00.0000] <hober>
but who Directors the Director?

[12:54:26.0000] <annevk>
Domenic: binary stream seems like a weird term to use, byte stream seems more accurate

[12:55:04.0000] <Domenic>
annevk: that is what I use?

[12:55:41.0000] <annevk>
Domenic: e.g. https://streams.spec.whatwg.org/#model mentions binary; my suggestion in the issue was to change that

[12:55:57.0000] <Domenic>
ah i see

[12:56:29.0000] <Domenic>
busy fixing my build process right now... i uncovered some very subtle bug in jsdom and the "proper" way to fix it led me to fixing our xml support... (ecmarkup depends on jsdom)

[12:57:03.0000] <annevk>
heh, good luck

[13:10:06.0000] <wanderview>
Domenic: when does (or did) fetch body streams hit chrome release?

[13:15:52.0000] <Domenic>
wanderview: Chrome 43, so since 42 just released ~6 weeks

[13:16:33.0000] <wanderview>
Domenic: ok, thanks... trying to get an idea how soon I need to do this system benchmark beyond ASAP

[14:55:54.0000] <Domenic>
TabAtkins: how do I fix my HTML reference? When I do `Link Defaults: html5 (dfn) structured clone` it gives the wrong spec and when I say `html` instead it gives `No 'dfn' refs found for 'structured clones' with spec 'html'`

[14:57:11.0000] <Domenic>
TabAtkins: also what happened to CSSWG specs using up-to-date references? They are all to /TRash URLs now

[14:57:31.0000] <TabAtkins>
HTML5 should be html.spec.whatwg.org.  What do you want for it?

[14:58:42.0000] <Domenic>
It is not

[14:58:56.0000] <Domenic>
https://streams.spec.whatwg.org/#index-defined-elsewhere

[14:59:01.0000] <TabAtkins>
It certainly is in the linking database.

[14:59:12.0000] <TabAtkins>
Oh, [[HTML5]]

[14:59:17.0000] <Domenic>
No

[14:59:19.0000] <Domenic>
[[HTML]] works

[14:59:27.0000] <Domenic>
but in link defaults I have the problem described

[14:59:57.0000] <Domenic>
So my document is mostly html.spec.whatwg.org but any cross-reffed terms end up referring to the fork

[15:00:18.0000] <TabAtkins>
Unfortunately, that's the biblio ref for "HTML5" in SpecRef. :/

[15:00:47.0000] <TabAtkins>
I'd have to verify, but I think if you manually specify a biblio reference in a <pre class=biblio> it'll override the default data.

[15:01:17.0000] <Domenic>
Does Link Defaults and [[bracket syntax]] use the same mapping?

[15:01:24.0000] <TabAtkins>
And the Index generation kinda just guesses that the shortname will match an appropriate biblio ref.  The naming bullshit around the HTML fork is messing this up.

[15:01:51.0000] <TabAtkins>
No, Link Defaults is about linking, using the linking database (it just defaults some of the link attributes on certain terms). [[foo]] is a biblio, using the biblio database.

[15:01:56.0000] <Domenic>
ok

[15:01:58.0000] <TabAtkins>
The two are separate for practical and historical reasons.

[15:02:08.0000] <Domenic>
can we add to/fix the linking database?

[15:02:23.0000] <TabAtkins>
Yeah, PR the SpecRef project on GitHub.

[15:03:07.0000] <Domenic>
I think I see

[15:03:15.0000] <Domenic>
I think html is supposed to work

[15:03:16.0000] <TabAtkins>
github.com/tobie/specref/

[15:03:23.0000] <Domenic>
But it is missing structured clone

[15:03:36.0000] <TabAtkins>
Rather, there *is* no spec named "html" in the linking database.

[15:03:41.0000] <TabAtkins>
It's called html5 there.

[15:03:58.0000] <Domenic>
no there is one

[15:04:08.0000] <Domenic>
https://github.com/tobie/specref/blob/master/xrefs.json#L1626

[15:04:24.0000] <TabAtkins>
That file's irrelevant.

[15:04:34.0000] <TabAtkins>
Bikeshed doesn't use Tobie's xrefs, just the biblio.

[15:04:41.0000] <TabAtkins>
It uses its own linking database, generated by Shepherd.

[15:04:45.0000] <Domenic>
oh damn

[15:04:48.0000] <TabAtkins>
Heh, sorry.

[15:05:04.0000] <TabAtkins>
You can check it by going to bikeshed/bikeshed/spec-data/anchors.data

[15:05:07.0000] <Domenic>
ok, so, can we get Shepherd to work better?

[15:05:19.0000] <TabAtkins>
Yeah, lemme see if I can tweak it to call the spec "html".

[15:05:38.0000] <Domenic>
does Shepherd have any entries for html.spec.whatwg.org?

[15:06:00.0000] <TabAtkins>
Yeah, that's what I'm saying.  Shepherd *only* parses the real HTML spec.  All the linking database entries are for it.

[15:06:17.0000] <Domenic>
Then why did https://streams.spec.whatwg.org/#index-defined-elsewhere happen

[15:06:42.0000] <TabAtkins>
I already explained it. ^_^  The Index generation sorta just hopes that the linking shortname is also the correct biblio reference.

[15:06:50.0000] <Domenic>
Ahhh yes was just connecting the dots

[15:06:52.0000] <TabAtkins>
Because, unfortunately, there's no explicit connection between the two databases.

[15:07:07.0000] <Domenic>
ok sweet

[15:07:21.0000] <TabAtkins>
That's why some of the CSS refs in the index don't work; the biblio name for them doesnt' match their shortname yet.

[15:08:00.0000] <TabAtkins>
And it's annoying to mess with SpecRef there, because it does automated dumps of biblio refs from the TR.xml generated by the W3C, so if I change things it'll just revert itself later.

[15:08:07.0000] <TabAtkins>
Need to figure out how to get around that.

[15:08:45.0000] <TabAtkins>
Really, I probably just need to check Shepherd's spec data first; it's less complete (won't generate quite as high-quality of a biblio entry), but it's synced with the linking database names.

[15:10:33.0000] <Domenic>
Well we've got two suffering specs now so no pressure :P

[15:10:47.0000] <TabAtkins>
I know, I know. File an issue on me or I'll forget.

[15:13:20.0000] <Domenic>
I often want to add you to the WHATWG GitHub org just so I can assign issues to you

[15:13:27.0000] <TabAtkins>
Do it?

[15:13:34.0000] <Domenic>
Sounds good

[15:13:48.0000] <Domenic>
I'll also file a Bikeshed issue


2015-04-17
[23:25:29.0000] <annevk>
TabAtkins: why are things such as "contains(token)" not marked up with <code>?

[23:27:12.0000] <annevk>
TabAtkins: interface Range lost its Constructor annotation

[23:27:43.0000] <annevk>
TabAtkins: as did Document

[23:30:20.0000] <annevk>
Does not seem too hard to restore...

[00:23:39.0000] <MikeSmith>
TabAtkins: I wonder how long it will be until somebody creates a Chuck Tingler book-cover generator

[00:57:14.0000] <zcorpan>
so this is how people are writing their pages now huh http://stackoverflow.com/questions/24532799/gap-between-picture-and-next-element-because-of-container-height

[01:35:35.0000] <annevk>
TabAtkins: dfn.js breakage is https://github.com/tabatkins/bikeshed/issues/391

[02:53:20.0000] <_1_kallu23>
hi

[02:56:56.0000] <jiojiajiu>
Hello, is there analog specification for http://www.w3.org/TR/animation-timing in Whatwg?

[03:05:13.0000] <annevk>
jiojiajiu: it's part of the HTML Standard these days

[03:12:24.0000] <jiojiajiu>
annevk: thank you, I've found it

[03:39:44.0000] <smaug____>
/me wonders if SharedWorker should have only Exposed=Window for now

[04:37:07.0000] <annevk>
yeah maybe

[04:37:17.0000] <annevk>
at least until we figure out the service/shared worker tension

[10:11:16.0000] <TabAtkins>
annevk_: Oh man, sorry for apparently dropping the constructor annotations. Copy-paste error I guess.

[10:11:43.0000] <annevk>
was easy to fix

[10:11:52.0000] <annevk>
I filed some issues on bikeshed from other things I found

[10:12:18.0000] <TabAtkins>
Thanks. Today will be spent ripping out most of my method-linking code and making it not a hacky pile of shit.

[10:13:05.0000] <annevk>
TabAtkins: you also replaced what I think was the only actual title="" with lt="" :-P

[10:13:13.0000] <TabAtkins>
Ahahaha

[10:13:24.0000] <TabAtkins>
Sorry, reflex.

[10:13:38.0000] <TabAtkins>
Out of curiosity, what was it?

[10:14:05.0000] <annevk>
TabAtkins: search for "F."

[10:14:29.0000] <annevk>
hmm "F. H" is unique

[10:14:38.0000] <TabAtkins>
hahaha

[10:15:09.0000] <TabAtkins>
Hmmm on the <script> thing. I purposely move <script> and <style> into the head, so the doc will validate better.  Can dfn.js just use an onload handler + async instead of requiring placement?

[10:16:29.0000] <annevk>
Hmm I guess we could do that

[10:16:55.0000] <TabAtkins>
It's a better practice anyway. ^_^

[10:49:18.0000] <Domenic>
No it's not ...

[10:49:32.0000] <Domenic>
<script>s at the bottom of the body seems much better

[10:49:38.0000] <Domenic>
<style>, sure

[10:54:17.0000] <TabAtkins>
Domenic: Fails validation, though, doesn't it?

[10:54:31.0000] <Domenic>
No

[10:54:55.0000] <TabAtkins>
Ah, then whatever I guess, I'll kill the <script> movement.

[10:55:00.0000] <TabAtkins>
I assumed it was the same as <style>.

[10:58:01.0000] <TabAtkins>
And done.

[10:58:17.0000] <Domenic>
\o/

[11:15:54.0000] <annevk>
*claps*

[11:16:06.0000] <TabAtkins>
I aim to please.

[11:49:01.0000] <annevk>
Domenic: the third was `frames` btw

[11:49:11.0000] <annevk>
nobody mentioned it thus far

[11:49:30.0000] <Ms2ger>
frames?

[11:50:37.0000] <annevk>
Ms2ger: frames === window === self

[11:51:03.0000] <Ms2ger>
I see

[11:51:03.0000] <annevk>
Ms2ger: some lame thread on es-discuss on standardizing on global as a way to reference the global nay WindowProxy because these three were not sufficient

[11:51:15.0000] <annevk>
I don't


2015-04-18
[18:49:41.0000] <Domenic>
The correct fix for this is at the ES level I think. Pick window or self (probably not frames) and then it gets implemented in engines and wooo io.js gets something you can use

[23:21:09.0000] <annevk>
TabAtkins: there's a lot of weird stuff going on...

[23:21:29.0000] <annevk>
TabAtkins: e.g. https://dom.spec.whatwg.org/#interface-node has Node and EventTarget as links to non-HTTPS versions of dom.spec.whatwg.org?!

[23:22:09.0000] <annevk>
TabAtkins: and Document links to HTML?

[13:01:58.0000] <TabAtkins>
annevk: I updated some of the specs in Shepherd, which temporarily wipes their definitions, so the linking database was a little funny for a bit.

[15:41:54.0000] <gsnedders>
What am I missing about min-height and height on body that makes http://jsbin.com/yuridimaso/1/ blue only at the top with min-height but the whole viewport blue with height?

[15:42:05.0000] <gsnedders>
/me feels like he's being stupid here

[15:45:57.0000] <Ms2ger>
Perhaps height on body is special-cased?

[15:46:52.0000] <gsnedders>
I don't believe it is?


2015-04-19
[19:41:24.0000] <dbaron>
gsnedders, http://dev.w3.org/csswg/css2/visudet.html#the-height-property defines percentage heights to behave like auto when the containing block's height is not specified explicitly

[19:41:40.0000] <dbaron>
gsnedders, presumably this case counts, although it isn't completely clear

[19:50:00.0000] <gsnedders>
dbaron: okay, that was my best guess

[20:04:02.0000] <gsnedders>
dbaron: yeah, that's definitely it

[20:56:05.0000] <gsnedders>
dbaron: (thanks, by the way)

[05:28:03.0000] <tombob51>
I would like to make an account, with the username "tombob51" so I can add a meta tag.

[05:40:55.0000] <MikeSmith>
tombob51: if you're adding the meta tag for the purpose of getting a document to validate, then don't bother, because the validator doesn't do any checking at all on meta[name] any more

[05:41:12.0000] <MikeSmith>
that whole thing is a failed experiment IMHO

[05:42:03.0000] <MikeSmith>
and speaking as one of the maintainers of the validator, it has cost me a huge amount of time for almost no real benefit to users in practice

[05:42:29.0000] <MikeSmith>
so I'm cutting my losses on that and not going to support meta[name] checking in the validator code any longer

[05:43:06.0000] <tombob51>
I haven't heard of any validator, I just want to add a meta tag so other people can know what it means and use it.

[05:43:53.0000] <MikeSmith>
well I wish I could say that I felt that was worth you taking the time do to it but I don't

[05:44:19.0000] <MikeSmith>
I have perms to add new users to the wiki but I'm not going to add any new users for this purpose

[05:44:36.0000] <MikeSmith>
you might be able to go somebody else here to do it though

[05:44:53.0000] <MikeSmith>
IMHO the whole registration mechanism for new meta[name] keywords has also been a failure

[05:45:18.0000] <tombob51>
I am using the NetBeans IDE, and it throws a warning for the meta tag I'm trying to use. I guess it must have a good validator because it says to add it to this wiki if it's not a typo.

[05:46:31.0000] <MikeSmith>
I don't know what it's using but if it's not just making a network call to the validator, then it might be using a jar I created

[05:46:51.0000] <MikeSmith>
and you might be able to update that jar

[05:47:07.0000] <MikeSmith>
https://github.com/validator/validator/releases

[05:47:20.0000] <tombob51>
I don't know either. Also, I barely know any Java. Could somebody please add this meta tag? Here's an example: <meta name="msapplication-tap-highlight" content="no" />

[05:47:23.0000] <MikeSmith>
https://sideshowbarker.net/releases/jar/

[05:47:32.0000] <tombob51>
https://msdn.microsoft.com/en-us/library/ie/bg182645(v=vs.85).aspx#tapHighlight

[05:48:17.0000] <MikeSmith>
you might also be able to point you IDE at http://validator.w3.org/nu/ instead of https://validator.nu/

[05:49:37.0000] <MikeSmith>
/me now regrets not having removed the meta[name] checking a long time ago

[05:50:11.0000] <tombob51>
Okay it's just a pain to have that warning keep popping up. Just do me a favor and add the meta tag if you won't give me an account.

[05:50:42.0000] <MikeSmith>
no

[05:50:43.0000] <MikeSmith>
sorry

[05:50:56.0000] <MikeSmith>
you can safely ignore that warning

[05:51:04.0000] <tombob51>
ok then. bye

[11:45:47.0000] <zcorpan>
TabAtkins: FATAL ERROR: No 'idl-name' refs found for 'EventTarget'.

[11:47:10.0000] <TabAtkins>
Yeah, Dom/HTML refs are being weird since Friday, sorry. Will troubleshoot tomorrow.

[11:47:40.0000] <TabAtkins>
Something funky with what I did in the DB

[11:48:35.0000] <TabAtkins>
I'm still not 100% sure how the Shepherd db works. 😮

[11:56:06.0000] <zcorpan>
ok

[16:04:31.0000] <theseb>
help! why got this? "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience."

[16:06:50.0000] <jgraham>
Because you did a synchronous XHR on the main thread, which is detrimental to the end user's experiene

[16:06:55.0000] <jgraham>
*experience

[16:09:00.0000] <theseb>
jgraham: how move to another thread?

[16:09:06.0000] <theseb>
jgraham: is that the answer?

[16:09:23.0000] <jgraham>
Probably the answer is to use asynchronous XHR instead

[16:09:42.0000] <jgraham>
That's almost always easier than movoing to another thread (or rather Worker)

[16:10:39.0000] <jgraham>
https://developer.mozilla.org/en/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest

[16:10:46.0000] <theseb>
brython.info has some examples that WORK and don't fall over...i guess i'll have to see how they avoid getting the error i got

[16:13:02.0000] <jarek>
theseb: you are aware that ES6 will support most of the Python features?

[16:13:31.0000] <jarek>
theseb: I would rather use something like Traceur instead of Brython if you want more expressive langauge

[16:13:55.0000] <theseb>
jarek: never heard of it..thanks..

[16:16:27.0000] <jgraham>
Yeah, so there are disadvantages of using languages that do sync io by default and targeting an environment where sync io is a bad idea

[16:17:10.0000] <jgraham>
But it looks like browser.ajax should support async requests

[16:17:36.0000] <jgraham>
xhr = browser.ajax()

[16:18:03.0000] <jgraham>
xhr.bind("loaded" on_loaded)

[16:18:31.0000] <jgraham>
xhr.open("GET", "http://yahoo.com", True)

[16:18:46.0000] <jgraham>
xhr.send()

[16:19:03.0000] <jgraham>
Where on_loaded is a function you define

[16:19:24.0000] <jgraham>
http://brython.info/static_doc/en/ajax.html


2015-04-20
[18:10:25.0000] <MikeSmith>
marcosc: ping

[18:10:34.0000] <MikeSmith>
just landed

[18:13:18.0000] <MikeSmith>
Stallman is on the plane here

[18:41:57.0000] <theseb>
MikeSmith: what?

[00:37:18.0000] <yongc>
Is this a place for asking questions about MIME Sniffing doc?

[00:50:38.0000] <Ms2ger>
Sure

[00:50:40.0000] <Ms2ger>
GPHemsley, ^

[00:56:48.0000] <yongc>
1. In step 8 ""While sequence[s] is not equal to the U+002F SOLIDUS    character ("/"), continuously execute the following steps". So for the content-type "type; parm=value" will set type as "type;parm=value" if there is no ''/" used type,parm,value.

[00:56:48.0000] <yongc>
2. In step 8.2 "If sequence[s] is undefined, return undefined", what's the undefined for sequence[s] mean? Non US-ASCII character?

[01:00:54.0000] <Ms2ger>
I imagine "read past the end of the sequence"

[01:14:51.0000] <yongc>
@Ms2ger, Thanks, from RFC2045, seems "/" is mandatory

[01:15:23.0000] <Ms2ger>
Perhaps, but that doesn't mean it'll always be there

[01:18:06.0000] <yongc>
hmm, but the doc doesn't handle this.

[05:10:39.0000] <GPHemsley>
/me looks

[05:12:16.0000] <GPHemsley>
Yes, "type;parm=value" will eventually terminate at step 8.2 and return undefined.

[05:12:28.0000] <GPHemsley>
yongc: ^

[05:12:31.0000] <GPHemsley>
Ms2ger: ^

[05:13:13.0000] <Ms2ger>
Does the spec explain somewhere that indexing a sequence at EOF yields "undefined"?

[05:14:14.0000] <GPHemsley>
"Let sequence be the byte sequence of the MIME type, where sequence[s] is byte s in sequence and sequence[0] is the first byte in sequence."

[05:15:07.0000] <GPHemsley>
That's intended to imply that if there is no byte s in sequence, then sequence[s] is undefined.

[05:15:51.0000] <GPHemsley>
"A byte sequence is a list of one or more bytes, such that the position of the first byte and the position of the last byte are unambiguously identifiable."

[05:16:06.0000] <GPHemsley>
Perhaps that definition could be extended, if necessary

[05:16:09.0000] <jgraham>
"intended to imply" doesn't sound great

[05:16:34.0000] <jgraham>
/me hasn't actually read the text to see if you actually mean "unambiguously states"

[05:16:47.0000] <GPHemsley>
jgraham: Well, I'm just spelling out my intention of what I meant.

[05:17:09.0000] <GPHemsley>
jgraham: I'll leave it to others to determine whether it matches what I wrote. ;)

[05:17:41.0000] <GPHemsley>
https://mimesniff.spec.whatwg.org/#parse-a-mime-type

[05:17:42.0000] <jgraham>
Well based on what you have written in channel, it doesn't

[05:18:27.0000] <GPHemsley>
If it doesn't, then what behavior would be expected?

[05:19:00.0000] <jgraham>
I have no idea. It seems to be entirely undefined. Maybe your printer is supposed to catch fire?

[05:19:22.0000] <jgraham>
Or do you mean "expected by the web"?

[05:19:27.0000] <GPHemsley>
So, it's undefined that it's undefined?

[05:19:41.0000] <jgraham>
Yes

[05:19:44.0000] <GPHemsley>
k

[05:20:30.0000] <GPHemsley>
Do you think the definition of "byte sequence" is an appropriate place to define it?

[05:20:39.0000] <GPHemsley>
(Because I use the construct a lot throughout)

[05:20:44.0000] <GPHemsley>
s/the/this/

[05:20:49.0000] <jgraham>
It seems like you need to define it where you define the indexing operation

[05:20:57.0000] <GPHemsley>
dang, ok

[05:23:09.0000] <jgraham>
I mean you should probably define indexing notation in a single place in the spec

[05:23:51.0000] <GPHemsley>
yeah

[05:23:54.0000] <jgraham>
Or define a <dfn>element of</dfn> operation on sequences that works like indexing but without brackets

[05:23:55.0000] <GPHemsley>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28519

[07:01:31.0000] <wanderview>
Domenic: I guess SharedArrayBuffer and friends is becoming more real...  have you looked at it in relation to streams API?

[07:29:17.0000] <Domenic>
wanderview: yeah, seems like it would allow a .read(view) that modifies view in-place instead of returning a promise fulfilled with a new view backed by the same memory.

[07:30:23.0000] <Domenic>
that was actually the original plan (more or less) until we realized it would cause user-observable data races

[07:30:42.0000] <Domenic>
now that everyone's like "oh those are fiiiiine" then i guess we can do it, for SAB.

[08:36:22.0000] <wanderview>
Domenic: or are these races something the SAB spec hasn't thought of?

[08:36:37.0000] <Domenic>
wanderview: SAB is specifically designed to allow races to be exposed to the web

[08:36:52.0000] <Domenic>
because that's the only way you can compile C++ to asm.js

[08:36:56.0000] <wanderview>
Domenic: btw, in this update to the memory promise issue gist... can you explain how that lets the chain get dropped?  it seems obervable .then requires the chain to be maintained:  https://gist.github.com/wanderview/16f2839ba57514a625c4#comment-1435869

[08:37:29.0000] <Domenic>
wanderview: there's no return, so no chain actually gets set up

[08:37:51.0000] <Domenic>
I think there might be a solution that allows both, have yet to test it

[08:37:59.0000] <wanderview>
Domenic: the last promise could be elided... but doesn't the chain have to exist?

[08:38:19.0000] <wanderview>
Domenic: I mean... if thats the case we could just collapse promises between the first and last

[08:38:22.0000] <Domenic>
wanderview: no? there's no way to create a chain if there's no returns

[08:38:32.0000] <bradleymeck>
there are also uses for shared memory, but it should be seen as a wart still

[08:38:42.0000] <Domenic>
wanderview: maybe i am confused what you meant by the chain has to exist

[08:38:43.0000] <bradleymeck>
shared locks and transferance is nice

[08:38:57.0000] <wanderview>
Domenic: oh... I thought you just did the if(!chunk) done() step... didn't see you dropped the other return

[08:39:06.0000] <Domenic>
yeah

[08:39:16.0000] <bradleymeck>
shared read locks would make me really happy

[08:39:33.0000] <wanderview>
Domenic: when I talked to bz about this issue he seemed to think the observable .then was the root of the problem...

[08:39:37.0000] <Domenic>
it might be

[08:39:55.0000] <Domenic>
I think there might be a way to use observable .then to collapse the chain "as you build it", but if there's not, then we'll just have to get rid of observable .then I think.

[10:01:32.0000] <MikeSmith>
we're on #extwebsummit for the little thing we're doing here

[14:23:21.0000] <MikeSmith>
https://mobile.twitter.com/ramunas_m/status/590241532613156864

[14:23:35.0000] <MikeSmith>
is that true?

[14:24:28.0000] <MikeSmith>
"End of an era. Opera software sacks 70 employees. Desktop team in Oslo is pretty much disbanded."

[14:24:58.0000] <Ms2ger>
That was a long time coming, if so

[14:43:29.0000] <jgraham>
MikeSmith: I don't know, but I was there for two Opera "rightsizings" and each time the press reported the end of the company

[14:44:02.0000] <MikeSmith>
jgraham: true

[14:46:34.0000] <tantek>
the press loves to report the end of things as well the amazing launch of some new vaporware

[15:40:56.0000] <aleray>
hi, in html5lib python, is there a way to avoid applying a filter on <pre><code> elements ?

[15:46:51.0000] <aleray>
ok I'm having a clue

[15:47:46.0000] <caitp->
don't forget to share your clue with everyone else

[15:48:09.0000] <MikeSmith>
caitp-: y u no come to extensible web summit

[15:48:19.0000] <MikeSmith>
we are talking about custome elements

[15:49:27.0000] <caitp->
i have a bad habit of missing events that i haven't heard of :(

[15:57:03.0000] <aleray>
caitp, basically it would look like: http://dpaste.com/06EZMCC


2015-04-21
[05:51:50.0000] <Ms2ger>
MikeSmith, why does https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html redirect to TR/?

[08:00:21.0000] <wanderview>
Domenic: our native promises are getting faster:  https://bugzilla.mozilla.org/show_bug.cgi?id=1152902

[08:00:43.0000] <wanderview>
Domenic: and we're trying to push on the "ignored return value" optimization, but its tricky:  https://bugzilla.mozilla.org/show_bug.cgi?id=1156797

[09:37:19.0000] <MikeSmith>
https://validator.w3.org/nu/

[09:37:27.0000] <MikeSmith>
now with "s"

[09:42:35.0000] <annevk>
MikeSmith: where are you hanging out this week?

[09:44:06.0000] <MikeSmith>
annevk: Akamai office on Market street

[09:44:26.0000] <MikeSmith>
Hotel is right down the road

[09:44:38.0000] <annevk>
MikeSmith: ah you're at the TAG thing?

[09:44:44.0000] <MikeSmith>
yeah

[09:46:27.0000] <MikeSmith>
annevk: where you?

[09:47:21.0000] <annevk>
MikeSmith: Mozilla

[09:47:37.0000] <annevk>
MikeSmith: trying to get through my backlog

[09:48:05.0000] <MikeSmith>
了解

[09:55:50.0000] <annevk>
Hmm, the WHATWG list too many recipients filter is annoying, can we up the limit Hixie_?

[09:56:07.0000] <annevk>
Or get active moderation? Heh

[10:18:58.0000] <smaug____>
annevk: how do custom elements behave if you for example get a document from XHR, and it has some <div is="foo">s and then you append such elements to the window.document.body and window.document has "foo" registered as custom element

[10:59:34.0000] <annevk>
smaug____: I don't think anything would happen in that scenario

[10:59:50.0000] <annevk>
smaug____: but I'm not a 100% sure

[11:42:48.0000] <Domenic>
web platform test people: is https://github.com/w3c/web-platform-tests/tree/13bff083fba249ed260966bca65319b1b35d3f34/dom/traversal/unfinished named "unfinished" because we should not use it, or...?

[11:45:19.0000] <wanderview>
jgraham: ^^^

[11:45:29.0000] <Domenic>
botie: tell annevk fun fact: https://github.com/whatwg/dom/pull/24 seems to come from an awesome person implementing NodeIterator from scratch from the spec. https://github.com/tmpvar/jsdom/pull/1092

[11:45:29.0000] <botie>
Domenic: i'm not following you...

[11:45:55.0000] <Domenic>
botie: inform annevk fun fact: https://github.com/whatwg/dom/pull/24 seems to come from an awesome person implementing NodeIterator from scratch from the spec. https://github.com/tmpvar/jsdom/pull/1092

[11:45:55.0000] <botie>
will do

[11:46:58.0000] <Domenic>
wanderview: (reading scrollback) oh awesome! Wow that [IsThenMethod] is... I feel bad for causing that.

[11:49:18.0000] <wanderview>
Domenic: I think that particular nuance went over my head

[11:57:08.0000] <trevnorris>
Domenic: is it part of the spec to not be able to call super.call() in a constructor()?

[11:57:24.0000] <Domenic>
trevnorris: you should be able to, after you do super() at least

[11:58:49.0000] <trevnorris>
Domenic: hm. well I wanted to call super.call() in place of super().

[11:59:08.0000] <Domenic>
trevnorris: can't do that. A class isn't initialized until its super() is called.

[11:59:34.0000] <Domenic>
trevnorris: if you want to return something besides whta the superclass allocates then you have to use return-override: var obj = {}; obj.prop = "bar"; return obj;

[12:00:01.0000] <caitp>
hmm, I'm not sure

[12:00:16.0000] <caitp>
you'd have problems if the receiver needed to be used for any SuperProperty

[12:00:22.0000] <Domenic>
trevnorris: https://esdiscuss.org/topic/super-on-class-that-extends

[12:00:32.0000] <caitp>
but I'm not sure it should throwin all cases

[12:00:45.0000] <trevnorris>
Domenic: sure. I was just wondering if there was a way in the immediate future (since io.js 2 won't have restful arguments or the spread operator) to get around doing class constructors with variadic arguments.

[12:01:14.0000] <caitp>
as implemented in v8, super.call() won't work though

[12:01:20.0000] <caitp>
you can't really refer to `super` by itself

[12:01:37.0000] <caitp>
and it's not really an alias for the constructor function

[12:01:41.0000] <Domenic>
trevnorris: yeah, nothing besides switch :-/. Or just assume that 10 arguments is enough for anyone so you can do super(arguments[0], arguments[1], arguments[2], ~~~)

[12:01:59.0000] <Domenic>
/me still thinks `this = new super()` avoided all the confusion.

[12:02:06.0000] <trevnorris>
hahaha. awesome. hopefully none of my constructors would require 10 arguments anyway. :P

[12:03:04.0000] <Domenic>
trevnorris: it's really interesting how you're the first person i've seen bring this up. it's so obvious that there's a dependence here but i've never seen it enunciated before. i feel bad we didn't realize and try harder to align shipping schedules.

[12:03:11.0000] <trevnorris>
caitp: yeah. I see the issue w/ using super.call(). just have this dilemma ATM w/ partial feature implementation. :)

[12:03:40.0000] <caitp>
well, spreadcalls are implemented, they're just very slow :(

[12:03:47.0000] <caitp>
or at least, about on par with traceur

[12:04:13.0000] <caitp>
really hard to optimizethose dynamic argument counts :l

[12:04:19.0000] <trevnorris>
Domenic: heh. no worries. there are a ton of features going in. i'm surprised things have kept as aligned as they have. :)

[12:05:29.0000] <trevnorris>
caitp: true. and w/ all the new features i'm sure the V8 team has their hands full trying to optimize all the things.

[12:06:54.0000] <caitp>
i seem to have my hands full deoptimizing all the things

[12:32:14.0000] <jgraham>
Domenic: No idea

[12:32:59.0000] <jgraham>
Domenic: Looking at the tests, they appear to not be in testharness format

[12:33:12.0000] <jgraham>
So I guess they're unfinished in the sene of "broken"

[12:33:27.0000] <Domenic>
jgraham: ah right, that is a giveaway. thanks.

[13:06:17.0000] <trevnorris>
caitp: hehe. i have wanted to be a fly on the wall in the V8 meetings as they discuss how they're going to implement all these new features while not sacrificing performance.

[13:37:46.0000] <annevk>
Hmm, kind of sad that service workers too will require some way to opt into modules

[13:37:47.0000] <botie>
annevk, at 2015-04-21 18:45 UTC, Domenic said: fun fact: https://github.com/whatwg/dom/pull/24 seems to come from an awesome person implementing NodeIterator from scratch from the spec. https://github.com/tmpvar/jsdom/pull/1092

[13:38:39.0000] <annevk>
Domenic: how's Munich?

[13:38:53.0000] <Domenic>
annevk: not there yet, going after the F2F friday

[13:39:08.0000] <annevk>
oh I see, so you're actually here in SF

[13:39:25.0000] <Domenic>
annevk: nope, i'm still in nyc, flying out thursday night

[13:39:47.0000] <annevk>
oh right, no more TAG for you

[13:43:14.0000] <annevk>
TabAtkins: I now get "FATAL ERROR: No 'idl' refs found for 'normalize'."

[14:11:58.0000] <TabAtkins>
annevk: Yeah, I've got a PR for you.  There were a few errors exposed by the new code.

[14:12:41.0000] <TabAtkins>
Okay, submitted.

[14:36:39.0000] <annevk>
TabAtkins: thanks, will take a look in a bit

[14:53:49.0000] <TabAtkins>
annevk: Yeah, put it together yesterday, but ran out of power before I could PR it. ^_^

[14:53:59.0000] <annevk>
TabAtkins: so this still doesn't really work

[14:54:10.0000] <annevk>
TabAtkins: I got some merge conflict

[14:54:29.0000] <annevk>
TabAtkins: from your commits I was able to get a bit further though

[14:54:33.0000] <annevk>
TabAtkins: current complaint is "FATAL ERROR: No 'propdesc' refs found for 'example'. "

[14:54:58.0000] <TabAtkins>
I fixed that too, hm.  Maybe I didn't successfully push? GH was having some service issues yesterday.

[14:55:02.0000] <TabAtkins>
one sec.

[14:55:27.0000] <TabAtkins>
Or you can manually fix - there's an example with some JS strings using single quotes.

[14:55:38.0000] <TabAtkins>
You can either fix those, or turn off the CSS markup shorthands entirely.

[14:55:44.0000] <TabAtkins>
fix = turn them into double quotes

[14:56:13.0000] <Domenic>
why ... why can't you use single quotes in your JS?

[14:56:16.0000] <TabAtkins>
turn off = Add "Markup Shorthands: css no".

[14:56:52.0000] <TabAtkins>
Domenic: You can't reliably  use single quotes, because they're used in some of the CSS markup shorthands.  This doesn't matter if the code is in a <pre>, <script>, or <style>, but the ones in question are in a <code>.

[14:57:05.0000] <annevk>
Now I get a stacktrace...

[14:57:08.0000] <TabAtkins>
And <code> isn't "opaque" to Bikeshed.

[14:57:09.0000] <annevk>
"UnboundLocalError: local variable 'printableSpec' referenced before assignment"

[14:57:21.0000] <TabAtkins>
Ahahaha, one sec, I'm a dummy.

[14:57:55.0000] <TabAtkins>
Fixed.

[15:25:19.0000] <annevk>
Domenic: I wish the GitHub client exposed --author

[15:25:28.0000] <Domenic>
annevk: aww it doesn't? :(

[15:25:58.0000] <annevk>
I wonder why GitHub for Mac is not on GitHub itself

[15:26:00.0000] <Domenic>
annevk: you can probably use the client then just do `git commit --amend --author...`

[15:26:11.0000] <Domenic>
(before pushing)

[15:26:31.0000] <annevk>
Domenic: it couples commit and push these days, but maybe that can be changed

[15:26:37.0000] <TabAtkins>
Or fuck it and do it after pushing, if you think that maybe other people haven't pulled. ^_^

[15:26:53.0000] <Domenic>
/me eyes TabAtkins suspiciously

[15:27:13.0000] <TabAtkins>
Listen man, I'm a rebel. I do what I want.

[15:27:52.0000] <Domenic>
woo {{s gone

[15:28:02.0000] <TabAtkins>
Yay!

[15:28:14.0000] <annevk>
/me emails support⊙gc

[15:28:33.0000] <TabAtkins>
Now to deal with biblio issues!

[15:28:38.0000] <annevk>
Wait, you can't change a commit after pushing?

[15:28:58.0000] <Domenic>
you can but it's frowned upon

[15:28:59.0000] <TabAtkins>
annevk: Well, you can do whatever you want. But if other people have pulled, and you alter history, they'll have conflicts when they pull again.

[15:29:11.0000] <annevk>
o_O

[15:29:11.0000] <TabAtkins>
They'll have to manage that themselves, which is frustrating.

[15:29:19.0000] <TabAtkins>
Don't alter history, bro.

[15:29:29.0000] <TabAtkins>
Didn't you watch Back To The Future?

[15:30:32.0000] <TabAtkins>
You push commits 1, 2, and 3.  They pull.  Then you alter history and push, so the repo shows 1, 2, and 3a.  They pull.  Now there's a conflict, because their local history says 3 is the HEAD, but 3 doesn't show up in the remote history at all anymore.

[15:30:56.0000] <TabAtkins>
They've gotta manually checkout 2, *then* merge in the remote history, so they can go to 3a properly.

[15:43:23.0000] <jamesr___>
non-fast-forward pushes are evil

[15:47:46.0000] <jgraham>
Well github is designed all around encouraging them

[15:48:15.0000] <jgraham>
See, for example, the number of people that push each new commit to a PR as a --amend

[15:49:06.0000] <jgraham>
That's pure GH failure, because it should clearly have a "squash and merge" option

[15:50:54.0000] <annevk>
TabAtkins: in Notifications API I get "FATAL ERROR: Couldn't find target anchor dom-notification-notification: "

[15:51:06.0000] <annevk>
TabAtkins: Bikeshed seems very unstable

[16:02:21.0000] <annevk>
/me finds a fix

[16:05:17.0000] <TabAtkins>
annevk: I didn't even realize Notifications was on Bikeshed.

[16:05:44.0000] <TabAtkins>
annevk: And the word you're looking for is "actively maintained" or "living standard".

[16:06:15.0000] <annevk>
A living standard doesn't break backcompat lightly though

[16:06:25.0000] <annevk>
even though its detractors like to use that as an argument

[16:07:10.0000] <JoWie>
annevk: hey

[16:07:21.0000] <annevk>
hey

[16:07:40.0000] <JoWie>
I found another issue in the node iterator removing steps

[16:07:47.0000] <JoWie>
(that PR was mine)

[16:08:31.0000] <JoWie>
point 3 says: "Set the referenceNode attribute to first node preceding oldPreviousSibling, if oldPreviousSibling is non-null,"

[16:09:03.0000] <JoWie>
i think the intent is to set it to the preceding of where the removed node was

[16:09:15.0000] <JoWie>
this matches the test

[16:09:26.0000] <JoWie>
what would be a good way to formulate this?

[16:09:55.0000] <JoWie>
I was thinking something like "Set the referenceNode attribute to the last descendant in tree order of oldPreviousSibling, ..."

[16:10:42.0000] <TabAtkins>
Back-compat is nice, yes, but it's way more important for standards than for standards-development tools. ^_^

[16:12:09.0000] <TabAtkins>
annevk: Ah, I see the error.  Yeah, that was due to a new check. I won't apologize for adding things that make specs better, which old specs might violate because it wasn't previously checked.

[16:13:15.0000] <annevk>
JoWie: isn't that what preceding means?

[16:13:27.0000] <TabAtkins>
(I'm gonna tweak it a bit, but you can probably use `lt="Notification()"` to link to things - whenever it's unambiguous, you should be able to omit the arguments from the linking text of a method link. If you find an exception, please let me know.)

[16:13:50.0000] <annevk>
I see

[16:13:57.0000] <JoWie>
annevk: it says preceding of oldPreviousSibling

[16:14:22.0000] <JoWie>
which is oldPreviousSibling.previousSibling.lastChild.lastChild (until not null)

[16:14:36.0000] <JoWie>
but what you need it oldPreviousSibling.lastChild.lastChild etc

[16:14:57.0000] <annevk>
Hmm yes

[16:16:26.0000] <annevk>
That is somewhat annoying, oldPreviousSibling might not have any descendants

[16:16:37.0000] <annevk>
So I guess that would need to be more elaborate overall...

[16:18:53.0000] <JoWie>
"inclusive descendant"?

[16:19:18.0000] <JoWie>
which exists

[16:31:00.0000] <JoWie>
anyway bedankt, i gotta sleep

[16:36:23.0000] <annevk>
graag gedaan


2015-04-22
[21:47:06.0000] <dglazkov>
smaug____: apologies for a (day-long) delay

[21:50:06.0000] <dglazkov>
when you get a document from XHR, the document that was created will not have a registry associated with it: http://w3c.github.io/webcomponents/spec/custom/#creating-and-passing-registries

[21:50:20.0000] <smaug____>
right

[21:50:24.0000] <dglazkov>
when you append such an element to another document, nothing will happen

[21:50:30.0000] <dglazkov>
unless you import it

[21:50:51.0000] <smaug____>
meaning, clone into document..

[21:50:54.0000] <smaug____>
but ok

[21:51:03.0000] <dglazkov>
yep

[21:51:16.0000] <dglazkov>
the element is once-born

[21:51:17.0000] <smaug____>
I've never understood why registry is for browsing context documents only

[21:52:23.0000] <dglazkov>
well, it seems bad that you're XHR-ing a doc, and suddenly you get all sorts of JS executed as a result

[21:52:31.0000] <smaug____>
but I can see that we don't want to change element's behavior when moving it between documents

[21:53:47.0000] <smaug____>
"suddenly", well you'd need to explicitly register stuff

[21:55:34.0000] <smaug____>
but not a big deal

[21:56:04.0000] <smaug____>
(the requirement for browsing context)

[21:56:36.0000] <dglazkov>
I guess because we don't have registries, another actor on the page could be registering elements.

[21:56:49.0000] <dglazkov>
FWIW, I really want to pursue registries and the ability to swap them around

[21:57:13.0000] <dglazkov>
so that you could potentially XHR a doc with a localized set of registered elements

[21:58:24.0000] <dglazkov>
but we need to learn to walk before flying

[21:58:45.0000] <dglazkov>
first get everyone agreed on the constructors/is=/upgrade

[05:53:13.0000] <Ms2ger>
mathiasbynens, ping

[08:11:24.0000] <mathiasbynens>
Ms2ger: pong

[08:11:35.0000] <Ms2ger>
Ah, now you're here :)

[08:11:39.0000] <Ms2ger>
https://github.com/w3c/csswg-test/pull/773

[08:12:38.0000] <mathiasbynens>
/me checks

[08:14:22.0000] <mathiasbynens>
Ms2ger: did you have to add any tests that were not in https://github.com/mathiasbynens/CSS.escape/blob/master/tests/tests.js? if so please let me know

[08:16:38.0000] <Ms2ger>
mathiasbynens, nope

[10:45:48.0000] <wanderview>
Domenic: do you have examples of eliding ignored-returned-promise optimization being a big win?

[11:32:55.0000] <annevk>
/me finds out IDB doesn't really do tasks

[11:35:43.0000] <wanderview>
annevk: what do you mean?

[11:35:55.0000] <annevk>
wanderview: mostly that the specification is bonkers

[11:36:18.0000] <annevk>
wanderview: in that it doesn't really integrate with the event loop

[11:53:11.0000] <MikeSmith>
which spec

[14:31:25.0000] <annevk>
MikeSmith: IDB

[14:41:43.0000] <annevk>
Domenic: ah, .patch is nice

[14:42:06.0000] <annevk>
Domenic: now I just need to figure out multiline comments in the Terminal...

[14:55:44.0000] <MikeSmith>
the HTTP2 spec calls streams "promises"?

[15:27:38.0000] <TabAtkins>
zcorpan: Any chance you can search for any pages with "@media not" or "media='not", and give me the rest of the MQ?

[15:29:29.0000] <TabAtkins>
Seeking forward to the { or newline in the first case, and to the matching quote in the other.

[15:30:04.0000] <TabAtkins>
Wanna do some analysis on whether using Kleene's 3-value truth algebra is backwards compatible, or if we have to do something slightly different.

[15:36:27.0000] <TabAtkins>
(In particular, the question is whether "false AND unknown" should evaluate to false or unknown. Naively preserving backwards compat demands "unknown", but if the breakage would be minimal or non-existent, evaluating to "false" has more consistent semantics.)

[16:00:05.0000] <dglazkov>
annevk: what are your thoughts on https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution?

[16:00:31.0000] <dglazkov>
I posted mine here: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0208.html

[16:13:22.0000] <TabAtkins>
While I'm not strongly opposed to a slot-name-based distribution, it's extra ugly work.  Requiring people to use an additional attribute/value combo for the declarative syntax, and requiring use of the imperative form to get anything better, just means the declarative form is a ghetto, and for no good reason.

[16:13:49.0000] <TabAtkins>
Super simple things, like "put an <h1> into your <x-slide>" become much more annoying. :/

[16:14:03.0000] <TabAtkins>
I mean, limiting the selectors that can be used is easy-peasy.

[16:17:53.0000] <dglazkov>
<x-side><h1>should work just fine</h1></x-side>, right?

[16:18:16.0000] <dglazkov>
oh, you mean the <details><summary> use case.

[16:20:56.0000] <TabAtkins>
dglazkov: Yeah, the <details> thing is actually pretty common.  I wanna be able to write <x-slide><h1>A topic</h1><p>stuff about the topic<p>more stuff</x-slide>

[16:21:42.0000] <TabAtkins>
And if I have to write <x-slide><h1 content-slot="heading">A topic</h1><p>stuff about the topic<p>more stuff</x-slide> it's like, really? Really??

[16:21:44.0000] <dglazkov>
I think we should start a page documenting where the flexibility is lost on the wiki

[16:21:55.0000] <TabAtkins>
Just screenshot the email thread. ^_^

[16:24:52.0000] <TabAtkins>
This sort of syntax just screams "this is bolted-on, and we don't care that it's obvious".

[16:26:13.0000] <TabAtkins>
But also, reprojection being essentially impossible without explicit coordination sinks this right away imo.


2015-04-23
[17:20:19.0000] <rniwa>
Domenic: I don't understand your comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544 at all

[17:20:26.0000] <rniwa>
Domenic: import { myClass } from 'mymodule';

[17:20:26.0000] <rniwa>
var a = new myClass;

[17:20:49.0000] <rniwa>
Domenic: wouldn't result in a ReferenceError of any sort

[17:22:27.0000] <caitp->
my understanding is that module imports are resolved before evaluation starts

[17:22:34.0000] <caitp->
too lazy to confirm

[17:23:06.0000] <caitp->
tdz of some sort i'm sure, but still

[17:27:08.0000] <rniwa>
caitp-: Right.

[17:27:25.0000] <rniwa>
caitp-: the fact it blows up in the case of a circular dependency is an orthogonal issue

[17:27:50.0000] <caitp->
iirc there's language to solve that, too

[17:28:17.0000] <caitp->
at the very least direct circular imports are ignored

[17:30:04.0000] <caitp->
oh, s/ignored/throws a syntax error

[17:32:25.0000] <rniwa>
caitp-: I think we did solve that issue by throwing ReferenceError

[17:32:58.0000] <caitp->
yes, ResolveExport returns null, and in response all callers throw a SyntaxError

[17:33:07.0000] <caitp->
so, maybe not quite as nice

[17:36:40.0000] <rniwa>
caitp-: well, circular dependency usually implies a programming error though

[17:36:42.0000] <rniwa>
so that might be okay

[17:36:52.0000] <rniwa>
although there are legitimate use cases...

[17:41:57.0000] <caitp->
in any case it's not a reference error or type error to touch an import "before it's loaded", because you can't (with the exception of dynamic module imports)

[23:12:37.0000] <zcorpan>
TabAtkins: can't omit </p> there, as it happens

[00:04:51.0000] <zcorpan>
TabAtkins: help http://dev.w3.org/csswg/bikeshed/cssom-view/

[00:06:47.0000] <zcorpan>
TabAtkins: also when i remove open() from Ignored Terms i get this:

[00:06:51.0000] <zcorpan>
WARNING: Multiple possible 'idl' refs for 'open()'.

[00:06:52.0000] <zcorpan>
Arbitrarily chose the one in html.

[00:06:52.0000] <zcorpan>
If this is wrong, insert one of the following lines into a <pre class=link-defaults> block:

[00:06:53.0000] <zcorpan>
spec:html; type:method; for:Window; text:open()

[00:06:55.0000] <zcorpan>
spec:html; type:method; for:Window; text:open()

[05:33:43.0000] <MikeSmith>
/win/win 2

[05:57:38.0000] <ondras>
win-win!

[09:14:37.0000] <TabAtkins>
zcorpan: Specs that aren't Bikeshedded sometimes define things twice, and I don't know how to avoid that.  That's why it was in Ignored Terms. ^_^

[09:15:32.0000] <darobin>
mmmmm

[09:15:40.0000] <darobin>
maybe this should be in the pubrules validator

[09:15:49.0000] <darobin>
don't define thing twice

[09:16:05.0000] <darobin>
the tool could do a lot more linting

[09:17:09.0000] <TabAtkins>
darobin: That would be nice! In this case, though, it's HTML, which I don't think is really PubRules checked. ^_^

[09:17:42.0000] <TabAtkins>
/me wonders if he should just make Bikeshed ignore it when it ends up with two identical definitions, and just silently choose one for you.

[09:17:45.0000] <darobin>
TabAtkins: well, if it's a part that is kept on the W3C side it gets pubrules checked every time it changes :)

[09:18:00.0000] <darobin>
and we could add support for linting WHATWG specs to specberus

[09:18:05.0000] <TabAtkins>
spec:html refers to WHATWG, yeah.

[09:19:09.0000] <TabAtkins>
zcorpan: I'll fix the stacktrace, though.

[09:30:48.0000] <annevk>
Apple's feedback reads pretty well to me

[09:30:54.0000] <annevk>
smaug____: you read it?

[09:33:21.0000] <smaug____>
annevk: well...

[09:34:17.0000] <smaug____>
it feels odd that you effectively say from outside the component where your child nodes should be distributed

[09:34:45.0000] <smaug____>
that hasn't been the idea with XBL and such

[09:35:23.0000] <smaug____>
but perhaps the slots + imperative API is enough

[09:35:52.0000] <annevk>
oh that bit, yeah, I'm not a 100% sold on slots yet, though I kind of like it

[09:36:03.0000] <annevk>
seems somewhat nice to have an opinionated public API contract

[09:42:31.0000] <Domenic>
It worries me that it means shadow DOM isn't useful for explaining <details> or <select> or similar.

[09:45:13.0000] <smaug____>
shadow DOM  (or shadow + custom) isn't enough to explain various behaviors of native elements

[09:45:44.0000] <smaug____>
but the slots approach does seem to take us even farther(sp?) away

[09:47:07.0000] <smaug____>
long ago when there was xforms (yes yes, I know) addon for Firefox, XBL, which has roughly the same capabilities as shadow dom + custom, wasn't enough to implement the new elements.

[09:47:17.0000] <smaug____>
XTF + XBL was enough

[09:47:40.0000] <smaug____>
XBL was used mainly as a presentation layer, and XTF was the lower level thing

[09:48:10.0000] <smaug____>
but XTF was so low level, that only privileged scripts could use it to implement new stuff

[09:50:39.0000] <Domenic>
For sure, it isn't enough, it's part of the puzzle. Or at least it would be, if we didn't have this slots thing.

[11:47:33.0000] <hober>
MikeSmith dglazkov: dumb github question. How do I get write access to the w3c/webcomponents.wiki repo (i'm trying to add a wiki page)

[11:47:56.0000] <MikeSmith>
hober: I have to add you

[11:48:07.0000] <hober>
MikeSmith dglazkov: normally i'd send a pull request but github doesn't do pull requests for gh wikis

[11:48:08.0000] <MikeSmith>
because of asshatted github ACLs setup

[11:48:12.0000] <MikeSmith>
yeah

[11:48:15.0000] <hober>
MikeSmith: ahh ok

[11:48:17.0000] <hober>
MikeSmith: thanks

[11:49:20.0000] <trevnorris>
Domenic: would there be some es6 class magic that would allow an inherited static method change a property on the inherited class? probably doesn't make sense. i'll write up some code.

[11:50:20.0000] <MikeSmith>
hober: you should be good to go now

[11:50:37.0000] <hober>
awesome, it worked. thanks!

[11:51:22.0000] <othermaciej>
MikeSmith: can I be added to so I can edit what hober just uploaded?

[11:51:35.0000] <othermaciej>
MikeSmith: I have a github account as “othermaciej”

[11:54:27.0000] <trevnorris>
Domenic: here's using both 5 and 6. https://gist.github.com/trevnorris/e3144f66dfa0aac6ff27

[11:57:20.0000] <MikeSmith>
othermaciej: hai, just added you

[11:58:16.0000] <othermaciej>
MikeSmith: thanks

[12:01:00.0000] <trevnorris>
Domenic: actually, can es6 classes have static members that aren't methods?

[12:16:20.0000] <Domenic>
trevnorris: sure, MyClass.x = "whatever" (or use static get/static set for accessors)

[12:17:07.0000] <trevnorris>
Domenic: though that really gimps "use strong" for v8.

[12:17:39.0000] <Domenic>
Yes well if you wanna program in JS program in JS if you wanna program in a V8 dialect program in that

[12:17:58.0000] <Domenic>
trevnorris: the two things in your gist look equivalent

[12:18:25.0000] <trevnorris>
Domenic: I just updated the es6 example with a more full implementation to show the required code duplication.

[12:18:35.0000] <Domenic>
Note that `this` inside static methods is the class itself

[12:18:49.0000] <trevnorris>
Domenic: even if it's inherited?

[12:19:31.0000] <trevnorris>
FREAK YES!

[12:19:38.0000] <Domenic>
None of the stuff you just added to that gist is necessary

[12:20:05.0000] <trevnorris>
awesome. so I can use this._onreadable inside the static method and the inheritance will work.

[12:20:31.0000] <Domenic>
Yep yep. ES6 classes do class-side inheritance

[12:20:41.0000] <trevnorris>
okay. i'm actually a little excited for es6 class syntax (still hate the class keyword since it's technically prototype, but whatever)

[12:22:38.0000] <trevnorris>
sweet, sweet. extends even makes sure to extend the static stuff after the fact. alright. this is legitimately good sugar. :)

[12:23:12.0000] <Domenic>
In ES5 terms, Derived.__proto__ = Base in addition to Derived.prototype.__proto__ = Base.prototype

[12:23:23.0000] <Domenic>
Haha yay :)

[12:29:48.0000] <gsnedders>
jgraham: do you have thoughts on how Reviewable compares with Critic?

[12:29:56.0000] <gsnedders>
Domenic: __proto__ isn't an ES5 term! *hides*

[12:32:13.0000] <trevnorris>
Domenic: hm. was getting ahead of myself and didn't think through the implementation impact. e.g. https://gist.github.com/trevnorris/e3144f66dfa0aac6ff27#file-inheritence-stuff-es6-js

[12:33:31.0000] <trevnorris>
Domenic: how do I get the _onreadable value from the specific class calling the constructor in Readable?

[12:34:42.0000] <trevnorris>
because it is changing the value on the inherited class properly, but not sure how to get it from the Readable constructor().

[12:53:21.0000] <trevnorris>
Domenic: nm. got it figured out. didn't know you could reference this.constructor.

[14:10:48.0000] <jgraham>
gsnedders: They managed to make the UI even more confusing

[14:11:55.0000] <gsnedders>
jgraham: impressive.

[14:12:05.0000] <gsnedders>
jgraham: sounds like it integrates better with GH, though

[14:31:22.0000] <MikeSmith>
does anybody ever try to run blame on the HTML spec

[14:31:39.0000] <MikeSmith>
nm

[14:31:55.0000] <MikeSmith>
was just taking a lot longer than I remembered it taking

[14:51:57.0000] <trevnorris>
Domenic: is there a spec somewhere for "new.target" within a class constructor?

[15:04:24.0000] <caitp>
trevnorris, what do you mean?

[15:05:05.0000] <trevnorris>
caitp: posted something on the "use strong" mailing list and someone told me that you can't use "this.constructor" in a constructor() callback. instead should use "new.target"

[15:05:13.0000] <trevnorris>
caitp: never heard of it before.

[15:05:20.0000] <caitp>
it's a new thing

[15:05:26.0000] <caitp>
as of like january, iirc

[15:05:56.0000] <trevnorris>
ah, okay. is there a spec out for it, or has it just been discussed?

[15:05:57.0000] <caitp>
if "new.target" is undefined, it means that the function was not called with `new`

[15:06:11.0000] <caitp>
yeah, it's all in the ES spec --- search for [[NewTarget]]

[15:06:16.0000] <trevnorris>
thanks.

[15:06:45.0000] <caitp>
if it's not undefined, it's the target constructor (eg, the one which was the operand of `new`)

[15:13:44.0000] <gsnedders>
MikeSmith: yes

[15:39:03.0000] <jgraham>
gsnedders: Yes, the github integration is better in the sense that rebases are more seamless and it seems to not randomly fail to sync occasionally

[15:39:11.0000] <jsbell>
uh, so idlharness requires ES6 arrow functions now?

[15:39:30.0000] <jgraham>
jsbell: That's a bug, fixes welcome

[15:39:42.0000] <jgraham>
I thought someone already fixed it but apparently not

[15:40:19.0000] <jgraham>
(people have been using them in Mozilla code for years, so it's easy to forget they don't work everywhere yet)

[15:45:33.0000] <jsbell>
jgraham: https://critic.hoppipolla.co.uk/r/4777

[15:45:50.0000] <jsbell>
"works on my machine"

[15:49:33.0000] <jgraham>
jsbell: r+ and merged

[15:51:19.0000] <jsbell>
jgraham: yay

[15:51:39.0000] <jgraham>
jsbell: Thanks for the fix and sorry for the inconvenience

[15:54:55.0000] <jsbell>
np; now to figure out if I should add allow_uncaught_exception sprinkles to some tests...

[16:48:01.0000] <TabAtkins>
zcorpan: Okay, stacktrace fixed. That one was tricky!


2015-04-24
[17:02:14.0000] <TabAtkins>
annevk: Heads up, just broke local anchor handling when I fixed zcorpan's issue.  Fixing now. ^_^

[17:21:15.0000] <TabAtkins>
annevk: And done.

[17:36:36.0000] <annevk>
TabAtkins: I'm gonna assume this is about DOM and say ta

[17:36:47.0000] <annevk>
/me has a huge backlog of all the things

[17:36:59.0000] <TabAtkins>
annevk: Yup. Fixing up the bibliography now.

[03:16:56.0000] <zcorpan>
PSA: i'll be offline from next week through mid-August (parental leave)

[03:19:30.0000] <Ms2ger>
r? https://critic.hoppipolla.co.uk/r/4754

[03:37:02.0000] <zcorpan>
r+

[05:35:05.0000] <zcorpan>
botie: inform annevk ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=26200#c25

[05:35:06.0000] <botie>
will do

[05:36:23.0000] <zcorpan>
botie: inform annevk (we have lots of *List interfaces without [NoInterfaceObject])

[05:36:23.0000] <botie>
will do

[09:05:53.0000] <botie>
annevk, at 2015-04-24 12:35 UTC, zcorpan said: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=26200#c25 and at 2015-04-24 12:36 UTC, zcorpan said: (we have lots of *List interfaces without [NoInterfaceObject])

[09:07:13.0000] <annevk>
good times

[12:33:02.0000] <gsnedders>
jgraham: also having the comments syned across both means that new contributors are less likely to get confused by comments being elsewhere

[12:34:00.0000] <jgraham>
OTOH having reviable spam all the commit messages is very annoying

[12:34:05.0000] <jgraham>
*reviewable

[12:35:18.0000] <gsnedders>
tbf, it seems more likely to improve than Critic ;P

[12:41:41.0000] <jgraham>
Could be.

[12:42:01.0000] <jgraham>
I have heard conflicting reports about how responsive the authors are to feedback

[12:42:22.0000] <jgraham>
They apparently flat-out refuse to fix issues that affect only Gecko for example

[12:42:33.0000] <jgraham>
Or, afaict, anything !chrome

[12:43:04.0000] <gsnedders>
:(


2015-04-25
[12:45:58.0000] <hallvors>
I'd like some developer comments on this idea: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0173.html - any idea how I can get it some attention? Seems Chrome is busy improving their clipboard stuff support, which is cool, but it means it would be nice to find a good feature detection story soon.. (also posted on W3C #webapps, with

[12:45:59.0000] <hallvors>
apologies to those in both rooms..)

[12:55:47.0000] <hallvors>
Asking IRC questions on a Saturday afternoon in April is obviously not the right way to get attention :)

[14:15:15.0000] <gsnedders>
Unicode 3.0 is such a clusterfuck. "A process shall interpret Unicode code values as 16-bit quantities"; "Unicode scalar value: a number N from 0 to 10FFFF_{16}", "A Unicode scalar value is also referred to as acode position or a code point"

[14:27:03.0000] <caitp>
does that predate the supplementary planes?

[14:27:09.0000] <caitp>
and if so, does it matter?

[14:29:03.0000] <gsnedders>
caitp: no, it doesn't

[14:29:19.0000] <gsnedders>
caitp: the supplementary planes are defined but have no allocations as of Unicode 3.0

[14:31:36.0000] <caitp>
but that's still like a decade and a half ago

[14:32:03.0000] <caitp>
just not totally sure why this still matters, the bmp should be more or less compatible still no?

[14:32:13.0000] <caitp>
not really following unicode too closely

[14:32:24.0000] <gsnedders>
it is, but it's still hurting insofar as pushing everything to use 16-bit code units as their basic unit

[14:32:54.0000] <gsnedders>
instead of code points

[14:43:19.0000] <caitp>
well it suits most of the people using computers that don't need to use ideographic writing systems often pretty nicely

[14:43:35.0000] <caitp>
so that's something at least


2015-04-26
[05:56:34.0000] <pyfisch>
hello, what is the "preferred" way to format quality values in http headers? "de,en-US;q=0.7,en;q=0.3" or "de, en-US;q=0.7, en;q=0.3" or "de, en-US; q=0.7, en; q=0.3"

[05:56:49.0000] <pyfisch>
And should q=1 be left out normally?


2015-04-27
[23:43:43.0000] <annevk>
hayato: I think I'll create an event tracking bug for Shadow DOM

[23:44:06.0000] <annevk>
hayato: to enumerate the various changes we discussed last week and have some kind of overview of that

[23:45:23.0000] <hayato>
annevk: you'll file a bug? I'm fine with it. Let's summarize what are required.

[23:54:27.0000] <annevk>
hayato: yeah will do in a bit

[00:01:44.0000] <MikeSmith>
/me waves from Tokyo

[00:02:17.0000] <MikeSmith>
lots hotter here today than it was in San Francisco yesterday

[00:15:07.0000] <Ms2ger>
annevk, is https://github.com/w3c/web-platform-tests/commit/02ac3d372060393f4c0a6a0f29a95dd9f0ee8fda still on your radar?

[00:54:17.0000] <annevk>
Ms2ger: the reason I pushed it is mostly so that others can take it and finish it

[00:54:32.0000] <Ms2ger>
Ah

[00:54:36.0000] <annevk>
Ms2ger: but maybe at some point I can get back to it

[00:54:38.0000] <Ms2ger>
Not it :)

[02:26:19.0000] <annevk>
/me wonders what mistake smaug saw in https://gist.github.com/annevk/e9e61801fcfb251389ef

[03:10:53.0000] <annevk>
/me wonders if Domenic still wants an example of how to replace .matches(getAttribute("select")) with .localName == ...

[04:26:31.0000] <annevk>
hayato: for parent/child across boundaries I suggest we introduce "composed parent/child", "deep parent/child", etc. and all their friends

[05:45:35.0000] <jgraham>
OK, this is bothering me. Does anyone remember where that Hixie quote about going to fix something and ending up having to rebuild the foundations of the (house? city?) is?

[06:03:07.0000] <MikeSmith>
sorta vaguely remember that but don't remember the specifics (except that I do think it was about ending up rebuilding the whole house)

[06:45:25.0000] <MikeSmith>
hallvors: so is http://jsfiddle.net/670s9usk/ in fact a solution for feature-detecting Clipboard API support?

[06:54:03.0000] <hallvors>
MikeSmith: yes, it might be *a* solution. Not sure if it's perfect..

[06:56:17.0000] <hallvors>
one of the flaws is that it can't run really early on - it needs a document where you can create some selection.

[07:00:26.0000] <hallvors>
but it might be a workable solution..

[07:25:29.0000] <MikeSmith>
hallvors: ok

[07:45:27.0000] <Domenic>
jgraham: "If you wish to make an apple pie from scratch, you must first invent the universe."? Carl Sagan

[07:45:45.0000] <Ms2ger`>
Not quite that :)

[07:46:27.0000] <Ms2ger`>
More like "if your apple pie is slightly too big for your oven, invent a new universe"

[07:49:11.0000] <jgraham>
s/invent a new universe/realise that the underlying problem is a poor choice of fundamental physical constants/

[07:49:39.0000] <jgraham>
and I geuss s/if /find /

[10:00:44.0000] <annevk>
smaug____: wouldn't components want to dispatch events for internal usage?

[10:07:16.0000] <smaug____>
annevk: well, so far they haven't wanted that

[10:07:28.0000] <smaug____>
I'm not really against the flag being exposed

[10:07:46.0000] <annevk>
baby steps I guess

[10:07:48.0000] <smaug____>
but let's just not expose random stuff we think might be needed

[10:07:52.0000] <smaug____>
yeah

[10:08:03.0000] <annevk>
the main thing people have asked for that isn't there is no retargeting

[10:08:25.0000] <smaug____>
(odd flight, only ~20% of the seats were taken)

[10:08:27.0000] <annevk>
there's workarounds in the form of deep* but not quite the same since a bunch of events end up never reaching the top

[10:08:50.0000] <annevk>
(I had a spare seat which was nice, but mostly full)

[10:09:06.0000] <smaug____>
I think we may want to rethink the "let's always retarget "

[10:09:58.0000] <annevk>
Assuming we go with visible/hidden/isolated terminology, I would kind of prefer that in visible there is no retargeting by default, but the Polymer guys don't seem to enjoy that idea

[10:09:59.0000] <smaug____>
though, if we weren't retargeting always, wouldn't some scripts still possibly want the deep stuff in case they do use retargeting

[10:10:17.0000] <annevk>
So Polymer wants retargeting + deep*

[10:10:25.0000] <smaug____>
sure

[10:10:42.0000] <smaug____>
well, so far apparently only deepPath

[10:10:42.0000] <annevk>
But Polymer is just a match of Web Components so it's hard to take it for granted...

[10:10:59.0000] <annevk>
Yeah also weird

[10:12:15.0000] <annevk>
Domenic: visible to the light DOM

[10:13:57.0000] <smaug____>
/me needs to find some food here at Heathrow

[10:16:01.0000] <Domenic>
annevk: I think "visible" describes non-shadow DOM (light DOM), it doesn't describe any kind of shadow DOM

[10:16:25.0000] <Domenic>
Indeed "hidden" describes it better since it's hidden from selectors and behind .shadowRoot.

[10:32:45.0000] <annevk>
Domenic: shadow / hidden / isolated kind of works

[10:32:54.0000] <annevk>
Domenic: shadowPath might even be okay then

[10:39:45.0000] <annevk>
maybe hiddenShadow / isolatedShadow since they're all shadow tree in some way...

[10:53:26.0000] <Domenic>
yeah i dunno was just trying to come up with something that makes it clear it's not business as usual

[10:53:41.0000] <Domenic>
I still like censored since it's descriptive of what's actually happening instead of trying to be an abstract concept

[10:57:57.0000] <SimonSapin_>
Is SVG Tiny relevant to the web?

[11:03:36.0000] <MikeSmith>
SimonSapin_: I think most people would answer that no it is not

[11:03:54.0000] <SimonSapin>
ok, thanks

[11:27:16.0000] <gsnedders>
How do I get Blink people to notice a site-compat bug?

[11:27:20.0000] <gsnedders>
Namely, https://code.google.com/p/chromium/issues/detail?id=481591

[11:33:12.0000] <caitp>
pinging some of the blink guys in here might be a start

[11:35:23.0000] <gsnedders>
I'm assuming a several of the Google people will ntoice. And not bothering to disturb them. Yet.

[11:56:33.0000] <MikeSmith>
also there's always the #blink and #chromium channels here

[11:56:48.0000] <MikeSmith>
that's what I use

[11:56:54.0000] <gsnedders>
tbf I feel a bit bad doing that because if everyone who reported bugs did that…

[11:57:04.0000] <MikeSmith>
well, not everybody does

[11:57:15.0000] <MikeSmith>
and also, you're not just everybody

[11:57:52.0000] <MikeSmith>
and also, that's what I do, so axiomatically it must be OK

[11:57:56.0000] <gsnedders>
MikeSmith: fine, you win

[11:58:14.0000] <MikeSmith>
/me awards himself a beer

[11:58:21.0000] <caitp>
triagers would probably get to it over night anyways

[11:58:40.0000] <caitp>
but getting someone in here to look at it quick might get the right people CC'd quickly

[11:58:45.0000] <MikeSmith>
yeah

[12:00:15.0000] <Ms2ger`>
MikeSmith, but what if everyone did that?

[12:01:57.0000] <MikeSmith>
/me gets Ms2ger`'s point and buys stock in beer before everybody else starts to realize what's going to happen 

[12:02:04.0000] <Ms2ger`>
:D

[12:02:25.0000] <caitp>
hah

[14:21:58.0000] <jgraham>
jsbell: https://critic.hoppipolla.co.uk/r/4822 https://critic.hoppipolla.co.uk/r/4823

[14:23:31.0000] <TabAtkins>
SimonSapin: SVG Tiny is definitely *not* web-relevant.  It was never implemented anywhere except maybe one of the weirder Opera variants.

[14:24:08.0000] <jsbell>
jgraham: thx. will take a look

[14:24:25.0000] <pdr>
A few of the svg tiny features were pulled into svg2 such as vector-effects: non-scaling-stroke

[14:24:28.0000] <jgraham>
https://critic.hoppipolla.co.uk/r/4825

[14:24:35.0000] <wanderview>
jsbell: I am writing a bunch of these? want me to email you or just add to the review somehow?

[14:24:48.0000] <wanderview>
I mean... I am writing a bunch of these

[14:24:54.0000] <jsbell>
wanderview: both?

[14:25:12.0000] <wanderview>
jsbell: I expect to have 8 or 9 PRs when I am done

[14:25:32.0000] <wanderview>
jsbell: summary of them is in the bug list here: https://bugzilla.mozilla.org/show_bug.cgi?id=1154325#c19

[14:25:47.0000] <wanderview>
you can hover over the links to see the summary

[14:26:43.0000] <wanderview>
I'll add you to the future reviews

[14:28:01.0000] <jgraham>
jsbell: You should set up a critic filter for /service-workers/

[15:39:51.0000] <trevnorris>
Domenic: in es7 will it be possible to set static class properties that aren't methods or getters/setters?

[15:42:03.0000] <caitp>
jeffmo has a stage 0 proposal (is it still stage 0?), and typescript and others follow in those footsteps

[15:42:13.0000] <caitp>
it's anyones guess :>

[15:43:23.0000] <caitp>
but i guess, hopefully

[16:06:40.0000] <aklein>
rniwa: ping?

[16:06:46.0000] <rniwa>
aklein: pong

[16:06:57.0000] <rniwa>
ark: thanks for all the bugs!

[16:07:17.0000] <aklein>
rniwa: just a quick clarification about your response re: timing and shadow dom distribution

[16:08:06.0000] <aklein>
rniwa: when you say timing is "deferred", you mean that there's no need for the spec to explain timing?

[16:08:21.0000] <aklein>
the explanation is "the distribution happens when you call distribute()"?

[16:09:34.0000] <aklein>
rniwa: in other news, re: static data properties, what caitp said above: it's part of jeffmo's proposal at https://gist.github.com/jeffmo/054df782c05639da2adb

[16:13:57.0000] <rniwa>
aklein: right.

[16:14:24.0000] <rniwa>
aklein: the idea is to let other APIs define the timing.

[16:14:28.0000] <aklein>
rniwa: got it, you can understand that the term "deferred" is a bit overloaded in this context

[16:14:32.0000] <rniwa>
aklein: instead of baking it into the distribution API.

[16:14:38.0000] <rniwa>
aklein: yeah i know :(

[16:15:17.0000] <rniwa>
aklein: our industry is horrible at overloading words with many meanings.


2015-04-28
[19:51:22.0000] <MikeSmith>
https://twitter.com/maxogden/status/592883522932756481

[22:29:08.0000] <hayato>
annevk: Sure. I think we can get benefits from these terms.  >>>  for parent/child across boundaries I suggest we introduce "composed parent/child", "deep parent/child",

[02:30:14.0000] <MikeSmith>
http://www.webkit.org/status.html seems to have magically appeared in the last day or so

[02:30:20.0000] <MikeSmith>
or maybe I just missed the news

[02:30:27.0000] <MikeSmith>
/me checks webkit-dev

[04:19:59.0000] <hsivonen_>
the ambigous ampersand stuff would be easier to review if Hixie had written the spec as a genuine state machine instead of having the character reference part of the spec unconsume input

[04:20:23.0000] <hsivonen>
need to mentally page in stuff

[05:01:22.0000] <MikeSmith>
hsivonen: unfortunately it's also been so long since I first wrote that patch that I need to go back and retrace what I was thinking myself and compare it to the spec

[06:33:36.0000] <wanderview>
Domenic: it appears streams API is on http://www.webkit.org/status.html

[06:37:21.0000] <Domenic>
wanderview: indeed :D

[06:38:34.0000] <wanderview>
Domenic: I guess if they don't have fetch or serviceworkers, then it must just be a js-only thing to start

[06:39:02.0000] <Domenic>
wanderview: yeah, that's what the code looks like; new ReadableStream() is the focus.

[06:39:25.0000] <Domenic>
wanderview: I am implementing that this week actually... in Munich working with the V8 team to make self-hosting in Blink better.

[06:39:35.0000] <wanderview>
Domenic: cool!

[06:40:23.0000] <wanderview>
webkit having removed SharedWorker seems to not bode well for ServiceWorkers there

[06:40:40.0000] <Domenic>
Yeah... their reasoning especially...

[06:40:52.0000] <Domenic>
Still I can't imagine they're going to be OK missing out on the service worker revolution.

[06:41:45.0000] <Domenic>
Array.prototype.includes is also nice haha, got my feature

[06:42:35.0000] <wanderview>
implementing Force Click... wonder how that plays with pointer events, etc

[06:43:01.0000] <Domenic>
heh yeah... that's one of those apple "spring new prefixed features on everyone!" fun times

[06:46:21.0000] <wanderview>
Domenic: btw, I hope to do some kind of system test for async read vs sync read this week... I will probably just build on top of released chrome fetch body stream... I'll make a pure js transform stream that does some parsing... it will then expose either does the Promise-for-every-read or a ready-promise-with-sync-read... then measure differences

[06:46:37.0000] <wanderview>
I don't feel I have time to prototype something in the gecko platform in time

[06:47:06.0000] <Domenic>
wanderview: awesome, will be good to have. We're looking into optimizing our promise impl so that this is a non-issue... the overhead is hurting lots of APIs that want to use promises, e.g. some CSS custom layout stuff.

[06:48:05.0000] <wanderview>
Domenic: do those other APIs encourage relatively tight async loops?  that seems somewhat unique to Streams as far as I know

[06:48:28.0000] <Domenic>
wanderview: yeah, they deal with many promises per frame

[06:49:00.0000] <wanderview>
ah, its a Promise thing for animations or something?  not familiar with that API

[06:49:19.0000] <Domenic>
yeah it's new, Houdini stuff if you're familiar with that term

[06:49:34.0000] <wanderview>
oh, the display worker or whatever?

[06:49:40.0000] <Domenic>
The idea is to allow customization of layout by JS code, but they want to make all access to layout properties async

[06:49:47.0000] <wanderview>
Domenic: I updated this last week with new data, btw: https://docs.google.com/spreadsheets/d/1rl6mbD2z1x1bgJLD6y9KJLYWjppB7BujfiWvUMjYTVs/edit?usp=sharing

[06:49:56.0000] <wanderview>
after we removed the setTimeout from benchmark.js

[06:59:18.0000] <Domenic>
Still weirded out by Bluebird's poor performance

[06:59:50.0000] <Domenic>
Should be using MutationObserver

[07:00:25.0000] <wanderview>
Domenic: what do you mean by poor performance there?  bluebird is better than Chrome and Firefox native promises

[07:00:36.0000] <wanderview>
are you looking at the "new data" tab?

[07:00:47.0000] <Domenic>
Nope!

[07:01:43.0000] <Domenic>
the degradation is still surprising to me though

[07:01:47.0000] <Domenic>
microtask hits should in theory be one-time

[07:01:52.0000] <Domenic>
then you get into a fast loop

[07:02:15.0000] <wanderview>
Domenic: I think I'm convinced its more GC costs now

[07:02:23.0000] <wanderview>
but I haven't profiled

[07:02:43.0000] <Domenic>
yeah maybe, although my recent experiments made it seem like chrome wasn't GCing at all while the loop was ongoing

[07:03:08.0000] <wanderview>
the slowdown could be at the end of the loop, but would still reduce overall ops/sec measurements

[07:03:31.0000] <wanderview>
and in an "infinite" loop, it would have to GC at some point

[07:03:49.0000] <wanderview>
I guess that would be on I/O

[07:05:07.0000] <smaug____>
wanderview: you don't have results for nightly/desktop ?

[07:05:50.0000] <smaug____>
(though, I guess nightly has those few regressions atm)

[07:05:52.0000] <wanderview>
smaug____: I didn't measure nightly, but I could... things are worse there, though, because of the async stacks

[07:06:30.0000] <smaug____>
right

[10:18:30.0000] <wanderview>
jsbell: do you follow your github/critic email?  you do you want me to paste the new review links to you here or in a separate email?

[10:22:49.0000] <jsbell>
wanderview: I have them all, just need to find time to get to them :(

[10:30:14.0000] <trevnorris>
Domenic: strange thing. using "this.constructor" in a class constructor makes V8 barf on performance: https://gist.github.com/trevnorris/0b7b208e420a4d8f7fc2

[10:30:22.0000] <trevnorris>
(done using latest 4.4 release)

[10:33:03.0000] <wanderview>
jsbell: cool... didn't want to spam you here if you checked that mail (seems like a lot of people mute github mail)... no rush on the review, just didn't want them to get lost

[10:33:11.0000] <wanderview>
thanks

[10:33:41.0000] <wanderview>
and I have two more PRs to write

[11:29:46.0000] <gsnedders>
jgraham: https://critic.hoppipolla.co.uk/r/4798 plz

[11:43:07.0000] <wanderview>
jsbell: does blink still need the MessageChannel thing for the SW tests?  or do you support the Client postMessage() now?

[13:24:44.0000] <jsbell>
wanderview: sorry, was afk. We support postMessage now, not sure if it where the message is delivered is in sync w/ the latest spec though...

[13:25:15.0000] <wanderview>
jsbell: the comment in the code indicates its actually a problem with MessageEvent.source not being set when doing ServiceWorker.postMessage()

[13:25:47.0000] <jsbell>
that too...

[13:25:53.0000] <wanderview>
jsbell: I tried to make it favor MessageChannel for now, but fallback to ServiceWorker.postMessage()... just let me know in the review if thats not needed

[13:26:07.0000] <jsbell>
wanderview: noted

[13:26:11.0000] <wanderview>
thanks!

[13:31:47.0000] <wanderview>
hmm... or the MessageChannel code I was just looking at doesn't even exist in wpt upstream :-\

[13:40:26.0000] <wanderview>
oh... its in the testharness.js submodule... oops

[14:20:07.0000] <Ms2ger>
"An extensive test suite for this specification <http://w3c-test.org/dom/> is available"

[14:20:13.0000] <Ms2ger>
/me cackles maniacally

[14:24:26.0000] <jgraham>
Where does it say that?

[14:25:36.0000] <jgraham>
And can we make it instead say "a somewhat lacking testsuite, that you should certainly contribute to, covers several of the features in this specification"

[14:26:05.0000] <jgraham>
gsnedders: Review done

[14:29:11.0000] <Ms2ger>
tr/dom/

[14:29:20.0000] <Ms2ger>
Quoted by ArtB

[14:37:07.0000] <gsnedders>
jgraham: we're caring about performance of rarely run bits of test harness code now?

[14:38:14.0000] <jgraham>
gsnedders: Well really I care about removing one easy-to-understand line and replacing it with regexps + an implementation of UTF16 decoding

[14:38:22.0000] <jgraham>
But I also think it will be slower :p

[14:38:51.0000] <gsnedders>
jgraham: I'm just as worried about it also converting things like \xff and \0

[14:39:23.0000] <jgraham>
Don't we control the data format here?

[14:39:50.0000] <gsnedders>
yeah, I know

[14:40:18.0000] <gsnedders>
I'd just rather follow the shared definition of the format instead of not

[14:41:21.0000] <jgraham>
Well whatever, I guess, but I think that implementing that ourselves when there's a library that does basically the right thing is crazy

[14:42:26.0000] <gsnedders>
ohhhh

[14:42:31.0000] <gsnedders>
now I rememeber reading the docs

[14:42:38.0000] <gsnedders>
"Decodes from Latin-1 source code. Beware that Python source code actually uses UTF-8 by default."

[14:43:04.0000] <gsnedders>
jgraham: that's why we can't

[14:43:44.0000] <jgraham>
Well comment then

[14:44:10.0000] <gsnedders>
that would be a good idea given I'd entirely forgotten :P

[15:05:06.0000] <caitp>
i'll buy someone a beer if they can explain to me how to read the mozilla telemetry dashboard's graphs

[15:05:38.0000] <trevnorris>
caitp: first you drink that beer, then another, and maybe one more.

[15:06:07.0000] <caitp>
i'm not really a beer person, but if you can explain the graphs, you can have your choice of whatever brew you like

[15:06:43.0000] <gsnedders>
caitp: what graph are you looking at, and what's not clear?

[15:07:21.0000] <gsnedders>
jgraham:

[15:07:23.0000] <gsnedders>
Merge 7e4dc99a adds merged-in commits.  Please push the merge manually

[15:07:35.0000] <caitp>
someone asked how much of the web was using http2, and chromestatus doesn't have a metric for it, so I was looking at mozilla's spdy telemetry (spdy_chunk_received should be a reasonably good measure?)

[15:07:38.0000] <gsnedders>
/me grumbles at Critic

[15:08:16.0000] <caitp>
i'm not sure how you'd draw a "% of the web" conclusion from it, although some people apparently have

[15:09:22.0000] <gsnedders>
caitp: HTTP_RESPONSE_VERSION seems better

[15:09:56.0000] <jgraham>
gsnedders: Don't push merge commits?

[15:10:08.0000] <gsnedders>
if you change it to be a table, and cross-ref with nsHttp.h, you'll find "9" refers to HTTP/0.9, "10" HTTP/1.0, "11" HTTP/1.1, "20" HTTP/2.0

[15:10:22.0000] <gsnedders>
jgraham: so never merge in master?

[15:10:52.0000] <gsnedders>
/me is used to Critic coping fine with merges from master…

[15:11:11.0000] <caitp>
ah I see

[15:11:18.0000] <gsnedders>
caitp: using the latest released version will probably give you better data

[15:11:22.0000] <jgraham>
gsnedders: Merging in master doesn't really help anyone

[15:11:32.0000] <caitp>
yeah i'm looking at rel39

[15:11:35.0000] <gsnedders>
jgraham: it gets rid of merge conflicts sooner rather than later

[15:11:50.0000] <jgraham>
gsnedders: If you need to do that for some reason, push new commits and then make a move-type rebase

[15:12:14.0000] <gsnedders>
jgraham: your review tools are too fussy nowadays!

[15:12:15.0000] <jgraham>
Otherwise you end up with an even more confuisng history than normal

[15:12:35.0000] <jgraham>
Well yes, it is a bit fussy, but in this case it's right

[15:12:52.0000] <jgraham>
(it would be better if you could rebase and push new commits at the same time)

[15:13:09.0000] <gsnedders>
Soz, I'm still not used to Critic coping with rebases.

[15:14:59.0000] <gsnedders>
caitp: really the trick most of the time is to guess probable strings related to what you want, then check in the code to make sure it's getting the data you want :P

[15:15:05.0000] <gsnedders>
(in my experience)

[15:15:52.0000] <caitp>
well, using that table it came out to about 18% of submissions

[15:16:13.0000] <caitp>
offset that by the number of people only browsing facebook, and it seems not inaccurate

[15:16:40.0000] <caitp>
*taken with grain of salt

[15:16:46.0000] <gsnedders>
caitp: huh, for me on rel37 it's 10%

[15:17:30.0000] <caitp>
oh. i mathed wrong

[15:17:36.0000] <gsnedders>
:)

[15:17:53.0000] <caitp>
didn't add the 20* items to the total before calculating

[15:33:24.0000] <gsnedders>
SimonSapin: hah, I just have an odd habit of maintaining stuff in languages I don't use much :)

[15:35:52.0000] <SimonSapin>
gsnedders: oh yeah, I’m still maintaining some python libraries

[15:35:53.0000] <SimonSapin>
kind of


2015-04-29
[17:38:53.0000] <jsbell>
wanderview: I'm probably mucking up the process, but hopefully the feedback so far is useful

[23:43:15.0000] <MikeSmith>
can anybody remind where there github issue tracker for issues in github itself is

[23:53:19.0000] <BigPants>
I don't think they have a public tracker, ironically enough

[00:11:28.0000] <MikeSmith>
BigPants: ok, yeah I had thought I just must not be looking in the right place

[01:32:31.0000] <Domenic>
MikeSmith: botie disappeared?

[01:53:36.0000] <MikeSmith>
Domenic: gets wedged sometimes and I need to restart it; will do that now

[01:56:06.0000] <MikeSmith>
botie, CSS?

[01:56:06.0000] <botie>
mikesmith: i don't know

[02:18:16.0000] <Domenic>
botie: inform annevk my jsdom co-contributor seems to have implemented the WHATWG URL spec: https://github.com/jsdom/whatwg-url/blob/master/lib/url.js

[02:18:17.0000] <botie>
will do

[02:18:24.0000] <Domenic>
botie: you are inhumanly fast

[02:18:25.0000] <botie>
OK, Domenic.

[03:37:20.0000] <botie>
annevk, at 2015-04-29 09:18 UTC, Domenic said: my jsdom co-contributor seems to have implemented the WHATWG URL spec: https://github.com/jsdom/whatwg-url/blob/master/lib/url.js

[03:45:25.0000] <annevk_>
Domenic: ooh shit, hmm, I wonder if he's interested in implementing a variant...

[03:53:33.0000] <Domenic>
annevk: probably, the enthusiasm is boundless... and we're going to need to modify it to make file:// URLs on windows work anyway.

[03:53:42.0000] <Domenic>
(file:// URLs are pretty crucial for jsdom)

[03:53:54.0000] <annevk>
yeah we need to get them fixed

[03:54:20.0000] <annevk>
one approach that was suggested to me is define both Unix and Windows with a switch of sorts

[03:54:38.0000] <annevk>
but it seems so shitty that default depends on a global variable

[03:55:44.0000] <Domenic>
Yeah I mean my intuition would be that browsers are unlikely to go to the trouble of fixing them ever, so just specify something good and hopefully that will serve the rest of the ecosystem (io.js etc.)

[04:05:10.0000] <annevk>
Browsers will implement if it improves interop for them

[04:05:14.0000] <annevk>
Not if it's worse

[04:05:32.0000] <annevk>
The current spec has some known flaws so is not strictly better than what they have today

[04:06:26.0000] <Domenic>
I am somewhat doubtful they will care about interop for file: though, so even if it were strictly better, in that case they might just leave the code as-is.

[04:46:31.0000] <SteveF_>
annevk: hi, any pointers to documentation on why styling of native controls is so probelematic?

[05:34:12.0000] <philipj>
annevk: I see you've converted DOM but not all your specs to Bikeshed. Do you enjoy using Bikeshed, would you recommend it for new specs?

[05:55:35.0000] <annevk>
SteveF_: someone at Google did research at some point, but I forgot where it went, but probably requires starting from scratch to some extent...

[05:55:53.0000] <annevk>
philipj: since it's maintained, yeah

[05:56:09.0000] <annevk>
philipj: and anything that's broken is fixed quite soonish

[05:56:39.0000] <annevk>
SteveF_: I think a large part of it is simply missing a solid specification and tests

[05:56:56.0000] <philipj>
annevk: good, I'm happy you don't regret switching then :)

[05:56:56.0000] <annevk>
SteveF_: e.g. what the effect of properties needs to be, how appearance behaves, etc.

[05:57:27.0000] <annevk>
philipj: there's a certain amount of magic, but Anolis has that too and I think I just need to get used to it

[06:16:49.0000] <MikeSmith>
can somebody remind me the family name of Justin from Polymer who was at the Web Components f2f meeting last week

[06:19:40.0000] <MikeSmith>
annevk: I'm not sure but I think SteveF_ might have been just wondering for now if there's even a short high-level explanation somewhere of why it's so hard; stuff like, e.g., "Some UAs display replaced content using native platform widgets/controls that aren't themselves styleable."

[06:38:29.0000] <MikeSmith>
has anybody here ever used gitlab for code review? and if so, how does it compare to other tools you've used (e.g., whatever tools you might have used for browser-project code review, or to Critic [for those of us who have used that])

[07:22:20.0000] <wanderview>
jgraham: should I be getting email from critic for reviews?

[07:24:52.0000] <jgraham>
wanderview: Yes, if you added your email address (or made it public in GitHub)

[07:25:45.0000] <wanderview>
jgraham: once something is "accepted" I close the review?

[07:25:52.0000] <wanderview>
jgraham: does it auto-merge the PR, then?

[07:26:04.0000] <jgraham>
wanderview: Merging in GH will close the review, but not the other way around

[07:27:03.0000] <wanderview>
jgraham: and you prefer not squashing commits, right?

[07:27:56.0000] <jgraham>
wanderview: I prefer squashing commits once they have review, but I recognise that most people are too lazy in the face of a big green button that does the wrong thing

[07:28:30.0000] <wanderview>
jgraham: well, I'm addressing jsbell's review feedback... but he marked accepted... should I just amend the commit then?

[07:28:52.0000] <jgraham>
wanderview: So he didn't mark accepted

[07:29:05.0000] <wanderview>
jgraham: this is the review I'm looking at: https://critic.hoppipolla.co.uk/r/4840

[07:29:20.0000] <wanderview>
there is a "note" about changing assert_object_equals to assert_equals

[07:29:30.0000] <jgraham>
"Accepted" is computed from the combination 100% reviewed and no opene issues

[07:29:41.0000] <jgraham>
A "note" is not an issue

[07:29:53.0000] <jgraham>
So the review is technically accepted

[07:29:54.0000] <wanderview>
jgraham: ok... I'm addressing his "note" then :-)

[07:30:09.0000] <jgraham>
Right, so push your fixup as a new commit

[07:30:14.0000] <jgraham>
I will review that commit

[07:30:14.0000] <wanderview>
ok

[07:30:28.0000] <jgraham>
Then you can either squash and push again, or just merge

[07:30:54.0000] <wanderview>
jgraham: do I have permissions to merge?

[07:31:36.0000] <jgraham>
wanderview: Oh, possibly not

[07:31:52.0000] <wanderview>
I fixed my email, so now I'm getting updates

[07:31:57.0000] <wanderview>
/me adds a new mail filter

[07:32:42.0000] <jgraham>
wanderview: Want to squash, or want me to just merge?

[07:33:04.0000] <wanderview>
jgraham: please just merge if you don't mind... I have a meeting coming up, so not a lot of time at the moment

[07:33:42.0000] <jgraham>
wanderview: Done, and thanks!

[07:38:44.0000] <wanderview>
jgraham: do you want to give me perms to merge the remaining PRs? I think I understand the process now

[07:41:20.0000] <wanderview>
jgraham: or, these two are ready for merge as well:  https://critic.hoppipolla.co.uk/r/4835 and https://critic.hoppipolla.co.uk/r/4822

[07:47:59.0000] <jgraham>
wanderview: I merged them. I din't think I can change who can merge

[07:48:08.0000] <wanderview>
ok

[07:49:59.0000] <wanderview>
jgraham: any advice on filtering critic emails in gmail?  I can filter the ones from the critic address pretty easily, but the ones it sends from my own address seem harder

[07:50:17.0000] <TabAtkins>
SteveF_: I started a document at http://dev.w3.org/csswg/css-forms/#examples about form styling. Want to collect more examples before I start working actively.

[07:50:54.0000] <wanderview>
jgraham: nm... I found the ignoreOwnChanges config

[07:50:56.0000] <TabAtkins>
annevk: I'd be interested in hearing about what you find "magic" in a bad way.

[07:51:01.0000] <SteveF_>
TabAtkins: cool thanks for the pointer

[07:52:25.0000] <jgraham>
wanderview: It also adds headers, but apparently gmail doesn't believe in things like headers

[07:52:38.0000] <wanderview>
jgraham: I also fixed the style nit in this one... so should be mergeable after that is approved:  https://critic.hoppipolla.co.uk/r/4823

[07:53:30.0000] <jgraham>
wanderview: Merged

[07:53:35.0000] <wanderview>
thanks!

[08:02:40.0000] <annevk>
MikeSmith: I don't think there is that either...

[08:02:55.0000] <annevk>
MikeSmith: all I know that is written down is that it's out of scope of CSS...

[08:03:13.0000] <annevk>
TabAtkins: I should probably get more familiar first

[08:03:54.0000] <annevk>
MikeSmith: Justin Fagnani?

[09:45:21.0000] <MikeSmith>
annevk: yeah must be Justin Fagnani I guess

[09:45:23.0000] <MikeSmith>
thanks

[10:44:45.0000] <wanderview>
JakeA: Domenic: does the current plan for cancellable promise for fetch match this at all? https://github.com/petkaantonov/bluebird/blob/master/API.md#cancellation

[10:44:47.0000] <wanderview>
just curious

[10:45:48.0000] <Domenic>
wanderview: my understanding of Bluebird aligns with the current plan being in line with Bluebird 3.x (i.e. Bluebird vNext), learning the lessons of Bluebird 2.x.

[10:47:22.0000] <wanderview>
Domenic: the cancel interfaces seem pretty similar in the docs of the 3.0 branch

[10:48:40.0000] <Domenic>
wanderview: https://github.com/petkaantonov/bluebird/issues/415

[10:49:21.0000] <wanderview>
thanks

[11:51:08.0000] <Ms2ger>
jsbell, r? https://critic.hoppipolla.co.uk/r/4818

[11:59:27.0000] <jsbell>
Ms2ger: take a peek at https://codereview.chromium.org/1071283004

[12:00:21.0000] <jsbell>
Ms2ger: We should check \u000B  \u2028 and \u2029 too

[12:01:08.0000] <Ms2ger>
Want me to add those?

[12:01:18.0000] <jsbell>
Ms2ger: please!

[12:01:40.0000] <Ms2ger>
/me is no longer used to NUL being special

[12:02:58.0000] <jsbell>
Ms2ger: heh

[12:04:34.0000] <Ms2ger>
Oh, you didn't say 0000, you said 000B

[12:04:37.0000] <Ms2ger>
Eh

[12:04:41.0000] <Ms2ger>
/me adds 0000 too

[12:05:40.0000] <jsbell>
sgtm

[12:06:58.0000] <jsbell>
Yep, "vertical tab" might technically be ASCII whitespace, but isn't in the spec's list.

[12:08:26.0000] <Ms2ger>
/me puts the other thing on his todo list

[12:08:45.0000] <Ms2ger>
jsbell, wanna r+? :)

[12:09:40.0000] <wanderview>
/me ponders "vertical tab"...

[12:10:09.0000] <jsbell>
Ms2ger: in critic is there a "show me the whole patch" not just individual commits?

[12:10:27.0000] <Ms2ger>
"pending" or "relevant"

[12:12:42.0000] <jsbell>
Ah, and click + drag to select things. Obvious...

[12:15:00.0000] <Ms2ger>
At least it's more obvious than reviewable :)

[12:16:43.0000] <Ms2ger>
jsbell, bah, I hoped nobody would notice name :)

[12:16:53.0000] <Ms2ger>
I'll squash if it looks good now :)

[12:17:08.0000] <jsbell>
Ms2ger: also I don't appear to have checkboxes to sign off on it (I'm not on the reviewer list?)

[12:17:14.0000] <jsbell>
still learning critic :P

[12:17:24.0000] <jsbell>
Ms2ger: yep

[12:18:28.0000] <Ms2ger>
Thanks!

[13:27:06.0000] <Sebmaster>
annevk: you there?

[13:32:22.0000] <wanderview>
Domenic: there is no way to stream an upload in chrome canary fetch, right?

[13:32:32.0000] <Domenic>
wanderview: nope :(

[13:32:51.0000] <wanderview>
ok

[13:33:28.0000] <wanderview>
Domenic: the body stream works nicely, though :-)

[13:33:54.0000] <wanderview>
I'll just do separate POST requests instead of a single POST with a stream

[13:53:23.0000] <wanderview>
Domenic: I see some pathological buffering from the chrome fetch body stream... chunk lengths of 1077, then 1, then 1077, then 1, then 1077, etc

[13:54:10.0000] <Domenic>
wanderview: oof, that's gross. Would be worth filing a bug, I bet Yutaka would be happy to take care of it... especially if it's consistently repro-able, but I can imagine it's not.

[13:54:34.0000] <wanderview>
Domenic: I will when I publish this test case

[14:11:30.0000] <wanderview>
Domenic: is there any easy way to convert the contents of an ArrayBuffer to a String?

[14:11:53.0000] <wanderview>
nm, I think I found it

[14:12:01.0000] <Domenic>
TextEncoder

[14:12:05.0000] <Domenic>
Or TextDecoder in this case.

[14:16:55.0000] <wanderview>
thanks

[14:19:25.0000] <smaug____>
oh, blink might remove support for SMIL

[14:19:31.0000] <smaug____>
so ++

[14:20:54.0000] <TabAtkins>
smaug____: That's the plan, yeah.

[14:22:31.0000] <smaug____>
/me just uploaded a patch for gecko to fix some event handling oddity in SMIL

[14:23:12.0000] <smaug____>
need to convince heycam|away to deprecate SMIL in Gecko too

[14:24:00.0000] <caitp>
which new web standards are hot this season, and which ones are hitting the bargain bin

[14:24:22.0000] <smaug____>
ACID3 will ofc break, but so what

[14:24:51.0000] <smaug____>
sw is hot in this season

[14:25:04.0000] <smaug____>
web components have been hot for some time

[14:25:33.0000] <smaug____>
(luckily we got it simplified, so it might become a thing real soon)

[14:25:35.0000] <caitp>
i'm not sure web components will survive another season unless the headaches are fixed

[14:26:33.0000] <smaug____>
I think all the difficult part of shadow dom are now removed, and  Imports is gone

[14:27:07.0000] <smaug____>
so it is "just" the imperative API for shadow dom distribution and custom elements

[14:37:37.0000] <wanderview>
Domenic: its not done, but here's the start of my system benchmark for the read() perf question: https://github.com/wanderview/streams-time-echo


2015-04-30
[18:31:24.0000] <MikeSmith>
caitp: about what's hot, 100% agree with what smaug said about ServiceWorker and the Web Components renaissance

[18:31:50.0000] <MikeSmith>
/me looks back through his list of other stuff

[18:38:56.0000] <caitp->
that comment was really more like "what will be getting deprecated in the next 5 years"

[18:39:08.0000] <caitp->
because you know, some of this stuff is gonna fall apart

[18:39:15.0000] <caitp->
and it will be sad

[19:45:16.0000] <MikeSmith>
caitp: oh, well that's an interesting question too

[19:47:42.0000] <MikeSmith>
caitp: so in that light, not sure the future looks so bright for IndexedDB

[19:49:02.0000] <MikeSmith>
caitp: maybe you know this already but annevk has been driving some effort on a more rational "unified architecture for storage on the web" https://wiki.whatwg.org/wiki/Storage

[19:50:32.0000] <MikeSmith>
other stuff... I wonder (hope) that a lot of use cases for Web Sockets might get obviated by WebRTC DataChannel

[19:50:49.0000] <roc>
MikeSmith: why do you say "not so bright for IndexedDB"?

[19:51:05.0000] <MikeSmith>
hey roc

[19:51:41.0000] <MikeSmith>
from talking with annevk and slightlyoff and others last week

[19:52:13.0000] <MikeSmith>
we already know webdevs aren't exactly warm to that API

[19:52:42.0000] <MikeSmith>
roc: lemme get you a URL for the notes from annevk session on storage last week

[19:53:02.0000] <MikeSmith>
roc: or did you see those notes already?

[19:53:37.0000] <MikeSmith>
roc: https://pad.w3ctag.org/p/EWS-20April2015-Breakout1.1.md

[19:54:23.0000] <MikeSmith>
hmm I see now those a pretty sketchy as far as capturing the comments about IndexedDB

[19:55:21.0000] <roc>
to be precise, it captured none of them :-)

[19:56:39.0000] <MikeSmith>
yeah I'm looking to see if some of slightlyoff comments elsewhere got recorded

[19:57:42.0000] <MikeSmith>
roc: in the mean time if you want a more informed view, you probably want to ask annevk to share some thoughts with you directly

[19:58:24.0000] <roc>
I hardly ever get to talk to Anne, he's on the wrong side of the planet :-)

[19:58:41.0000] <MikeSmith>
well

[19:58:49.0000] <MikeSmith>
you just need to travel more

[19:58:58.0000] <MikeSmith>
but yeah, sucks for us

[19:59:28.0000] <MikeSmith>
probably you're in the worst possible timezone for wide real-time collaboration

[19:59:33.0000] <MikeSmith>
Tokyo is just slightly better

[19:59:41.0000] <MikeSmith>
roc: https://pad.w3ctag.org/p/22-minutes

[19:59:56.0000] <MikeSmith>
see the first part on Storage

[20:00:49.0000] <MikeSmith>
e.g., slightlyoff comments about "likely we'll struggle with the storage mechanismsm we have right now, because they're not integrated. Re the locking propblem: IndexDB has a similar problem"

[20:01:35.0000] <MikeSmith>
and "How do we deal with storage locking? Now, IndexDB has a nasty way of daling with this: it closes transactions at the end of the task.  You could extend the life of the transaction (artifically), — but it's there to keep developers from getting themselves into an inconsistent state.... This goes badly with other apps wanting access to the storage and trying to coordinate about the transaction lifet

[20:01:41.0000] <MikeSmith>
ime"

[20:02:08.0000] <MikeSmith>
"But now, It isn't possible to coordinate your rights to a cached storage area with a indexDB transaction.  We're clearly missing a locking system"

[20:03:04.0000] <MikeSmith>
this reminds me, Travis is pretty great a scribing

[20:03:47.0000] <MikeSmith>
I was there in the room for that discussion and those notes do a very good job of capturing it in good detail

[22:43:01.0000] <annevk>
MikeSmith: so that's the underlying architecture of IDB and localStorage et al

[22:43:08.0000] <annevk>
MikeSmith: there's no plans for getting rid of IDB

[22:43:15.0000] <annevk>
MikeSmith: in fact, we're extending it

[22:43:55.0000] <MikeSmith>
ah so I was confused

[22:44:26.0000] <MikeSmith>
so you're documenting the underlying architecture but not changing it?

[22:44:57.0000] <MikeSmith>
I mean it can be changed fundamentally at this point can it?

[22:45:03.0000] <annevk>
MikeSmith: yeah, in a way

[22:45:20.0000] <annevk>
MikeSmith: what I want to define is what all these APIs are grounded in, what their underlying storage box is

[22:45:26.0000] <annevk>
MikeSmith: and then define ways to make that box persistent

[22:45:41.0000] <MikeSmith>
ok

[22:45:48.0000] <annevk>
MikeSmith: and then define ways to make additional boxes and allow IDB and Cache API etc to use those newly created boxes

[22:45:49.0000] <MikeSmith>
annevk: ok what about the IndexedDB locking issue that slightlyoff pointed out?

[22:45:54.0000] <MikeSmith>
I see

[22:47:03.0000] <MikeSmith>
so I guess there's no plan to expose a different higher-level API

[22:47:23.0000] <annevk>
MikeSmith: due to IDB having transactions it doesn't actually have a locking problem

[22:47:24.0000] <MikeSmith>
/me realizes now he'd been reading too much into this

[22:47:42.0000] <annevk>
MikeSmith: but the way it does transactions is also what makes it complicated

[22:48:03.0000] <MikeSmith>
annevk: I thought slightlyoff or somebody brought this up at the summit session too

[22:48:12.0000] <MikeSmith>
I mean the thing I pointed roc too

[22:48:19.0000] <MikeSmith>
in the TAG minutes

[22:48:23.0000] <annevk>
https://gist.github.com/inexorabletash/8c122c84a65de65c35b3 and https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191 have ideas around new higher-level APIs and new lower-level APIs around IDB

[22:48:31.0000] <MikeSmith>
ah ok

[22:49:11.0000] <annevk>
To model IDB with promises you basically need to create some kind of promise subclass to handle transactions

[22:49:12.0000] <MikeSmith>
so maybe I wasn't completely imagining it

[22:49:44.0000] <MikeSmith>
my memory is pretty sketchy even in the best of times, let alone when jetlagged and hung over

[22:49:52.0000] <MikeSmith>
/me looks at annevk links

[22:50:05.0000] <roc>
phew!

[22:50:23.0000] <MikeSmith>
heh

[22:50:58.0000] <MikeSmith>
I'm still sure I didn't imagine the think slightlyoff said about the locking-like problem

[22:52:30.0000] <MikeSmith>
annevk: from http://krijnhoetmer.nl/irc-logs/whatwg/20150430#l-139

[22:53:10.0000] <MikeSmith>
"Re the locking propblem: IndexDB has a similar problem" and the other quoted stuff after that

[22:53:19.0000] <annevk>
MikeSmith: sure, I addressed that above

[22:53:26.0000] <MikeSmith>
oh

[22:53:36.0000] <MikeSmith>
I guess I should actually read stuff

[22:53:42.0000] <annevk>
MikeSmith: all storage has a locking issue since two tabs can address the same storage at the same time

[22:54:05.0000] <annevk>
MikeSmith: IDB deals with this by having transactions, but not everyone is a fan of the way it does those

[22:54:09.0000] <MikeSmith>
ah flags

[22:54:25.0000] <annevk>
MikeSmith: localStorage has a theoretical "storage mutex", but in practice it's racy

[22:54:43.0000] <MikeSmith>
right yeah that much I already understood

[22:55:34.0000] <MikeSmith>
and knew too that IndexedDB by design didn't need a mutex

[22:57:00.0000] <MikeSmith>
hmm I also recall now that I only caught half your session because I was in whatever session that was next door the other half of that hour

[22:58:23.0000] <MikeSmith>
anyway I'm glad there's a way forward and things will get rationalized further

[22:59:38.0000] <annevk>
We have some cross-browser agreement to add persistent storage

[23:00:09.0000] <annevk>
But there's quite a bit of demand from e.g. gaming to go beyond that as per the wiki page

[23:00:21.0000] <annevk>
Need to flush that out some more and I guess write down persistent storage and storage architecture...

[23:01:20.0000] <MikeSmith>
I guess that's what I had been thinking about, along with thinking it was planned to supersede/obsolete both IndexedDB and localStorage

[23:02:07.0000] <annevk>
Ah I see, underpinnings != primitives, at least not yet

[23:06:28.0000] <MikeSmith>
aha

[23:06:29.0000] <MikeSmith>
ok

[00:34:50.0000] <annevk>
Hmm

[00:35:11.0000] <annevk>
Were accounts moved to this new discuss.webplatform.org thing too?

[00:35:48.0000] <annevk>
Not sure I'm super happy contributing to webplatform.org branded stuff given the disaster they made out of docs

[00:48:30.0000] <MikeSmith>
annevk: please keep an open mind there

[00:49:03.0000] <MikeSmith>
at this point everybody recognizes that the docs thing didn't work out

[00:50:14.0000] <MikeSmith>
IMHO it was a failed plan from the get-go but I don't fault others for having thought differently and having actually tried in good faith to make it happen as planned

[00:52:49.0000] <MikeSmith>
but there is some momentum toward making a reborn webplatform.org that discuss.webplatform.org will be part of, and I think you'll see it transition into being much more of a genuinely community-driven project that you'll be much happier to participate in

[00:53:00.0000] <MikeSmith>
more like web-platform-tests

[00:53:26.0000] <annevk>
I don't know, I wasn't particularly thrilled either with the forking of URL to yet another location either

[00:53:39.0000] <annevk>
I've yet to see the benefit of that

[00:53:46.0000] <MikeSmith>
well that was not a top-down thing

[00:53:49.0000] <MikeSmith>
iirc

[00:53:55.0000] <MikeSmith>
that was a choice that Sam made

[00:54:59.0000] <MikeSmith>
and maybe it's not going to work out at that other place but if so we can write it off a lesson learned I guess

[00:55:47.0000] <annevk>
And that community supported that action apparently rather than pushing back

[00:57:04.0000] <MikeSmith>
I don't know that anybody "supported" it other than in the sense of facilitating Sam's choice to experiment with it there

[00:57:15.0000] <MikeSmith>
anyway to be clear I think when the dust settles for discuss.webplatform.org it will be  minus any of the docs.webplatform.org stuff, which at this point pretty clearly to everybody is now completely obviated by MDN (or clearly now always has been)

[00:58:08.0000] <MikeSmith>
just please don't feed into killing new ideas for what to do with webplatform.org before anybody's had a chance to try more

[00:58:39.0000] <annevk>
Well, what good stuff has happened there so far?

[00:58:40.0000] <MikeSmith>
the basic goal here really is to try to faciliate more real colloboration

[00:59:01.0000] <MikeSmith>
annevk: the specifiction stuff

[00:59:44.0000] <annevk>
It seems to me that happened elsewhere and just got folded in, as they tried to do with MDN and failed pretty drastically at

[01:00:00.0000] <MikeSmith>
which is just changing from being run at Robin's own domain into being something that tries to fit in with a bigger picture around collaboration

[01:00:31.0000] <MikeSmith>
no the analogy would be more like MDN having been moved to a new domain

[01:00:47.0000] <MikeSmith>
so it's not a fair comparison

[01:16:45.0000] <annevk>
philipj: yo

[01:16:53.0000] <annevk>
philipj: I guess you can rename that repo now

[01:17:25.0000] <annevk>
philipj: let me know when you're all set up and then I can add the commit hook and such

[01:20:34.0000] <Domenic>
annevk: looks like fixing file URLs on windows will be easier than you thought: https://github.com/jsdom/whatwg-url/commit/c13670dffdef1f31cb53d9c342076a27a5742760

[01:21:15.0000] <annevk>
Domenic: the lack of tests is disturbing

[01:21:41.0000] <Domenic>
annevk: heh yeah that commit was 14 commits ago before he put the web-platform-tests in place. It was just a prototype.

[01:21:50.0000] <annevk>
Ah okay

[01:22:03.0000] <Domenic>
annevk: I am pretty sure Sebmaster is waiting to get 100% pass rate on web-platform-tests before starting to make spec modifications

[01:22:29.0000] <Domenic>
I am hopeful that we can convince Sebmaster to start submitting PRs to url.spec.whatwg.org :). We can probably tackle lots of the cases at https://url.spec.whatwg.org/interop/test-results/?select=current too

[01:22:51.0000] <annevk>
Do you think he's willing to help edit the spec? Sam hasn't really been making progress and I don't think the diagramification of parsing is the way to go anymore...

[01:23:02.0000] <annevk>
Sounds good

[01:23:27.0000] <Domenic>
Yeah I mean even if he's not then I might be up for doing literal translation from JS to spec-ese since the implementation follows the spec so closely it should be quite easy

[01:24:55.0000] <Domenic>
Agreed that diagramification was not so great... I mean I think state machines are pretty reasonable for implementers. Maybe not for authors, but that's a separate issue IMO.

[01:25:46.0000] <Ms2ger>
/me is very surprised

[01:26:13.0000] <Sebmaster>
o/

[01:27:15.0000] <annevk>
I slightly prefer the functional variant SimonSapin came up with for Rust, I think that could work well in the specification and make it a little easier to comprehend

[01:27:27.0000] <Sebmaster>
Not sure if I'm good at writing specs

[01:27:40.0000] <annevk>
But I could live with keeping the current state-based version

[01:27:58.0000] <annevk>
Sebmaster: it's translating code to English and coming up with "good" terms

[01:28:35.0000] <Sebmaster>
my modification to the algorithm is buggy at the moment in any case, it doesn't work well with resolving //C:/abc on base file:///D:/

[01:28:36.0000] <botie>
Hmm.  No matches for that, Sebmaster.

[01:28:41.0000] <Sebmaster>
but that shouldnt be hard to fix

[01:30:17.0000] <Domenic>
wait, what triggered botie, that was weird

[01:37:21.0000] <MikeSmith>
Domenic: yeah I guess that triggered the thing in botie where looks for "x is y" stuff but not sure why botie seems to have thought Sebmaster was asking for a match for something

[01:44:29.0000] <philipj>
annevk: richt and I are setting it up right now, I'll ping you shortly

[01:45:29.0000] <annevk>
philipj: cool, I agree that the renaming is better

[01:45:56.0000] <annevk>
philipj: GitHub takes care of redirects and you keep everyone that already starred and forked engaged

[01:53:13.0000] <philipj>
annevk: I didn't know about renames before Marcos told me yesterday :)

[01:58:30.0000] <philipj>
annevk: https://github.com/whatwg/mediasession now has a mediasession.html, any time the master branch changes we'd like that to be published to https://mediasession.spec.whatwg.org

[02:05:35.0000] <annevk>
philipj: it's live

[02:05:57.0000] <annevk>
philipj: you need to update some links in the spec to reflect the new GitHub URL

[02:08:15.0000] <Domenic>
philipj: I also have it on my todo list to hook up automatic compilation so you don't have to commit output to repos

[02:32:13.0000] <annevk>
philipj: you also need a logo :p

[02:47:01.0000] <Sebmaster>
Oh yeah, annevk

[02:47:37.0000] <Sebmaster>
the url test suite expects some test cases to fail; does "fail" in that context mean parse error or return failure?

[03:03:07.0000] <annevk>
Sebmaster: not sure

[03:03:17.0000] <annevk>
Sebmaster: prolly return failure

[03:03:27.0000] <Sebmaster>
yeah, i think so too

[03:03:42.0000] <annevk>
Sebmaster: I don't think parse errors are tested

[03:03:54.0000] <Sebmaster>
since as far as i read, parse errors arent even exposed on the final url object?

[03:04:10.0000] <annevk>
Anyone experience with WiFi repeaters? Wondering whether to buy an Airport Express since there's some lag between floors...

[03:04:24.0000] <annevk>
Sebmaster: correct, they're an error console affair

[03:04:34.0000] <annevk>
Sebmaster: well, potential error console affair

[03:04:48.0000] <annevk>
Sebmaster: it's not entirely clear what we want to do with them yet

[03:04:54.0000] <SteveF_>
annevk: cheers for responses yestrerday

[03:06:09.0000] <Sebmaster>
14 test cases still failing then, most of them due to unicode / host verification

[03:06:48.0000] <annevk>
Sounds like we need more tests

[03:50:09.0000] <Sebmaster>
i think i won't be able to continue with host validation without someone implementing this flavor of TR46 in JS :(

[03:52:31.0000] <Domenic>
Sebmaster: I think rubys might have done so. At least, he has a JS implementation that passes all the tests.

[03:52:43.0000] <Sebmaster>
where's that?

[03:53:27.0000] <Domenic>
https://github.com/rubys/url/tree/peg.js/reference-implementation I think... there's some Ruby-to-JS stuff going on...

[03:55:15.0000] <Sebmaster>
ah, that retrieves the mapping table thing

[03:55:36.0000] <Domenic>
then https://github.com/rubys/url/blob/peg.js/url.pegjs#L600-L616

[05:05:59.0000] <philipj>
annevk: awesome, thanks you!

[05:06:57.0000] <philipj>
Domenic: that would be cleaner, but I quite like that I can go back in the history of specs to see what they looked like at each point, which is a lot harder if toolchains and build scripts change over the years

[05:08:54.0000] <annevk>
philipj: Domenic keeps static snapshots for that

[05:09:09.0000] <philipj>
annevk: in a separate repo?

[05:09:29.0000] <annevk>
philipj: no repo, similar to what browsers do for nightly builds

[05:09:43.0000] <Domenic>
auto-generated and uploaded to the server on every push. https://streams.spec.whatwg.org/commit-snapshots

[05:09:58.0000] <philipj>
oh, I guess that works if you're looking for a specific version

[05:13:36.0000] <Domenic>
https://streams.spec.whatwg.org/commit-snapshots/?C=M;O=D gives a nice chronological view too

[05:19:29.0000] <philipj>
annevk: is the webhook installed now? https://mediasession.spec.whatwg.org/ is no longer in sync with Git

[05:19:39.0000] <philipj>
or does it update once an hour or something?

[05:20:19.0000] <annevk>
philipj: oh maybe I forgot to set chmod

[05:22:29.0000] <annevk>
philipj: seems to work?

[05:23:11.0000] <philipj>
annevk: now it's up to date, did you have to poke something?

[05:23:26.0000] <annevk>
philipj: well I poked something that should be poked automatically

[05:23:59.0000] <philipj>
annevk: hmm, is the webhook on a specific port that needs to be opened?

[05:24:05.0000] <philipj>
(that's how I did mine)

[05:24:10.0000] <annevk>
philipj: no

[05:24:29.0000] <annevk>
philipj: it says it already worked a couple times successfully

[05:24:40.0000] <annevk>
philipj: perhaps you had a cache hit?

[05:25:35.0000] <philipj>
annevk: I reloaded a bunch, so I don't think so

[05:25:46.0000] <annevk>
philipj: hmm let me know if this persists

[05:25:48.0000] <philipj>
annevk: where are the logs on the server so I can check myself if it fails again?

[05:25:58.0000] <annevk>
philipj: in logs top-level dir

[05:27:23.0000] <philipj>
annevk: I guess it's not on the same machine as html5.org where I'm looking?

[05:27:31.0000] <annevk>
philipj: oh right

[05:29:29.0000] <annevk>
philipj: let me try to copy your key to this other server too

[05:30:21.0000] <philipj>
annevk: I guess I can then just ssh to mediasession.spec.whatwg.org?

[05:30:42.0000] <annevk>
philipj: yeah, if only I could figure out how to copy a line from nano

[05:32:29.0000] <philipj>
annevk: ctrl+k, but I don't know if that puts it in any clipboard

[05:32:47.0000] <annevk>
doesn't

[06:08:47.0000] <annevk>
Domenic: I feel like you hijacked that thread a bit... oh well, hopefully everyone can still follow

[06:09:30.0000] <Domenic>
annevk: I was trying to come up with a way to solve the "when do we call distributeCallback" and "how do we get consistency on offsetTop etc." problem.

[06:09:46.0000] <annevk>
we can't

[06:09:59.0000] <annevk>
that's why you throw offsetTop of the rails

[06:10:33.0000] <Domenic>
it wasn't clear to me at the time. last message helps a bit.

[06:11:22.0000] <annevk>
To understand this is a bit like baking apple pie

[06:12:05.0000] <annevk>
Actually, the first invent the universe analogy doesn't hold up too well

[06:12:44.0000] <annevk>
Domenic: so Layout is async. But offsetTop forces Layout to be sync.

[06:13:09.0000] <annevk>
Domenic: Distribution is async but needs to happen before Layout. So offsetTop forces it to be sync.

[06:13:11.0000] <Domenic>
sure. still seems OK to me for .offsetTop to invoke distributeCallback.

[06:13:16.0000] <Domenic>
why is distribution async

[06:13:43.0000] <annevk>
Domenic: well say it's sync

[06:13:54.0000] <annevk>
Domenic: then modifying the DOM invokes distribution sync

[06:14:00.0000] <annevk>
Domenic: and then we have mutation events back

[06:14:27.0000] <annevk>
we want sync mutation events less than we want offsetTop to work, imo

[06:15:13.0000] <Domenic>
maybe. I dunno, I can see authors adding `set offsetTop(v) { this.distribute(); super.offsetTop = v; }` etc. to get the behavior back.

[06:15:31.0000] <annevk>
seems fine

[06:15:40.0000] <annevk>
and they could likewise overload appendChild and such like that

[06:15:58.0000] <Domenic>
yeah, someone will make a mixin that just overrides everything necessary.

[06:16:14.0000] <Domenic>
almost some sort of ... shadow DOM polyfill ....

[06:16:18.0000] <annevk>
which is why I'd prefer not do anything with timing or doing anything automatically for v1

[06:16:50.0000] <annevk>
although timing equivalent to mutation observers seems reasonable and not too hard to add

[08:53:34.0000] <annevk_>
TabAtkins: so if I want to link "environment settings object" in HTML, what's the easiest way to do that?

[09:09:02.0000] <dglazkov>
annevk: have to be careful here with offsetTop et al.

[09:09:19.0000] <dglazkov>
I agree they're terrible APIs, but they also are widely used

[09:10:07.0000] <dglazkov>
so we need to make darn sure we don't turn the distribution API into something that you can only use on in a small set of the web that doesn't use these terrible APIs

[09:10:49.0000] <annevk>
As long as we leave timing to users of the API there's no problem

[09:11:02.0000] <dglazkov>
can you explain this a bit more?

[09:11:18.0000] <annevk>
Distribution only happens when you invoke distribute()

[09:12:01.0000] <dglazkov>
btw, my concern is captured well here: https://gist.github.com/rniwa/2f14588926e1a11c65d3#extention-to-custom-elements-for-consistency

[09:13:11.0000] <dglazkov>
I think the question is: who needs to invoke the distribute()? In a situation where component is developed by dev A and is being used by dev B, specifically.

[09:13:56.0000] <smaug____>
annevk: well, we may need to define some way to trigger callbacks at the end of nanotasks, in order to have distribution happening early enough

[09:14:34.0000] <dglazkov>
what if we just run them in a separate environment, pure-function-style

[09:14:35.0000] <dglazkov>
?

[09:15:00.0000] <smaug____>
don't understand that question

[09:15:33.0000] <smaug____>
separate environment?

[09:15:34.0000] <dglazkov>
run distribution callback in a separate script environment, with no access to the docs global

[09:15:42.0000] <smaug____>
like, adding isolation ;)

[09:15:52.0000] <dglazkov>
sort of, except in a very limited way

[09:16:10.0000] <dglazkov>
like a pure function, where there's really nothing else but the arguments of the function

[09:16:53.0000] <dglazkov>
that way, there will never be a problem with timing and we don't have to specify how the execution of the distribution callback correlates with the style resolution or anything like that

[09:17:08.0000] <smaug____>
well, if arguments are like nodelists, you can access the global object from there

[09:17:19.0000] <dglazkov>
they would be some dumb objects

[09:17:44.0000] <smaug____>
oh, some kind of weird proxy objects around the actual nodes

[09:17:50.0000] <dglazkov>
like a serialization of an element

[09:17:56.0000] <dglazkov>
or a proxy

[09:17:57.0000] <smaug____>
s/weird/dummy/

[09:18:04.0000] <dglazkov>
/me waves hands

[09:21:18.0000] <annevk>
I'm not sure that's gonna work

[09:21:32.0000] <annevk>
that would defeat things like using Media Queries as input to distribute nodes

[09:21:47.0000] <annevk>
or require adding all those APIs in an "separate script environment"

[09:22:15.0000] <dglazkov>
true

[09:22:15.0000] <annevk>
dglazkov: A needs to invoke distribute(), though B could too I suppose if it's not closed

[09:22:40.0000] <annevk>
smaug____: do we need to do that for v1?

[09:22:42.0000] <smaug____>
add a flag to MutationObserver whether it should be called at the end of microtask or nanotask, and let shadow dom users then call distribute if needed ?

[09:23:03.0000] <dglazkov>
annevk: when does A invoke distribute(), then?

[09:23:12.0000] <annevk>
smaug____: nanotask observers seems useful, but I wonder whether we need it for v1

[09:23:13.0000] <smaug____>
annevk: maybe not for v1, but need to think about v2 too a bit

[09:23:19.0000] <annevk>
dglazkov: whenever they think that is needed

[09:23:41.0000] <dglazkov>
annevk: I would like to flesh this out a bit more :)

[09:24:59.0000] <annevk>
dglazkov: I think I would put advice to devs to use mutation observers

[09:25:20.0000] <annevk>
dglazkov: but they have the freedom to call it at other times or provide hooks to the outside world, etc.

[09:25:51.0000] <smaug____>
yeah, I like the freedom distribute() gives

[09:26:18.0000] <smaug____>
we're just missing the nanotask-like thing from the platform atm, and that will be needed at some point

[09:26:54.0000] <smaug____>
(perhaps we need nanotasks only for DOM mutations, so it wouldn't be a generic thing, but MutationObserver only)

[09:27:06.0000] <annevk>
nanotasks are like IDL exit callbacks

[09:27:07.0000] <dglazkov>
let's try to make this a bit more concrete: https://gist.github.com/dglazkov/bdbe817b9cce48e4d072

[09:27:24.0000] <dglazkov>
when does A have a chance to run distribute in that gist?

[09:27:40.0000] <annevk>
dglazkov: as I said elsewhere that fails

[09:27:50.0000] <annevk>
dglazkov: though not with a future nanotasks thingie

[09:28:05.0000] <annevk>
dglazkov: here is the tradeoff: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0450.html

[09:28:22.0000] <annevk>
dglazkov: if you can defeat the tradeoff you win, but otherwise we should just make a choice and move on

[09:28:34.0000] <smaug____>
annevk: we don't want distribute() to be called at the end of any nanotask, only after dom mutations, I think

[09:28:56.0000] <dglazkov>
annevk: I am confused. Are you saying that you would put the burden on B to make this work?

[09:28:59.0000] <annevk>
smaug____: I agree that we want to scope nanotasks

[09:29:17.0000] <annevk>
dglazkov: yeah

[09:29:38.0000] <dglazkov>
annevk: that means that shadow DOM components can't be used in pretty much any framework that exists today.

[09:29:47.0000] <dglazkov>
that seems... drastic?

[09:29:52.0000] <annevk>
dglazkov: again see tradeoff?

[09:31:17.0000] <dglazkov>
annevk: I saw the link, but I am not sure that the cost of web component not being adopted anywhere in any foreseable future is worth the benefit in this trade-off

[09:31:34.0000] <dglazkov>
right?

[09:31:53.0000] <dglazkov>
I mean.. the whole point of web components is to conform to DOM contract that exists currently

[09:32:25.0000] <annevk>
dglazkov: I don't think there's another tradeoff?

[09:32:49.0000] <dglazkov>
the separate environment is one

[09:33:25.0000] <dglazkov>
you're trading hypothetical media query use cases for being able to satisfy all other requirements

[09:33:30.0000] <annevk>
dglazkov: that seems very unlikely to happen to me

[09:34:32.0000] <dglazkov>
tell me more

[09:35:02.0000] <annevk>
As far as I know this has been a research area for TC39 for quite a while

[09:35:16.0000] <dglazkov>
oh, I see

[09:35:16.0000] <annevk>
At least subclassing was a somewhat concrete idea when we started Shadow DOM

[09:35:27.0000] <annevk>
I mean, Web Components

[09:35:54.0000] <dglazkov>
you're worried that if we pursue true pure functions, we'll be blocked on TC39 for a while

[09:36:18.0000] <annevk>
Another five years?

[09:36:31.0000] <dglazkov>
that seems _awesome_

[09:36:37.0000] <dglazkov>
:D

[09:36:39.0000] <annevk>
/me would like to ship something...

[09:36:55.0000] <annevk>
dglazkov: so nanotasks?

[09:37:09.0000] <annevk>
dglazkov: mutation observer nanotasks, that is

[09:37:48.0000] <annevk>
dglazkov: that gives A a callback at the end of B's call to appendChild(), which can invoke distribute(), which means B's call to offset gets the right answer

[09:38:12.0000] <dglazkov>
you know what

[09:38:15.0000] <dglazkov>
maybe!

[09:38:18.0000] <dglazkov>
let me think about this

[10:02:17.0000] <annevk>
Hahaha

[10:02:29.0000] <annevk>
<a>origin</a> links to http://dev.w3.org/csswg/css-cascade-4/#origin

[10:06:19.0000] <annevk>
TabAtkins: so what I'd like is something like <a from=html>origin</a>

[10:29:53.0000] <Domenic>
Pure functions can be defined without TC39 I think

[10:30:00.0000] <Domenic>
You serialize the function to a string

[10:30:12.0000] <Domenic>
If it works in the other environment then it's pure

[10:30:32.0000] <Domenic>
That is what came up when I asked TC39 about this

[10:35:25.0000] <bradleymeck>
Domenic: you can also parse out if a function is pure, but it is pricey in JS

[10:35:45.0000] <bradleymeck>
parse/analyze

[11:02:58.0000] <wanderview>
jgraham: I think this one is ready for merge: https://critic.hoppipolla.co.uk/r/4838

[11:10:36.0000] <jgraham>
wanderview: Done. How many of your PRs are left?

[11:11:01.0000] <jgraham>
Just one?

[11:11:02.0000] <wanderview>
jgraham: just one :-) https://critic.hoppipolla.co.uk/r/4825

[11:11:46.0000] <jgraham>
OK, I'll kick off an update in gecko as soon as that one gets reviewed

[11:11:49.0000] <jgraham>
and merged

[11:17:02.0000] <dglazkov>
Domenic: how quickly can we confirm/reject the hypothesis that we don't need TC39 for pure functions?

[11:17:18.0000] <dglazkov>
I would like to keep all ideas on the table

[11:17:28.0000] <dglazkov>
do we even need pure functions?

[11:22:49.0000] <SteveF_>
/me trys to follow shadow dom/web components discussion, totally out of my league

[11:33:46.0000] <MikeSmith>
botie, inform SteveF_ re: "SteveF_ trys to follow shadow dom/web components discussion, totally out of my league", you're in good company. I think the set of people who actually understand all of this well can be counted on two hands

[11:33:46.0000] <botie>
will do

[11:42:56.0000] <caitp->
trevnorris, re: optimizing subclasses, i wouldn't expect hydrogen to deal with them, but turbofan might already

[11:43:40.0000] <trevnorris>
caitp-: not as of 4.4.44. was trying to get some info out for IRHydra and there was no output.

[11:44:05.0000] <caitp->
does IRHydra deal with TF at all?

[11:44:16.0000] <trevnorris>
yup.

[11:44:31.0000] <caitp->
anyways, it will end up optimized in TF at some point

[11:45:02.0000] <trevnorris>
no doubt. it just threw me when there wasn't any output. thought there was something wrong with the internal V8 tracing.

[12:10:22.0000] <Domenic>
dglazkov: we can do a slow polyfill (web workers + actual JS serialization) in a day or two.

[12:15:35.0000] <botie>
SteveF_, at 2015-04-30 18:33 UTC, MikeSmith said: re: "SteveF_ trys to follow shadow dom/web components discussion, totally out of my league", you're in good company. I think the set of people who actually understand all of this well can be counted on two hands

[12:16:40.0000] <SteveF_>
botie: gotcha player ;-)

[12:16:40.0000] <botie>
SteveF_: i'm not following you...

[12:18:16.0000] <jgraham>
Anyone know why this expects to throw an error? https://github.com/w3c/web-platform-tests/blob/master/workers/interfaces/WorkerGlobalScope/close/setTimeout.html

[13:13:58.0000] <wanderview>
Domenic: its unfortunate Response.body.getReader() does not have backpressure yet

[13:14:56.0000] <wanderview>
I guess I can build backpressure at the app level

[14:26:22.0000] <jgraham>
Hixie: Did the spec at some point change so that a worker that does close(); setTimeout(function(){},0) would no longer fire an error event?

[14:37:53.0000] <dglazkov>
MikeSmith: can you give rniwa w3c/webcomponents commit bit?

[14:49:06.0000] <terinjokes>
JakeA: w/r/t your tweet, it's something I certainly want to do

[15:22:36.0000] <TabAtkins>
annevk: You're looking for the spec='' attribute.  The problem, though, is that HTML is really incredibly terrible for Bikeshed links.  Nothing is "exported", in Bikeshed's terms, and it's all typed as "dfn" type definitions.  That's why CSS's "origin" definition is winning; Bikeshed prefers exported definitions by default.

[15:23:23.0000] <TabAtkins>
After I finish up this File API spec, though, I'm gonna roll up something to do some manual link-adding, so we can put HTML terms in manually and let everyone use them.

[15:24:20.0000] <TabAtkins>
(Technically I can add custom definitions right now, but they all get interpreted as being "local" definitions, which auto-win over cross-spec defs, which isn't the behavior I want here.  It won't be hard to fix.)

[15:25:45.0000] <TabAtkins>
annevk: For arbitrary terms that you want to link to in a one-off fashion, tho, just add them to the <pre class=anchors> block in your spec.  There should already be a bunch of HTML anchors in there, so it'll be obvious how to do so.

[15:37:48.0000] <TabAtkins>
annevk: Oh man, just realized why a bunch of terms aren't linking to DOM; they're not exported either.  Do you want a PR for exporting all the stuff, or is it okay for me to push directly to the spec?

[16:37:14.0000] <MikeSmith>
dglazkov: Yeah will try to do that right now (from my mobile) cc rniwa

[16:41:14.0000] <MikeSmith>
dglazkov: Ok, invite sent

[16:41:40.0000] <MikeSmith>
rniwa: you should have perms now