05:54
<annevk>
https://github.com/w3c/html/commit/180c3a639a0b1998596e16907c8c182c82a7f53a "Integrate changes from other location"
05:54
<annevk>
That is so messed up
08:30
<Ms2ger>
Domenic++
08:31
<annevk>
Ms2ger: script cleanup?
08:32
<Ms2ger>
In particular, but also all the horrible js interaction crap he's been doing :)
09:05
<Ms2ger>
annevk, do you think setting this up would be useful: https://travis-ci.org/Ms2ger/dom/builds/128303192
09:05
<Ms2ger>
To make sure PRs don't accidentally break the spec generation
09:06
<annevk>
Ms2ger: yeah maybe, should ask Domenic too
09:06
<Ms2ger>
Domenic, consider yourself asked :)
09:06
<annevk>
Ms2ger: he had some ideas about running bikeshed on the server instead, and also publishing snapshots
09:06
<Ms2ger>
That'd be nice too
09:07
<annevk>
Ms2ger: with this we could presumably also let Travis post a review URL so you can read the generated HTML rather than the diff
09:07
<annevk>
lots of folks don't like to read spec-HTML, and I can't really blame them
12:42
<annevk>
We should maybe rename tuple origin to network origin
13:07
<jgraham>
Got to love @mention spamming
13:08
<annevk>
jgraham: from wpt?
13:11
<jgraham>
w3c/encryptedmedia
13:12
<jgraham>
Someone deciced to @mention everyone in the w3c github org or something
13:24
<JohnMH>
That's just another flaw with GitHub, should honestly be handled with Bugzilla or with a mailing list and a thread per issue
13:40
<caitp>
a mailing list? ...really?
13:41
<JohnMH>
Yes?
13:41
<JohnMH>
A mailing list is the best way to perform threaded communication.
13:42
<JohnMH>
Unless you use the gmail web client, anyway
13:42
<JohnMH>
If you use a real mail client, you'll have a much better experience.
13:43
<JohnMH>
I would suggest Mozilla Thunderbird, and if you use GNU+Linux I would suggest trying Evolution
15:04
<annevk>
jyasskin: I wonder if some kind of non-HTML sketch of the model would make it easier
15:04
<annevk>
jyasskin: since I suspect everyone is getting lost in the weeds
15:05
<annevk>
jyasskin: also, for me personally I'm having a lot of other things at the moment so I haven't really put as much thought into it as I probably should
15:06
<jyasskin>
annevk: I've got https://docs.google.com/document/d/1sdRwvnG3lAk95RNPHXFSuWQeq9Rx8lgMKPvrmjQ-y4I/edit?usp=sharing, but it doesn't have a lot of examples.
15:06
<annevk>
jyasskin: I'm getting that impression from most other participants too, nobody has this really figured out, not sure if that means we should take a step back or some such
15:07
<jyasskin>
annevk: Yeah. We could set up a VC in a week or two, and I could undo the changes to Bluetooth that rely on having permission storage.
15:08
<annevk>
jyasskin: e.g., one thing that was brought up is privacy mode, but I don't think that is worth of consideration here
15:08
<annevk>
jyasskin: if we introduce that as a thing, that would end up splitting a lot of things into two effectively, I think trying to consider it here in isolation is very distracting
15:09
<jyasskin>
I think privacy mode fits into either of the last two models, but their complexity is needed even to capture Firefox and Safari at the same time.
15:09
<jyasskin>
(Firefox's and Safari's non-private modes)
15:10
<annevk>
jyasskin: so one good thing to do I guess would be to write down the requirements for the more complicated permission types, including the requirements coming from various browsers
15:13
<annevk>
jyasskin: it does seem though that a generic permissions API is not super great given that so far it seems a lot of them have very different requirements
15:14
<annevk>
jyasskin: but maybe there's some primitives we can uncover...
15:15
<jyasskin>
annevk: By "permission types", do you mean the values of the PermissionName enum, or the kinds of ways that browsers store permissions?
15:16
<annevk>
jyasskin: former
15:20
<jyasskin>
'k, I'll make a document listing their behavior.
15:25
<annevk>
jyasskin: thanks, I still feel like I'm not really helping you, but I should have more time soon
15:34
<jyasskin>
annevk: Thanks for the help you have been providing.
20:53
<wanderview>
Domenic: is there a description of this spec language using "!" or "?" before calling a function? for example, "Return ! CreateArrayFromList(branches)."
20:53
<Domenic>
Heh, that's a popular topic today..
20:53
<Domenic>
https://tc39.github.io/ecma262/#sec-algorithm-conventions
20:53
<Domenic>
seems like we should link all !s and ?s to there
20:54
<wanderview>
hmm
20:54
<wanderview>
ecmascript docs hurt my brain
20:55
<wanderview>
seems "?" means that the algorithm may abort depending on the returned result?
20:55
<wanderview>
and "!" are essentially infallible?
20:55
<Domenic>
Yep that's the idea
20:55
<caitp>
? used to be written as ReturnIfAbrupt, basically
20:56
<wanderview>
ok, thanks
20:56
<Domenic>
Sorry for the confusion :-/
20:56
<wanderview>
Domenic: how is a logic not operation written if we are using "!" for this?
20:56
<Domenic>
wanderview: "if true, false. if false, true"
20:57
<Domenic>
Usually you just end up saying "if x is false"
20:57
<wanderview>
ok
21:13
<wanderview>
Domenic: how can "highWaterMark" be undefined in new ReadableStream() step 7a? It seems to default to 1
21:13
<wanderview>
new ReadableStream(underlyingSource = {}, { size, highWaterMark = 1 } = {})
21:14
<Domenic>
wanderview: good catch, we didn't fix the heading when we introduced the different defaults
21:14
<wanderview>
Domenic: I'll write an issue
21:15
<wanderview>
Domenic: https://github.com/whatwg/streams/issues/447
21:16
<Domenic>
\o/
21:19
<wanderview>
Domenic: is the ReadableStream spec pretty stable now?
21:20
<wanderview>
any more large changes in the works?
21:20
<Domenic>
wanderview: apart from piping, yes, i'd say very stable
21:20
<wanderview>
but we need WritableStream for that, though, right?
21:20
<Domenic>
exactly
21:20
<wanderview>
k
21:20
<Domenic>
writable/transform/piping still unstable, sadly
21:21
<wanderview>
the controller changes seem pretty extensive
21:28
<Domenic>
Yeah... the actual behavior changes were very minor, but Takeshi moved a bunch of stuff into the controller to fit your suggestion as to how to use the revealing constructor pattern to customize one class into doing two jobs
21:29
<wanderview>
yea... I think it will be good to avoid the two types
21:29
<wanderview>
just unwinding what that means for our first cut at streams
21:29
<wanderview>
I think I'm just going to update it all to the new spec language
21:30
<Domenic>
We have something that might be helpful... Takeshi updated the implementation for the new changes, just without any byte stuff yet
21:31
<Domenic>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/streams/ReadableStream.js&q=ReadableStream.js&sq=package:chromium&l=1
21:34
<wanderview>
Domenic: thanks! although our self-hosting code looks a bit different
21:34
<wanderview>
may not be able to use that too much
21:34
<Domenic>
yeah that's fair
21:35
<wanderview>
for example, our self-hosted code doesn't support constructors directly :-(
21:35
<wanderview>
we have to bounce through c++ the first time to a constructor handle, etc
21:35
<wanderview>
good times
21:35
<wanderview>
anyway, I have to run to dinner
21:35
<wanderview>
thanks for the help!
21:39
<Domenic>
anytime!
21:45
<zcorpan>
still have 1h to answer the #HTMLQuiz y'all 📢 https://twitter.com/zcorpan/status/730891209019822084
21:49
<Domenic>
I checked after my answer; I got it wrong :(