| 00:45 | GPHemsley | imagines what a world with an Internet Media Type like 'archive/tar+gz' would look like. |
| 00:46 | <GPHemsley> | 'archive/tar+gzip' perhaps |
| 00:47 | <GPHemsley> | archive/tar+bzip2 |
| 00:49 | <GPHemsley> | archive/xpi+zip |
| 00:49 | <GPHemsley> | hmm... needs some work |
| 00:52 | <GPHemsley> | image/svg+xml+bzip2 |
| 00:53 | <GPHemsley> | maybe image/svg+xml.bzip2 |
| 00:54 | <GPHemsley> | image/svg+xml$bzip2 |
| 00:55 | <GPHemsley> | image/svg+xml!bzip2 |
| 00:55 | GPHemsley | shrugs. |
| 01:11 | GPHemsley | also thinks that there should be an alias system, similar to how Encoding is doing it. |
| 02:52 | <wirepair_> | anyone here work with HSTS? |
| 03:03 | <MikeSmith> | aleray: you could try using validator.nu HTML parser instead |
| 03:03 | <MikeSmith> | http://about.validator.nu/htmlparser/ |
| 03:04 | <wirepair_> | hey mike, are you familiar with HSTS at all? |
| 03:04 | <MikeSmith> | wirepair_: nope sorry |
| 03:04 | <MikeSmith> | dunno even what it is |
| 03:04 | <wirepair_> | strict-transport-security |
| 03:04 | <MikeSmith> | ah |
| 03:04 | <wirepair_> | for forcing https |
| 03:04 | <MikeSmith> | yeah |
| 03:04 | <MikeSmith> | so yeah heard of it but don't know the details |
| 03:04 | <MikeSmith> | never have worked with it |
| 03:05 | <wirepair_> | ok thanks anyways :) |
| 03:29 | <MikeSmith> | wirepair_: I guess abarth would be a good person to ask |
| 03:29 | <MikeSmith> | when he's around |
| 03:30 | <wirepair_> | yeah |
| 03:30 | <wirepair_> | will do |
| 03:35 | <Hixie> | GPHemsley: "archive" is spelt "multipart" in mime's world |
| 04:25 | <GPHemsley> | Hixie: AFAICT, "multipart" is mostly used for things like e-mail, where multiple files are included in a single file body, with a particular format. That's not the same as an "archive" as I would define it. |
| 04:25 | <GPHemsley> | "The body must then contain |
| 04:25 | <GPHemsley> | one or more body parts, each preceded by a boundary delimiter line, |
| 04:25 | <GPHemsley> | and the last one followed by a closing boundary delimiter line." |
| 04:26 | <GPHemsley> | I'd say it's rather e-mail specific. |
| 04:27 | <GPHemsley> | or "Internet message", if you'd like |
| 04:28 | <GPHemsley> | (multipart/voice-message suggests it's not just e-mail) |
| 04:28 | <GPHemsley> | but still, the list is small, and I don't think "multipart" and "archive" are necessarily the same thing |
| 04:29 | <GPHemsley> | The worst part, as annevk knows from his dealings with URLs, is that it's hard to track down the set of documents that describe all of what a MIME/Internet media type is and how the registry works, etc. |
| 04:30 | <GPHemsley> | It's strewn over a bunch of different RFCs, some of which are only partially obsoleted |
| 04:31 | <Hixie> | oh MIME definitely used to be for e-mail only |
| 04:31 | <Hixie> | i'm just saying the type that MIME uses for multiple files (an archive) is "multipart" |
| 04:31 | <Hixie> | but yes, multipart does imply a particular format for historical reasons |
| 04:31 | <GPHemsley> | I don't think you'd ever see something like "multipart/zip", even if that format restriction was lifted |
| 04:32 | <GPHemsley> | but I just discovered that there is currently a new draft document in the works |
| 04:32 | <GPHemsley> | http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14 |
| 04:34 | <GPHemsley> | I don't have the mind to read it fully right now, though |
| 04:34 | <Hixie> | yeah, i was just coming to that conclusion myself :-) |
| 04:34 | <zewt> | what was "application/*" ever even supposed to mean |
| 04:34 | <GPHemsley> | last updated in June... not sure what that means for its progress |
| 04:35 | <zewt> | "a format read by applications" doesn't seem like it's much of a categorization, heh |
| 04:35 | <GPHemsley> | zewt: One of the RFCs describes that somewhere, but I'm too tired to look it up |
| 04:35 | <GPHemsley> | probably not a great definition, whatever it is, though |
| 04:36 | <zewt> | guessing it's something meaningless, because it sure seems like a meaningless group |
| 04:36 | <GPHemsley> | Does the RFC Editor's Queue mean that a draft is almost done? |
| 04:36 | GPHemsley | is not up on IETF terminology |
| 04:37 | <zewt> | actually it just seems like a weird name for "we don't have a category for this" |
| 04:38 | <GPHemsley> | probably |
| 04:38 | <zewt> | or at least that's what it turned into |
| 04:38 | <GPHemsley> | I was wondering whether also having "document" would make things better or worse |
| 04:39 | <zewt> | coming up with a bunch of new categories probably wouldn't actually help make things less confusing, particularly since it's not a single axis categorization so there's going to be overlap |
| 04:41 | <GPHemsley> | The only two I'm really proposing are "font" and "archive"; I think those are distinct enough to warrant their own categories. |
| 04:41 | <GPHemsley> | I think we can probably deprecate a few categories, too. |
| 04:41 | <GPHemsley> | But IDK. I haven't spent too much time thinking about it or looking into it yet. |
| 04:42 | <zewt> | but there are already mime types for the major file formats in use, so unless you think there'll be a big influx of new archive formats... |
| 04:42 | Hixie | mumbles something about just dropping this whole thing as much as possible |
| 04:42 | <GPHemsley> | (I did see a suggestion that "font" is being used in the wild somewhere.) |
| 04:42 | <GPHemsley> | zewt: Well, I was also proposing an alias mechanism, too. |
| 04:42 | <GPHemsley> | Hixie: The problem is, magic numbers aren't always magic. |
| 04:43 | <GPHemsley> | Nor should they always be. |
| 04:43 | <zewt> | sounds like something that would cause breakage and busywork |
| 04:43 | <GPHemsley> | Mozilla uses various ZIP-derived formats, for example. They're really just rebranded ZIPs, actually. Magic numbers wouldn't allow that. |
| 04:44 | <zewt> | but introducing an "archive/zip" alias for application/zip would only be making things more complicated |
| 04:45 | <GPHemsley> | zewt: It depends on how it was implemented/specced. Without any specifics, it's probably not worth speculating. |
| 04:45 | <zewt> | if it results in people serving ZIPs from HTTP servers with "Content-Type: archive/zip", then i don't think it matters how it's specced |
| 04:46 | <zewt> | it's something that people have to handle that they don't have to today |
| 04:48 | <GPHemsley> | It's a lot easier to handle "archive/*" than arbitrary types |
| 04:48 | <zewt> | you have to handle arbitrary types; application/zip isn't going away |
| 04:49 | <GPHemsley> | alright; like I said, I'm tired; not worth getting into a discussion right now |
| 04:49 | <zewt> | anyone who wants to say "match all mime types that are archive-like formats" will always need a list of formats |
| 04:50 | <GPHemsley> | zewt: We can discuss this more tomorrow, if you want. (Feel free to review mimesniff in the meantime.) |
| 04:50 | GPHemsley | heads off to bed. |
| 04:51 | <GPHemsley> | Oh, P.S.: http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-07 |
| 04:56 | <MikeSmith> | jgraham: I have a PDF copy of that HTML5 parser paper |
| 04:57 | <MikeSmith> | the references section lists html5lib |
| 04:58 | <MikeSmith> | and the validator.nu parser |
| 05:00 | <MikeSmith> | there is a section where they identify some markup cases where implementations have "incompatibilities" with the spec |
| 05:01 | <MikeSmith> | they fine one such incompatibility in Safari, 3 in html5lib, and 6 in the vnu parser and Firefox |
| 05:01 | <MikeSmith> | *find |
| 05:02 | <MikeSmith> | and none in Opera or IE |
| 05:02 | <MikeSmith> | one case they say the vnu parser and Firefox get wrong is this: |
| 05:03 | <MikeSmith> | <body><dd><optgroup><dd></dd></body> |
| 05:03 | <MikeSmith> | which parses as <body><dd><optgroup></optgroup></dd><dd></dd></body> in Safari, Opera, html5lib, and IE |
| 05:04 | <MikeSmith> | but as <body><dd><optgroup><dd></dd></optgroup></dd></body> in the vnu parser and FF |
| 05:05 | <MikeSmith> | <body><ruby><button><rp></rp></button></ruby></body> is another case that the vnu parser and FF and also Safari get wrong |
| 05:05 | <MikeSmith> | they parse it as <body><ruby><button></button><rp></rp></ruby></body> |
| 05:05 | <MikeSmith> | but it should stay as <body><ruby><button><rp></rp></button></ruby></body> |
| 05:07 | <MikeSmith> | ah the 3 cases they list as html5lib getting wrong are basically the same case |
| 05:07 | <MikeSmith> | so there're only one thing html5lib gets wrong |
| 05:07 | <MikeSmith> | w |
| 05:07 | <MikeSmith> | which is <body><table><li><li></li></table></body> |
| 05:08 | <MikeSmith> | it should parse as <body><li></li><li></li><table></table></body> |
| 05:08 | <MikeSmith> | but html5lib gives <body><li></li><table><li></li></table></body> |
| 05:09 | <MikeSmith> | and the 6 cases that FF and the vnu parser get wrong basically all come down to variations of the two cases listed above |
| 05:55 | <MikeSmith> | http://www.score.cs.tsukuba.ac.jp/~minamide/html5spec/model.html5 |
| 07:12 | <annevk> | GPHemsley: seems like you're confusing MIME type and HTTP's Content-Encoding header |
| 07:15 | <annevk> | MikeSmith: pretty awesome that they found those bugs |
| 07:19 | <MikeSmith> | annevk: yeah and they found them by only testing with a subset of 24 elements |
| 07:19 | <MikeSmith> | if they tested with more they might find some other things that were missed |
| 07:20 | <MikeSmith> | btw the ruby bug they describe seems to have already been fixed in Gecko and WebKit |
| 07:20 | <MikeSmith> | actually I think it wasn't really even an oversight bug anyway |
| 07:21 | <MikeSmith> | it's just that the spec changed and the versions of Firefox and Safari they tested with at the time were before the parsers were brought up to date with the spec |
| 07:21 | <MikeSmith> | the versions they tested with were from around February I think |
| 07:22 | <annevk> | hmm okay |
| 08:03 | <MikeSmith> | question of the day: |
| 08:03 | <MikeSmith> | "Does IETF have an XML vocabulary for expressing ABNF (RFC 5234?) grammars?" |
| 08:03 | <MikeSmith> | solid gold |
| 08:04 | <MikeSmith> | http://lists.w3.org/Archives/Public/uri/2012Nov/0005.html |
| 08:23 | <zcorpan> | "[whatwg] Question on Limits in Adaption Agency Algorithm" - does the provided case actually hit the loop limit? i'll admit that i don't know how aaa works but it's not obvious to me that it invokes the limit |
| 08:27 | <zcorpan> | though dropping the <i> makes the xyz go as the last child of body, so i guess it does invoke the limit |
| 08:40 | <annevk> | http://code.google.com/p/google-url/issues/detail?id=32 is an interesting discussion |
| 08:40 | <annevk> | it's about that weird behavior you found zcorpan |
| 09:02 | <zcorpan_> | annevk: http://simon.html5.org/tools/js/svg-optimizer/ (use quality 10 or so) |
| 09:05 | <annevk> | zcorpan_: higher is better? |
| 09:05 | <zcorpan_> | yes |
| 09:06 | <zcorpan_> | (try e.g. 0.1) |
| 09:06 | <annevk> | if I increase the quality the file savings get better... |
| 09:06 | <annevk> | oh wait, nm |
| 09:07 | <annevk> | I don't really see the difference between 10 and 100 |
| 09:08 | <annevk> | zcorpan_: but this is very cool; how do I now remove the translate() ? |
| 09:08 | <zcorpan_> | change the viewBox values |
| 09:08 | <annevk> | zcorpan_: add it to each coordinate pair? |
| 09:09 | <zcorpan_> | something like that |
| 09:09 | <annevk> | would be nice if the tool did that |
| 09:11 | <zcorpan_> | this tool is such a gross hack that doing that is not implementable without reimplementing the whole thing in a more proper way |
| 09:11 | <zcorpan_> | like, e.g., operating on the parsed tree instead of the source |
| 09:15 | <annevk> | oh lol |
| 09:15 | <annevk> | okay then |
| 09:16 | <annevk> | did anyone write a tool to translate an SVG path and just get the normalized result? |
| 09:16 | <zcorpan_> | annevk: OH: "The behavior is very well-defined." |
| 09:16 | <annevk> | zcorpan_: I was quite surprised by that one |
| 09:18 | <annevk> | Inkscape reportedly has the ability to do this |
| 10:12 | <annevk> | zcorpan: I just got some SVG from ed and using that in your tool with a high quality makes the size bigger |
| 10:13 | <zcorpan> | annevk: not surprising if the original svg already uses integers for the coordinates, e.g. |
| 10:13 | <annevk> | k |
| 10:27 | <kennyluck> | I made a demo for calculating the dimension of a replaced element for whoever is interested: http://lists.w3.org/Archives/Public/www-archive/2012Nov/att-0010/replaced-element-dimension-calulation |
| 10:28 | <kennyluck> | It's a bit shocking that there's still non-interoperable case for this sort of thing... |
| 10:29 | <kennyluck> | (Note that most of the circles are draggable) |
| 10:31 | <annevk> | shocking and non-interoperable do not go together in one sentence |
| 10:32 | <annevk> | ;) |
| 10:33 | <SimonSapin> | kennyluck: How does it work? What is each line? |
| 10:33 | <kennyluck> | huh |
| 10:33 | <annevk> | MikeSmith: public-iri has a restricted list? |
| 10:33 | <MikeSmith> | shouldn't |
| 10:33 | <kennyluck> | SimonSapin, the rectangle is the min/max constraint. |
| 10:33 | <annevk> | MikeSmith: you have to subscribe in order to post to it apparently |
| 10:34 | <MikeSmith> | hmm |
| 10:34 | <MikeSmith> | lemme check |
| 10:34 | <MikeSmith> | I can change that |
| 10:34 | <kennyluck> | SimonSapin, orange circle is the intrinsic dimension and the green circle is the specified dimension |
| 10:34 | <annevk> | my message did get archived at http://lists.w3.org/Archives/Public/uri/2012Nov/0007.html so I suppose it's not a big problem |
| 10:34 | <annevk> | but it's kind of a nuisance if someone cc's public-iri and you reply to that |
| 10:35 | <MikeSmith> | yeah |
| 10:35 | <kennyluck> | SimonSapin, oh, the red circle is the result dimension. |
| 10:36 | <SimonSapin> | kennyluck: I see, thanks |
| 10:36 | <kennyluck> | So I think to explain the min/max table for a replaced element in terms of this graph, it's something like this: |
| 10:39 | <kennyluck> | For a replaced element with intrinsic side and both dimension being 'auto' (not specified), the result dimension is the closest point from the intrinsic line to the constraint rectangle. Whenever there are multiple closest results (2 or infinity), the result dimension is the one that's closest to the intrinsic point. |
| 10:40 | <kennyluck> | s/2 or infinity/infinite ones/ |
| 10:55 | <hsivonen> | MikeSmith: did the authors of the paper send it to you as a bug report? or was it up to you to discover that someone had written a paper about bugs without actually filing the bugs? |
| 10:58 | <jgraham> | hsivonen: Did you see the paper? |
| 10:58 | <hsivonen> | jgraham: no |
| 10:58 | <hsivonen> | jgraham: just a bug MikeSmith filed based on the paper |
| 11:06 | <hsivonen> | GPHemsley: my advice is trying to avoid fighting the IANA to make application/* make sense. |
| 11:06 | <hsivonen> | GPHemsley: better just treat the "application/" part as meaningless legacy boilerplate and move on with life. |
| 11:07 | <annevk> | fwiw, if you don't want jreschke to call you on that, s/IANA/IETF/ |
| 11:07 | <annevk> | IANA supposedly does as they're told (except for when they broke all the registry URLs, that was them) |
| 11:23 | <kennyluck> | What paper? |
| 11:25 | <annevk> | kennyluck: http://krijnhoetmer.nl/irc-logs/whatwg/20121104#l-276 |
| 11:26 | <kennyluck> | annevk, thanks~ |
| 12:02 | <annevk> | http://html5.org/temp/unicorn.svg is now much smaller |
| 12:03 | <annevk> | further improvements under CC0 welcome |
| 12:05 | <annevk> | haha |
| 12:05 | <annevk> | that URL from that google-url bug report |
| 12:05 | <annevk> | http://%ef%bc%85%ef%bc%94%ef%bc%91.com/ |
| 12:05 | <annevk> | gives different results in almost every browser |
| 12:06 | <annevk> | Safari's host name is the best ％４１.com (yes using fullwidth %, 4, and 1 afaict) |
| 12:07 | <annevk> | "The behavior is very well-defined." |
| 12:23 | <annevk> | matjas: you around? saw that １ turns into some Punycode string per http://mothereff.in/punycode but no browser does that, not even Opera |
| 12:23 | <annevk> | matjas: so if that's IDNA2008... well... |
| 12:24 | <matjas> | annevk: you’re really finding all the edge cases aren’t you :) good catch |
| 12:26 | <matjas> | filed https://github.com/bestiejs/punycode.js/issues/12 |
| 12:29 | <Lachy> | "Polyglot markup is a super subset…" (from public-html) - WTF is a "super subset"? How can it be both a superset and a subset at the same time?! |
| 12:29 | <AryehGregor> | Perhaps it's just a particularly awesome type of subset. |
| 12:37 | <[tm]> | heh |
| 12:37 | Stevef | a day in the leif |
| 12:38 | <FireFly> | Wouldn't that basically be the definition of set equality? (being both a subset and superset of another set) |
| 12:41 | <annevk> | I think what's meant is "extended subset" |
| 12:44 | <annevk> | oh, that's not what's meant |
| 12:46 | <hsivonen> | besides, “extended subset” is a joke |
| 12:47 | <jgraham> | But also a term that people are using in ernest, I think? |
| 12:48 | <hsivonen> | sadly, that may be true |
| 12:49 | <jgraham> | I actually can't tell what Leif means |
| 12:51 | <jgraham> | This is not unusual |
| 12:54 | <annevk> | matjas: I'm really just doing some adhoc testing, I actually should do a thing where I just pour all code points in and see what comes out, but I'm lazy |
| 12:57 | <annevk> | matjas: so afiact what you're doing is correct per IDNA2008 |
| 12:58 | <annevk> | matjas: mapping fullwidth to ASCII is something that's allowed in the UI layer (not required), but not the protocol layer, I wouldn't count <a href=""> as part of the UI layer |
| 12:59 | <hsivonen> | so I’m bad at this sysadmin stuff. |
| 12:59 | <hsivonen> | how should I debug when I have the same /etc/cron.d/foo file on two Ubuntu boxes |
| 12:59 | <zcorpan> | hsivonen: we made <a href="®=2"> parse different from legacy IE on the basis that legacy IE was not what people expect and there were few enough pages relying on this that we could change it |
| 12:59 | <zcorpan> | hsivonen: i had to argue the case to convince Hixie to change it |
| 12:59 | <hsivonen> | both have the same file permissions |
| 13:00 | <hsivonen> | the cron job works on only one of the Ubuntu boxes |
| 13:00 | <hsivonen> | how to debug? |
| 13:00 | <hsivonen> | zcorpan: ok |
| 13:01 | <hsivonen> | zcorpan: I think we shouldn’t change how it parses, but I think it’s bad that it isn’t a parse error |
| 13:01 | <annevk> | hsivonen: http://serverfault.com/ ? |
| 13:02 | <annevk> | hsivonen: not sure that's a maintained site, mind you |
| 13:08 | <hsivonen> | init: cron main process (314) killed by TERM signal |
| 13:08 | <hsivonen> | there’s my problem |
| 13:09 | <matjas> | annevk: http://mathias.html5.org/data/unicode/format?version=6.1.0&property=Any&type=symbols may be useful for your tests |
| 13:09 | <matjas> | annevk: see http://mathias.html5.org/data/unicode/ for README |
| 13:14 | <MikeSmith> | hsivonen: authors of that paper did not send a bug report to me |
| 13:14 | <MikeSmith> | and at the point when I first read the paper I didn't know it might be describing any bug cases |
| 13:15 | <hsivonen> | MikeSmith: ok. not cool. |
| 13:15 | <MikeSmith> | I just read it because I saw that one of them had posted an interesting question to the whatwg list recently. I didn't know about the paper at that point but I found it when looking at his about page as Tsukuba university |
| 13:16 | <MikeSmith> | hsivonen: yeah they should have taken the time to report the bug |
| 13:16 | <MikeSmith> | the paper is interesting |
| 13:16 | <MikeSmith> | the parts of it that I can understand at least |
| 13:18 | <MikeSmith> | the paper describes a method for generating test cases |
| 13:18 | <MikeSmith> | starting by using a language they developed to formalize the parser algorithm |
| 13:19 | <hsivonen> | looks like I had a midway interrupted update of cron itself on the system |
| 13:19 | <hsivonen> | dpkg --configure -a |
| 13:19 | <hsivonen> | did something to cron |
| 13:19 | <MikeSmith> | the method could be used to generate a lot more test cases if it were expanded to cover more than just the 24 elements they limited it to |
| 13:20 | <MikeSmith> | "we exclude formatting elements from our formalized specification because of difficulties with the destructive manipulation of the stack" |
| 13:21 | <MikeSmith> | "We are planning to address this limitation by checking the reachability to the first point where a destructive operation on the stack is required." |
| 13:21 | <Ms2ger> | Defining html parsing with a formal grammar�still hard? |
| 13:21 | <MikeSmith> | Ms2ger: still hard I guess |
| 13:22 | <hsivonen> | I wonder if someone offers bugzilla hosting priced by amount of traffic/bugs and allows custom hostnames |
| 13:22 | <hsivonen> | I’d like not having to run bugzilla.validator.nu myself |
| 13:23 | <hsivonen> | specifically, exposing perl and a bunch of CGI scares me from the security POV |
| 13:24 | <hsivonen> | this sysadmin stuff is really not my cup of tea |
| 13:24 | <Ms2ger> | perl scares me from any POV |
| 13:30 | <annevk> | hsivonen: why not ask for a Product on w3.org? |
| 13:30 | <annevk> | hsivonen: and just redirect there? |
| 13:30 | <hsivonen> | annevk: not sure what the Freedom to Leave situation at w3.org is |
| 13:31 | <annevk> | WHATWG is happy there |
| 13:31 | <hsivonen> | also, I’d like to keep the old bug numbers |
| 13:32 | hsivonen | wonders if Bugzilla works with a vanilla Dreamhost shared host where Dreamhost takes care of updating Perl |
| 13:38 | <annevk> | hsivonen: have a DreamHost account? |
| 13:38 | <annevk> | hsivonen: I'm happy to give you one for trying things out |
| 13:43 | <GPHemsley> | annevk: Where am I confusing MIME type and Content-Encoding? |
| 13:45 | <annevk> | GPHemsley: http://krijnhoetmer.nl/irc-logs/whatwg/20121105#l-24 |
| 13:48 | <GPHemsley> | Hixie: I intend to avoid fighting with the IETF on anything. I was just pondering what would be necessary to improve MIME/Internet media types. |
| 13:52 | <GPHemsley> | Oh, that was supposed to be hsivonen: ^^ |
| 13:53 | <karlcow> | MikeSmith: "Anyway, one problem currently is that a lot of people don't seem to know that the validator.nu HTML parser exists." — http://www.w3.org/mid/20121105074634.GG29943@sideshowbarker |
| 13:53 | <karlcow> | Are there wrappers (or equivalent built-ins) in scripting languages such as python, ruby, php? |
| 13:54 | <MikeSmith> | no |
| 13:54 | <GPHemsley> | annevk: Ah, that. I was confusing the two. I was imagining a world where a file could be described by only a media type. As it stands, would you really be required to have a Content-Encoding header for a .tar.gz file? |
| 13:54 | GPHemsley | wishes that weren't the case. |
| 13:55 | <annevk> | afaik, yes |
| 13:56 | <annevk> | matjas: I think IDNA2008 does require NFC at least, so input like è (e, followed by U+0300) gives the wrong output in your tool compared to browsers |
| 13:56 | <hsivonen> | GPHemsley: application/zip in ancient, so improving it would probably do more harm than good |
| 13:57 | <hsivonen> | .tar.gz is indeed annoying from the type perspective |
| 14:00 | <hsivonen> | GPHemsley: however, AFAICT, .tar.gz is a solved problem |
| 14:00 | <hsivonen> | you say Content-Type: application/x-tar |
| 14:00 | <hsivonen> | Content-Encoding: gzip |
| 14:00 | <annevk> | matjas: this is mostly about processing before Punycode happens though, so how you want to call that is another matter |
| 14:01 | <hsivonen> | and browsers will still save the gzipped file instead of ungzipping on the HTTP layer |
| 14:01 | <annevk> | that's prolly documented nowhere :/ |
| 14:02 | <GPHemsley> | hsivonen: Well, alright. I wasn't necessarily saying it was a problem. I was actually just imagining what it would mean to extend +-suffixes. |
| 14:02 | <hsivonen> | GPHemsley: I’d much rather see documentation for application/x-tar than an invention of archive/tar |
| 14:02 | <GPHemsley> | hsivonen: I found out later that someone had already imagined that; it's written up in an IETF draft. |
| 14:03 | <GPHemsley> | hsivonen: What kind of documentation? |
| 14:03 | <hsivonen> | GPHemsley: saying it exists for starters. Maybe saying that if you are downloading application/x-tar to disk, don’t handle Content-Encoding: gzip on the HTTP layer |
| 14:04 | <GPHemsley> | hsivonen: Ah, so that would be what the +gzip would be useful for; but I see your point. |
| 14:06 | <hsivonen> | hmm. I don’t actually find any explicit code for making Necko not gzip that stuff |
| 14:06 | <hsivonen> | but I just tested and it doesn’t |
| 14:06 | <hsivonen> | hmm. |
| 14:08 | <hsivonen> | GPHemsley: anyway, this stuff needs testing and more than it needs new types |
| 14:08 | <GPHemsley> | Now, the Just Solve the File Format Problem project is documenting as many file formats as they can... but I wonder if it would be useful to have a document somewhere that said "Handle this format according to this spec." |
| 14:08 | <GPHemsley> | Something like "So you want to write a web browser" or something :P |
| 14:09 | <hsivonen> | I think +zip for new types like application/epub+zip is OK, but I think it would be disruptive to try to force it on existing types |
| 14:09 | <hsivonen> | like all the ODF/OOXML stuff |
| 14:09 | <hsivonen> | (there’s a crazy number of MIME types for ODF/OOXML) |
| 14:09 | <zcorpan> | a "So you want to write a web browser" document would probably just say "You must be new here." |
| 14:10 | <hsivonen> | the ODF/EPUB way of putting the MIME type in the file itself at a well-known byte position is kinda cool |
| 14:10 | <hsivonen> | I wonder if any server uses that to generate the Content-Type header |
| 14:10 | <hsivonen> | I suspect not |
| 14:11 | <zcorpan> | hsivonen: like html4 <meta http-equiv>? |
| 14:13 | <hsivonen> | zcorpan: well, that one wasn’t at a known byte pattern |
| 14:13 | <zcorpan> | true |
| 14:16 | <SimonSapin> | what’s wrong with writting a web browser? |
| 14:18 | <SimonSapin> | http://weasyprint.org/docs/tutorial/#weasyprint-navigator |
| 14:21 | <GPHemsley> | annevk: I see that you've spread out your definition of terms across multiple sections in URL, whereas I tend to stick them all into the "Terminology" section in mimesniff. Is there a preference for one way over another? |
| 14:25 | <odinho_> | SimonSapin: I really like that project :-) BTW, I'm _still_ in Lyon :S Waiting for flight now. Will leave in 2h30m. |
| 14:27 | <SimonSapin> | odinho_: eh. trouble with a previous flight? |
| 14:30 | <annevk> | GPHemsley: I put them closest to where they are used |
| 14:31 | <annevk> | GPHemsley: and if they're pretty general I put them in Terminology |
| 14:31 | <GPHemsley> | I see. |
| 14:31 | <GPHemsley> | annevk: How do you define "pretty general"? :) |
| 14:33 | <annevk> | either things that are used in most major sections or things that could move into some "Platform Terminology" document at some point |
| 14:33 | <annevk> | judgment call |
| 14:37 | <zcorpan> | http://vimeo.com/52740599 seems marcos misunderstands how !important works in css (around 9:00-10:00) |
| 14:38 | <annevk> | seems right to me |
| 14:39 | <annevk> | roughly, anyway |
| 14:40 | <odinho_> | Of what I said, it all sounded very much better inside my head :P I need moar training speaking. |
| 14:40 | <zcorpan> | an author rule without !important still overrides a user rule without !important. so adding !important to the author rule doesn't mean it overrides the user rule more. |
| 14:56 | <annevk> | learning way more about IDNA2008 than I ever wanted :/ |
| 15:00 | <annevk> | GPHemsley: btw, for now you only clean up the draft right? no new concepts? |
| 15:00 | <GPHemsley> | annevk: 99%, yeah. |
| 15:01 | <annevk> | okay, as new implementation requirements I'd like to see discussed somewhere and definitely stuff like minting new MIME types |
| 15:01 | <GPHemsley> | incidentally... does <span class=XXX> work? |
| 15:01 | <annevk> | yes |
| 15:01 | <GPHemsley> | ok |
| 15:03 | <GPHemsley> | annevk: Anything in particular you want me to make note of? |
| 15:06 | <annevk> | no, just making sure we have the same understanding about what's going on at a high-level :) |
| 15:06 | <annevk> | though now I'm reading things, I'd prefer if you used "MIME type" as HTML does as media type is something CSS uses |
| 15:07 | <annevk> | GPHemsley: and the thing from XHR I was wondering about was "XML MIME type" which XHR defines |
| 15:08 | <GPHemsley> | annevk: HTML also defines an XML MIME type |
| 15:08 | <annevk> | yeah, as long as they're all the same we're good and at some point we should maybe have a common terminology doc |
| 15:08 | <GPHemsley> | yeah, they're all roughly the same; it's just the precise language that's different |
| 15:09 | <GPHemsley> | as for MIME type: arghhhh |
| 15:11 | <GPHemsley> | I'm pretty sure "Internet media type" is the "official" terminology now |
| 15:11 | <GPHemsley> | it's certainly the name of the Wikipedia article |
| 15:12 | <GPHemsley> | and the IANA calls them media types, too |
| 15:12 | <GPHemsley> | well, parts of it call them MIME media types, so that's not helpful |
| 15:22 | <SimonSapin> | "media type" is not much used anymore in CSS. We talk more of media queries |
| 15:23 | <annevk> | GPHemsley: hmm, I guess I'll defer to Hixie |
| 15:23 | <annevk> | GPHemsley: but if HTML is not going to use "media type" for that, I don't think this document should either |
| 15:23 | <GPHemsley> | annevk: I'll take a page out of Hixie's playbook and say that it's easier for me to do nothing at this point. ;) |
| 15:24 | <GPHemsley> | but we'll see what he says |
| 15:24 | <GPHemsley> | no one has mentioned it before |
| 15:24 | <GPHemsley> | and he has looked at it |
| 15:37 | <annevk> | sure man, I'll keep bringing it up until one of you convinced the other or you both agree :) |
| 15:56 | <annevk> | oh lol |
| 15:56 | <annevk> | http://tools.ietf.org/html/rfc5894#section-4.4 is the rationale document for changes in IDNA2008 |
| 15:57 | <annevk> | "IDNA2008 permits, at the risk of some incompatibility" |
| 15:57 | <annevk> | hahaha |
| 15:58 | <annevk> | (that's about changing the mapping of ß to Punycode form rather than ss, ™ to Punycode form rather than tm, and similar such changes) |
| 15:59 | <MikeSmith> | J. Klensin |
| 16:01 | <annevk> | For an organisation that is concerned with current implementations that sure is a striking statement |
| 16:02 | <annevk> | oh oh oh, we cannot change URI because that would mean implementations are non-conforming, but sure we can piss all over domain names? |
| 16:03 | <MikeSmith> | I kind of wonder whether it might all have been intentional |
| 16:04 | <MikeSmith> | some people really didn't ever like the idea of IDNs |
| 16:04 | <MikeSmith> | sabotage |
| 16:06 | <annevk> | this rationale document also keeps talking about user input |
| 16:06 | <annevk> | user input, really? |
| 16:06 | <annevk> | users use Google |
| 16:06 | <annevk> | the input comes from strings, legacy strings spread all around the web |
| 16:07 | <annevk> | changing their meaning is insane |
| 16:07 | <annevk> | even in the name of "more sensible" and "less surprising" results (I kid you not, that's the justification thus far) |
| 16:08 | <Ms2ger> | Hi, IETF |
| 16:08 | <annevk> | whoever is on the IAB should be ashamed to have let this through |
| 16:10 | <MikeSmith> | whoever it was is probably graduated from the IAB already |
| 16:17 | <annevk> | http://unicode.org/reports/tr46/#Table_IDNA_Comparisons has a nice summary btw |
| 16:18 | GPHemsley | wonders if sniffing should have some sort of requirement that there be binary bytes, to avoid accidentally sniffing plaintext documents. |
| 16:18 | GPHemsley | also wonders whether there should be a requirement that future magic numbers contain at least one binary byte. |
| 16:18 | <annevk> | no and no |
| 16:19 | jgraham | gets confused from Hixie making multiple changes in a single commit |
| 16:20 | <annevk> | WebVTT and cache manifests don't such a byte and would not benefit from it |
| 16:21 | GPHemsley | wonders who annevk is talking to. |
| 16:21 | <annevk> | GPHemsley: last two lines were for you |
| 16:21 | <GPHemsley> | ah |
| 16:21 | <annevk> | GPHemsley: the rest is just blogging on IRC |
| 16:22 | <GPHemsley> | right |
| 16:22 | <GPHemsley> | your responses were generic enough that they could have been towards MikeSmith or someone |
| 16:22 | <GPHemsley> | annevk: But I'm wondering about your second no. |
| 16:23 | <GPHemsley> | I mean, what if I have a text file that begins "GIF89a"? |
| 16:24 | <GPHemsley> | Or worse, "BM" |
| 16:24 | <GPHemsley> | Like, "BMW Motors" |
| 16:24 | <GPHemsley> | that'll get sniffed as a bitmap |
| 16:24 | <annevk> | depends on the context |
| 16:25 | <GPHemsley> | What's the context? It's a file without a Content-Type header. |
| 16:25 | <GPHemsley> | There is no context. |
| 16:25 | <annevk> | loading context |
| 16:25 | <GPHemsley> | It's a file served by HTTP without a Content-Type header. |
| 16:25 | <GPHemsley> | It's the standard always-sniff context. |
| 16:26 | <annevk> | for non-text formats it might make sense to require a zero byte or some such |
| 16:27 | <annevk> | but typically those requirements are not read anyway so I'm not sure it makes sense |
| 16:29 | <GPHemsley> | what do you mean by "not read"? |
| 16:29 | <annevk> | well there's a requirement you register new MIME types for instance, that almost never happens |
| 16:30 | <GPHemsley> | oh, you're still talking about the magic number registration, OK |
| 17:19 | <GPHemsley> | hmm... CSS... |
| 17:28 | <MikeSmith> | so fwiw the IRI WG is meeting f2f at IETF tomorrow |
| 17:29 | <MikeSmith> | https://datatracker.ietf.org/meeting/85/agenda/iri/ |
| 17:29 | <Ms2ger> | Time to set up ietfmemes |
| 17:29 | <MikeSmith> | hahaha |
| 17:29 | <MikeSmith> | yeah |
| 17:30 | <MikeSmith> | anyway the agenda has only 15 minutes set aside for "URI/IRI/URL thread among IETF/W3C/WHATWG (Larry Masinter)" |
| 17:30 | <MikeSmith> | from 18:00 to 18:15 |
| 17:30 | <annevk> | IRI is not that interesting (imo) as you just get percent-encoded stuff out of the parser anyway |
| 17:30 | <annevk> | it's just a syntax |
| 17:31 | <GPHemsley> | annevk, TabAtkins_ : What was the discussion recently about charset determination for CSS? |
| 17:31 | <GPHemsley> | In particular, where does the outcome of that discussion now reside? |
| 17:31 | <annevk> | GPHemsley: css3-syntax |
| 17:32 | <GPHemsley> | Thanks. |
| 17:35 | <TabAtkins_> | GPHemsley: Yeah, I updated Syntax to the latest sometime last week. |
| 17:39 | <GPHemsley> | thanks |
| 17:58 | <TabAtkins_> | GPHemsley: Just to make sure, you're looking at dev.w3.org/csswg/css3-syntax, right? |
| 17:58 | <GPHemsley> | yup |
| 17:58 | <TabAtkins_> | GPHemsley: Also, I forget, did I end up meeting you sometime last week? |
| 17:58 | <GPHemsley> | heh, no |
| 17:58 | GPHemsley | has gone anywhere. |
| 17:58 | <GPHemsley> | n't |
| 17:58 | <Ms2ger> | You've gone anywhere? :) |
| 18:01 | <GPHemsley> | brain <--> fingers |
| 18:09 | <annevk> | aah, I was hoping zewt showed up in http://lists.w3.org/Archives/Public/www-international/ |
| 18:10 | <Ms2ger> | More of a list for crazy, I guess |
| 18:10 | <annevk> | that's why I joined |
| 18:11 | <Ms2ger> | Fair enough |
| 18:12 | GPHemsley | grumbles something about mailing lists. |
| 18:13 | <Ms2ger> | They're support forums |
| 18:13 | <GPHemsley> | I suggest the IETF drop their version of mimesniff, they say they may assign new editors at the IETF meeting this week. |
| 18:14 | <GPHemsley> | -_- |
| 18:14 | GPHemsley | has no interest in participating in territory disputes. |
| 18:15 | <Ms2ger> | Then you came to the wrong place, sir |
| 18:15 | <gsnedders> | WELL IT'S OBVIOUSLY AN IETF SPEC SO WHY ARE YOU STEALING IT FROM US!? |
| 18:16 | <GPHemsley> | My statement that prompted such a response: "That's correct; I do not intend to work on this document through the IETF. I think the potentially fluid nature of the material would be better served as a living WHATWG standard than a frozen RFC. I would recommend that websec drop it as a deliverable." |
| 18:16 | <annevk> | GPHemsley: well, I'd welcome the competition |
| 18:16 | <gsnedders> | GPHemsley: Link? |
| 18:16 | <GPHemsley> | gsnedders: Private e-mail. |
| 18:16 | <annevk> | GPHemsley: history shows that unless a browser vendor is actively involved the IETF outcome is, well, not super |
| 18:17 | <gsnedders> | D'awww. |
| 18:17 | <gsnedders> | Where's the fun in that? |
| 18:18 | <GPHemsley> | gsnedders: Actually, the particular e-mail I'm quoted was also forwarded to a public mailing list without my permission, so you may be able to find it. |
| 18:18 | <GPHemsley> | s/quoted/quoting/ |
| 18:18 | <Ms2ger> | s/unless a browser vendor is actively involved// |
| 18:18 | <GPHemsley> | gsnedders: But not he response. |
| 18:18 | <GPHemsley> | +t |
| 18:18 | GPHemsley | sighs at the keyboard. |
| 18:19 | <GPHemsley> | I don't really understand all these territorial disputes; in my mind, the WHATWG, W3C, and IETF all have different functions. |
| 18:21 | <Ms2ger> | The WHATWG writes specs, the W3C publishes them for patent protection, and the IETF whines about them in 1970's-style text files? |
| 18:22 | <GPHemsley> | lol |
| 18:24 | <annevk> | In the W3C WebApps Charles asked who wanted to become famous by copying WHATWG drafts, putting their name on it, and publishing them at the W3C |
| 18:24 | <annevk> | meeting /\ |
| 18:25 | <gsnedders> | What followed that? |
| 18:26 | <annevk> | gsnedders: sorry? |
| 18:26 | <Ms2ger> | A call for editor for the URL spec? |
| 18:26 | <annevk> | Oh, that was about all drafts I used to edit at WebApps |
| 18:26 | <annevk> | I was in the room too |
| 18:27 | <annevk> | It's such a weird dynamic |
| 18:27 | <gsnedders> | annevk: What was the response from the group? |
| 18:27 | <annevk> | Well they have some volunteers for XHR; Lachy volunteered for DOM |
| 18:27 | <annevk> | dunno about Fullscreen / URL |
| 18:28 | <gsnedders> | So basically they decided who wanted to become famous by copying WHATWG drafts and putting their name on it. |
| 18:28 | <gsnedders> | Well done, W3C. |
| 18:29 | <GPHemsley> | Oh, is that what the IETF is gonna do to me? |
| 18:30 | <annevk> | I'm mostly here to solve problems and to raise problems with capital p Process |
| 18:30 | <annevk> | GPHemsley: well last time IETF tried (about:blank) they rendered their variant way worse so we have to take it back again |
| 18:31 | <annevk> | GPHemsley: I would not expect them to do a good job of capturing requirements of browsers |
| 18:31 | <GPHemsley> | Who does the IETF think they represent, if not the browsers? |
| 18:31 | <annevk> | the Internet |
| 18:31 | <GPHemsley> | which is... who, exactly? |
| 18:32 | <Ms2ger> | The Internet |
| 18:32 | <GPHemsley> | or do they do ephemeral work for an ephemeral entity? |
| 18:32 | <karlcow> | http://www.ietf.org/about/ |
| 18:33 | <gsnedders> | GPHemsley: Everyone who uses the internet. |
| 18:33 | <GPHemsley> | karlcow: According to that, their area should be restricted to networking architecture. |
| 18:34 | <GPHemsley> | As long as the Web can be built on that architecture, they have no jurisdiction over the Web. |
| 18:34 | <GPHemsley> | In theory. |
| 18:34 | Ms2ger | sniggers |
| 18:34 | <karlcow> | GPHemsley: history, social dynamics, communities. People != robots. Or at least they try sometimes. |
| 18:35 | <GPHemsley> | karlcow: Pfft. |
| 18:35 | <karlcow> | QED. :) |
| 18:36 | <Ms2ger> | □ |
| 18:37 | <GPHemsley> | :) |
| 18:37 | <GPHemsley> | Well, I guess we solved the Internet. We can all go home now. |
| 18:38 | <karlcow> | Was there something to solve? :) |
| 18:38 | <karlcow> | There is a story, but nothing to solve. |
| 18:38 | <karlcow> | It's more like an epic poem. |
| 18:38 | <GPHemsley> | Emphasis on the "epic" |
| 18:38 | <karlcow> | yup |
| 18:39 | <karlcow> | I meant https://en.wikipedia.org/wiki/Epic_poetry |
| 18:41 | <karlcow> | talking about it, I should go for writing a bit about webdriver hopes for testing. :) |
| 18:47 | <annevk> | ah karl left? |
| 18:48 | <annevk> | I was gonna say, I hope our epic poem is somewhat easier to read than e.g. that of John Milton |
| 18:48 | <annevk> | but then I suspect for many people it isn't :/ |
| 18:52 | <annevk> | why does Fullscreen link to both HTML and HTML5? |
| 18:52 | <annevk> | did I do that? |
| 18:53 | <annevk> | ah https://github.com/whatwg/fullscreen/commit/1991f306a4e4e37c450542e29e78075de06305d2 |
| 18:53 | <annevk> | hmm |
| 19:01 | <GPHemsley> | In case anyone here is interested, I filed a Mozilla bug on mimesniff implementation earlier today: https://bugzilla.mozilla.org/show_bug.cgi?id=808593 |
| 19:17 | <annevk> | GPHemsley: I guess the stuff Zack mentions there could be done in a "css sniffing context" (or whatever that's called now) |
| 19:17 | <annevk> | GPHemsley: currently HTML defines those rules, and I'm not sure if they apply outside of HTML... |
| 19:18 | <GPHemsley> | right... I didn't finish investigating how far the HTML go |
| 19:18 | <GPHemsley> | +rules |
| 19:18 | <GPHemsley> | nor is it clear to me when CSS would be parsed outside of HTML |
| 19:19 | <GPHemsley> | (and thus not be covered by HTML rules) |
| 19:19 | <annevk> | SVG |
| 19:19 | <annevk> | CSS referencing CSS |
| 19:19 | <annevk> | HTTP Link header in some implementations |
| 19:20 | <annevk> | (but the last one should prolly be removed) |
| 19:20 | <annevk> | <?xml-stylesheet?> |
| 19:20 | <GPHemsley> | CSS doesn't give rules about how to parse other potentially CSS files? |
| 19:20 | <annevk> | although CSSOM might describe it for that at the moment |
| 19:21 | <annevk> | GPHemsley: CSS doesn't define the edges well, generally speaking |
| 19:21 | <GPHemsley> | I wouldn't even know how to go about sniffing CSS |
| 19:22 | <annevk> | GPHemsley: e.g. @import url(test\ test); // CSS does not define how to parse that URL well and does not define how it's fetched (what Referer is etc.) and does not define what to do with the result if it e.g. lacks a content-type header; in a way that matches implementations |
| 19:22 | <annevk> | GPHemsley: it's not exactly sniffing |
| 19:22 | <annevk> | GPHemsley: it's more like, lacks content-type, assume it's text/css if these other conditions are true |
| 19:22 | <GPHemsley> | annevk: Are there flaws in that method? |
| 19:23 | <GPHemsley> | annevk: Or is it just not specced? |
| 19:23 | <annevk> | as I said, it's specced in HTML, but whether it should apply elsewhere too is unclear |
| 19:23 | <GPHemsley> | right |
| 19:23 | <GPHemsley> | and you think it's within the scope of mimesniff to document that/ |
| 19:24 | <GPHemsley> | ? |
| 19:24 | <annevk> | kinda |
| 19:24 | <annevk> | lacks Content-Type, so what to do? |
| 19:25 | <GPHemsley> | well, without special handling, running it through the unknown sniffing algorithm would return text/plain, I think |
| 19:25 | <annevk> | model brainstorming: URL -> HTML fetch -> resource |
| 19:25 | <GPHemsley> | sounds reasonable |
| 19:25 | <annevk> | resource + context -> determine type |
| 19:25 | <annevk> | determine type is MIME sniffing |
| 19:26 | <annevk> | then process resource |
| 19:26 | <annevk> | based on type |
| 19:26 | <GPHemsley> | I see |
| 19:26 | <GPHemsley> | hmm |
| 19:26 | <GPHemsley> | who defines context? |
| 19:26 | <annevk> | the step before URL |
| 19:27 | <annevk> | API.resource = Fetch(API.url) |
| 19:28 | <annevk> | API.resource.type = MIME Sniffing(API.resource, API.context) |
| 19:28 | <annevk> | API.context can be something like "image context" |
| 19:29 | <GPHemsley> | so, "sniffing * specifically" = context? |
| 19:30 | <annevk> | if I rename context to constraints, does that help? |
| 19:31 | <GPHemsley> | neither is a term I use in mimesniff, so not really :P |
| 19:32 | <annevk> | e.g. for <img> you want to use the image sniffing rules for the resource you fetched |
| 19:32 | <GPHemsley> | I'm just trying to determine exactly which parts fall into my jurisdiction |
| 19:32 | <annevk> | <img> would be the API in the above example |
| 19:33 | <GPHemsley> | OK; <img> current invokes the 'rules for sniffing images specifically' |
| 19:33 | <annevk> | yeah that works |
| 19:33 | <GPHemsley> | +ly |
| 19:33 | <GPHemsley> | geez, keyboard |
| 19:34 | <annevk> | I guess my thinking was to have "get the MIME type for resource /resource/, constrained with /images/" or some such |
| 19:36 | <annevk> | not sure btw CSS really fits well into this model though, as I believe a number of things depend on whether the fetching resource is in standards mode and whether it's cross-origin or same-origin |
| 19:37 | <GPHemsley> | right now, I have the general sniffing algorithm that calls the various pattern matching algorithms based on UA preferences |
| 19:38 | <GPHemsley> | and then I have the separate algorithms that also call the pattern matching algorithms which can be used for hooks like HTML needs |
| 19:39 | <GPHemsley> | HTML calls the 'rules for distinguishing if a resource is text or binary' directly to work around the same Apache bug the main sniffing algorithm works around. |
| 19:39 | <GPHemsley> | and HTML calls the 'rules for sniffing images specifically' when dealing with images (<link>, <img>, <button>, <object>, etc.) |
| 19:40 | <GPHemsley> | otherwise, I think it defers to the 'media type sniffing algorithm' for detecting MIME types |
| 19:40 | <GPHemsley> | (or, it will, whenever Hixie gets around to updating references to the new spec) |
| 19:42 | <GPHemsley> | perhaps I could say somewhere that if a file is expected to be CSS and the sniffer determines it to be 'text/plain', then assume it's 'text/css'? |
| 19:45 | <asmodai> | I seriously wonder what this person thought when he put black text on a white/grey checkered background. |
| 19:45 | <annevk> | GPHemsley: it's not that simple |
| 19:46 | <GPHemsley> | annevk: Well, I'm not sure how else to worm my way into other specs. |
| 19:47 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/#link-type-stylesheet |
| 19:47 | <annevk> | not sure why that's just quirks mode though |
| 19:47 | <annevk> | Zack seemed to suggest it affects standards mode too |
| 19:48 | <annevk> | but it doesn't make much sense to define that override in MIME sniffing imo |
| 20:19 | <Hixie> | hober: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18365#c6 "defined" is a strong word to use... :-P |
| 20:20 | <annevk> | heh |
| 20:21 | <annevk> | scumbag hober: says something is defined; is not actually defined :p |
| 20:22 | <Hixie> | nah, that would be if he said he would define it himself |
| 20:22 | <annevk> | fair enough |
| 20:23 | <GPHemsley> | lol |
| 20:30 | <annevk> | hmm so what Opera implements for http://™/ neither matches IDNA2003 nor IDNA2008 |
| 20:30 | <GPHemsley> | Has anyone written a search: protocol so that you can link to the user's default search engine? |
| 20:31 | <annevk> | ™ is in IDNA2008's DISALLOWED class and has a mapping to "tm" for IDNA2003 |
| 20:31 | <annevk> | GPHemsley: http://www.iana.org/assignments/uri-schemes.html suggests no |
| 20:31 | <GPHemsley> | anyone else think one would be useful? |
| 20:32 | <annevk> | Opera maps ™ to "y2g" per Punycode which is probably correct, but it's not correct in the first place... |
| 20:33 | <annevk> | But Ａ is mapped to a... |
| 20:36 | <annevk> | Maybe Opera only implements the UI mapping http://tools.ietf.org/html/rfc5895#section-2 ? And somehow implements that for <a> too which is not UI? |
| 20:36 | <annevk> | Not really sure what Opera has done here makes a lot of sense... |
| 20:46 | <Hixie> | GPHemsley: isn't that what web intents was for? |
| 20:46 | <Hixie> | not sure what's going on with web intents |
| 20:46 | <GPHemsley> | Hixie: link? |
| 20:46 | jgraham | now has "let's Push Things Forward" by The Streets in his head, but with a web platform twist (You say every browser don't render the same / Then you download them / There ain't no excuses my friend / Let's test the web forward) |
| 20:46 | <Hixie> | GPHemsley: search:web%20intents ? :-) |
| 20:46 | <GPHemsley> | ^_^ |
| 20:46 | <jgraham> | Well that and "In the Aeroplane Over the Sea" |
| 20:47 | <jgraham> | Playing on top of each other |
| 20:47 | <GPHemsley> | oh, it has its own website! |
| 20:47 | <jgraham> | Hixie: There were plenty of TPAC sessions about it at least |
| 20:47 | <GPHemsley> | http://lbeach.org/schools/long_beach_high_school |
| 20:47 | <GPHemsley> | argh |
| 20:47 | <GPHemsley> | http://webintents.org/ |
| 20:48 | <jgraham> | Not that I was at most of them |
| 20:48 | <TabAtkins_> | annevk: I'm one of the Values editors, so I can define whatever is necessary for url() handling when I'm told what it is. |
| 20:48 | <GPHemsley> | W3C Editor's Draft 11 September 2012 |
| 20:48 | <TabAtkins_> | annevk: I assume we can get away with something simple in CSS, where we just automatically parse as whatever is necessary for the context without having to sniff much. |
| 20:49 | <TabAtkins_> | annevk: For @import, for example, CSS parsing is defined for all bytestreams, so it should be safe to just immediately parse as CSS regardless. |
| 20:49 | GPHemsley | thinks search: would be much simpler |
| 20:50 | <annevk> | TabAtkins_: yeah, I don't think CSS needs sniffing, it's more about what to do with unexpected Content-Type values or lack of Content-Type |
| 20:50 | <annevk> | TabAtkins_: will let you know when the hook for url() is ready |
| 20:50 | <TabAtkins_> | annevk: I'd have to test to see what browsers actually do, but I don't *think* we actually need to care about Content-Type at all for @import. You do need to sniff for images, of course. |
| 20:50 | <annevk> | TabAtkins_: all the other specs that define values with a url() will need to hook into HTML fetch; I suspect that might be more controversial |
| 20:50 | <Hixie> | jgraham: last i heard it was DOA, but I haven't been even remotely looking closely, so my information may well be way out of date |
| 20:50 | <TabAtkins_> | annevk: That's not problematic - define it once per <type>. |
| 20:51 | <TabAtkins_> | GPHemsley: I kinda like that search: idea. |
| 20:51 | <annevk> | TabAtkins_: well you can't just ignore Content-Type all the time, that might expose sensitive information |
| 20:51 | GPHemsley | starts writing the IETF draft... oh wait |
| 20:51 | <TabAtkins_> | annevk: Really? I wouldn't have thought so, actually. |
| 21:06 | <Hixie> | hsivonen/MikeSmith: can you help the guy out in help⊙wo? He's having trouble getting an uploaded file validate as XHTML on validator.nu, but he's exit my area of expertise |
| 21:06 | <MikeSmith> | Hixie: will take a look |
| 21:06 | <Hixie> | thanks |
| 21:13 | <annevk> | TabAtkins_: yeah e.g. for <link> it's restricted to quirks mode at the moment; not sure about all the details anymore |
| 21:21 | <MikeSmith> | Hixie: replied |
| 21:35 | <Hixie> | thanks |
| 21:36 | <TabAtkins_> | Ahahaha, holy crap, Twitter.com *breaks* if you try and bring up the short-details window for the @__proto__ account. |
| 21:36 | <TabAtkins_> | JS console shows the obvious reason why. |
| 21:36 | <TabAtkins_> | I wonder what it would do about a @toString account? |
| 21:37 | <gsnedders> | @valueOf? |
| 21:37 | <gsnedders> | TabAtkins_: __proto__ in what browser? Different ones have radically different behaviour. |
| 21:37 | <TabAtkins_> | Chrome, at least. Haven't tried the others. |
| 21:37 | <Hixie> | how do i see this? |
| 21:37 | <TabAtkins_> | Hixie: One sec, I'll tweet it. |
| 21:37 | <Hixie> | (don't know twitter well) |
| 21:37 | <Hixie> | k :-) |
| 21:37 | <TabAtkins_> | Then you can just click on it in my tweet. |
| 21:38 | <Hixie> | woops, lunch is gonna end soon |
| 21:38 | <Hixie> | better go get some food |
| 21:38 | <Hixie> | bbiab |
| 21:41 | <TabAtkins_> | Hixie: https://twitter.com/tabatkins/status/265568812320047104 |
| 21:43 | <smaug____> | seems to happen in FF too |
| 21:43 | <TabAtkins_> | Maps can't come soon enough. |
| 23:06 | <jgraham> | TabAtkins_: http://www.2ality.com/2012/01/objects-as-maps.html claims that google docs used to hang with __proto__ at the start of a document |
| 23:07 | <jgraham> | valueOf and toString on twitter seem to be fine, possibly due to case insensitivity |
| 23:07 | <TabAtkins_> | Alternately, they just don't invoke to valueOf or toString behavior on that object. |
| 23:07 | <TabAtkins_> | But they definitely depend on the proto chain. |
| 23:08 | <jgraham> | Sure, it could be that too |
| 23:09 | <jgraham> | But I think that even if they do use those properties it would be fine because the usernames are valueof and tostring |
| 23:11 | <TabAtkins_> | Yeah, if they lowercase it's fine. |
| 23:31 | <zewt> | annevk: fwiw here's a site off the top of my head that *can* use ISO-2022-JP (but it's one of a selection of available encodings, so it may be an outlier) http://rut.org/cgi-bin/j-e/jis/tty/dict |
| 23:31 | <zewt> | i *think* i've seen pages where i've had to pick that encoding to unmojibake it, but can't say for sure |
| 23:34 | <zewt> | wish there was a way to search google by HTTP headers |
