02:06
<jacobolus>
does anyone know if there's an IRC channel for web assembly?
02:23
<MikeSmith>
jacobolus: yeah, on irc.w3.org, #webassembly
02:24
<jacobolus>
just found that :)
02:24
<jacobolus>
thanks
02:24
<MikeSmith>
k
02:24
<MikeSmith>
it's fairly activeーcore committers hang out there
02:24
<jacobolus>
MikeSmith: know if it has a bot saving history somewhere?
02:25
<MikeSmith>
dunno
02:25
<MikeSmith>
sunfish there might know
06:44
<annevk>
http://www.sadtrombone.com/ excellent
06:45
<annevk>
jgraham: not sure if you saw my ping, but could you take a look at https://github.com/whatwg/html/pull/323 please?
06:53
<annevk>
The GitHub x/y links only work within the same organization? That is kind of lame
07:18
<annevk>
https://docs.google.com/presentation/d/1pOZ8ppcxEsJ6N8KfnfrI0EXwPEvHwg3BHyxzXXw8lRE/edit is really quite great
07:19
<annevk>
Waiting for foolip to tweet it
07:19
<annevk>
Or rbyers
07:26
<annevk>
Seems rbyers did
08:34
<zcorpan_>
i don't like that webvtt has the id above the timings. would be much nicer to have the id as a setting
08:35
<zcorpan_>
wonder if that can still be changed
08:43
<jgraham>
annevk: Oh sorry. I seem to be subscribed to that repo so I can't tell when someone specifically pings me
08:45
<zcorpan_>
annevk: i think foolip tweeted it also
08:51
<annevk>
zcorpan_: hmm, Twitter search sucks or does Docs URLs are not stable
08:51
<annevk>
or are stable but duplicates exist
08:52
<zcorpan_>
https://twitter.com/foolip/status/664548364978008064
08:52
<zcorpan_>
seems his url ends with ?usp=sharing
09:31
<JakeA>
wanderview: it yeah seen as a performance issue due to updating .installing etc, and updating the registration value itself. But if you don't think it is… it'd be convenient
09:47
<annevk>
yoav: are you planning btw on updating <link rel>, <iframe sandbox>, etc. in HTML to make use of the supported tokens construct?
09:47
<yoav>
annevk: I plan to update <link rel>
09:49
<annevk>
ok
09:49
<annevk>
mkwst: you might want to update <iframe sandbox> I suppose
09:49
<annevk>
bz seems pretty keen on implementing in Gecko once the standard is in place
09:49
<yoav>
if it's a simple change I might update both, haven't looked at <iframe> just yet
09:55
<annevk>
Those seem like the only two for which this is applicable
09:55
<annevk>
Perhaps <a rel>/<area rel>, but user agents don't really do anything with those
09:58
<annevk>
jgraham: so the problem is mostly that opening new browsing contexts requires user interaction
09:59
<annevk>
jgraham: so any test would be a terrible manual test
10:00
<Ms2ger>
window.open()?
10:00
<annevk>
Ms2ger: yes
10:00
<Ms2ger>
Alternatively, webdriver in the future
10:00
<annevk>
sure
10:01
<Ms2ger>
But wpt tests can assume that window.open() works without user interaction
10:01
<annevk>
Ms2ger: oh they can, how?
10:01
<mkwst>
annevk: What is this?
10:02
<annevk>
mkwst: yoav landed a thing in DOM that allows DOMTokenList/DOMSettableTokenList to be used for feature testing, but it requires HTML to hook into the thing
10:02
<mkwst>
annevk: Oh.Ok, this is for feature detecting sandbox flag support?
10:03
<yoav>
mkwst: yeah. I plan to look into adding the corresponding parts into <link rel>
10:03
<annevk>
mkwst: yeah, and <link rel> values
10:03
<mkwst>
yoav: If you point me to whatever you added, I'm happy to add it to HTML. Or you can do it. Whatever. :)
10:03
<Ms2ger>
annevk, I think wptrunner should set a pref in Firefox, not sure how it's handled for other browsers
10:04
<yoav>
mkwst: I'll add it to <link rel> and see if it's not too much hassle to add to iframe as well. I'll ping you if I give up :)
10:06
<mkwst>
yoav: Excellent! /me delegates
10:09
<JakeA>
annevk: wikileaks.org and search.wikileaks.org are the same IP, would a MITM be able to tell the difference?
10:10
<jgraham>
annevk: window.open?
10:10
<jgraham>
Oh Ms2ger said all this
10:11
<jgraham>
wpt requires that you disable the popup blocker for the domain
10:11
<jgraham>
Otherwise you will get spurious results
10:16
<mkwst>
jgraham: Just wait until we specify the popup blocker's behavior.
10:16
<mkwst>
Test _that_. Muwahaha.
10:22
<jgraham>
Pretty sure after hearing what the web bluetooth people want you can't scare me anymore
11:16
<annevk>
JakeA: DNS lookups?
11:16
<botie>
I can't find that machine name
11:16
<annevk>
JakeA: but yeah, the hostname is transmitted in clear text
11:17
<annevk>
JakeA: that might go away at some point, maybe, but that would still leave DNS lookups I think
11:24
<JakeA>
annevk: ohh, I didn't realise that dns was clear text hmm.
11:25
<annevk>
JakeA: in TLS the host is also transmitted as clear text afaik
11:26
<annevk>
JakeA: the idea here is that the server can dispatch the request to the right process more easily that way, e.g., you don't need to have all the certificates available at the root or some such
11:27
<annevk>
JakeA: but still, I think that was poor judgment and it may or may not get fixed in TLSv13
11:27
<JakeA>
yeah, seems pretty leaky
11:38
<annevk>
JakeA: DNS is the worst, but fortunately there's HTTPS to save the day
11:38
<annevk>
And sometimes someone might utter DNSSEC, but they haven't read http://sockpuppet.org/blog/2015/01/15/against-dnssec/
11:39
<annevk>
Also, I don't think DNSSEC gives confidentiality
11:58
<gsnedders>
annevk: it doesn't. it merely gives a basis to trust the response.
12:40
<mkwst>
annevk: Very important question: what should `URLSearchParams('=').toString()` produce? What about `URLSearchParams('%e2').toString()`?
12:43
<mkwst>
Mozilla has an answer, but it seems strange.
12:44
<Ms2ger>
I think URLSearchParams('=').toString() === '=' per spec and Gecko
12:45
<mkwst>
Basically, I don't follow the logic of https://bugzilla.mozilla.org/show_bug.cgi?id=1032511 for '%e2', 'a%e2', 'a%e2b'.
12:48
<Ms2ger>
I think `URLSearchParams('%e2')` would give an internal list of [('%e2', '')]
12:48
<Ms2ger>
Oh wait
12:49
<Ms2ger>
[('=', '')]
12:49
<Ms2ger>
So I think it should serialize to '=='
12:49
<Ms2ger>
Which is not what Gecko does
12:54
<mkwst>
Chrome doesn't like `decodeURIComponent('%e2')`. Neither does Gecko, for that matter.
13:13
<annevk>
Parsing = leads to an empty pair, which when serialized becomes = afaik
13:16
<annevk>
%2e becomes "." afaict since the parser percent decodes
13:16
<annevk>
mkwst: Ms2ger: ^
13:17
<Ms2ger>
2e is =, no?
13:17
<Ms2ger>
The parser percent decodes after splitting on =
13:17
<mkwst>
e2. Not 2e.
13:18
<annevk>
Oh
13:18
<annevk>
Yeah, for that case == sounds reasonable
13:20
<annevk>
Sorry, %e2 is non-ASCII of course, not =
13:20
<annevk>
So the reason that fails is that E2 by itself is not valid UTF-8, so trying to decode it will get you a replacement code point
13:20
<annevk>
Which is why you get the '\ufffd=' serialization
13:21
<annevk>
mkwst: Ms2ger: ^
13:22
<mkwst>
Ok. It looks like Chrome is decoding it as ASCII, which seems potentially incorrect. :)
13:38
<zcorpan>
anyone know if http://stackoverflow.com/questions/30548399/filter-issues-on-github-that-will-be-closed-by-a-pull-request is possible?
13:41
<zcorpan>
maybe i can use assignee as workaround
13:42
<zcorpan>
though that means more spam plus a manual step
14:00
<mkwst>
annevk: I guess `URLUtils` is obsolete?
14:00
<annevk>
mkwst: yes
14:00
<mkwst>
Wunderbar. Do you intend to add `searchParams` to `HTTPAnchorElement`?
14:01
<mkwst>
Or, HTMLHyperlinkElementUtils rather.
14:10
<annevk>
mkwst: Firefox implements that at the moment, but I think it's cleaner if we keep it to URL
14:10
<annevk>
mkwst: because we cannot offer it for Location
14:11
<annevk>
mkwst: so instead of Location/WorkerLocation being the weird ones, seemed saner to make URL special
14:12
<mkwst>
I'm fine either way, I just need to know what I actually need to implement. :)
14:14
<annevk>
mkwst: just on URL
14:15
<mkwst>
ok. beautiful.
14:19
<Ms2ger>
annevk, do you know if anyone has written tests for https://github.com/whatwg/dom/commit/2920fc15b9e894c45ff84c5d3bb77f7513ff50e5 ?
14:20
<annevk>
Ms2ger: I suspect there are tests already given that bz found it, but haven't checked
14:20
<Ms2ger>
Ok
14:40
<smaug____>
annevk: CanvasRenderingContext2D.canvas is HTMLCanvasElement even in workers
14:40
<smaug____>
in the spec
14:41
<smaug____>
CanvasRenderingContext2D is exposed in workers, but HTMLCanvasElement isn't
14:41
<annevk>
smaug____: yeah so is any of that implemented and specified as folks want?
14:42
<annevk>
smaug____: I had the impression that we're still changing how to do canvas in workers
14:42
<smaug____>
I'm just reviewing a patch which implements this stuff
14:42
<smaug____>
in the patch it is readonly attribute CanvasObj? canvas;
14:42
<smaug____>
typedef (HTMLCanvasElement or OffscreenCanvas) CanvasObj;
14:43
<annevk>
smaug____: https://wiki.whatwg.org/wiki/OffscreenCanvas
14:43
<annevk>
smaug____: oh great
14:43
<annevk>
smaug____: I didn't realize folks were implementing that wiki page already
14:43
<annevk>
smaug____: or that it was done somehow
14:43
<annevk>
smaug____: none of this is integrated into HTML proper
14:44
<smaug____>
taiwan folks do all this great canvas and video worker stuff atm :)
14:44
<smaug____>
this will be behind a pref initial ofc
14:45
<annevk>
smaug____: that is pretty cool, but do we know whether this draft is stable? It's certainly not been hold to any kind of spec-writing scrutiny
14:45
<annevk>
"This proposal has been vetted by developers of Apple's Safari, Google's Chrome, Microsoft's Internet Explorer, and Mozilla's Firefox browsers. All vendors agreed upon the basic form of the API, so it is likely it will be implemented widely and compatibly."
14:45
<annevk>
I guess the wiki page is pretty confident it's all good
14:45
<smaug____>
roc has been involved with this stuff
14:45
<smaug____>
I'm just reviewing the .webidl bits
14:46
<smaug____>
looks like also Justin Novosad commented in the bug recently
14:50
<annevk>
Yeah, certainly seems like it's much further along than I thought
14:50
<annevk>
I figured they'd turn it into some PR at some point
14:50
<annevk>
Perhaps I should start asking about that now
16:24
<yoav>
zcorpan: around?
16:30
<zcorpan>
yoav: for a bit'
16:30
<yoav>
zcorpan: looks at adding the html bits for <link> relList
16:31
<zcorpan>
yoav: ok cool
16:31
<yoav>
I got:
16:31
<yoav>
<p>The IDL attribute <dfn><code data-x="dom-link-rellist">relList</code></dfn> <span
16:31
<yoav>
w-nodev>must</span> <span data-x="reflect">reflect</span> the <code
16:31
<yoav>
data-x="attr-link-rel">rel</code> content attribute. The <code data-x="supported tokens">supported tokens</code> for <code
16:31
<yoav>
data-x="dom-link-rellist">relList</code> include the rel values defined in <a>linkTypes</a>. Other specifications may add other supported
16:31
<yoav>
tokens</p>
16:32
<yoav>
which is total pseudo-code in many places where I don't know how to link :)
16:32
<yoav>
Could you take a look and tell me how to do what I'm trying to do?
16:33
<yoav>
e.g. how to link to things in the DOM spec?
16:33
<yoav>
how to link to linkTypes
16:33
<yoav>
and to dom-link-rellist
16:36
<zcorpan>
yoav: html has a Dependencies section where cross-spec terms are <dfn>ed
16:36
<Ms2ger>
And that's a crappy approach
16:36
<Ms2ger>
Doesn't html have real cross-spec links yet?
16:36
<yoav>
zcorpan: OK, thanks, I'll look into that
16:37
<zcorpan>
Ms2ger: nope
16:39
<zcorpan>
yoav: <span> for non-code xrefs
16:40
<yoav>
so, "<span>linkTypes</span>" ?
16:43
<zcorpan>
yes, or <span data-x="the-actual-xref-term-w00t">linkTypes</span>
16:44
<yoav>
ok, cool
17:34
<annevk>
I think link types is the only which requires <a>
17:34
<annevk>
We should probably clean that up at some point
18:57
<yoav>
annevk: https://github.com/whatwg/html/pull/340 is a first stab at adding the feature detection parts to html