| 00:18 | <annevk> | "We don't want the Web to be a bunch of cordoned-off apps." I wonder if Jeff Jaffe heard of SysApps. |
| 00:51 | <karlcow> | http://www.w3.org/QA/2013/05/perspectives_on_encrypted_medi.html |
| 00:52 | <zewt> | uninteresting |
| 00:53 | <karlcow> | Thus Spoke Zarathustra |
| 00:55 | <zewt> | i find it hard to believe anyone arguing for drm in an open web (an obviously fundamental incompatibility) doesn't have a personal stake in the matter, and arguing against it is, well, obvious; so arguments on both sides are uninteresting to me |
| 00:57 | <zewt> | (it's also an ancient argument, not significantly changed by the web context, so I'd be surprised if there's any new content in it this time around) |
| 09:44 | <jgraham> | Ms2ger: Yes, I think I agree with your reading of the spec |
| 09:47 | <Ms2ger> | Thanks :) |
| 11:04 | <hsivonen> | http://www.w3.org/QA/2013/05/perspectives_on_encrypted_medi.html#c4842306 |
| 12:19 | <Ms2ger> | jgraham, do you know if Opera has tests for form.foo? |
| 12:21 | <jgraham> | Ms2ger: I don't know |
| 12:21 | <jgraham> | I might remember to look later |
| 12:21 | <Ms2ger> | I would be grateful if you could |
| 12:22 | <Ms2ger> | Our code for that is so full of suck... :/ |
| 12:41 | <Ms2ger> | Consider http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2245 |
| 13:05 | <GPHemsley> | Is there precedent (that I can look at) for using ABNF in WHATWG specs? |
| 13:06 | <darobin_> | GPHemsley: yes, but no one has lived to tell the tale |
| 13:07 | <Ms2ger> | Does http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#publickeyandchallenge count as abnf? |
| 13:09 | <MikeSmith> | Ms2ger: seems like it ise |
| 13:09 | <MikeSmith> | eh or does ABNF use braces? |
| 13:10 | <GPHemsley> | I was referring specifically to RFC 5234: http://tools.ietf.org/html/rfc5234 |
| 13:10 | <MikeSmith> | there was some other ABNF in the spec |
| 13:10 | <MikeSmith> | maybe still there |
| 13:10 | MikeSmith | tries to remember what |
| 13:13 | GPHemsley | also wonders if he should distinguish between "well-formed" MIME types and "valid" MIME types |
| 13:13 | <MikeSmith> | GPHemsley: that sounds odd |
| 13:14 | <MikeSmith> | I'd wonder who cares about the distinction |
| 13:14 | <MikeSmith> | not implementors |
| 13:14 | <GPHemsley> | k |
| 13:14 | <GPHemsley> | in other news, there is no .abnf class in the spec CSS file |
| 13:15 | <MikeSmith> | so I guess whatever other ABNF Hixie had in the there before, it's gone now |
| 13:16 | <MikeSmith> | ah I remember |
| 13:16 | <MikeSmith> | it was for the text content of script elements |
| 13:16 | <MikeSmith> | or maybe style elements |
| 13:16 | <MikeSmith> | can't remember which |
| 13:17 | <jgraham> | If you think you want to use ABNF you are probably doing it wrong |
| 13:17 | <darobin> | definitely |
| 13:17 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements |
| 13:17 | <MikeSmith> | that is BNFish still |
| 13:18 | <GPHemsley> | that is precisely the ABNF I was referring to |
| 13:18 | <MikeSmith> | ah OK |
| 13:18 | <GPHemsley> | though I note it doesn't have special styling |
| 13:18 | <GPHemsley> | MikeSmith: Thanks for finding it |
| 13:19 | <GPHemsley> | jgraham, darobin: Care to elaborate/enlighten? |
| 13:19 | <darobin> | GPHemsley: ABNF is fine for describing things like valid document constraints |
| 13:19 | <MikeSmith> | yeah that's the case here |
| 13:19 | <darobin> | but it tends to suck if what you want is to describe implementation behaviour |
| 13:20 | <MikeSmith> | it's not defining parsing here |
| 13:20 | <darobin> | GPHemsley: as MikeSmith says, you *don't* want it to define parsing rules |
| 13:20 | <MikeSmith> | well it also suck if you have to write a parser based on it anyway |
| 13:20 | <darobin> | but it's good to describe constraints on content |
| 13:20 | <MikeSmith> | I did have to write a parser for the validator based on that ABNF |
| 13:21 | <MikeSmith> | and it was was PITA |
| 13:21 | <darobin> | yeah |
| 13:21 | <darobin> | supposedly you could generate one |
| 13:21 | <MikeSmith> | right, in theory |
| 13:21 | <GPHemsley> | in your defense, though, it has rules like "any string that doesn't contain a substring that matches not-data1" |
| 13:21 | <darobin> | but I've never seen a tool that really worked well for the languages I was interested in |
| 13:21 | <MikeSmith> | darobin: yep, I tried that in this case but gave up after running into nothing but fail |
| 13:22 | <darobin> | had the same problem with WebIDL |
| 13:22 | <darobin> | ended up hand rolling because none of the generators made any sense |
| 13:22 | <GPHemsley> | Well, the alternative is to have something like this, which seems like overkill: http://mimesniff.spec.whatwg.org/#parse-a-mime-type |
| 13:23 | <darobin> | GPHemsley: if you want to constrain how an implementation behaves, and you want error handling, you need stuff like that |
| 13:23 | <GPHemsley> | Also, I'm currently using the hodgepodge definition from HTTP to define what a MIME type is: http://mimesniff.spec.whatwg.org/#valid-mime-type |
| 13:23 | <MikeSmith> | we could just replace that ABNF with something based on the state-machine code I wrote for it in the validator. And then Hixie could run that through his pre-processor that turns the code into semi-prose. |
| 13:24 | <jgraham> | GPHemsley: There are two valid approaches for speccing parsing algorithms that I have seen: explicit state machines and prose recursive descent parsers |
| 13:24 | <MikeSmith> | I much prefer http://mimesniff.spec.whatwg.org/#parse-a-mime-type even if/when it seems like overkill |
| 13:24 | <GPHemsley> | If I rewrite the definition of "valid MIME type" and related terms using my own ABNF, it would simplify the definitions (and the dependencies) and I think it would making defining parsing easier |
| 13:25 | <MikeSmith> | hmm |
| 13:25 | <MikeSmith> | it would not make it easier to implement man |
| 13:25 | <jgraham> | Most of the difficulty in parsing is handling edge cases |
| 13:25 | <GPHemsley> | I don't think it would make it any harder, either, though |
| 13:26 | <MikeSmith> | well only one person has to define the parsing behavior, so optimizing the spec to make things easier for one person doesn't seem like such a great plan |
| 13:26 | <GPHemsley> | I do wonder what makes it difficult, though |
| 13:26 | <MikeSmith> | browser implementors at least are very happy without ABNF and with state-machine-type definitions instead |
| 13:27 | <MikeSmith> | IETFers are a different story of course |
| 13:27 | <GPHemsley> | but ABNF can be used to define state machines, can't it? |
| 13:27 | <MikeSmith> | GPHemsley: look back at what darobin said |
| 13:27 | <MikeSmith> | especially about handling errors |
| 13:28 | <GPHemsley> | What I have in mind is something like "if it doesn't match ABNF-A, do X" |
| 13:28 | <MikeSmith> | hmm |
| 13:29 | <GPHemsley> | I don't plan to just say "here's the ABNF, bye" |
| 13:29 | <MikeSmith> | as somebody who may need to be implementing parsing for this, I would not like that much |
| 13:29 | <MikeSmith> | that's kind of the worst of both worlds |
| 13:29 | <MikeSmith> | I think you are likely to make everybody even less happy with that than now |
| 13:30 | <jgraham> | Yeah, unless there is exactly one error path, and even then, that sounds horrendous |
| 13:30 | <GPHemsley> | but isn't it essentially just a regexp? |
| 13:31 | <jgraham> | No actual browser when confronted with parsing problem thinks "hey, I know, I'll use regexps" |
| 13:31 | <Ms2ger> | Actually... |
| 13:32 | jgraham | suddenly becomes very afraid of the Gecko code |
| 13:32 | <GPHemsley> | ^_^ |
| 13:32 | <Ms2ger> | :D |
| 13:33 | <GPHemsley> | OK, so, then I have to ask: Do you all take issue with "valid MIME type" as it's currently defined? |
| 13:33 | <jgraham> | But seriously, bonsai or it didn't happen |
| 13:33 | <GPHemsley> | The link again: http://mimesniff.spec.whatwg.org/#valid-mime-type |
| 13:34 | <GPHemsley> | " A valid MIME type is a media-type, as defined in HTTP/1.1 or its successor, and is made up in part by a type and a subtype. The MIME type portion of a valid MIME type is the string represented by concatenating type, the string "/", and subtype. [HTTP] |
| 13:34 | <GPHemsley> | The MIME type portion of a valid MIME type excludes all parameters and is case-insensitive. [HTTP] " |
| 13:34 | <GPHemsley> | That's the part that I'm planning to replace with ABNF |
| 13:34 | <jgraham> | (I guess for the past half decade or so I mean mxr, but bonsai sounded better) |
| 13:34 | <GPHemsley> | heh |
| 13:35 | <GPHemsley> | I was like, "Do we really need to go back to CVS for this?" |
| 13:36 | <MikeSmith> | GPHemsley: making something essentially be a regexp is not a great goal. We have some code in the validator for parsing <time> that is an actual regexp where we do capturing groups and then check to see which capturing-group matches failed. i.e., pretty much what you've described |
| 13:36 | <MikeSmith> | and it's nasty |
| 13:36 | <GPHemsley> | Hmm |
| 13:36 | <GPHemsley> | OK |
| 13:36 | <Ms2ger> | jgraham, I guess I was thinking about pattern="" calling into the JS engine, which is kinda something else |
| 13:36 | <GPHemsley> | can you point me to a pretty example, then? :) |
| 13:37 | <jgraham> | Ms2ger: Right, in that case the input is a regexp, so there's not that much choice |
| 13:38 | <jgraham> | Obviously pattern should have taken BNF |
| 13:40 | <darobin> | GPHemsley: the thing is, in most cases you can't have isABNF || error() |
| 13:40 | <darobin> | what you want is ABNFConstruct1 || error1(), ABNFConstruct2 || error2(), etc. |
| 13:40 | <darobin> | actually if we had a language that did that nicely it could be sweet |
| 13:40 | <GPHemsley> | Well, yeah. I plan to use multiple ABNF rules |
| 13:41 | <darobin> | GPHemsley: at some point you're getting very close to prose then :) |
| 13:41 | <GPHemsley> | Perhaps I should just write it and let you all criticize it after the fact :P |
| 13:44 | <darobin> | GPHemsley: that's the right attitude :) |
| 14:33 | <GPHemsley> | Do WHATWG specs generally have abstracts? |
| 14:36 | <darobin> | GPHemsley: some do, some don't |
| 14:36 | <darobin> | (IIRC) |
| 14:37 | <Ms2ger> | jgraham, I was wondering if you remembered to look for those tests ;) |
| 14:37 | <darobin> | GPHemsley: using an abstract will simplify the life of whoever gets to steal your spec on behalf of a W3C WG |
| 14:37 | <GPHemsley> | Ah, so if I want to discourage that, I should remove it? ^_^ |
| 14:38 | <jgraham> | Ms2ger: No, but now was a good time to remind me. Looking coming right up |
| 14:38 | <Ms2ger> | \o/ |
| 14:38 | <jgraham> | I wouldn't get too excited |
| 14:38 | <GPHemsley> | darobin: Do you have any sense as to which portion is the majority? |
| 14:39 | GPHemsley | feels like the mimesniff abstract is mostly redundant to the introduction |
| 14:39 | <darobin> | GPHemsley: if you want to discourage that you should submit your spec to the HTML WG when it gets its new open license :) |
| 14:39 | <darobin> | GPHemsley: but overall, no, I don't know what the majority is |
| 14:40 | <GPHemsley> | Also, does anyone have any distinction between "key word" and "keyword"? |
| 14:40 | <darobin> | I think you want the latter |
| 14:41 | <GPHemsley> | darobin: I think I do, too, but that would go against the status quo |
| 14:41 | <GPHemsley> | (RFC 2119 uses "key word", and that is propagated to specs mentioning RFC 2119) |
| 14:43 | <darobin> | GPHemsley: ah, dunno then. I'd still use keyword at least outside of that context |
| 14:43 | <GPHemsley> | I'd like to use keyword inside of that context ;) |
| 14:43 | <darobin> | has anyone looked at making &apos: accepted in text/html as well? I thought it was but apparently not |
| 14:43 | <MikeSmith> | what rough beast, its hour come round at last, slouches towards Bethlehem to be born |
| 14:43 | <darobin> | GPHemsley: I wouldn't sweat it |
| 14:44 | <darobin> | MikeSmith: EME spec? :) |
| 14:44 | <MikeSmith> | heh |
| 14:44 | <MikeSmith> | well, now that you bring that up: http://www.w3.org/News/2013#entry-9813 |
| 14:44 | <MikeSmith> | http://www.w3.org/TR/encrypted-media/ |
| 14:44 | <MikeSmith> | the rest is future history |
| 14:48 | <jgraham> | Ms2ger: Well I found a file called Testcase%20showing%20the%20problem..html |
| 14:48 | <Ms2ger> | Heh |
| 14:48 | <jgraham> | Which isn'ta testcase and doesn't show the problem, but does seem to be related to named getters on forms |
| 14:49 | <jgraham> | Apart from that I'm not seeing much |
| 14:49 | <jgraham> | Asking zcorpan or hallvors on Monday might be a good strategy |
| 14:49 | <Ms2ger> | Sounds like I'm trying to coerce baku_ into writing them, then :) |
| 19:20 | <GPHemsley> | X-Content-Type-Options is now specced: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039561.html |
| 19:49 | <annevk> | GPHemsley: I don't think that's what actually happens for <img> |
| 19:49 | <annevk> | GPHemsley: I'm pretty sure that image/png will still decode image/gif |
| 19:50 | <annevk> | GPHemsley: because of the way image decoders work |
| 20:29 | <GPHemsley> | annevk: I'm not sure what you mean. How does what you said contradict what I said? |
| 20:30 | GPHemsley | is starting to wonder whether he remembers how to put thoughts into words. |
| 20:41 | <annevk> | GPHemsley: X-Content-Type-Options: nosniff still works for image/gif labeled as image/png I think |
| 20:41 | <annevk> | GPHemsley: I think the spec has that wrong, or did you test that case? |
| 22:57 | <GPHemsley> | annevk: I'm still not clear on what you're saying, but if you load an image in the main browsing context, the nosniff rule should apply. If you load an image through <img>, HTML bypasses the main sniffing algorithm using a context-specific sniffing algorithm. |