02:12
<cluelesscoder>
so I figured why not read the HTML syntax spec... and it's been a bit tough reading. "If the current node is an HTML element whose tag name is subject" - what element has the tag name of subject?
02:28
<caitp>
reading the adoption agency algorithm?
02:28
<caitp>
the text of that one can pretty much be replaced with "dumbdumbdumbdumbdumbdumbdumbdumbdumb" with no difference in meaning
02:30
<caitp>
I mean you'd have to repeat that a few dozen times to really capture the same semantics, but basically
02:32
<caitp>
unfortunately html doesn't make the rules, it just writes them down
05:55
<MikeSmit1>
cluelesscoder: yeah that spec text doesn’t mean a tag named “subject”
05:56
<MikeSmith>
cluelesscoder: not literally “subject” but instead that’s a placeholder for whatever the actual tag name is, when that generic algorithm is called on that tag
06:38
<annevk>
https://github.com/whatwg/html/pull/1428#issuecomment-226282258 <3
10:45
<wanderview>
JakeA: what version of node are you using for this? https://github.com/jakearchibald/range-request-test
10:45
<JakeA>
wanderview: v6.2.1 - sorry, I just had to update node on one of my machines to get it working too
10:46
<wanderview>
JakeA: np... just thought I would ask instead of continuing to guess :-)
10:47
<JakeA>
wanderview: updated the readme. Didn't realise I was using new-node stuff when I originally built it.
10:47
<wanderview>
np
10:49
<wanderview>
JakeA: weird that brew only has node 5.x
10:53
<JakeA>
wanderview: lmk if it's getting in the way. I can probably avoid whatever feature that requires 6. I think it's the spread operator.
11:06
<wanderview>
JakeA: its fine... I do see the range header in the service worker... but we don't play the video in that case... so something is broken
11:06
<ondras>
annevk: CSP headers are relevant only to html resources, right?
11:07
<JakeA>
wanderview: but is the range header actually being sent? I don't see it in the server's log
11:07
<JakeA>
wanderview: https://bugs.chromium.org/p/chromium/issues/detail?id=620386
11:07
<annevk>
ondras: hmm ask mkwst
11:08
<annevk>
ondras: currently parsed for all though, maybe…
11:08
<wanderview>
JakeA: no... you found the error... its spec'd that way as far as I can tell: step 5 here https://fetch.spec.whatwg.org/#concept-headers-append
11:09
<JakeA>
wanderview: not sure how the range header appears on the request at all then
11:10
<wanderview>
JakeA: well, I think media probably does not go through the headers append algorithm in practice... but when you fetch I think we re-append headers, etc
11:10
<ondras>
mkwst: ?
11:10
<JakeA>
this seems like a similar issue to the client headers stuff. Maybe headers need the concept of "UA-added" meaning they bypass some of the checks +annevk
11:10
<wanderview>
JakeA: maybe we can just blame annevk
11:10
<ondras>
mkwst: CSP headers are relevant only to html resources, right?
11:10
<JakeA>
haha
11:10
<wanderview>
JakeA: he is not looking at his computer at the moment... I should probably pay attention to this meeting too
11:10
<JakeA>
wanderview: btw, pub this evening?
11:11
<wanderview>
JakeA: yes pleae!
11:11
<wanderview>
please
11:11
<JakeA>
\o/
11:20
<annevk>
JakeA: hmm I thought about that, but it seems bad from a security perspective
11:21
<annevk>
JakeA: trying to figure out what we are willing to do about that
11:21
<annevk>
JakeA: some of the institutional knowledge got lost
11:21
<JakeA>
annevk: we need to come up with a way to let things like Range headers through. At the moment event.respondWith(fetch(event.request)) breaks
11:22
<wanderview>
JakeA: I'm not sure it should from the spec... fetch header list should just be copied across from the original request
11:24
<wanderview>
JakeA: I think maybe firefox never provides the response back to the media element in fetch(event.request) case and exact range request
11:26
<annevk>
JakeA: 😞
11:27
<JakeA>
We'll give ourselves one pint to solve it later
11:27
<annevk>
JakeA: I will look into it next week I suppose
11:27
<annevk>
heh
11:28
<JakeA>
But I can't think of anything better other than "The UA may add headers that bypass filters" - because that's effectively what it already does
11:28
<wanderview>
JakeA: can you turn these into WPT tests? :-)
11:29
<JakeA>
Y'know what, it's been lovely to do a little bit of research on this stuff and have a think about standards. *dev-rel whip cracks* oh yeah gotta a get a talk ready
11:29
<JakeA>
wanderview: I'd be happy to do this. Not written one before though
11:30
<wanderview>
JakeA: would just be nice since you are half-way there and clearly there are some bugs here... might help the other browsers get it right the first time they do it too
11:30
<JakeA>
agreed
12:14
<tobie>
heycam: what's the status of the Java-specific stuff from within the spec?
12:14
<heycam>
tobie: it should all have been removed
12:14
<heycam>
a while ago
12:14
<tobie>
heycam: alright. Just wanted to make sure. :)
12:33
<gsnedders>
tobie: <3
13:06
<MikeSmith>
noticing https://www.linkedin.com/in/h%C3%A5vard-molland-45022b5
13:06
<MikeSmith>
Haavard Molland moving on
15:36
<MikeSmith>
https://twitter.com/myriamjessier/status/743412990138028032 “I went into a German conference on web components. I don't speak German. Here are my notes.”
22:34
<tobie>
TabAtkins: WebIDL has ednotes. What would you make those into in bikeshed? Issues?
22:35
<tobie>
TabAtkins: e.g.: http://heycam.github.io/webidl/#idl-callback-functions
22:35
<TabAtkins>
Ah, the "Editorial note"?
22:35
<TabAtkins>
Oh yeah, sorry, I was misreading as "endnotes"
22:35
<TabAtkins>
So yeah, issue.
22:36
<TabAtkins>
Either class=issue, or if you're taking advantage of markdown, just start a paragraph with "Issue: "
22:38
<TabAtkins>
Oh yeah, and newish thing: any webidl in a non-normative block (if it or an ancestor is class=example, class=note, or class=non-normative) will get syntax-highlighted but not linked up. So make sure all your IDL blocks have class=idl and either they or an ancestor has one of the non-normative classes.
22:39
<tobie>
TabAtkins: yeah, saw those improvements, that's awesome.
22:39
<tobie>
While I have your attention, what's your suggestion on how to deal with the grammar?
22:40
<tobie>
TabAtkins: i.e., this stuff: http://heycam.github.io/webidl/#prod-Definitions
22:41
<TabAtkins>
I don't have an abnf parser yet. (Mike West said he would work on it, BUT HE HAS FAILED TO.)
22:42
<TabAtkins>
So, uh, dunno.
22:42
<TabAtkins>
I'd say use type=type, as that's what we use for CSS grammar non-terminals, but maybe we don't want things to overlap?
22:43
<TabAtkins>
I'm wondering if a type=abnf would work, with a mandatory for='' value.
22:43
<TabAtkins>
To algorithm-scope it.
22:49
<tobie>
mmm
22:52
<tobie>
I guess I need to think about this some more.
22:58
<TabAtkins>
or i do
22:59
<TabAtkins>
just write it in a pre for now; i'll put "auto-parse abnf" on my roadmap for the near future
22:59
<TabAtkins>
it's not hard
22:59
<tobie>
I like where you're going with this. :)
23:00
<TabAtkins>
What, "do whatever the easiest thing is, I'll make the hard parts work automatically"?
23:00
<tobie>
yes
23:00
<tobie>
:)
23:00
<TabAtkins>
^_^
23:10
<TabAtkins>
Hmm, it looks like IDL is just using some ad hoc grammar convention.