06:01
<annevk>
rcombs: I learned recently that even basic HTTP range support in Gecko is not great
06:01
<annevk>
rcombs: e.g., no support for multiple ranges in the cache
06:02
<rcombs>
not a single implementation I'm aware of even parses the Accept-Ranges header per the spec
06:02
<rcombs>
they all shortcut it in some way
06:05
<annevk>
Yeah, so it seems unlikely they're interested at this point in complicating their setup
06:06
<annevk>
It's usually a good idea to try to improve interoperability of the current situation, before adding new features
06:06
<annevk>
E.g., by contributing to web-platform-tests
06:10
<annevk>
miketaylr: https://github.com/Fyrd/caniuse/issues/1768 :-/
08:03
<annevk>
JakeA: https://github.com/whatwg/fetch/issues/93
08:16
<annevk>
MikeSmith: https://github.com/whatwg/platform.html5.org/pull/11
08:16
<annevk>
MikeSmith: any ideas?
08:16
<annevk>
MikeSmith: I think we should just have one link for Media Queries
08:18
<MikeSmith>
annevk: I agree with you
08:18
<MikeSmith>
About the caniuse thing, he needs to talk to Fyrd I guess
08:18
<MikeSmith>
and I wish him luck
08:19
<annevk>
Yeah, no luck for being mean on prefixes
08:59
<annevk>
Going to retweet that ReSpec advice from @WHATWG since that's been the unofficial motto of this channel for years
09:13
<annevk>
MikeSmith: I updated a whole bunch of old links in platform.html5.org
09:13
<annevk>
MikeSmith: and merged four PRs
09:14
<annevk>
oh, looks like there's another 3 PRs, I guess I can do those too
10:05
<JakeA>
annevk: ta, will pick this up now. Back in the country fightin' jetlag
10:05
<annevk>
JakeA: hehe
10:06
<annevk>
JakeA: seems like you had a good conference
10:07
<JakeA>
annevk: yeah, one of the best tbh (and took a couple of days to explore Austin) - shame you weren't there
10:08
<annevk>
Could maybe try next year. I didn't know about it and would've been somewhat impossible with my partner being abroad at the moment
10:55
<JakeA>
annevk: <link rel="preload" href="/blah" as="image"> - does this have a context of image or preload?
11:13
<s_bash>
\who
11:41
<s_bash>
\part
11:41
<s_bash>
\quit
12:07
<annevk>
JakeA: undefined
12:46
<MikeSmith>
annevk: thanks (platform.html5.org PRs)
12:47
<annevk>
MikeSmith: there's a new one if you're up for it
12:48
<MikeSmith>
ook will check
13:51
<annevk>
JakeA: you can't distinguish <form> from <a> for a whole bunch of cases
13:51
<annevk>
JakeA: I like your general setup though
13:51
<annevk>
JakeA: some merger of that and what igrigorik proposed seems reasonable
13:52
<JakeA>
annevk: when would you want to distinguish the two?
13:52
<annevk>
JakeA: for CSP
13:52
<JakeA>
annevk: yeah, that's why I said CSp would need a bit for form submission. Although I wish they'd just redefine in terms of what the page can post/get
13:52
<annevk>
JakeA: it's not entirely clear to me why https://w3c.github.io/webappsec/specs/content-security-policy/#directive-form-action exists, mind you, but it does...
13:53
<JakeA>
hah
13:53
<JakeA>
snap
13:53
<annevk>
It's the only value that tries to tackle navigation and does it poorly...
13:54
<annevk>
JakeA: so navigation you'd discover through request.clientType === "document"
13:55
<JakeA>
annevk: or "child-document"
13:55
<annevk>
oh
13:55
<annevk>
perhaps that should be a distinct axis? the nesting...
13:56
<JakeA>
yeah, probably, was trying to avoid a new thing that only applied to documents, but maybe isTopLevel makes a return
13:57
<annevk>
I guess it's either that or isNavigation makes a return
13:57
<annevk>
meh
14:02
<JakeA>
annevk: for what it's worth, given the use case of showing a fallback page, I probably wouldn't want that for iframes
14:40
<annevk>
JakeA: what if it's a third-party iframe?
14:41
<JakeA>
annevk: hmm, yeah, I guess in that case I'd do the same as if I was opened as top-level (thinking of disqus)
14:41
<annevk>
or youtube.com
14:42
<JakeA>
yeah
14:45
<annevk>
So if that's the use case you probably want some context about your ancestors
14:46
<annevk>
Maybe pass on ancestorOrigins
14:46
<annevk>
Or only use "nested-document" when same-origin... Otherwise "document"
14:47
<annevk>
But that seems ugly
15:07
<miketaylr>
annevk: "Having to use a prefix is a minor inconvenience"... short term thinking there.
15:15
<annevk>
yeah I don't even
15:21
<beverloo>
annevk, updated the PR. It'll take another iteration, sorry :)
15:21
<beverloo>
annevk, also, Chrome now returns a Promise for requestPermission(). I'm sending out a PSA later today
15:21
<annevk>
heh that was quick
15:22
<beverloo>
It's a trivial change
15:22
<annevk>
review might have to wait until Monday
15:22
<beverloo>
No worries, nobody implements this yet
15:22
<beverloo>
I'm on holiday from Wednesday until the 24th btw
15:23
<annevk>
nice
16:29
<ccardona-work>
Good morning WHATWG crew o/
18:35
<TabAtkins>
SimonSapin (or others who might know): Rust does function overloading on return type as well as argument types. How does it handle functions called only for their side effects, whose return values aren't assigned to anything? Do you have to declare your function as such?
18:42
<TabAtkins>
SimonSapin: Never mind, I found it - you return () if you don't declare anything, and are treated as assigning to a () type if you call as a statement.
21:33
<SimonSapin>
TabAtkins: There is no overloading, but the return type can be generic. If there is not enough context to infer the concrete type for a given call, it’s a build error and you need to add some type annotations.
21:38
<SimonSapin>
TabAtkins: str::parse is such a function: http://is.gd/o2gEG1 http://doc.rust-lang.org/std/primitive.str.html#method.parse
23:34
<Domenic>
annevk_ or otherwise: anyone know where exactly HTML monkey-patches ES to override the global `this` binding?
23:49
<TabAtkins>
SimonSapin: "overloading" is exactly what Rust does, unless you're being pedantic. Multiple definitions of the same function, distinguished by their signatures.