| 00:05 | <GPHemsley> | which is scarier: unexpected, unanticipated, or unforeseen? |
| 00:05 | <zewt> | inconceivable |
| 00:06 | <GPHemsley> | that's a little over the top ;) |
| 00:08 | <zewt> | perhaps "never go in against a sicilian when death is on the line" |
| 00:12 | GPHemsley | bops zewt on the head. |
| 00:24 | <Velmont> | jgraham, gsnedders, hsivonen and other html5lib people: So I have a friend using html5lib now (since he couldn't find a more performant and well-working lib). But he wants stuff in <noscript> not to be taken as text, but parsed. |
| 00:25 | <Velmont> | Is that possible? What do implementations do when they don't have script? Take that snippet-o-text and run parser on it as a fragment? |
| 00:26 | <GPHemsley> | annevk: I want to steal all your definitions. |
| 00:29 | <GPHemsley> | (But I can't) |
| 00:45 | <GPHemsley> | Is the only way to define ASCII through Unicode? |
| 00:45 | <GPHemsley> | oh, RFC 20 |
| 00:53 | <abarth> | GPHemsley: are you looking for me? |
| 00:53 | <abarth> | GPHemsley: i'm sorry I haven't been online recently. what can I do for you? |
| 00:54 | <GPHemsley> | abarth: Are you officially done being the editor of mimesniff? |
| 00:54 | <abarth> | GPHemsley: that sounds like a loaded question |
| 00:55 | <GPHemsley> | well |
| 00:55 | <abarth> | GPHemsley: :) |
| 00:55 | <GPHemsley> | Well, see, if you aren't, then I've usurped you |
| 00:55 | <GPHemsley> | :) |
| 00:55 | <abarth> | what changes have you been making? |
| 00:56 | <abarth> | i haven't seen any discussed on whatwg@ |
| 00:56 | <abarth> | maybe there's another mailing list? |
| 00:56 | <GPHemsley> | the discussion has mostly been in here |
| 00:56 | <abarth> | that's unfortunate for folks who aren't available synchronously |
| 00:57 | <abarth> | generally, I prefer mailing lists |
| 00:57 | <abarth> | so I don't have to be in the same time zone as the discussion |
| 00:57 | <GPHemsley> | yeah |
| 00:57 | <GPHemsley> | so I take it you're still attached, then? |
| 00:57 | <abarth> | I don't really know how to answer that question |
| 00:58 | <abarth> | whatwg is a do-ocracy |
| 00:58 | <abarth> | i haven't being doing much recently |
| 00:58 | <abarth> | you seem interested in doing more |
| 00:58 | <abarth> | https://github.com/whatwg/mimesniff/commit/3efba5ec7b621deb7d08ace0939b1ec2338a083e is hard to read |
| 00:58 | <abarth> | is there anything interested in that change from a technical PoV? |
| 00:59 | <GPHemsley> | nope |
| 00:59 | <GPHemsley> | [16:12:49] <GPHemsley> Well, that diff is messy and mostly useless. |
| 00:59 | <GPHemsley> | [16:12:56] <GPHemsley> But I swear it's mostly whitespace. |
| 00:59 | <GPHemsley> | [16:13:11] <GPHemsley> A few bits of punctuation and tag clean-up, too. |
| 00:59 | <GPHemsley> | [16:13:14] <GPHemsley> But mostly whitespace. |
| 00:59 | <abarth> | so far all these changes look great |
| 00:59 | abarth | is reading https://github.com/whatwg/mimesniff/commit/10b89e4601ab9f7671b7be717c4eb072a7561f4c |
| 00:59 | <abarth> | ah, you've personified user agents :) |
| 01:00 | <GPHemsley> | indeed |
| 01:00 | <GPHemsley> | right now, though, I'm mostly worried about this change: https://github.com/whatwg/mimesniff/commit/4878990a333db8bb3e30b8602ea8ff986aec5ef6 |
| 01:00 | <GPHemsley> | :) |
| 01:00 | <abarth> | GPHemsley: I can't worry about that stuff |
| 01:01 | <GPHemsley> | so you don't mind? |
| 01:01 | <abarth> | not if you're planning to improve the spec |
| 01:01 | <GPHemsley> | *hew* |
| 01:01 | <GPHemsley> | +p |
| 01:01 | <GPHemsley> | but yeah |
| 01:01 | <abarth> | for technical changes, i think it would be good to discuss the changes on whatwg@ |
| 01:01 | <GPHemsley> | well, I don't plan on making any substantive changes just yet |
| 01:01 | <GPHemsley> | but it does seem like things could be consolidated |
| 01:02 | <abarth> | what do you mean by that? |
| 01:02 | <GPHemsley> | well, for example, each section seems to start the algorithm over again |
| 01:02 | <GPHemsley> | like, read up to 512 bytes, etc. |
| 01:03 | <GPHemsley> | and that stuff could probably all be consolidated to a single section |
| 01:03 | <abarth> | yeah, that's to make it easier to reference from other specs |
| 01:03 | <abarth> | e.g., HTML wants to sniff for images only for <img> |
| 01:03 | <GPHemsley> | hmm |
| 01:03 | <abarth> | you should be careful not to break any external references |
| 01:03 | <GPHemsley> | is there a list of such things somewhere? |
| 01:04 | <abarth> | nope |
| 01:04 | <GPHemsley> | well, I was told people would tell me if I broke things |
| 01:05 | <abarth> | the bold things are things that might be referenced |
| 01:05 | <abarth> | e.g., " match the signature for MP4" |
| 01:05 | <abarth> | http://mimesniff.spec.whatwg.org/#rules-for-sniffing-fonts-specifically needs work |
| 01:05 | <abarth> | there's a bunch of reverse engineering that needs to be done for that section |
| 01:06 | <GPHemsley> | right |
| 03:06 | <Hixie> | GPHemsley: generally assume each named algorithm or algorithm in its own section is referenced from somewhere unless you ask around and nobody knows, including at least me (html), anne (xhr), and abarth |
| 03:06 | <Hixie> | GPHemsley: i think they're all referenced from HTML, at least |
| 03:07 | <Hixie> | maybe not fonts and video-related stuff yet |
| 03:07 | <Hixie> | though the later is probably coming |
| 03:20 | <MikeSmith> | learning about "URL units" and "the URL byte" |
| 03:20 | <MikeSmith> | seems like that should be "a URL byte" |
| 03:24 | <MikeSmith> | fewer letters than "percent-encoded octet" |
| 03:34 | <MikeSmith> | Hixie, it seems you've lost your seat at the "table of standards discussions" |
| 03:34 | <MikeSmith> | now you gotta go sit at the kids table |
| 03:34 | <Hixie> | so i heard |
| 03:34 | <MikeSmith> | oh wait I think the kids table is where we already been sitting for a while now |
| 03:35 | <MikeSmith> | I wonder who's still sitting at the table of standards discussions |
| 03:36 | <Hixie> | kids tables is where all the fun is anyway |
| 03:38 | <MikeSmith> | you're too dangerous for polite standards society |
| 03:38 | <MikeSmith> | you should put that on our c.v. |
| 03:41 | <MikeSmith> | the only thing that message is lacking is a Cc to Ban Ki-moon |
| 03:48 | <Hixie> | hah |
| 03:48 | <Hixie> | hopefully i won't need my cv for a looong time |
| 03:48 | <Hixie> | amusingly, my boss loves it when he hears complaints about me |
| 03:49 | <Hixie> | he once told me off for not working hard enough on the basis that he hadn't heard any complaints in months |
| 03:49 | <Hixie> | one complaint he heard even made him think i should get a pay raise |
| 03:49 | <Hixie> | so really, i'm all for danny's rants :-P |
| 03:52 | <MikeSmith> | I'm intrigued by this "boss loves it when he hears complaints about me" idea |
| 03:52 | <MikeSmith> | I'm gonna talk to my boss about that one |
| 03:52 | <Hixie> | good luck with that. i have a particularly great work situation. |
| 03:52 | <MikeSmith> | get him to come around to seeing it as a plus |
| 03:53 | <MikeSmith> | Hixie: well I have better public transportation where I live |
| 03:54 | <MikeSmith> | so la-di-da |
| 03:54 | <Hixie> | can't argue with that |
| 03:55 | <Hixie> | to get from my place to where i work takes two busses and an hour. I can cycle there in 15 minutes. |
| 03:56 | <Hixie> | Google Maps actually tells me it's quicker to walk than take public transit. |
| 03:56 | <MikeSmith> | wow |
| 03:56 | <MikeSmith> | yeah it sucks to be somebody who doesn't have a drivers license and be visiting there |
| 03:57 | <MikeSmith> | and the taxis there are a farce |
| 03:57 | <Hixie> | (i didn't even know google maps could give that option. that's kinda funny.) |
| 03:58 | <MikeSmith> | they must have added it to compete with Apple iOS Maps |
| 03:58 | <Hixie> | sooooooo no comment |
| 04:02 | <MikeSmith> | me wonders if kennyluck is around |
| 04:02 | <kennyluck> | MikeSmith, Iam. |
| 04:02 | <MikeSmith> | oh cool |
| 04:02 | <MikeSmith> | kennyluck: wanted to ask you about the bug comment you made on ampersands handling in IE |
| 04:03 | <kennyluck> | MikeSmith, what about it? |
| 04:03 | <MikeSmith> | you said it doesn't work properly in IE |
| 04:03 | <kennyluck> | No. |
| 04:03 | <MikeSmith> | one thing, the example you gave was href="foo&r eg" |
| 04:03 | <MikeSmith> | but that's not an ambiguous-ampersand case |
| 04:04 | <MikeSmith> | not at at the spec defines it |
| 04:04 | <kennyluck> | MikeSmith, I think I gave something like "a=1®=2" |
| 04:04 | <MikeSmith> | yeah |
| 04:04 | <MikeSmith> | that too |
| 04:04 | <MikeSmith> | "®" is a match in the named-character references table |
| 04:05 | <MikeSmith> | I assumed that means it's one of those that UAs recognize and handle even if they don't have a semicolon |
| 04:05 | <MikeSmith> | and somebody who tested told me that yeah IE9 handles it that way as expected |
| 04:06 | <MikeSmith> | so anyway what I am wondering is what exactly does IE9 and before not handle corretly |
| 04:06 | <MikeSmith> | like, does IE9 not deal with a simpler case like "a=1&b=2" correctly |
| 04:06 | <kennyluck> | MikeSmith, so for example, in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1857 |
| 04:07 | MikeSmith | takes a look |
| 04:07 | <kennyluck> | IE9 shows "a=1®=2 a=1®=2 Link" |
| 04:07 | <kennyluck> | while the standards/Firefox/WebKit say it should be "a=1®=2 a=1®=2 Link" |
| 04:08 | <MikeSmith> | oh ok |
| 04:08 | <MikeSmith> | I see |
| 04:09 | <MikeSmith> | still that's not a problem with general handling of the simple case |
| 04:09 | <kennyluck> | MikeSmith, spec says whenever a semicolon-less entity is encountered in the attribute, there's special handling, and IE9- doesn't do that. |
| 04:09 | <MikeSmith> | the non-looks-like-named-character-reference case |
| 04:09 | <MikeSmith> | yeah I understand now |
| 04:09 | <MikeSmith> | thanks -- wasn't clear to me before |
| 04:10 | <MikeSmith> | so for that case in the validator at least we could have it emit a warning I think |
| 04:10 | <kennyluck> | MikeSmith, warning or error, yes. |
| 04:10 | <MikeSmith> | oh wait |
| 04:10 | <MikeSmith> | we already do man |
| 04:10 | <MikeSmith> | what am I saying |
| 04:10 | <MikeSmith> | yeah we emit an error for that |
| 04:10 | <kennyluck> | MikeSmith, yes, the problem is that the spec seems to forbid doing that? |
| 04:11 | <MikeSmith> | no |
| 04:11 | <MikeSmith> | it doesn't |
| 04:11 | <kennyluck> | Since it's not a parse error? |
| 04:11 | <MikeSmith> | it says that if you have a match to something in the table but the last character is not a semicolon, then that's a parse error |
| 04:11 | <MikeSmith> | it is a parse error |
| 04:11 | <MikeSmith> | and we report the parse error |
| 04:12 | <MikeSmith> | Henri's HTML parser code does, and then the gets sent on to the validator message reporter |
| 04:12 | <MikeSmith> | lemme get you the spec reference |
| 04:12 | <MikeSmith> | it's like the second-to-last paragraph |
| 04:13 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenizing-character-references |
| 04:13 | <kennyluck> | MikeSmith, no, I think the spec intentionally leaves this case as non-error. "If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next character is either a U+003D EQUALS SIGN character (=) or in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, or U+0061 LATIN SMALL LETTER A to U+007 |
| 04:13 | <kennyluck> | LATIN SMALL LETTER Z, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND character (&) must be unconsumed, and nothing is returned." |
| 04:13 | <MikeSmith> | "Otherwise, a character reference is parsed. If the last character matched is not a U+003B SEMICOLON character (;), there is a parse error." |
| 04:13 | <kennyluck> | Note that this paragraph, unlike the others, doesn't have "then this is a parse error." |
| 04:14 | <kennyluck> | but this case falls into the "part of an attribute" case. |
| 04:14 | <MikeSmith> | ah yeah |
| 04:14 | <MikeSmith> | so maybe Hixie just needs to add that same language there |
| 04:15 | <MikeSmith> | seems like that should just a parse error |
| 04:15 | <kennyluck> | which makes certain sense. When almost all browsers support this special handling, you no longer have any fear in using something like "a=1®=2", so it shouldn't be a parse error (at least in the future). |
| 04:16 | <MikeSmith> | yeah |
| 04:16 | <kennyluck> | But for now, I think it could be a parse error. (If we allow dynamic author conformance, which I don't consider a bad thing) |
| 04:16 | <MikeSmith> | the validator and Firefox treat it as a parse error already |
| 04:17 | <kennyluck> | s/dynamic/evolving/ |
| 04:17 | <MikeSmith> | yeah |
| 04:18 | <MikeSmith> | if you do View Source on your example from http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1857 it should mark that stuff in red to show it's a syntax error |
| 04:18 | MikeSmith | tries it |
| 04:18 | <kennyluck> | Yeah. |
| 04:19 | <MikeSmith> | yeah it does |
| 04:19 | <MikeSmith> | that is so cool |
| 04:20 | <MikeSmith> | hsivonen++ |
| 04:20 | <MikeSmith> | anyway I guess that parser is not conformant with the spec right now |
| 04:21 | <MikeSmith> | kennyluck: thanks for explaining |
| 04:21 | <kennyluck> | MikeSmith, nope. |
| 04:26 | <kennyluck> | I kind of think "the next character is either a U+003D EQUALS SIGN character (=) or…" should also include "%" though. |
| 04:27 | <MikeSmith> | why? |
| 04:27 | <kennyluck> | just for <input name="reg表"> or something this crazy. |
| 04:28 | <kennyluck> | which generates a "®%E8%A1%A8=…" |
| 04:28 | <kennyluck> | Anyway, not an important case that I care enough. |
| 04:31 | <MikeSmith> | ok |
| 04:31 | <kennyluck> | I do wonder why the spec doesn't just stop parsing semicolon-less entity in attributes. |
| 05:15 | <annevk> | kennyluck: some Adobe blog said you're working at Opera, is that true? |
| 05:15 | <annevk> | kennyluck: http://blogs.adobe.com/webplatform/2012/10/25/test-the-web-forward-beijing/ |
| 05:16 | <annevk> | kennyluck: seemed unlikely to me, but who knows |
| 05:24 | <MikeSmith> | annevk: maybe "URL-encoded byte" |
| 05:24 | <MikeSmith> | sorry for party rocking |
| 05:24 | <annevk> | ah yeah, that terminology is not really fixed |
| 05:24 | <MikeSmith> | I think we should now use "party rocking" instead "bikeshedding" |
| 05:24 | <annevk> | heh |
| 05:25 | <MikeSmith> | dude on uri@ says you can only use "bikeshedding" if you're a nuclear scientist |
| 05:25 | <annevk> | and I used "The" because for some reason I ended up using "The" for all of them |
| 05:26 | <annevk> | I'm happy for a native speaker to reword to patch all of that a bit |
| 05:29 | <MikeSmith> | I'm sure somebody more OCD than me will eventually give you a bunch of suggestions |
| 05:30 | <annevk> | only invalid ports and relative URLs resolved against URLs without a relative schemes cause the parser to halt at this point |
| 05:30 | <annevk> | I think there's a few host-related errors that do the same, but that's surprisingly few |
| 05:31 | <MikeSmith> | yeah |
| 05:33 | <MikeSmith> | hmm but also for no scheme, right? |
| 05:33 | <MikeSmith> | "If base URL is null, or base URL's scheme is not a relative scheme, invalidate." |
| 05:34 | <annevk> | yeah, that's the relative URL case I mentioned |
| 05:34 | <annevk> | when you parse a relative URL you start out by parsing the scheme, because you don't know it's a relative URL just yet |
| 05:35 | <annevk> | you know it's a relative URL because it does not start with something that's a scheme |
| 05:35 | <MikeSmith> | ah ok |
| 05:36 | <annevk> | GPHemsley: please call them bytes |
| 05:46 | <annevk> | http://www.communitywiki.org/DoOcracy is nice |
| 05:46 | <annevk> | thanks abarth for the new word |
| 05:49 | <abarth> | annevk: you're welcome :) |
| 05:50 | <annevk> | abarth: did you ever fully figure out file URLs btw? |
| 05:50 | <annevk> | ah, good night |
| 06:02 | <annevk> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0305.html |
| 06:02 | <annevk> | it doesn't seem too complex |
| 06:02 | <annevk> | anyone know what other URLs Gecko has this "no authority" thing for? |
| 06:03 | <annevk> | per http://www.cs.tut.fi/~jkorpela/fileurl.html stripping the host away btw seems like a problem |
| 06:05 | <MikeSmith> | I'm wondering if it would be better to just not spec file URLs at all |
| 06:05 | <MikeSmith> | they're not really portable anyway |
| 06:05 | <MikeSmith> | not something you share with somebody else |
| 06:06 | <MikeSmith> | so not clear what real utility they have anyway |
| 06:06 | <MikeSmith> | or what need there is for interoperability |
| 06:07 | <MikeSmith> | I mean I don't even expect that I can take a file URL that Firefox shows me in its address bar, and copy & paste that into my Chrome address bar and necessary expect that it'll work |
| 06:08 | <MikeSmith> | I realize there are other cases like using command-line utils with file URLs |
| 06:27 | <annevk> | I don't want the API to be unpredictable for a very tiny subset of URLs |
| 06:28 | <annevk> | and the parser already covers most of the things such as treating \ and / equivalent |
| 06:28 | <annevk> | a few of the things bz mentions are about further processing file URLs, we don't have to specify that |
| 06:30 | <annevk> | we just want to define what new URL("file:" + anything).href and new URL(anything, "file:" + anything2).href return |
| 06:31 | <annevk> | benschwarz: http://developers.whatwg.org/ has no style sheet? |
| 06:31 | <annevk> | benschwarz: https://twitter.com/RPKaper/status/261638622061686785 |
| 06:33 | <benschwarz> | annevk: hmm. thanks for the heads up |
| 06:33 | <benschwarz> | checking it out |
| 06:35 | <MikeSmith> | annevk: yeah fair enough |
| 06:37 | <benschwarz> | annevk: look better now? |
| 06:37 | <annevk> | benschwarz: works, thanks |
| 06:37 | <benschwarz> | no idea. |
| 06:37 | <benschwarz> | just regenerated and deployed |
| 06:37 | <a-ja> | WFM now too |
| 06:38 | <annevk> | benschwarz: btw, we have https://github.com/whatwg now, but I guess the setup as you have it now works fine |
| 06:46 | <benschwarz> | annevk: it probably needs a bit of love, but yeah, as long as I don't die… its fine |
| 06:56 | <annevk> | Ms2ger? Why does XPathEvaluator have a constructor rather being replaced with "partial Document"? Also, why do I care? Reference: http://wiki.whatwg.org/wiki/DOM_XPath |
| 07:02 | <annevk> | MikeSmith: btw, I called it a URL byte because percent escape does not tell you at all you're actually looking at a byte |
| 07:02 | <MikeSmith> | yeah understood |
| 07:03 | <annevk> | anecdotal evidence suggests developers think they're looking at characters |
| 07:03 | <MikeSmith> | elsewhere they're called "percent-encoded octets" |
| 07:04 | <MikeSmith> | so bytes is better than octets |
| 07:04 | <MikeSmith> | but I think what "URL byte" is missing is the fact that they're encoded |
| 07:05 | <MikeSmith> | but anyway in practice people talk about "URL encoding" stuff |
| 07:05 | <MikeSmith> | more than "percent-encoding" |
| 07:05 | <MikeSmith> | so "a URL-encoded byte" seems clear |
| 07:06 | <annevk> | fair enough, will do that |
| 07:07 | <annevk> | MikeSmith: would this work for the algorithm then: "To URL-encode a byte /byte/ into a *URL-encoded byte*, run these steps:" |
| 07:08 | <annevk> | or would that be "To URL encode" sans hyphen? |
| 07:11 | <MikeSmith> | sans hyphen is OK |
| 07:11 | <MikeSmith> | b |
| 07:11 | <MikeSmith> | because it's not ambiguous |
| 07:12 | <MikeSmith> | the purpose of adding a hyphen is usually just to make it grammatically unambiguous |
| 07:13 | <MikeSmith> | usually for compound words that are used as adjectives |
| 07:13 | <annevk> | actually, might have to call it percent-encoded byte after all, it's also used for host names |
| 07:13 | <MikeSmith> | ah |
| 07:13 | <MikeSmith> | makes sense |
| 07:14 | <MikeSmith> | byte is still better than octet at least |
| 07:14 | <annevk> | not sure what to call URL units then |
| 07:14 | <MikeSmith> | I never have understood in what real-world normal cases something that's an octet is not a byte |
| 07:14 | <annevk> | or maybe it's fine to use URL as a term even for host names |
| 07:15 | <annevk> | MikeSmith: I think Chris Lilley gave me an example, but I might misremember |
| 07:15 | <MikeSmith> | ah OK |
| 07:15 | <annevk> | something ancient |
| 07:15 | <MikeSmith> | yeah |
| 07:15 | <MikeSmith> | I guess Richard probably knows some |
| 07:15 | <MikeSmith> | URL units is same as what RFCs call unreserved, right? |
| 07:16 | <annevk> | Encoding Standard defines it as having room for 256, i.e. 8 bits |
| 07:16 | <annevk> | MikeSmith: not entirely |
| 07:16 | <MikeSmith> | unreserved chars |
| 07:16 | <MikeSmith> | o |
| 07:16 | <MikeSmith> | oh OK |
| 07:16 | <annevk> | sub-delims, iunreserved, iquery/ifragment, ipchar |
| 07:17 | <annevk> | I made URL units the superset and then added local restrictions |
| 07:17 | <annevk> | that seemed way more clear then the ABNF thing |
| 07:19 | <annevk> | MikeSmith: e.g. userinfo is pchar, it just lacks @ so it has a way more complicated production instead, and they all do stuff like that while the difference is only a character or two |
| 07:20 | <MikeSmith> | OK |
| 07:20 | <MikeSmith> | and I hear you about being clearer than ABNF |
| 07:28 | <kennyluck> | annevk, (re. some Adobe blog said you're working at Opera, is that true?) more or less. It's more like a joint venture of Opera and another Chinese company. |
| 07:33 | <annevk> | kennyluck: congrats then, thought you were still at the W3C |
| 07:34 | <kennyluck> | annevk, oh ok. |
| 07:41 | Ms3ger | waves at shepazu |
| 07:41 | <Ms3ger> | annevk: because everyone implements the constructor, I think |
| 07:43 | <Ms3ger> | annevk: I found a Mozilla test that happened to rely on that, so I thought I might as well document that somewhere |
| 07:43 | <annevk> | Ms3ger: so I guess we need to add Document implements XPathEvaluator; to that fragment too |
| 07:43 | <annevk> | Ms3ger: Opera implements the constructor too |
| 07:43 | <annevk> | so does Chrome |
| 07:44 | <Ms3ger> | annevk: looks that way for implements |
| 07:44 | <MikeSmith> | Ms3ger: btw GPHemsley was asking earlier what the rfc.json file was for |
| 07:45 | <annevk> | i'll add that |
| 07:45 | <Ms3ger> | annevk: thanks :) |
| 09:37 | <annevk> | tantek's URL breakdown does not cover userinfo much :/ |
| 11:01 | <annevk> | quite pleased with my UTFString invention |
| 11:01 | <annevk> | now I just need heycam to write it down |
| 11:02 | <SimonSapin> | annevk: can we read about this somewhere yet? |
| 11:02 | <annevk> | sorry, http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0082.html |
| 11:02 | <SimonSapin> | sounds good |
| 11:32 | <annevk> | there's even less conversion towards STD 66 for URLs without relative schemes |
| 11:33 | <annevk> | afaict only code points lower than U+0020 (not including!) and higher than U+007E are escaped for e.g. mailto:, random: etc. |
| 11:36 | <annevk> | oh what the fuck |
| 11:37 | <annevk> | for URLs with a relative scheme Chrome does not escape fragment code points higher than U+007E but they do for URLs without relative scheme |
| 11:37 | <annevk> | that's some crazy right there |
| 11:45 | <MikeSmith> | weird |
| 11:52 | <MikeSmith> | Velmont: I will set up GH mirroring for the webapps repo but for the webappsec one I guess I should ask the chairs of that group first |
| 12:04 | <annevk> | MikeSmith: did you end up posting to that list? |
| 12:05 | <MikeSmith> | no not yet |
| 13:17 | <gsnedders> | Velmont: No easy way, because script execution has to happen during parsing. |
| 13:17 | <gsnedders> | Velmont: c.f. document.write, etc. |
| 14:13 | <annevk> | hacking validation in the parser has a few tricky corner cases |
| 14:14 | <annevk> | maybe I should write it out in JavaScript first |
| 14:22 | <hsivonen> | any recommendations for an Android text editor |
| 14:22 | <hsivonen> | ? |
| 14:23 | <gsnedders> | Jota seems to be decent, for what I've used it for. |
| 14:23 | <gsnedders> | How much editing are you doing, and what sort? |
| 14:27 | <MikeSmith> | hsivonen: I've never used a text editor on Android. Would be nice if there were an Android version of iAWriter |
| 14:27 | <hsivonen> | oh no. memes are offline. |
| 14:27 | <hsivonen> | gsnedders: not much and of the sort of tweaking config files or the like |
| 14:28 | <gsnedders> | Then Jota gets my vote. |
| 14:28 | <hsivonen> | hmm. there’s Jota and Jota+ |
| 14:29 | <hsivonen> | what’s its business model, BTW? |
| 14:30 | <hsivonen> | Maybe Jota is for Android < 2.2 and Jota+ is for Android >= 2.2 |
| 14:30 | <gsnedders> | No idea, can't remember off hand. |
| 14:32 | <hsivonen> | gsnedders: thanks |
| 14:34 | <hsivonen> | whoa. the W3C has finally gotten https for https://lists.w3.org/Archives/Member/ |
| 14:35 | hsivonen | wonders if Member-only pages on www.w3.org are now behind https |
| 14:36 | <annevk> | hsivonen: /Member/ does redirect |
| 14:37 | <hsivonen> | at least dbmg is behind https now |
| 14:37 | <Lachy> | annevk, yes, it does |
| 14:37 | hsivonen | didn’t know about /Member/ |
| 14:37 | <annevk> | so does /Style/Group/CSS/ |
| 14:38 | <annevk> | don't really recall any other Member-only links |
| 14:40 | <annevk> | hober: abarth: file:test/ parses in a buggy way |
| 14:42 | <annevk> | Does anyone know why Mozilla always kills the authority component in a file URL? |
| 14:46 | <hsivonen> | annevk: if you want to know about file: URLs in Gecko, you need to ask bz |
| 14:46 | <annevk> | I have an email from him on file, maybe a pointer to the codebase is sufficient |
| 14:49 | <hsivonen> | fun. there a 4 implementations |
| 14:49 | <hsivonen> | OS/2, OS X, Unix and Windows |
| 14:50 | <hsivonen> | https://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsURLHelperWin.cpp#50 |
| 14:50 | <hsivonen> | https://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsURLHelperOS2.cpp#48 |
| 14:50 | <hsivonen> | https://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsURLHelperOSX.cpp#144 |
| 14:50 | <hsivonen> | https://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsURLHelperUnix.cpp#51 |
| 14:50 | <hsivonen> | annevk: ^ |
| 14:51 | <annevk> | oh my |
| 14:51 | <hsivonen> | s/there a/there are/ |
| 14:52 | <annevk> | wait, I think this is after parsing |
| 14:54 | <annevk> | http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsURLHelper.cpp#147 looks like it's it |
| 14:55 | <annevk> | (the actual parser) |
| 14:56 | <annevk> | hmm, Gecko's URL implementation is weiiird |
| 14:56 | <Ms2ger> | annevk, well, it's Gecko :) |
| 14:57 | <annevk> | I think I got most of the file URL logic except that // means authority and anything else means empty authority |
| 14:57 | <annevk> | it seems that everyone but Opera has that |
| 14:57 | <annevk> | and then I guess there's the Windows C: drives thing, not sure what to do with those |
| 14:57 | <annevk> | would be a bit weird to special case Windows in the spec |
| 15:13 | <GPHemsley> | annevk: The use of "octet" is a pre-existing condition. I'd be happy to reference another spec, but I didn't think the encoding definition was specific enough. |
| 15:13 | GPHemsley | wonders if we shouldn't have a special spec just for common definitions |
| 15:14 | <GPHemsley> | Hixie: Is there an easy way to discover exactly where in the HTML spec the sub-algorithms are referenced? |
| 15:15 | <annevk> | GPHemsley: pre-existing? |
| 15:16 | <annevk> | GPHemsley: oh you mean Adam was using that already? |
| 15:16 | GPHemsley | disagrees with MikeSmith's assessment that "in practice people talk about "URL encoding" stuff more than "percent-encoding"" |
| 15:17 | <annevk> | GPHemsley: if you think the definition of "byte" has a bug, you should file a bug |
| 15:18 | <GPHemsley> | Wikipedia suggests that the use of octet was to get around the fact that "byte" could be 6, 7, 8, etc. bits long, depending on usage |
| 15:19 | <annevk> | I know, but that's ancient and people call it a byte these days |
| 15:19 | <annevk> | (I used octet before in the Encoding Standard) |
| 15:22 | <GPHemsley> | So, you're saying that bytes are nowadays already assumed to have 8 bits? |
| 15:23 | <annevk> | no, I should prolly make that explicit as you did |
| 15:23 | <SimonSapin> | we use octet in French, and I learned byte as the translation |
| 15:23 | <GPHemsley> | Also, it seems to are deliberately avoiding actually defining 'byte' in the encoding spec. What's the motivation there? |
| 15:23 | <annevk> | I'm saying we should use the term byte, everywhere |
| 15:23 | <GPHemsley> | ah |
| 15:24 | <hsivonen> | octet is IETF speak. everyone else says byte |
| 15:24 | <GPHemsley> | annevk: Alright, let me know when you update encoding |
| 15:24 | <GPHemsley> | Incidentally, do you link every instance of 'byte' back to the definition? |
| 15:24 | <annevk> | no |
| 15:26 | <GPHemsley> | should one? |
| 15:26 | <annevk> | GPHemsley: not sure, you'd get a lot of links :) |
| 15:26 | <annevk> | GPHemsley: not sure about code point and string either |
| 15:26 | <annevk> | GPHemsley: feel free to experiment and see how it goes :) |
| 15:26 | <annevk> | GPHemsley: fixed encoding btw |
| 15:27 | <GPHemsley> | k |
| 15:27 | <GPHemsley> | I'll update in a moment |
| 15:28 | <GPHemsley> | I'm wondering whether the Unicode-based definitions are appropriate for mimesniff |
| 15:28 | <GPHemsley> | because they're dealing directly with the bytestream |
| 15:28 | <GPHemsley> | s/they're/it's/ |
| 15:28 | <annevk> | you can just use your own definitions |
| 15:29 | <GPHemsley> | ok |
| 15:29 | <GPHemsley> | do you think the ones I have are good enough? |
| 15:29 | <annevk> | but keep them in sync, maybe at some point we'll write draft for all these simple terms |
| 15:29 | <GPHemsley> | ok |
| 15:32 | <annevk> | GPHemsley: I would say The C bytes are bytes x, y, and z. |
| 15:32 | <annevk> | talking about the value of a byte seems cumbersome |
| 15:33 | <GPHemsley> | ok |
| 15:34 | <annevk> | and one last bit of advice, if you disagree with something in a spec, please do raise it :) |
| 15:34 | <GPHemsley> | alright |
| 15:34 | <GPHemsley> | it wasn't like I was hanging on to it for a while |
| 15:36 | <annevk> | fair enough |
| 15:43 | <annevk> | TabAtkins: you need to deal with lone surrogates |
| 15:44 | <annevk> | TabAtkins: at least, http://lists.w3.org/Archives/Public/www-style/2012Oct/0689.html suggests you don't |
| 15:58 | <GPHemsley> | Ms2ger: Is there any chance you can document all the fancy things that Anolis does? |
| 15:58 | <annevk> | has anyone developed a clever filter yet for emails such as http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0272.html ? |
| 15:59 | <Ms2ger> | GPHemsley, a rather small one :) |
| 15:59 | <Ms2ger> | GPHemsley, you found the readme? |
| 16:17 | <annevk> | hmm, no strict parser yet, but I think I have figured out how to put file URLs in the parser |
| 16:17 | <annevk> | but also no commit for that |
| 16:24 | <GPHemsley> | Ms2ger: Oh, no, I didn't actually try looking first. That's silly. ;) |
| 16:30 | <[tm]> | deep into a shochu session here. probably a good time for me to post some replies on the uri⊙w thread |
| 16:33 | <[tm]> | either that our email www-archive and www-tag to complain that Hixie is the antichrist |
| 16:34 | <Ms2ger> | Trying to get him a pay raise, eh? |
| 16:34 | <GPHemsley> | annevk: It'd probably be useful if you spelled out precisely which terms in url are used as defined in encoding |
| 16:35 | <GPHemsley> | Ms2ger: What do we do with plurals? |
| 16:35 | <Ms2ger> | Sorry? |
| 16:35 | <GPHemsley> | like, if I define a term as singular and then want to mark up a plural instance |
| 16:35 | <Ms2ger> | <span title=singular>plural</span> |
| 16:35 | <GPHemsley> | <dfn>byte</dfn> <span>bytes</span> |
| 16:36 | <GPHemsley> | ah, ok |
| 17:00 | <annevk> | GPHemsley: I don't care for that, too much work and they are linked anyway |
| 17:00 | <annevk> | maybe once everything is done |
| 17:00 | <GPHemsley> | well, until then, it's an almost useless statement, IMO |
| 17:01 | <GPHemsley> | s/useless/redundant/, if you like |
| 17:02 | <Hixie> | GPHemsley: find in page? |
| 17:03 | <GPHemsley> | Hixie: hmm? |
| 17:03 | <Hixie> | GPHemsley: how to find use of an algorithm |
| 17:04 | <GPHemsley> | ah |
| 17:04 | <GPHemsley> | that's not the easiest possible way |
| 17:05 | <Hixie> | try looking for the first reference to mimesniff |
| 17:05 | <Hixie> | maybe there's some <dfn>s you can click on |
| 17:05 | <Hixie> | no guarantee though |
| 17:08 | <GPHemsley> | alright |
| 17:09 | <Hixie> | actually just looking for the string [mimesniff] should find you most references |
| 17:12 | <Ms2ger> | GPHemsley, it's kinda hard to figure out where the ref should go, and I kinda like the idea of making cross-doc dependencies explicit |
| 17:12 | <GPHemsley> | Ms2ger: What do you mean? If it's declared once in the file, shouldn't that be enough? |
| 17:12 | <Ms2ger> | Anyway, off for a bit |
| 17:13 | <GPHemsley> | Because you already can't have a local term that has the same name as an external term |
| 17:17 | <Ms2ger> | A kind of from foo import bar, then? |
| 17:27 | <GPHemsley> | Ms2ger: If that's only an analogy, then yes, I suppose. |
| 17:28 | <Ms2ger> | Mm |
| 17:28 | <Ms2ger> | Patches welcome, I guess ;) |
| 17:28 | <GPHemsley> | heh |
| 17:28 | <Ms2ger> | The current situation is a local optimum for me :) |
| 17:28 | <GPHemsley> | perhaps <dfn data-anolis-ref> |
| 17:29 | <GPHemsley> | err |
| 17:29 | <GPHemsley> | perhaps <dfn data-anolis-spec> |
| 17:29 | <Ms2ger> | Mm, and then strip those dfn nodes? |
| 17:30 | <GPHemsley> | <dfn data-anolis-spec> would be treated like <span data-anolis-spec> is now |
| 17:30 | <GPHemsley> | and then <span> will be the same for both local and external terms |
| 17:52 | <GPHemsley> | is 'retrieve' an OK term to use for obtaining a file, or should I use 'fetch'? |
| 17:53 | <Ms2ger> | Probably avoid 'fetch' if you don't mean the one in HTML |
| 17:57 | <GPHemsley> | ok |
| 18:49 | <GPHemsley> | FYI: You can now follow mimesniff commits by following @mimesniff on Twitter. |
| 18:52 | <annevk> | GPHemsley: to define byte is redundant? |
| 18:52 | <annevk> | GPHemsley: I think defining the primitives is quite useful |
| 18:52 | <GPHemsley> | no, I was referring to the mention of the Encoding Standard in URL |
| 18:53 | <GPHemsley> | "Some terms used in this specification are defined in the Encoding Standard." is useless and/or redundant without specifying exactly which terms |
| 18:53 | <GPHemsley> | IMO |
| 18:54 | <annevk> | it's just to get it in the references section, for people who prefer to see the dependencies |
| 18:54 | <annevk> | that's mostly the reason |
| 18:54 | <GPHemsley> | ah, I see |
| 18:55 | <GPHemsley> | still, I think it'd be better if you specified exactly which terms |
| 18:55 | <GPHemsley> | and if Ms2ger happens to implement my feature suggestion, it would simplify things even more |
| 18:55 | <annevk> | I don't want to keep updating boilerplate text |
| 18:55 | <annevk> | indicating which specifications you need to have prior knowledge of is useful |
| 18:56 | <annevk> | me having to keep track of which terms I use exactly is busy work |
| 18:56 | <GPHemsley> | hmm |
| 18:56 | <GPHemsley> | I don't think I agree with you on that point |
| 18:57 | <annevk> | I'm happy to discuss technical matters, editorial matters I'm much less interested in debating |
| 19:00 | <GPHemsley> | very well |
| 19:00 | <GPHemsley> | in that case, any thoughts on my most recent commits? |
| 19:07 | <GPHemsley> | d'oh |
| 19:15 | <annevk> | GPHemsley: fwiw, what you suggested can prolly be automated by implementing some kind of "<!--terms-->" directive in Anolis |
| 19:15 | <annevk> | GPHemsley: if someone does that I'm happy to use it in my specs |
| 19:17 | <annevk> | Velmont: didn't dare to mention green? :p |
| 19:19 | <Hixie> | this is fasciating. Shelley is so pissed at me that even when I agree with her, she says i'm wrong. |
| 19:19 | <annevk> | GPHemsley: HTTP does not define media types, it's some other RFC that HTTP references |
| 19:20 | <annevk> | GPHemsley: <p class=note> and MUST NOT do not go together |
| 19:21 | <annevk> | GPHemsley: I'm not sure if we use "file" or "resource"; I think we use "resource" and I think HTTP headers are considered to be part of the "resource" |
| 19:21 | <annevk> | that was for https://github.com/whatwg/mimesniff/commit/a074d56faecd1d7f9c2558e21b63747248d22e97 |
| 19:22 | <Hixie> | I use "resource" to mean a bag of bits, e.g. the body of an HTTP response. The headers are associated with the resource, but aren't the resource itself. |
| 19:23 | <annevk> | ah yeah |
| 19:24 | <annevk> | GPHemsley: is your idea for the twitter accounts to make them follow their dependencies? |
| 19:24 | <annevk> | GPHemsley: because that seems like a nice inside joke :) |
| 19:46 | <annevk> | not sure why I calculated this, but four years from now the WHATWG will have existed for half the length of the existence of the web at that point |
| 19:49 | <Hixie> | ok so appcache interceptor idea |
| 19:49 | <Hixie> | appcache contains a reference to a JS file |
| 19:50 | <Hixie> | when the appcache is complete and has a declared interceptor, the networking model changes to a third model that just does this: |
| 19:50 | <Hixie> | launch a dedicated worker |
| 19:50 | <Hixie> | each time there's a network request, post the request to the worker in a defined way |
| 19:50 | <Hixie> | e.g. as a { url: '', headers: [], body: '' } object |
| 19:51 | <Hixie> | and a port with the request |
| 19:52 | <Hixie> | the worker then, at its leisure, sends the data back through that port, in the form of one or more messages whose payloads are strings |
| 19:52 | <Hixie> | the payload is concatenated together and treated like an HTTP response |
| 19:52 | <Hixie> | and there's some defined way to end the connection, e.g. sending a payload of 'null' or something |
| 19:52 | <annevk> | I always wondered why that wasn't there |
| 19:54 | <annevk> | but if the worker does not have a DOM, that might suck... |
| 19:54 | <Hixie> | maybe a shared worker instead of a dedicated worker |
| 19:54 | <annevk> | I mean we always tell people to use a DOM, and then suddenly we give them string concat to produce HTML |
| 19:54 | <annevk> | security guys are gonna have a field day with that |
| 19:55 | <annevk> | or field years, more likely |
| 19:55 | <Hixie> | agreed but i dunno what to do about that |
| 19:55 | <Hixie> | though actually, maybe this can't actually be used for HTML anyway |
| 19:55 | <Hixie> | so that's a non-issue |
| 19:56 | <Hixie> | since any time you would use HTML, you don't yet have a cache and worker to get the data from |
| 19:57 | <annevk> | but you'd want to use HTML for this... |
| 19:59 | <annevk> | in fact I think people may even prefer sometimes using something like this over pushState() even when network is available as it makes it much easier to separate server and client logic |
| 20:05 | <GPHemsley> | annevk: Indeed, that was the idea (re followees). :) |
| 20:06 | <annevk> | @encodings is going to be popular |
| 20:06 | <GPHemsley> | annevk, Hixie: So, should keep 'file' or switch to 'resource'? |
| 20:06 | <GPHemsley> | heh |
| 20:07 | <GPHemsley> | +I |
| 20:07 | <annevk> | resource as bag of bits seems cleaner |
| 20:07 | <GPHemsley> | ok |
| 20:08 | <annevk> | hahahaha http://krijnhoetmer.nl/irc-logs/whatwg/20121026#l-783 |
| 20:08 | <annevk> | I need to get to Tokyo somehow |
| 20:15 | <mmiller_> | TabAtkins: hey dude, I'm trying to use your CSS parser to parse jQuery-ui, and I'm running into an error Unknown state 'url-unquote'. Is it a known issue. |
| 20:15 | <mmiller_> | Is that a known issue? |
| 20:16 | <GPHemsley> | annevk: HTTP defines what it means to be a valid media type, syntactically. |
| 20:16 | <annevk> | https://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIStandardURL.idl does not seem to cover mailto: very weird |
| 20:16 | <GPHemsley> | Hixie: Do you explicitly define 'resource' somewhere? |
| 20:17 | <annevk> | GPHemsley: could be, I haven't checked, but it could also be that it just defines the constrained HTTP syntax, but that might be all you need |
| 20:17 | <GPHemsley> | indeed, I think it is |
| 20:17 | <GPHemsley> | media-type = type "/" subtype *( ";" parameter ) |
| 20:17 | <GPHemsley> | type = token |
| 20:17 | <GPHemsley> | subtype = token |
| 20:17 | <GPHemsley> | that's all |
| 20:18 | <annevk> | well and whatever token is, and that you can have whitespace between those tokens because of some text somewhere in HTTP |
| 20:18 | <annevk> | and that for finding the charset parameter it's not entirely followed iirc |
| 20:19 | <annevk> | MIME types are a can of worms |
| 20:19 | <GPHemsley> | annevk: As for note + MUST NOT, what do you recommend? |
| 20:19 | <annevk> | GPHemsley: just say "are not used" because the specification already makes the requirement by not allowing it |
| 20:19 | <GPHemsley> | ok |
| 20:20 | <GPHemsley> | ah, interesting |
| 20:21 | <annevk> | "official" sounds kinda lame btw, can't you just say, to determine the "media type" of a file? |
| 20:21 | <GPHemsley> | I didn't pick up on the whitespace issue |
| 20:21 | <GPHemsley> | annevk: We have two different fversions of that |
| 20:22 | <GPHemsley> | there's the media type as told to us by the server, and then there's the media type that we detect from the actual bytes |
| 20:22 | <GPHemsley> | i.e. "official media type" vs. "sniffed media type" |
| 20:22 | <annevk> | I'd go with "media type" and "sniffed media type" (or "actual media type") |
| 20:23 | <GPHemsley> | alright |
| 20:23 | <annevk> | it's not official if it's ignored :) |
| 20:23 | <GPHemsley> | I was just building off of the existing text here |
| 20:24 | <GPHemsley> | oh, but then that conflicts with my other definition of "media type" |
| 20:24 | <GPHemsley> | maybe suggested? |
| 20:27 | <GPHemsley> | annevk: "suggested media type" vs. "actual media type"? |
| 20:28 | <annevk> | GPHemsley: "specified" |
| 20:28 | <GPHemsley> | ok |
| 20:28 | <annevk> | oh man, now I'm editorializing |
| 20:28 | <annevk> | I better focus on something else :) |
| 20:29 | <annevk> | like reading https://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIStandardURL.idl again |
| 20:29 | <annevk> | still looks weird |
| 20:29 | <annevk> | ooh, I suppose mailto is not a "standard URL" |
| 20:32 | <annevk> | Is https://mxr.mozilla.org/mozilla-central/ident?i=getRelativeSpec actually used? does not seem exposed to the platform |
| 20:32 | <annevk> | interesting function though |
| 21:16 | <GPHemsley> | File Anolis bug so no one forgets: https://bitbucket.org/ms2ger/anolis/issue/7/support-external-definition-dependencies |
| 21:17 | <GPHemsley> | +d |
| 22:22 | <GPHemsley> | gee, this place sure empties out on a Friday afternoon... |
| 22:33 | <Hixie> | GPHemsley: i try to avoid having anything depend on the exist meaning of the word "resource", but the html spec has some handwaving about it somewhere |
| 22:34 | <Hixie> | GPHemsley: in particular, things to be wary of (and reasons not to use the term "file") include that resources can be infinite, that they might have no name or metadata, that they might be finite but slow (e.g. 10 bytes spread over 10 seconds, impossible to get quicker), etc |
| 22:52 | <Hixie> | hmmmmmmm. |
| 22:52 | <Hixie> | i wonder if instead of a shared or dedicated worker, it should be a new kind of worker |
| 22:52 | <Hixie> | ApplicationCacheInterceptWorkerGlobalScope or something |
| 22:53 | <Hixie> | it wouldn't be something you can _directly_ communicate with, but you could have it connect to a shared worker and share stuff that way |
| 23:06 | <Hixie> | are XHR headers ordered? anyone know? |
| 23:06 | <Hixie> | looks like yes |
| 23:07 | <Hixie> | i wonder if it's ok to drop the sort order for request headers across names |
| 23:08 | <Velmont> | 21:18 < annevk> Velmont: didn't dare to mention green? :p |
| 23:09 | <Velmont> | annevk: Hehe... I was actually more specifically talking about IndexedDB, and this was specifically for writing tests, so no wonder they should use the real (ED) version. |
| 23:10 | <Velmont> | annevk: But I did say «Don't ever see blue, like ever, this should always be red. If it's blue, you're looking at some outdated old crap» <-- something like that. |
| 23:10 | <Velmont> | Fired people up well and good ;-P |