| 00:05 | <GPHemsley> | Hixie_: Sure. Could you file a bug, if there isn't already one? |
| 00:08 | <Hixie_> | sure |
| 00:09 | <GPHemsley> | Hixie_: (I know there's already a bug about clarifying the definitions of the various parts.) |
| 00:10 | <Hixie_> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=21393 |
| 00:10 | <GPHemsley> | thanks |
| 00:13 | <GPHemsley> | Hixie_: FYI, when that change happens, you may have to update references to algorithms. (I think they use "media type".) |
| 00:14 | <Hixie_> | yeah |
| 00:14 | <Hixie_> | just reassign the bug to me if there's something to change on my end |
| 00:16 | <GPHemsley> | Did your recent commit change all sections that reference mimesniff? |
| 00:19 | <Hixie_> | it changed all sections that reference [MIMESNIFF] |
| 00:19 | <Hixie_> | i may have some where i forgot the reference, in which case i missed them |
| 00:19 | <Hixie_> | i definitely have cases where the references are indirect through the first one that mentions MIMESNIFF, i hope they're ok |
| 00:21 | <GPHemsley> | Hixie_: Just so I know, whose responsibility is it to check on that? ;) |
| 00:24 | <Hixie_> | my spec, my responsibility |
| 00:24 | <Hixie_> | but if you see any, let me know :-) |
| 00:34 | <GPHemsley> | Hixie_: Would s/media type/MIME type/ be acceptable, as far as you're concerned? |
| 00:35 | <zewt> | calling mime types "media type" seems like calling urls "uris" and megabytes "mibibytes", heh |
| 00:35 | <GPHemsley> | zewt: We're past that discussion already. |
| 00:35 | <zewt> | javascript "ecmascript" |
| 00:35 | <zewt> | GPHemsley: not until people stop doing them :P |
| 00:36 | <GPHemsley> | zewt: Well, I meant in this context. |
| 00:36 | <GPHemsley> | although your latter two examples have sufficient distinction to warrant separate terms, I think |
| 00:37 | <zewt> | they're all things where somebody took a well-understood term, went "we need a new term for some anal reason!", resulting in more confusion than any conceivable benefit. heh |
| 00:37 | <zewt> | (or some close variant, of course) |
| 00:38 | <GPHemsley> | the binary prefix issue was more than just "some anal reason" |
| 00:38 | <GPHemsley> | and there does exist http://javascript.spec.whatwg.org/ |
| 00:38 | <zewt> | yeah, that's trying to help hard drive marketing departments justify lying |
| 00:39 | <zewt> | also, the idea that anyone would seriously expect me to say "gibibytes" out loud with a straight face is pretty legitimately hilarious |
| 00:39 | <GPHemsley> | (which may or may not fall under your claims of justifications) |
| 00:39 | <GPHemsley> | actually, no, the prefixes maintain the distinction betwen 1000 and 1024 |
| 00:40 | <GPHemsley> | it's just that now, when people use the SI prefixes, they actually mean the SI meanings |
| 00:40 | <GPHemsley> | instead of the binary ones |
| 00:44 | <Hixie_> | GPHemsley: fine by me, but obviously as with any such thing check that the result is sound :-) |
| 00:45 | <GPHemsley> | I think it is; I don't reference CSS, and I didn't really use "MIME type" before. |
| 00:47 | <Hixie_> | i just mean make sure you don't have anything that says "And if you check the <em>media</em> type..." or "the second letter of the term "media type" is "e"" or some such |
| 00:47 | <Hixie_> | obviously those examples are silly |
| 00:47 | <Hixie_> | but you know what i mean |
| 00:48 | <Hixie_> | gotta go |
| 00:50 | <GPHemsley> | ah, hmm... the only conflict might be wrt the terminology discussion about the various parts: does "MIME type portion" make the same amount of sense as "media type portion"? |
| 00:50 | <GPHemsley> | perhaps not, but that terminology should change anyway |
| 00:53 | <GPHemsley> | of course, there may now be a question: should the standard be called "MIME Type Sniffing"? |
| 01:03 | <stevefaulkner> | any known implementations of inert attribute? |
| 01:07 | <falken_> | stevefaulkner: i'm working on it for webkit, but it's not really done |
| 01:08 | <stevefaulkner> | falken_: thanks, what about the dialog element? |
| 01:08 | <falken_> | stevefaulkner: yes, i'm also working on that... something is landed but it also has a lot of work still |
| 01:09 | <stevefaulkner> | falken_: cool! you have a bug number? |
| 01:09 | <falken_> | stevefaulkner: https://bugs.webkit.org/show_bug.cgi?id=84635 |
| 01:10 | <stevefaulkner> | falken_: thanks! |
| 01:10 | <falken_> | stevefaulkner: np |
| 04:38 | <sangwhan> | paul_irish: Yes, I saw this: https://bugs.webkit.org/show_bug.cgi?id=73885 - but there is no rationale, just hard facts. Was curious about the reasoning, apart from it's possibly the lowest hanging fruit. |
| 10:58 | <annevk> | Hmm, what the best list to discuss new Web Notifications features? |
| 10:59 | <annevk> | Or Notifications API features, really. Now public-web-notification has arisen from the death... |
| 11:02 | <smaug____> | hmm, I don't follow public-web-notifications |
| 11:02 | <smaug____> | I think |
| 11:35 | <annevk> | Man, CSP specifications are a mess... |
| 11:35 | <annevk> | If the security crowd gives you that, you gotta wonder... |
| 12:58 | <hsivonen> | how should v.nu pharse the whine about non-UTF-8 encodings? |
| 12:58 | <hsivonen> | how about "Legacy encoding \u201C" + encoding.getCanonName() + "\u201D used. To avoid data loss in form submissions and data corruption in the handling of non-ASCII characters in query strings in URL, documents should use UTF-8." ? |
| 12:59 | <hsivonen> | s/URL/URLs/ |
| 12:59 | <jgraham> | That sounds over-technical to me |
| 13:00 | <jgraham> | Specifically "data corruption in the handling of non-ASCII characters in query strings in URL" |
| 13:01 | <hsivonen> | hmm. and the rationale would be untrue for UTF-16 |
| 13:01 | <hsivonen> | and partially untrue for GB18030 |
| 13:01 | <hsivonen> | just "Legacy encoding \u201C" + encoding.getCanonName() + "\u201D used. Documents should use UTF-8." |
| 13:01 | <hsivonen> | then? |
| 13:03 | <jgraham> | Yeah, if you start getting questions about it then add more information |
| 13:06 | <hsivonen> | old copyright years in license headers make me feel old and unproductive |
| 13:16 | <annevk> | Maybe at some point error messages should have links to more information? |
| 13:18 | <hsivonen> | whoa. wchen landed <template>. the first time I have a collision in the htmlparser repo a couple of minutes after hg pull -u |
| 13:32 | <hsivonen> | UTF-8 whine deployed: http://html5.validator.nu/?doc=http%3A%2F%2Fhsivonen.iki.fi%2Ftest%2Fmoz%2Fcharset-menu%2Fchild-6-meta-parent-bomless-utf-16-child-with-http.htm16be |
| 13:50 | <zcorpan> | hsivonen: nice |
| 13:50 | <zcorpan> | hsivonen: do you plan on removing the messages about preferredness? |
| 13:51 | <hsivonen> | zcorpan: yes, but I'd rather back it up with Hixie's spec text instead of willfully violating the spec on my own |
| 13:51 | <hsivonen> | so I'll work on other stuff first |
| 13:51 | <zcorpan> | ok |
| 13:52 | <hsivonen> | specifically, changing the parser to use Encoding Standard alias resolution |
| 13:53 | <annevk> | alias -> labal |
| 13:53 | <annevk> | label even |
| 14:04 | <hsivonen> | encodings supported by the Encoding Standard but not by OpenJDK6: |
| 14:04 | <hsivonen> | hz-gb-2312 |
| 14:04 | <hsivonen> | iso-8859-10 |
| 14:04 | <hsivonen> | iso-8859-14 |
| 14:04 | <hsivonen> | iso-8859-16 |
| 14:04 | <hsivonen> | iso-8859-8-i |
| 14:04 | <hsivonen> | macintosh |
| 14:04 | <hsivonen> | replacement |
| 14:05 | <hsivonen> | x-mac-cyrillic |
| 14:05 | <hsivonen> | x-user-defined |
| 14:05 | <hsivonen> | annevk: why isn't hz-gb-2312 aliased to replacement yet? |
| 14:05 | <annevk> | hsivonen: can we remove that encoding? |
| 14:06 | <hsivonen> | I hope we can but I don't know |
| 14:06 | <odinho> | jgraham: And we can't contribute pike tests back? :P Hehe. Okay :/ They are sometimes possible to transalte though. Although that is $work |
| 14:13 | <annevk> | hsivonen: if we remove it I can update the spec |
| 14:13 | <annevk> | hsivonen: I'd prefer not going too far ahead of what impls are doing I think |
| 14:15 | <hsivonen> | so I think I will need to make the htmlparser depend on https://github.com/whatwg/encoding/ for code generation |
| 14:15 | <hsivonen> | what's the right way to deal with a git repo dep in a hg-based project? |
| 14:16 | <hsivonen> | should I just put a directory called encoding in ignore and tell people who wish to rerun code generation to pull https://github.com/whatwg/encoding/ into a dir called encoding as a child dir of htmlparser? |
| 14:16 | <hsivonen> | or should I tell people to pull it as a sibling |
| 14:16 | <hsivonen> | I guess sibling is easier |
| 14:17 | <hsivonen> | MikeSmith: any objections to making build.py pull https://github.com/whatwg/encoding/ as a sibling of the other repos? |
| 14:19 | <hsivonen> | annevk: thanks for having this stuff under compatible copyright terms :-) |
| 14:19 | <annevk> | my pleasure |
| 14:21 | <hsivonen> | annevk: do all characters in the single-byte encodings decode to the Basic Multilingual Plane? |
| 14:22 | <annevk> | afaik |
| 14:22 | <hsivonen> | great |
| 14:32 | <MikeSmith> | hsivonen: no objections from me |
| 14:46 | <zewt> | are there even any legacy multibyte encodings that go outside it except for gb18030? |
| 14:46 | <Hixie_> | hsivonen: if there's something where i'm blocking you, send me a quick mail about it, i'm only barely paying attention to IRC these days due to busy "real world" stuff |
| 14:46 | <Hixie_> | (should be back able to pay full attention to stuff in june) |
| 14:50 | <hsivonen> | Hixie_: I sent email to the list. basically, allowing non-preferred labels for non-UTF-8 encodings would solve the problem. OK if I assume that? |
| 14:54 | <zewt> | (should just use encoding labels, not encoding names, right?) |
| 14:57 | <Hixie_> | hsivonen: i guess the logic is that now that there's a fixed set, it doesn't matter what people pick, they are always going to be treated the same? |
| 14:58 | <Hixie_> | hsivonen: i'm still a bit dubious about allowing ISO-8859-1 if you're not following the actual 8859-1 spec |
| 14:58 | <Hixie_> | hsivonen: which is the main reason the restriction was in place before |
| 14:58 | <Hixie_> | hsivonen: iirc |
| 14:59 | <zewt> | (the 8859-1 spec should be updated to just include the win-1252 characters and end one little bit of lunacy, heh) |
| 14:59 | <Hixie_> | well that's kind what encoding.spec.whatwg.org does |
| 14:59 | <hsivonen> | Hixie_: well, it's not particularly useful for authors to be told to change a label that works to another that works |
| 15:02 | <Hixie_> | hsivonen: won't there be software that gets it wrong? e.g. anything using iconv presumably doesn't handle 8859-1 "correctly" if you're using win1252 specials, right? |
| 15:02 | <zewt> | hsivonen: hmm, yeah, seems like noise that would make the encoding-related warnings that are actually useful stand out less (declare your encoding; use utf-8) |
| 15:04 | <hsivonen> | Hixie_: oh if you care about non-browser software that's also Encoding Standard-incompliant, then the legacy labels might indeed be a problem |
| 15:05 | <zewt> | maybe that's not a big issue as long as it's at a lower level of warnings (not a big angry red alert) |
| 15:05 | <Hixie_> | gotta go |
| 15:05 | <Hixie_> | if you decide it's not something we should care about, update the list thread accordingly and say in that mail that i said that i'd do whatever you did |
| 16:07 | <zcorpan> | MikeSmith: https://www.w3.org/Bugs/Public/ gives me an error |
| 16:08 | <zcorpan> | "Can't connect to the database." |
| 16:17 | <nielsle> | Are there any tools for doing something like latex page references with css3 regions? That is: Get the label of a div containing a given label and display it as text within the html-page. (I am not trying to solve a specific problem. I just wondered if it was possible) |
| 16:19 | <astearns> | nielsle: Nothing declarative has been decided on. You can of course use JavaScript to accomplish this now, until we agree how it can be done in CSS |
| 16:20 | <nielsle> | Thanks :) |
| 16:21 | <MikeSmith> | hsivonen: I've pushed the parser encoding-reporting changes to the W3C service now too |
| 16:22 | <MikeSmith> | zcorpan: apparently some problem with W3C servers right now |
| 16:22 | <MikeSmith> | ah, db |
| 16:22 | <MikeSmith> | they working on it |
| 16:25 | <hsivonen> | MikeSmith: thanks |
| 16:26 | <cwilso_> | Yeah, it's making the logistics of the (just started) Web Audio FTF interesting. :) (Can't get to logistics) |
| 16:26 | <hsivonen> | MikeSmith: I think I'll implement the label and single-byte stuff from the Encoding Standard soon |
| 16:26 | zcorpan | stumbles upon http://webdevdata.org/ |
| 16:32 | <nimbu1> | zcorpan: woah wat dat? |
| 16:32 | <nimbu1> | who is behind it? |
| 16:34 | <miketaylr> | these guys http://www.w3.org/community/webdevdata/ |
| 16:40 | <sangwhan_> | Interesting how there seems to be a Mozilla bug on "de-supporting" ISO-2022-KR while it's not supported |
| 16:44 | <divya> | miketaylr: interesting but what data is being published dont want to download datasets to find out >:| |
| 16:45 | <annevk> | sangwhan_: it is supported for decoding |
| 16:46 | <annevk> | hsivonen: non-browser software is also why we'd want to restrict to utf-8 though, although I guess a case can be made that most non-browser software knows how to deal with iso-8859-1 in some way |
| 16:49 | <sangwhan_> | annevk: Ah, I assume it's still in the Gecko core for Thunderbird use? |
| 16:49 | <annevk> | Oh it is disabled now from the browser side? |
| 16:50 | <annevk> | sangwhan_: no, https://bugzilla.mozilla.org/show_bug.cgi?id=827796 is not fixed |
| 16:51 | <sangwhan_> | It could be the Opera test case I used is flawed, but it passed fine on Chrome and IE7(!) |
| 16:54 | <sangwhan_> | Regardless, ISO-2022-KR should go |
| 16:57 | <SteveF> | zcorpan: webdevdata is stuff i have collected, the one from dec is expanded (35000) home pages from top 50000 |
| 17:07 | <SteveF> | <main> element now supported in Chrome stable version 26 |
| 17:14 | <GPHemsley> | TIL Hixie_ speaks French. |
| 17:15 | <Ms2ger> | Like a ten-year-old, apparently |
| 17:22 | <GPHemsley> | Hmm... I'm thinking the term "MIME type with parameters" will prove to be problematic with other definitions used in mimesniff |
| 17:23 | <GPHemsley> | e.g. I'll have to use "valid MIME type with parameters" everywhere I currently use "valid MIME type" |
| 17:24 | <GPHemsley> | which seems unnecessarily unwieldy |
| 17:25 | <GPHemsley> | on the other hand, though, I never seem to do anything with parameters |
| 17:25 | <GPHemsley> | oh, except in the unfinished "parse a MIME type" algorithm |
| 17:26 | <GPHemsley> | hmm |
| 17:27 | <GPHemsley> | ah, the parameters are also important for the "supplied MIME type" as it relates to the "MIME type sniffing algorithm" |
| 17:28 | <GPHemsley> | but perhaps I will change "MIME type portion" (formerly "media type portion") to "MIME type without parameters" |
| 17:46 | <zewt> | i've never viewed parameters as part of a mime type in the first place; mime type as just "text/plain" and parameters metadata associated with it |
| 18:29 | <gsnedders> | So how long, how FF includes OdinMonkey, before someone deliberately starts serving code that takes an impractical amount of time to compile, given they're still doing on-thread compilation? |
| 18:31 | <SimonSapin> | gsnedders: is there a bug open on this? |
| 18:33 | <Ms2ger> | <dvander> (1) it's parallel and (2) that would be a problem in most browsers, for normal js, prior to fx 20 |
| 18:34 | <gsnedders> | Ms2ger: Ah, last I'd seen making it parallel was still to-do. And the only thing is it's far easier to do with AOT complication. |
| 18:34 | <gsnedders> | Yes, you *can* still hit it in other borwsers doing JIT compilation. |
| 22:19 | <rillian> | what should document.createElement('track').track return? |
| 23:45 | <MikeSmith> | rillian: a TextTrack object with default values for any properties that have defaults |
| 23:46 | <MikeSmith> | or undefined? |