| 00:03 | <GPHemsley> | the registration is included in an amendment as Annex E, but it appears to be identical to what is at IANA |
| 00:03 | <GPHemsley> | (as it should be, I suppose) |
| 00:17 | <GPHemsley> | as I think I was saying, the registration is in ISO/IEC 14496-22:2009/Amd 2:2012 |
| 02:28 | <SimonSapin> | TabAtkins: ping |
| 02:48 | <GPHemsley> | Does anyone have an opinion on whether I should assume that a MIME type is ASCII/UTF-8? |
| 02:54 | <SimonSapin> | GPHemsley: sounds reasonable, if nothing else specifies it. |
| 02:55 | <SimonSapin> | you’d need to define error handling, although you might not have to do it yourself if you refer to the Encoding standard. (Which AFAIR defaults to inserting replacement characters.) |
| 11:20 | <hsivonen_> | I wonder if <script defer> has ever worked per spec in Gecko |
| 11:27 | <Ms2ger> | That seems unlikely from first principles |
| 11:28 | <jgraham> | It's a browser feature, all browser features mismatch the spec, therefore it mismatches the spec? |
| 11:34 | <Ms2ger> | Sounds about right |
| 11:55 | <zcorpan> | GPHemsley: it was inconsistent so i just picked one. if you prefer to include the suffix, feel free to change it |
| 13:14 | <GPHemsley> | zcorpan: If they're all consistent now, that's fine. |
| 13:15 | <GPHemsley> | SimonSapin: It was more a question of whether I should refer to bytes (0x20) or code points (U+0020) |
| 13:40 | <GPHemsley> | SimonSapin: IIRC, your data: URL spec was waiting on me to complete the "parse a MIME type" algorithm; if so, that's now done. |
| 13:41 | <GPHemsley> | (Where "complete" and "done" indicate that the algorithm now fully terminates, not that it can't be improved.) |
| 13:41 | <GPHemsley> | http://mimesniff.spec.whatwg.org/#parse-a-mime-type |
| 13:42 | GPHemsley | wonders if the data: URL spec won't have the same issue wrt bytes vs. code points |
| 13:44 | <GPHemsley> | ah, right, it was the data: URL spec that sparked the discussion about null vs. empty string parameter values |
| 13:45 | <GPHemsley> | (the "parse a MIME type" algorithm handles/allows this distinction) |
| 13:47 | <GPHemsley> | (it's the difference between ";base64;" and ";base64=;" |
| 13:47 | <GPHemsley> | ) |
| 13:49 | <GPHemsley> | hmm... I may have to do special handling on commas |
| 13:49 | <GPHemsley> | but perhaps not; perhaps that's more in scope of the data: URL spec |
| 13:50 | <GPHemsley> | you'll basically just have to search for matching quotes before you can determine the right comma to split on |
| 13:50 | <GPHemsley> | which is annoyingly unfortunate |
| 13:51 | <GPHemsley> | (it's possible that half of this dialog is going on in my head) |
| 13:52 | <GPHemsley> | SimonSapin: Note that you should be doing percent decoding before any processing/splitting |
| 13:52 | <GPHemsley> | IIUC |
| 13:53 | <GPHemsley> | hmm... |
| 13:53 | <GPHemsley> | "Attribute values in [RFC2045] are allowed to be either represented as |
| 13:53 | <GPHemsley> | tokens or as quoted strings. However, within a "data" URL, the |
| 13:53 | <GPHemsley> | "quoted-string" representation would be awkward, since the quote mark |
| 13:53 | <GPHemsley> | is itself not a valid urlchar. For this reason, parameter values |
| 13:53 | <GPHemsley> | should use the URL Escaped encoding instead of quoted string if the |
| 13:53 | <GPHemsley> | parameter values contain any "tspecial"." |
| 13:53 | <hsivonen_> | the <script defer> code is so broken in terms of the spec that I have a hard time believing I could have accidentally broken it that badly if it used to be correct |
| 13:54 | GPHemsley | will shut up now |
| 13:54 | <annevk> | GPHemsley: basically you can get both string and byte sequence input for media types |
| 13:54 | <GPHemsley> | annevk: Yeah, that's what I figured... |
| 13:54 | <GPHemsley> | :/ |
| 13:55 | <GPHemsley> | annevk: So I need to keep working with code points, then? |
| 13:55 | <annevk> | I guess you should figure out how implementations deal with the mismatch |
| 13:55 | <annevk> | and if they try to share code and if they want to, etc. |
| 13:56 | <GPHemsley> | how would I even go about testing how a MIME type is parsed? |
| 14:02 | <GPHemsley> | interesting... apparently Firefox accepts "text/html/test" as a valid MIME type (but it prompts for download) |
| 14:02 | <annevk> | You'd read the source code |
| 14:02 | <annevk> | I wonder why in http://first-website.web.cern.ch/sites/first-website.web.cern.ch/files/u4/Screen%20Shot%202013-05-27%20at%202.25.30%20PM.png sometimes trailing dots are used, sometimes :80, sometimes both, ... |
| 14:03 | GPHemsley | notes that the data: URL RFC doesn't even define what it means to be base64-encoded |
| 14:05 | <annevk> | I wouldn't pay too much attention to RFCs |
| 14:07 | <GPHemsley> | that was just an aside |
| 14:07 | <GPHemsley> | since I was looking for a source |
| 14:07 | <GPHemsley> | (I figured it'd at least be linked from the RFC) |
| 14:09 | <hallvors> | annevk: what is the #fragment part of the URL called in the Fetch spec? There is no instance of the word "fragment", just wondering if it's not covered there or named something else |
| 14:12 | <annevk> | hallvors: it's not called out at the moment, it'd be called "fragment" |
| 14:12 | <hallvors> | ok, thx |
| 14:15 | <annevk> | "The hypertext community were unimpressed with the web" |
| 14:15 | <annevk> | http://first-website.web.cern.ch/blog/1991-web-page-found-password-lost |
| 14:16 | <GPHemsley> | ...first I have to find the source code... |
| 14:16 | <Ms2ger> | annevk, yeah, too messy |
| 14:18 | <GPHemsley> | ah, I think I've got it |
| 14:19 | <annevk> | where did hallvors go? |
| 14:19 | <Ms2ger> | Pang |
| 14:30 | <GPHemsley> | boy the Gecko code does a lot work based on file extensions.. |
| 15:26 | <GPHemsley> | hmm... RFC 2231 specifies parameter continuation for MIME types in mail (i.e. actual MIME); RFC 5987 states HTTP doesn't need it |
| 15:26 | <GPHemsley> | so now I have to decide what to do |
| 15:27 | <GPHemsley> | I suppose I could just let downstream assemble any continued parameters |
| 15:27 | <GPHemsley> | yeah, that probably makes sense |
| 15:30 | <GPHemsley> | or else give the algorithm a parameter to indicate whether to support continuations |
| 15:55 | <GPHemsley> | oh, hmm... apparently my algorithm does allow arbitrary value-less parameters |
| 15:55 | <GPHemsley> | only if it's the last one in the MIME type |
| 15:55 | <GPHemsley> | interesting |
| 15:55 | <GPHemsley> | that's probably not right |
| 16:00 | GPHemsley | wonders whether Google's decision to create Blink was made to intentionally ensure that mobile doesn't become a monoculture |
| 16:01 | <Ms2ger> | *becomes a Google-owned monoculture |
| 16:02 | <GPHemsley> | fair enough, I suppose |
| 16:02 | <GPHemsley> | depends on how well WebKit does without Google, I guess |
| 16:04 | <GPHemsley> | does Chrome have an equivalent of Firefox's Page Info? |
| 16:14 | <Philip`> | GPHemsley: Does it matter how technically well WebKit does, given that Apple can force the use of WebKit on iOS, so web developers will have to support it regardless of how far it might fall behind some Android browsers? |
| 16:15 | <GPHemsley> | ah, right, I knew there was something I was forgetting |
| 16:15 | <GPHemsley> | so then my original point still stands then, doesn't it? |
| 16:16 | <jgraham> | It is an interesting question |
| 16:16 | <jgraham> | Does Apple need the web more than then web needs apple |
| 16:17 | <Philip`> | If Google changes the default Android browser to use Blink, and Apple doesn't abandon their current course, then I guess it's inevitable that it'll create a multicuture |
| 16:18 | <jgraham> | If WebKit on iOS became the new IE6 (which, as expressions go, is the new black), would people stop buying iOS devices, or would developers just grit their teeth and make things work with WebKit/iOS |
| 16:19 | <zewt_> | is that a serious question? heh |
| 16:19 | <GPHemsley> | WebKit on iOS would only become the new IE6 if it stopped innovating |
| 16:19 | <jgraham> | Well that was the premise |
| 16:20 | <jgraham> | That it fell far behind "some Android browsers" |
| 16:20 | <GPHemsley> | that doesn't appear to be happening at the moment though, right? |
| 16:20 | <zewt> | (people don't buy iOS devices for the browser) |
| 16:20 | <jgraham> | I have no idea |
| 16:20 | <jgraham> | I don't think anyone does really |
| 16:20 | <Philip`> | I'd probably assume Google's main motivation was that they think they can do everything better than everyone else, so Blink lets them get a competitive advantage over iOS, and if that resulted in a technically inferior iOS losing market share and dyng then they'd be perfectly happy with that, regardless of the monoculturality |
| 16:20 | <GPHemsley> | one would presume that Apple would not let their iOS browser stagnate as the rest of the Web moved forward |
| 16:20 | <GPHemsley> | (because it doesn't look like the rest of the Web is going to give up this time) |
| 16:21 | <GPHemsley> | Philip`: Yeah... I was just looking for a glimmer of Don't Be Evil, that's all |
| 16:21 | <jgraham> | AFAICT (and I stress, I have no special insight here) we haven't reached any kind of steady state in blink or webkit development post-split |
| 16:21 | <darobin> | if iOS lost market share for being technically inferior, it would be dead by now |
| 16:22 | <jgraham> | zewt: No, but would they accept a browser that was much worse than on other platforms |
| 16:22 | <zewt> | to what? having done a lot of both iOS and Android dev in the last year, i can tell you it's not inferior to android for development nor for users, heh |
| 16:23 | <jgraham> | Is the allure of the walled garden so strong that people would forego the web entirely? |
| 16:23 | <zewt> | jgraham: they don't have any choice, short of jumping ship entirely, which I expect nearly nobody would do |
| 16:23 | <jgraham> | If not, how bad would it have to be? |
| 16:23 | <Ms2ger> | On another note, sure would be nice if calendar providers interoperated |
| 16:23 | <jgraham> | I wonder if it is true that "nearly nobody" has jumped from iOS to another smartphone platform |
| 16:23 | <zewt> | due to browsers? |
| 16:24 | <jgraham> | In general |
| 16:24 | <zewt> | not talking in general |
| 16:24 | <jgraham> | Well at present the browsers are rather similar |
| 16:24 | <jgraham> | So "due to browsers" isn't a very interesting question |
| 16:24 | <jgraham> | +default |
| 16:25 | <jgraham> | Dunno if anyone has changed specifically to get Firefox/Opera Mobile |
| 16:25 | <zewt> | i don't think the browser is a big enough chunk of people's use of iOS, even if it was catastrophically bad I suspect the app marketshare of iOS would still keep most people there |
| 16:25 | <jgraham> | (I should note that "most people" don't use iOS, but perhaps you mean "most current users") |
| 16:25 | <zewt> | what? i mean most users of iOS, of course |
| 16:26 | <jgraham> | Ms2ger: And make it easy to switch to an alternate provider? Why would they do that? |
| 16:27 | <zewt> | i'd hope that apple would have the sense to keep their browser current; just saying, don't make the web-centric view that they have to or everyone will leave, since the browser isn't the center of iOS |
| 16:28 | <Philip`> | Given that the market is still expanding, it's probably more important to worry about attracting new users to a platform, than about switching existing users |
| 16:29 | jgraham | didn't actually take any view, just said it was an interesting question |
| 16:29 | <Philip`> | (and it's much easier to influence a new user who hasn't got a heavy investment in one platform already) |
| 16:30 | <zewt> | and apple tends to keep the browser on iOS just-slightly-worse for using apps than native, to make sure people keep making native apps |
| 16:30 | <zewt> | (eg. can't put an app bookmark on the home screen without the user using an obscure UI; no WebGL) |
| 16:54 | <GPHemsley> | Does any WHATWG spec define what it means to convert something to ASCII lowercase? |
| 16:55 | <zewt> | http://www.whatwg.org/specs/web-apps/current-work/#converted-to-ascii-lowercase |
| 16:55 | <GPHemsley> | hmm, DOM apparently |
| 16:55 | <GPHemsley> | or that |
| 16:56 | <GPHemsley> | thanks |
| 18:47 | <ripples> | pewpew |
| 18:48 | <Ms2ger> | Ahem? |
| 20:53 | <GPHemsley> | Feedback welcome: http://mimesniff.spec.whatwg.org/#parse-a-mime-type |
