08:37
<bblfish>
annevk: thanks for answering. Do you have a pointer to work on caching for the whole site?
08:39
<bblfish>
Also timbl made an interesting point: that if the browser made a HEAD instead of an OPTIONS on a GET preflight, then there would be a need for 1 less connection.
08:40
<bblfish>
mhh, but perhaps the reason for the 3 calls for me is that the browser first does a GET
08:41
<bblfish>
It's odd in chrome I always see the GET first, then OPTIONS. But I suppose that is just a display error.
08:44
<bblfish>
Yes, on my server I first see the GET, then then OPTIONS. Presumably because the GET returned a 401?
08:48
<bblfish>
but the GET has all the required headers.
09:20
<bblfish>
annevk: I got the whole order wrong of what was happening. So I rewrote the entry. https://github.com/solid/solid-spec/issues/52#issuecomment-157882202
09:22
<bblfish>
It actually looks like things might be perfectly efficient.
09:22
<bblfish>
at least for a GET, which should be the most usual case.
09:23
<bblfish>
It's just weird that a GET returning a 401 then is followed by an OPTIONS
09:27
<MikeSmith>
nice to see patches finally landing in gecko for <details>+<summary> https://bugzilla.mozilla.org/show_bug.cgi?id=591737#c96
09:40
<rits_>
hello everyone, i am glad to start working as an outreachy intern in whatwg, thanks for the opportunity :-)
09:40
<MikeSmith>
hi rits_
09:41
<MikeSmith>
your application was accepted?
09:42
<rits_>
MikeSmith: hello, yes it was accepted, was there any issue related to it?
09:42
<MikeSmith>
rits_: very cool
09:42
<MikeSmith>
that's great to hear
09:43
<MikeSmith>
no, no issues that I know of
09:43
<rits_>
MikeSmith: great, thanks :)
09:43
<MikeSmith>
and I didn't have anything to do with helping with it so far, but going forward I'm happy to help you when I can
09:44
<MikeSmith>
I just had a new baby born about a month ago, and still in the process of trying to figure out some new work-life balance around that
09:44
<MikeSmith>
right now my baby has mostly been winning :)
09:45
<MikeSmith>
as far as where I've been spending time
09:45
<rits_>
MikeSmith: yeah, i wanted to discuss about my further steps, i am starting with bugs according to the timeline i made
09:45
<MikeSmith>
ok
09:45
<annevk>
zcorpan: happy b-day! 🎂
09:45
<zcorpan>
annevk: thx!
09:45
<jgraham>
++
09:45
<rits_>
congrats for the baby :) MikeSmith
09:46
<jgraham>
++ to that too
09:46
<MikeSmith>
rits_: thanks :)
09:46
<MikeSmith>
zcorpan: felix navidad!
09:47
<rits_>
MikeSmith: baby would be winning around 1year of yours more :D
09:47
<jgraham>
MikeSmith: Out by about a month there :)
09:47
<rits_>
zcorpan: Happy b'day :)
09:48
<MikeSmith>
rits_: yeah but I need to get better skilled at squeezing in more work between baby time
09:48
<rits_>
MikeSmith: yeah if the baby allows you
09:48
<MikeSmith>
yeah
09:48
<MikeSmith>
rits_: as far as next steps I think it's just "more of what you already did"
09:49
<MikeSmith>
you already landed at least one spec change, right?
09:49
<rits_>
MikeSmith: yeah i did
09:50
<zcorpan>
thx. and congrats MikeSmith :-)
09:50
<MikeSmith>
rits_: ok, so far as I know it's up to you to decide what bugs to work on next or where else to put your time
09:51
<rits_>
MikeSmith: yes i will resolve the critical issues first,
09:52
<annevk>
rits_: indeed, you can make up your own schedule, but also, to be clear, at this point you're not expected to do anything
09:53
<annevk>
rits_: I believe the internships starts with the week in Orlando and will last three months or so from that point
09:53
<annevk>
rits_: having said that, if you want to contribute now, that's perfectly fine and appreciated :-)
09:54
<rits_>
annevk: yeah ok, then i will try to learn about solving the issues till then, this time can be utilized for that
09:54
<annevk>
bblfish: there may or may not be an open issue or bug against Fetch
09:54
<annevk>
bblfish: not sure
09:55
<bblfish>
annevk: I rewrote the entry, it looks like everything is fine, except for the weirdness that an OPTIONS follows a GET with CORS headers
09:55
<rits_>
annevk: i will work both ways :), will contribute in parallel with working according to the timeline,
09:56
<yoav>
annevk: regarding your "this should not use <code>" comment, did you refer to the "supported tokens"?
09:56
<annevk>
yoav: yes
09:56
<yoav>
OK, thanks
09:56
<annevk>
bblfish: hmm, are you sure something is not cached?
09:56
<annevk>
bblfish: sounds very fishy
09:56
<annevk>
rits_: \o/
09:56
<bblfish>
I'll make a new resource
09:57
<rits_>
annevk: :-)
09:57
<bblfish>
To mee it sounds brillant though :-)
10:01
<yoav>
annevk: addressed your comments
10:02
<annevk>
yoav: so instead of <code> you want to use <span>
10:02
<annevk>
yoav: and the sandbox entry needs to be consistent with that of course
10:02
<yoav>
Oh, OK
10:03
<yoav>
that's what I was missing :)
10:03
<annevk>
yoav: it also seems that the xref for "the sandbox attribute" is wrong
10:04
<annevk>
yoav: you want to xref just "sandbox", as <code data-x="attr-iframe-sandbox">
10:05
<yoav>
annevk: OK, fixed
10:06
<annevk>
yoav: is the xref for supported tokens not still wrong?
10:07
<annevk>
yoav: and it's still inconsistent with sandbox, where you use <code>
10:07
<yoav>
yeah, just saw that
10:07
<yoav>
fixing it
10:07
<annevk>
yoav: using a separate paragraph for relList's DOMTokenList's supported tokens might be good too
10:07
<annevk>
yoav: to make them completely identical
10:08
<annevk>
yoav: oh, and "the sandbox attribute" is not fixed yet
10:09
<yoav>
separated relList to its own <p>
10:10
<yoav>
what is still wrong with the sandbox attribute?
10:10
<yoav>
annevk: should it be <code>? should it just xref "sandbox"?
10:11
<annevk>
yoav: yes and yes
10:11
<yoav>
OK
10:11
<annevk>
When in doubt, just look at what the rest of HTML does
10:13
<annevk>
yoav: also, the second 's doesn't seem to make sense for the sandbox sentence...
10:13
<yoav>
so:
10:13
<yoav>
<p>The <span data-x="dom-domtokenlist-supported-tokens">supported tokens</span>
10:13
<yoav>
for <code data-x="sandbox">sandbox</code>'s <code>DOMSettableTokenList</code>'s are
10:13
<yoav>
the allowed values defined in <code data-x="sandbox">the sandbox attribute</code>
10:13
<yoav>
and supported by the user agent.</p>
10:14
<zcorpan>
s/'s are/ are/
10:15
<annevk>
yoav: hmm, no
10:15
<zcorpan>
data-x="attr-iframe-sandbox" i think?
10:15
<annevk>
yoav: "the <code data-x="attr-iframe-sandbox">sandbox</code> attribute"
10:15
<annevk>
yoav: is what the rest of HTML does, as far as I can tell
10:16
<annevk>
Hmm, Twitter is done?
10:16
<annevk>
down, even
10:17
<yoav>
<p>The <span data-x="dom-domtokenlist-supported-tokens">supported tokens</span>
10:17
<yoav>
for <code data-x="attr-iframe-sandbox">sandbox</code>'s <code>DOMSettableTokenList</code> are
10:17
<yoav>
the allowed values defined in <code data-x="attr-iframe-sandbox">the sandbox attribute</code>
10:17
<yoav>
and supported by the user agent.</p>
10:20
<annevk>
yoav: shouldn't the first sandbox reference the IDL attribute? The second is still not as I quoted it
10:22
<yoav>
<p>The <span data-x="dom-domtokenlist-supported-tokens">supported tokens</span>
10:22
<yoav>
for <code data-x="dom-iframe-sandbox">sandbox</code>'s <code>DOMSettableTokenList</code> are
10:22
<yoav>
the allowed values defined in the <code data-x="attr-iframe-sandbox">sandbox</code> attribute
10:22
<yoav>
and supported by the user agent.</p>
10:22
<yoav>
OK, sorry for missing that
10:24
<yoav>
annevk: OK, pushed that latest version. Gotta go now, but let me know if there are any further issues
10:27
<annevk>
Hmm, I wish I'd know earlier he was in a hurry
10:27
<annevk>
known*
10:37
<annevk>
I wonder how html/browsers/origin/cross-origin-objects/cross-origin-objects.html ever landed since it hardcodes domain names
10:37
<annevk>
Seems like Ms2ger might have reviewed that
10:38
<annevk>
jgraham: would the best course of action here be to rename the files to include .sub and make the appropriate modifications?
10:38
<annevk>
jgraham: or first land a rename commit and then make modifications?
10:43
<annevk>
Well, I'll just do my best to get them fixed...
10:48
<jgraham>
annevk: Fix and rename in one step seems fine
10:49
<Ms2ger>
Hrm, I didn't notice that bit
10:53
<annevk>
jgraham: https://github.com/w3c/web-platform-tests/pull/2360
10:53
<annevk>
Ms2ger: ^
10:53
<annevk>
Running that locally makes Firefox still pass all tests
10:54
<annevk>
jgraham: how is it clear btw what is test and what are support files?
10:54
<annevk>
that doesn't really seem indicated in that test
10:54
<Ms2ger>
"includes testharness.js"
10:54
<Ms2ger>
I don't think '//{{domains[www1]}}:' + location.port is right
10:54
<Ms2ger>
jgraham, ^
11:04
<annevk>
Ms2ger: why would that be wrong?
11:23
<jgraham>
Well I would usually write {{ports[http][0]}} unless that wasn't what was required
11:24
<zcorpan>
jgraham: {{GET[foo]}} in .sub.html escapes &, but doesn't escape "?
11:25
<zcorpan>
jgraham: this makes it impossible to use literal &quot; (in attribute value)
11:27
<jgraham>
zcorpan: Hmm, it uses cgi.escape
11:28
<zcorpan>
If it is used as cgi.escape(string_to_escape, quote=True), it also escapes ". https://wiki.python.org/moin/EscapingHtml
11:28
zcorpan
lunch
11:30
<jochen__>
annevk, is "content attribute" a defined term?
11:30
<jgraham>
zcSounds reasonable if it doesn't break anything
11:30
<jochen__>
annevk: i.e. should I reference some spec for it, or just write "content attribute"?
11:31
<MikeSmith>
annevk: with the changes Hixie made on the whatwg.org host does that now mean it's possible to get https://lists.whatwg.org/pipermail/whatwg-whatwg.org URLs working
11:40
<Ms2ger>
jochen__, there's a definition you can link to, I believe
11:41
<Ms2ger>
Hrm
11:42
<Ms2ger>
jochen__, nevermind, there's a definition, but it doesn't get an ID for some reason
11:42
<jochen__>
kk
11:42
<Ms2ger>
https://html.spec.whatwg.org/multipage/infrastructure.html#terminology
11:42
<Ms2ger>
annevk, ^
11:52
<annevk>
MikeSmith: that still depends on DreamHost enabling HTTPS support for hosted email lists
11:52
<MikeSmith>
ah OK
11:52
<MikeSmith>
I thought they told you they were going to do that
11:52
<MikeSmith>
or something
11:53
<annevk>
jgraham: wouldn't you just want to reflect the port in use typically?
11:53
<annevk>
MikeSmith: no, unfortunately not
11:53
<MikeSmith>
ah
11:58
<jochen__>
annevk, hope I've addressed all your comments on the referrerPolicy IDL thing
11:59
<jgraham>
annevk: I guess that's also fine if it's what you want
11:59
<jgraham>
It depends if you already using script or not
11:59
<jgraham>
If you are then using location.port isn't too bad. If you are trying to write a href attribute or stylesheet or something, that doesn't work
12:00
<annevk>
jochen__: looks more reasonable now
12:00
<annevk>
jgraham: this already uses script, I've used {{location[port]}} for the other cases in recently submitted PRs
12:03
<jgraham>
annevk: Yeah, it isn't a problem afaik
12:30
<Ms2ger>
Suddenly, <details> support in Gecko
12:37
<nox>
Interesting.
12:37
<odinho>
boom
12:54
<zcorpan>
jgraham: is it https://github.com/w3c/wptserve/blob/b6b082fb70c592c6164c76aa167ae4dc284ebb69/wptserve/pipes.py#L422 ?
13:00
<jgraham>
zcorpan: Yes
13:04
<catalinb>
JakeA: ping
13:07
<JakeA>
catalinb: morning!
13:08
<catalinb>
JakeA: hey. I need some help understanding something regarding SW registrations. Do you have a few minutes?
13:13
<JakeA>
catalinb: sure, although I'm on my phone so my debugging is limited
13:14
<catalinb>
JakeA: okay, so we have a sequence of two register calls for the same scope with two different scripts. The first service worker script will reject the install handler after some.
13:15
<catalinb>
JakeA: can the following sequence happen?
13:15
<catalinb>
1. call register() number two which will invoke Get Registration and find the registration created by the previous call
13:16
<catalinb>
2. the install handler from the first sw rejects and ends up clearing the registration and thus removing it from the registration map
13:16
<catalinb>
3. continue updating (from the second register call) with a registration that's not in the registration map
13:20
<catalinb>
JakeA: does it make sense?^
13:21
<JakeA>
catalinb: sounds like a bug, which could be a spec bug. Hang on, let me dig into the spec (it's 5am here so expect slowness)
13:23
<catalinb>
thanks! and sorry for bothering you so early in the morning :)
13:29
<JakeA>
catalinb: at what point is register 1 at when register 2 is invoked?
13:30
<zcorpan>
jgraham: https://github.com/w3c/wptserve/pull/68 - it does what i want but i don't know if some existing test relies on not escaping ". it seems unlikely though
13:34
<catalinb>
JakeA: register 2 is called while waiting for the first sw to reject the install waitUntil promise.
13:36
<catalinb>
at this point the registration is in the map
13:37
<catalinb>
We then get to Step 4.1 from Update Algorithm which is called in parallel
13:39
<catalinb>
I think this can race with steps 13-18 from "Install Algorithm" for the first service worker
13:41
<JakeA>
catalinb: is the race solved by https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#dfn-registration-queue-adt
13:41
<smaug____>
oh, I just realized Gecko does something very different to what the spec says with pushState/replaceState. Hmm, spec seems to have yet another bug there, but whether Gecko is sane...dunno
13:43
<catalinb>
JakeA: well no, because the first service worker's timestamp was already popped from the registration queue
13:43
<smaug____>
(or maybe it isn't that bad)
13:45
<JakeA>
catalinb: so 4.2 is hit at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#update-algorithm - the installing worker is terminated. When is the registration removed from the map?
13:47
<catalinb>
JakeA: at 16.3 at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#installation-algorithm
13:47
<catalinb>
before 4.2 is hit
13:48
<catalinb>
this is possible since 4.2 from Update is not reached atomically from Register
13:48
<JakeA>
Ahhhh so registration 1 rejects itself, I thought it was being rejected because reg2 terminated it
13:49
<JakeA>
Following now
13:50
<JakeA>
catalinb: yeah, I don't think this should happen. Can you file a bug?
13:50
<catalinb>
yup.
14:06
<zcorpan>
argh when will i learn to git add before git commit --amend
14:09
<roc>
just use -a a lot and try to pretend the index doesn't exist
14:12
<smaug____>
Why TokenList validation steps convert to lowercase ascii?
14:20
<smaug____>
in all the cases
14:20
<smaug____>
looks odd
14:20
<smaug____>
oh well, not going to care about this
14:52
<gsnedders>
is there any telemetry for % of users with user stylesheets?
14:53
<jgraham>
I don't know, but I would guess it's very very low
14:53
<gsnedders>
This is the obvious answer. :)
15:01
<Ms2ger>
Does Stylish count?
15:04
<gsnedders>
Ms2ger: I'm going for yes
15:04
<Ms2ger>
amo says ~600000 users
15:04
<Ms2ger>
That's still very low, of course
15:23
<Ms2ger>
> W3C Invites Implementations of XSL Transformations (XSLT) Version 3.0
15:24
<gsnedders>
hey, I'm sure there will be implementations!
15:24
<gsnedders>
…just not in browsers
15:53
<caitp>
heycam|away|away / annevk / whoever: is it a good idea to ship DOM @@iterator stuff in the state they're in (with inconsistencies between certain iterable DOM interfaces), or should more time be spent poking and prodding people to make them consistent
15:53
<caitp>
eg window[@@iterator] vs NodeList.prototype[@@iterator]
15:53
<annevk>
caitp: I think bz would prefer some more prodding
15:54
<caitp>
I'd prefer some more modding too it just doesn't look like it's been happening
15:54
<annevk>
caitp: there's not much folks working actively on IDL
15:54
<annevk>
so it's always a bit behind the facts
15:54
<caitp>
:(
15:57
<caitp>
on the one hand, it would be nice to ship now, on the other hand, might be hard to fix things later if they do ever change
15:57
<annevk>
maybe run it by bz?
15:57
<caitp>
does he hang out here? I don't spend a lot of time on public-script-coord etc
15:57
<annevk>
see /msg
15:58
<annevk>
jgraham: so can I merge https://github.com/w3c/web-platform-tests/pull/2360?
16:21
<Ms2ger>
No
16:21
<Ms2ger>
(I beat you to it :))
16:23
<annevk>
ta
17:20
<annevk>
mkwst: did you look at the latest in https://github.com/whatwg/html/pull/323 very recently?
17:20
<annevk>
mkwst: would appreciate review
19:22
<mkwst>
annevk: Sorry, was out this afternoon. Will look at the PR tomorrow morning. :)
20:32
<emerson>
https://gist.github.com/emersonveenstra/f79807307abae9a16401 with this document, would Baz be a subsection of Bar?