09:56
<annevk>
jgraham: is the effect of the filter I created that I get a lot of email spam?
09:57
<annevk>
jgraham: because then I'm going to remove that again and only review if someone requests that I look at something
10:08
<zcorpan>
annevk: can you review https://critic.hoppipolla.co.uk/r/23 ? :-)
10:09
<annevk>
darobin: so I looked into "JSON-LD" and that draft is sooo bad
10:10
<annevk>
darobin: so I wonder whether I'll need to care about it
10:10
<darobin>
annevk: as I said the other day, I wasn't looking at the actual design but rather at the overall issue they had with WebIDL :)
10:11
<darobin>
annevk: I just realised that you weren't there when I brought it up (on another channel), but do you reckon that the TAG has a credible reason to support open licenses?
10:11
<darobin>
I'm just wondering if it would be useful weight to throw in
10:19
<annevk>
darobin: it enables distributed extensibility
10:20
<annevk>
And I'm only half-joking here as I think that's pretty much what this is about.
10:23
<darobin>
annevk: if you feel you can make the case then you might want to caucus with your new friends and scare up a quick finding
10:37
<jgraham>
annevk: If you only want to review in certain folders then you can change the filters. If you just want less mail in your inbox you can use OperaCritic-* headers to filter
10:37
<jgraham>
Or you can disable email in critic config, I think
10:39
<annevk>
I guess I only want to look at critic if someone asks me
10:39
<jgraham>
OK, well you should leave the filter but disable the email I think
10:40
<jgraham>
Although I suppose that won't work so well for reviews where you *do* want the email
10:42
<annevk>
I don't need the email, if there's hurry someone can ping me I suppose
10:42
<annevk>
You don't want to rely on me there anyway :-)
10:42
<jgraham>
Well I do want to if you havew submitted comments on my tests :)
10:45
<Ms2ger>
And I want more people to get mail about new reviews :)
10:50
<annevk>
I'm getting no emails for now
11:09
<annevk>
zcorpan: so I'm not intimately familiar with message ports
11:09
<zcorpan>
annevk: no problem, just read the spec :-P
11:11
<annevk>
zcorpan: are timers and message channels on the same event loop?
11:11
<annevk>
zcorpan: I guess I should say "task source"
11:13
<zcorpan>
annevk: no
11:14
<annevk>
zcorpan: 003.html seems to depend on when going before the other
11:15
<annevk>
I guess I should add comments
11:17
<jgraham>
darobin, odinho: Email?
11:17
<darobin>
jgraham: ?
11:18
<darobin>
jgraham: are you asking about what odinho meant by email in a somewhat compact manner?
11:18
<jgraham>
Yes
11:18
<jgraham>
Maybe should have been "Email?!"
11:19
<darobin>
jgraham: GitHub can send email on push, as you know, and we're using that at this point
11:19
<jgraham>
You have a script that gets email?
11:19
<Ms2ger>
Sounds like tinderbox
11:19
<darobin>
yeah
11:19
<Ms2ger>
It ended in tears
11:19
<darobin>
setting that up on a w3c box is simple
11:19
<jgraham>
And that was easier than a script that responds to a HTTP request?
11:19
<darobin>
it involved changing one line in an existing script and one line in an existing .forward
11:20
<jgraham>
OK
11:20
<darobin>
whereas there was no existing script handling HTTP for this :)
11:21
<darobin>
if we start doing more things over HTTP then we can easily move to that, but this was really low cost
11:21
<jgraham>
Well I guess if you already have the infrastructure for it
11:21
<darobin>
the kind people in the W3C systeam recently moved the testing box under Puppet control
11:21
<darobin>
with that came all sorts of nice infrastructure
11:22
<odinho>
darobin: Merely curious on behalf of the list :-)
11:23
<darobin>
odinho: you'll have to tell me how you assess list curiosity one of these days ;)
11:23
<odinho>
^_^
11:23
<darobin>
you folks going to the HTML & co f2f btw?
11:23
<odinho>
I'm not employed to do any spec/W3C/WHATWG things.
11:24
<Ms2ger>
Yet
11:24
<odinho>
(any more)
11:24
<jgraham>
Heh
11:24
jgraham
isn't going either
11:24
<Ms2ger>
darobin, watch out, glazou will ambush you
11:25
<darobin>
ah, shame, beer could've been involved
11:25
<darobin>
Ms2ger: I'm not afraid of the glazou, I actually bump into him regularly around here :)
11:25
<darobin>
well, beer will be involved
11:25
<darobin>
but would've been nice in present company
11:26
<jgraham>
As batter for fish and chips?
11:26
<jgraham>
s/as/in/
11:26
<darobin>
you want me to use you guys as batter for F&C?
11:26
<darobin>
that doesn't sound wholly appropriate
11:36
<annevk>
I was already going to SF beginning of May, didn't want to go twice
11:36
<annevk>
Also, I'm not in any of those groups
11:38
<jgraham>
You didn't rejoin webapps?
11:48
<Ms2ger>
You can take my place
11:53
<zcorpan>
is there any presedent for a spec defining that clicks should go through? http://www.w3.org/mid/20839.59437.162735.705552⊙ggH
11:59
<Ms2ger>
text: {type: "string", treatNullAsEmptyString: true},
11:59
<Ms2ger>
link: {type: "string", treatnullAsEmptyString: true},
11:59
Ms2ger
wonders if they both work
12:17
<annevk>
jgraham: W3C didn't resolve the problem yet
12:18
<annevk>
zcorpan: there's a precedent for hit testing being wholly undefined
12:19
<annevk>
zcorpan: and CSS 'pointer-events' having some influence on that
12:19
<zcorpan>
annevk: ok
12:20
<jgraham>
You mean pointere events changes it from being undefined to being differently undefined?
12:20
<annevk>
jgraham: kinda like that, yes
12:45
<zcorpan>
well then i guess multicol should just handwave it
12:46
<smaug____>
annevk seems to have the default answer "x should use Futures" these days :)
12:47
<annevk>
smaug____: I found my hammer
12:47
<smaug____>
( I don't know whether that is right or wrong answer )
12:53
<gsnedders>
I feel like all I'm doing this week is filing bugs on Python implementations.
13:11
<zcorpan>
gsnedders: too few Futures?
13:33
<zcorpan>
ok so what's the correct branch naming? submission/Opera/my-topic ?
13:35
<Ms2ger>
I believe so, yes
13:36
<darobin>
zcorpan: we're not too strict on that...
13:37
<darobin>
note that if you name your branch submission/Opera/my-topic I think it'll clash when someone tries to name their submission/Opera/other-topic
13:37
<Ms2ger>
Don't think so
13:37
<darobin>
maybe not, I don't see why, but ISTR that someone had a problem
13:38
<darobin>
in any case, just make sure there's some identification of the submitter and the feature after "submission/"
13:38
<Ms2ger>
Given that there's three submission/Opera/*'s already :)
13:38
<jgraham>
submission/Opera would clash with submission/Opera/foo
13:39
<jgraham>
Because that makes "Opera" a file under submisssion, so it can't also be a folder
13:39
<darobin>
ah, that's the one
13:40
<zcorpan>
ok
13:41
<jgraham>
(if helps if you know that branches are refs are files)
13:42
<Ms2ger>
I thought they were homeomorphic endofunctors mapping submanifolds of a Hilbert space?
13:46
<darobin>
only in same-sex git
13:46
<Ms2ger>
I hear France doesn't like that now
13:47
<darobin>
actually we do, the Senate just voted on it
13:51
<zcorpan>
jgraham: should i ping you when i make a new PR or should i expect a critic review to appear?
13:56
<zcorpan>
jgraham: https://github.com/w3c/web-platform-tests/pull/75
14:05
<jgraham>
zcorpan: A critic review does appear, but critic doesn't know your email address so you don't get notified
14:06
<zcorpan>
jgraham: how do i make it know my email?
14:07
<jgraham>
zcorpan: Add it to the "email" box on https://critic.hoppipolla.co.uk/home
14:10
<zcorpan>
ah
16:10
karlcow
is not on public-script-coord but the http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0061.html
16:11
<karlcow>
>We need a few people who can drink from a firehose on "all the lists",
16:11
<karlcow>
>who then bubble issues up to public-script-coord.
16:11
<karlcow>
Does tc-39 post the minutes of their meetings to public-script-coord?
16:12
<karlcow>
maybe that could be a 1st step if not done.
16:14
<annevk>
I think what Boris suggested about routing all new drafts through public-script-coord is a good idea
16:14
<karlcow>
but even that… it's a lot lot lot of high level and super technical inputs. It's becoming very hard to understand and follow.
16:14
<annevk>
TC39 meeting minutes I've seen so far require in-depth knowledge
16:14
<karlcow>
yeah
16:15
<annevk>
I can follow them, but when I look at what drafts people are cooking up I kinda doubt the same goes for them
16:16
<karlcow>
chaos… each foot on a highly moving platforms. Loss of equilibrium.
16:16
<karlcow>
:(
16:18
<jsbell>
I strenuously object to more coordination between "the JS people" and "the DOM people". The entertainment that arises when one group realises what the other has done is far more popcorn-worthy than anything Hollywood spits out.
16:18
<karlcow>
http://wiki.ecmascript.org/doku.php?id=meetings:minutes_feb_12_2009
16:18
<annevk>
I don't think it's all too bad really. We lack a bit of leadership and coherent vision.
16:18
<annevk>
jsbell: hehehe
16:18
<karlcow>
hmm not a lot of informations in these minutes
16:23
karlcow
is trying to see if a script would work for Hollywood with "Jaws Savage against Death Of Moan"
16:29
<annevk>
http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/att-0007/WebRequestStatusCodes4.html
16:29
<annevk>
Hmm, should I follow public-web-perf too? Not entirely clear I would be able to get any work done if I just start subscribing to the firehose, as Brendan puts it.
16:48
<karlcow>
annevk: the volume of mails starts to be insane. It's a full time job to just read them on all mailing-lists. One person doesn't scale (to my own misery for the open web summary)
16:50
<annevk>
Right, lets not forget it's a good thing too. This thing is more successful than ever.
16:50
<annevk>
We just need to deal with the growing pains somehow.
17:29
<annevk>
TabAtkins: in "Add convenience functions for immediate/canceled promises" you agree with Future.resolve but yesterday you asked for .accept
17:29
<annevk>
TabAtkins: that's confusing
17:32
<TabAtkins>
annevk: I forgot the exact names. Also, I haven't yet internalized the difference between accept and resolve.
17:43
<annevk>
TabAtkins: thought I'd mention it since Domenic did point out what resolve() would do
17:43
<annevk>
TabAtkins: so I was confused whether you'd be okay with that or not
17:43
<TabAtkins>
He pointed it out? He must have done so in a way that doesn't actually explain it, since I still don't know what it does. :/
17:50
<TabAtkins>
I suspect I'm well-placed to do the firehose thing (I subscribe to and read all of www-style, webapps, www-dom, script-coord, whatwg, and es-discuss), but because I read all of it, I'm bad at realizing when things need to be bubbled up for other people. ^_^
17:51
<annevk>
There's a bunch more, too. webappsec, media-capture, html-media, webcrypto, ...
17:51
<TabAtkins>
Yeah, I don't pay attention to those.
18:06
<TabAtkins>
annevk: If I'm reading right, the difference between accept() and resolve() is that accept() just immediately resolves the future to the passed value, while resolve() checks if the value is also a future(/thenable), and if so, waits until *that* future resolves, and resolves the initial future to that value.
18:06
<TabAtkins>
That's a lot of pronouns, but you should get what I mean.
18:07
<annevk>
yes
18:07
<annevk>
yes
18:07
<TabAtkins>
Okay. In that case, no reason not to provide all three of the resolver methods straight on Future.
18:08
<annevk>
sure
18:08
<TabAtkins>
I just sent email.
18:09
<annevk>
I'll look at most of that stuff later
18:09
<annevk>
there were some interesting ideas there too with respect to streams and signals
18:09
<TabAtkins>
Yes, I'd be interested in exploring that with you, when you have time.
18:10
<annevk>
TabAtkins: I'm in SF May 6-10, MV the Monday after
18:10
<annevk>
TabAtkins: and in Tokyo June 6-23 or so, I hear you go there now and then
18:11
<TabAtkins>
I appear to be free in May, and I'll be in Tokyo for at least a week in the beginning of June (for SVG and CSS and maybe TTWF).
18:11
<annevk>
But hopefully we'll get some stuff sorted out async/via IRC by that time
18:12
<annevk>
I gotta go for a bit, have been staring at this thing too long
18:20
jgraham
notes that all the suggestions in http://www.w3.org/mid/D236F78E-8320-4FC2-986B-6EE57FE6FED3⊙wc are of the from "W3C should (do thing) to give TC39 a voice"
18:28
<jgraham>
The obvious implication being that the right solution is "TC39 should disband and Javascript should be developed through the W3C"
18:29
<Ms2ger>
I suggest you reply with that and I sit back and enjoy the results :)
18:30
<divya>
ahahhahaha
18:36
<Ms2ger>
TabAtkins, no, only if you date someone with mixed red-brown hair
18:37
<Hixie>
jgraham: "more meetings" doesn't seem to me like the best way to solve TC39's problems :-)
18:37
<jgraham>
I am really very tempted, but I can't quite bring myself to do it. Not because I'm not serious, but because I can't face all the explainations as to why it can't happen.
18:37
<jgraham>
(that was aimed as Ms2ger)
18:38
<jgraham>
I'm not sure "disband TC39 and start a W3C group instead" implies "more meetings"
18:40
<Hixie>
jgraham: that e-mail was all about more meetings at TPACs
18:40
<Hixie>
as far as i can tell :-)
18:48
<Hixie>
TabAtkins: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=17812
18:52
<jgraham>
Hixie: If they weren't a seperate body they wouldn't have *more* meetings at TPACs; it's just that their normal meetings would happen to be at TPACs and DOM people could attend (and they could attend e.g. webapps meetings if they wanted)
18:53
Ms2ger
imagines that
18:53
<Ms2ger>
Every time someone mentions WebIDL
18:54
<Ms2ger>
"Hi, I'm from TC39, I don't know anything about how WebIDL works, and I think it sucks"
19:07
<Hixie>
jgraham: fair enough
19:07
<Hixie>
jgraham: i didn't get teh feel from that e-mail that they wanted to disband TC39
19:07
<Ms2ger>
Hixie, they don't
19:07
<Ms2ger>
Hixie, but jgraham pointed out that that would be a solution to the stated problems
19:14
<TabAtkins>
jgraham: Suggest it. I've been told the historical reasons for why ES was developed in ECMA originally, but I don't remember what they are anymore. Certainly, whatever they were no longer applies.
20:41
<jwalden>
I have a very very very vague recollection of the hurdles ECMA put in place being much lower, and therefore it being desirable to get something that corresponded much more closely to the implementation, than something "cleaner" but not compatible with the web
20:41
<jwalden>
that's what I remember hearing, at least
20:44
<annevk>
the dynamics have certainly changed since '96 though
20:45
<jwalden>
yup
20:45
<jwalden>
also the name *cough* Ecma *cough* :-)
20:45
<MikeSmith>
i think part of the reason had to do with Dan Connolly not arguing for it to come to W3C but instead letting it go to Ecma
20:46
<annevk>
And Bert Bos and something about a dead body?
20:46
<jwalden>
although, the context I vaguely remember hearing this in was that Ecma's still like that, wrt the MS Office XML formats
20:46
<annevk>
That might have been later
20:46
<MikeSmith>
and that largely because W3C at the time was averse to standardizing programming languages at W3C
20:46
<MikeSmith>
this was before XSLT
20:47
<jgraham>
The policy was "no programming languages unless they are XML"?
20:47
<MikeSmith>
Netscape apparently submitted it initially to the W3C and IETF as well as Ecma
20:47
<MikeSmith>
jgraham: not sure there was any policy
20:48
<MikeSmith>
and it was before XML too
20:48
<jgraham>
Anyway I presume that ECMA would put up a fight to keep JS. After all they don't do anything else that anyone's heard of
20:49
<MikeSmith>
but note also that Microsoft had submitted JScript and VBScript to W3S too
20:50
<MikeSmith>
jgraham: they could continue to publish the EcmaScript spec regardless, even if the upstream spec came from a W3C group
20:51
<jgraham>
That doesn't sound entirely unreasonable
20:51
<jgraham>
But of course I don't know the constraints
20:51
<MikeSmith>
or maybe Javascript and the Microsoft specs had not but formally submitted to the W3C at the time but I think they were kind of being discussed for publication as standards in various places, including W3C
20:52
<MikeSmith>
jgraham: yeah me neither
20:56
<MikeSmith>
hmm from what I can glean, apparently at that time in 96 there was some policy document published at W3C that talked about "Independence of essential services
20:56
<MikeSmith>
> from programming language
20:56
<MikeSmith>
"
20:57
<MikeSmith>
"While some services should remain specific to individual language runtime systems, the interface between the language runtime and the HTML document must be compatible with a variety of programming languages. Givent the history of programming languages, it's clear that binding such essential services to any particular language would compromise the evolution of the web."
20:58
<TabAtkins>
Given that binding to a particular language *at that time* would probably have meant Java, they were probably right.
21:00
<jgraham>
Well except it is bound to a particular language so they were wrong
21:01
<TabAtkins>
I meant that they were right about binding to Java compromising the evolution of the web.
21:01
<TabAtkins>
Later, the web de facto bound itself to a single language which was better, so they were wrong.
21:03
<MikeSmith>
yeah
21:04
<MikeSmith>
anyway from what I can tell it seems that Netscape originally had preferred to take it to either W3C or IETF but the reason they didn't is that both the W3C and IETF basically told them No, we're not interested
21:05
<TabAtkins>
Right. Nowadays, it does seem that the different orgs just make it harder to evolve the web semi-coherently.
21:06
<MikeSmith>
yup
21:06
<MikeSmith>
see also https://brendaneich.com/2011/06/new-javascript-engine-module-owner/
21:06
<MikeSmith>
"At some point in late summer or early fall 1996, it became clear to me that JS was going to be standardized. Bill Gates was bitching about us changing JS all the time (some truth to it; but hello! Pot meet Kettle…). We had a standards guru, Carl Cargill, who knew Jan van den Beld, then the Secretary-General of ECMA (now Ecma). Carl steered our standardization of JS to ECMA.
21:07
<TabAtkins>
Ah, accidents of history...
21:08
<MikeSmith>
interesting statement at http://quod.lib.umich.edu/j/jep/3336451.0014.103/--why-standardization-efforts-fail?rgn=main;view=fulltext too
21:08
<MikeSmith>
from Carl
21:08
<MikeSmith>
"When the initial standards activity was being proposed, Java was still relatively new to market, and Microsoft had just forced Netscape to standardize JavaScript in Ecma. "
21:08
<MikeSmith>
"forced"
21:15
<odinho>
Well, if vendors go together, it would be possible to fix the overarching problems, and evolve it somewhat more coherently.
21:15
<odinho>
Or at least in a hopefuly theory.
21:17
<MikeSmith>
reading https://groups.google.com/a/chromium.org/forum/#!topic/storage-dev/o6ZeVTXtuWQ
22:01
<Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21180 is the best bug ever
22:01
<Hixie>
the sum total of the bug description is "please correct"
22:03
<rillian>
Hixie: be fair. there's a section reference. they're not expecting all of HTML to be corrected.
22:04
<Hixie>
fair enough.
22:04
<Hixie>
no idea what's wrong though!
22:04
<rillian>
if only it had said #main-element
22:05
<annevk>
/whois rillian
22:05
annevk
was wondering who made him laugh
22:31
<Hixie>
css people who care about bidi, ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=21188
22:35
<Hixie>
well this is an extreme case of this copy-and-paste phenomenon: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21196&list_id=7566
22:57
<Hixie>
heycam|away: ping for advice on https://www.w3.org/Bugs/Public/show_bug.cgi?id=19611
23:20
<Hixie>
mounir: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=11937
23:37
<jsbell>
heycam|away: in WebIDL, is the TypeSuffix nonterminal intentionally recursive, i.e. type[][][]?[]????[][] ? Seems like it should only be allowing type, type?, type[] and type[]? but perhaps I'm mis-reading.
23:40
<jsbell>
I mean: a nullable array of nullable array of array of array of nullable array (etc) of type is itself a conceivable type, but is that expressiveness *in WebIDL* intentional or a grammar glitch in the spec?