14:35
<annekv>
GPHemsley: why does MIME need to reference Fetch?
14:36
<annekv>
GPHemsley: custom about URLs lead to a network typically, ... I guess I should allow certain arbitrary identifiers to resolve there provided they're documented.
15:50
<GPHemsley>
annevk: It doesn't need to, necessarily; it just seems like mimesniff and fetch are gently brushing up against each other, so it might be worth connecting them
16:20
<ambv>
gsnedders: if it was a duplicate then I did it fail for PullDOM and the other didn't?
16:20
<ambv>
*then how did it
17:04
<gsnedders>
ambv: That's a more worrying question.
17:27
<gsnedders>
ambv: "<!DOCTYPE html><html xml:lang=bar><html xml:lang=foo>" in test14.dat should be failing. Why isn't it?
17:27
<gsnedders>
ambv: (Rhetorical question!)
17:28
<gsnedders>
ambv: Because doctypes aren't supported by PullDOM.
17:34
<ambv>
OK. I get it.
18:46
<GPHemsley>
hmm... if I run all the mimesniff stuff through the filter of the 'parse a MIME type' algorithm, I can sidestep any issues with terminology or existing specs...
18:47
<GPHemsley>
(I can create something like a "MIME type object" to use spec-internally)
18:47
<GPHemsley>
(is this where APIs come from?)
18:47
<GPHemsley>
(or where WebIDL is used?)
18:53
<GPHemsley>
I don't remember if I knew about RFC 6838 (the latest incarnation of BCP 13, released in January 2013) before...
18:53
<GPHemsley>
("Media Type Specifications and Registration Procedures")
21:19
<GPHemsley>
Hixie: Do nested browsing contexts have separate security concerns from top-level browsing contexts when it comes to sniffing MIME type?
21:35
GPHemsley
wonders what to do in situations where an <img> element loads "single-page vector documents (single-page PDFs, XML files with an SVG root element)" or "animated vector graphics (XML files with an SVG root element that use declarative SMIL animation)"...
21:37
<GPHemsley>
"In particular, img elements should not be used to display transparent images" – shouldn't that be "wholly transparent"?