| 09:04 | <jgraham> | Hixie: I have temporarily paged everything to do with the navigation out of my head. And it always takes a distressingly long time to reload. But the generic answer to your question is that if "cancel" means "don't run any further steps in the algorithm", that should be defined. But I don't recall if that was really a safe/correct thing to do, because half-finished steps could leave you with state that needs to be cleaned up |
| 13:10 | <zcorpan> | https://bugzilla.mozilla.org/show_bug.cgi?id=815014 - was this supported in spidermonkey before? |
| 13:14 | <matjas> | those quotes in comment 1 hurt |
| 13:18 | <zcorpan> | seems to me opera, safari, chrome, ie8 all support a.arguments |
| 13:19 | <zcorpan> | what does ie9, ie10 do? |
| 13:20 | <matjas> | (I don’t have a VM handy to test, and I don’t remember) |
| 13:21 | <matjas> | IIRC Firefox supports fn.arguments too but doesn’t make the object === the standard `arguments` object |
| 13:24 | matjas | tests |
| 13:25 | <matjas> | confirmed |
| 13:25 | <zcorpan> | yeah. then they're just being silly |
| 13:28 | <zcorpan> | ie8 seems to throw when doing == or === comparison with arguments or a.arguments |
| 13:35 | <matjas> | interesting |
| 13:37 | <MikeSmith> | can somebody please enlighten me as to why in Firefox window.hasOwnProperty('localStorage') is false while "'localStorage' in window" is true? |
| 13:37 | <zcorpan> | hmm, maybe it only does that for w() in live dom viewer. i get a different result with document.write. |
| 13:37 | <zcorpan> | MikeSmith: maybe it's on the prototype? |
| 13:38 | <MikeSmith> | ah |
| 13:38 | <MikeSmith> | if so that'd explain it I guess |
| 13:38 | <zcorpan> | 'localStorage' in Window.prototype // true |
| 13:38 | <MikeSmith> | aha |
| 13:39 | <MikeSmith> | thanks |
| 13:39 | <zcorpan> | Window.prototype.hasOwnProperty('localStorage') // i guess it a better test. also true |
| 13:40 | <MikeSmith> | yeah that seems better than just doing "'localStorage' in window" I guess |
| 13:41 | <MikeSmith> | hmm |
| 13:41 | <MikeSmith> | or maybe not |
| 13:42 | <MikeSmith> | false in Opera |
| 13:42 | <MikeSmith> | and Chrome |
| 13:42 | <MikeSmith> | I guess I'll just stick with "'localStorage' in window" |
| 13:43 | <MikeSmith> | zcorpan: btw, wondering if you or jgraham might know why most of the tests in http://www.lookout.net/test/url/ don't get run in Operea |
| 13:43 | <Ms2ger> | We might end up having to put those properties all on the window object, fwiw |
| 13:43 | <MikeSmith> | *Opera |
| 13:43 | <MikeSmith> | Ms2ger: ok |
| 13:43 | <zcorpan> | Ms2ger: oh? why? |
| 13:44 | <Ms2ger> | Did you follow the "var indexedDB" mess? |
| 13:44 | <zcorpan> | i recall something about it. i thought the conclusion was that spidermonkey had a bug |
| 13:45 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=770844#c79 |
| 13:45 | <zcorpan> | so i guess that includes methods, but it's only for window? is that right? |
| 13:46 | <zcorpan> | where methods i mean properties that are functions |
| 13:46 | <Ms2ger> | I'm not sure |
| 13:46 | Ms2ger | got terribly confused in that discussion |
| 13:55 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1927 - opera and chrome have open() on the object, safari has it on both the object and the prototype |
| 13:57 | <zcorpan> | i guess webidl should special-case the global object, then. wonder if the result is the same in workers... |
| 14:02 | <annevk> | I liked that idea of inline workers |
| 14:02 | <annevk> | <script type=worker> |
| 14:06 | <zcorpan> | postMessage([self.hasOwnProperty('postMessage'), self.__proto__.hasOwnProperty('postMessage')]); // safari: false,true. chrome: false,false. opera: true,false. firefox: false,true |
| 14:07 | <zcorpan> | i guess workers' idl are kinda special, or have been, at least |
| 14:12 | <annevk> | I wonder if you can attribute this mess to not directly specifying things in terms of JavaScript |
| 14:13 | <Ms2ger> | You can attribute it to not really specifying things :) |
| 14:14 | <Ms2ger> | I doubt the situation would be better even if the Old People had gone for JS-only specs |
| 14:20 | <annevk> | maybe if TC39 defined all the things? |
| 14:24 | <Ms2ger> | Like __definePropery__, eh? |
| 14:27 | <zcorpan> | turns out the prototype chain is deeper in workers in various browsers |
| 14:29 | <Ms2ger> | Didn't the spec used to do something weird there too? |
| 14:29 | <zcorpan> | yes |
| 14:30 | <zcorpan> | firefox seems like closest to the spec, but it has two DedicatedWorkerGlobalScope. i don't think the spec has that |
| 14:31 | <zcorpan> | or wait, i'm confused |
| 14:31 | <zcorpan> | the object and the prototype both get stringified to [object DedicatedWorkerGlobalScope] in firefox |
| 14:31 | <Ms2ger> | That doesn't surprise me |
| 14:34 | <hallvors> | MikeSmith: turns out http://www.lookout.net/test/url/ is quite an IFRAME and IFRAME.onload stress test |
| 14:34 | <MikeSmith> | yeah |
| 14:34 | <MikeSmith> | torture test |
| 14:34 | <hallvors> | It first creates an IFRAME per test (they will be removed on onload) |
| 14:34 | <MikeSmith> | hallvors: there's got to be a better way to od it |
| 14:34 | <MikeSmith> | yeah |
| 14:35 | <hallvors> | There are some hardcoded limits in Opera regarding the number of allowed frames in a document |
| 14:36 | <hallvors> | I don't remember them exactly (and I thought they were aligned with or more generous than corresponding limits in other browsers) but that's likely the reason not all tests run here. |
| 14:39 | <annevk> | maybe in other browsers the limit is on the number of <iframe>s in a document rather than the number that was created? |
| 14:40 | <annevk> | MikeSmith: could use <a> instead? |
| 14:41 | <hallvors> | annevk: seems the nearly 500 IFRAMEs are created and appended from a single JS thread |
| 14:41 | <annevk> | not removed too? oh |
| 14:41 | <hallvors> | ..so there's no pause where we could get some of those onloads fired and get rid of some of them again :-[ |
| 14:41 | <hallvors> | :-/ |
| 14:42 | <hallvors> | I don't really see why waiting for onload would be necessary |
| 14:42 | <hallvors> | document.write() into IFRAME should have the contents parsed immediately AFAIK |
| 14:43 | <hallvors> | so it should be possible to do the asserts just after document.write() |
| 14:43 | <MikeSmith> | oh |
| 14:43 | <MikeSmith> | that'd make it easier |
| 14:43 | <hallvors> | (but perhaps whoever wrote that harness already tried that and had problems?) |
| 14:43 | <MikeSmith> | dunno |
| 14:44 | <hallvors> | it would certainly be way easier from Opera's point of view :-p |
| 14:44 | <MikeSmith> | he doesn't frequent IRC much I don't think |
| 14:44 | <MikeSmith> | ok |
| 14:44 | <MikeSmith> | I'll take a look at it later myself |
| 14:47 | <annevk> | MikeSmith: test_simple can be |
| 14:47 | <MikeSmith> | can be <a> instead, you mean? |
| 14:48 | <annevk> | var a = document.createElement("a"); a.href = url; assert_equals(a, expect_url); |
| 14:49 | <annevk> | see also https://github.com/annevk/url/blob/master/test-components.html#L129 |
| 14:49 | <annevk> | though I'm not sure how well that works in Internet Explorer |
| 14:49 | <annevk> | maybe it's using <iframe> in part of browser compat problems |
| 14:49 | <annevk> | Firefox e.g. does not handle dynamic <base> |
| 14:52 | <hallvors> | I wonder if setting a.href might parse some of the weird input differently than the document.write() does |
| 14:53 | <hallvors> | I have no idea if the tests would be equivalent if one just sets a.href .. |
| 14:53 | <annevk> | I do though :) |
| 14:53 | <hallvors> | OK :) |
| 14:54 | <annevk> | actually, unless you put stuff like &test; in tests, but I did not spot that |
| 14:54 | <hallvors> | BTW annevk: would you like to add test coverage script to the WHATWG version of XHR? |
| 14:54 | <annevk> | and that shows why DOM manipulation would be better anyway |
| 14:55 | <annevk> | hallvors: the tests coverage does not seem linked? |
| 14:56 | <annevk> | hallvors: and it's a bit too much in your face for my taste |
| 14:56 | <hallvors> | test coverage data is a little bit incomplete but we're working on it |
| 14:56 | <hallvors> | right now it will improve a lot once somebody runs some script to re-generate JSON data.. |
| 14:57 | <hallvors> | I'm sure the styling can be amended :) |
| 14:57 | <annevk> | hallvors: I guess once a) you can actually get to the test and b) it doesn't take up a whole horizontal thingie anymore it might be good |
| 14:57 | <hallvors> | anytime you like ;) |
| 14:57 | <annevk> | hallvors: I can add a post-commit hook to GitHub that will run that script |
| 14:58 | <hallvors> | cool. I don' really know where the script is myself, Julian has been talking to Robin B so he knows that stuff |
| 14:59 | <darobin> | yeah ask Julian :) |
| 15:00 | <annevk> | currently for each commit to xhr.spec.whatwg.org there's a script run that can also run other scripts and fetch JSON data if needed |
| 15:00 | <annevk> | should not really be a problem to integrate if someone lays out the bits for me |
| 15:00 | <hallvors> | or even better, lean back and let Julian just do the work :D |
| 15:00 | <annevk> | sure :) |
| 15:01 | <zewt> | as long as the styling isn't so intrusive :) |
| 15:05 | <annevk> | MikeSmith: I don't see the subsequent commit in https://github.com/sideshowbarker/url-testing/commits/master where you added that / |
| 15:05 | <MikeSmith> | oh |
| 15:05 | <MikeSmith> | maybe I forgot to push |
| 15:05 | <annevk> | MikeSmith: but if you also add it to "url", where are you testing that it does get added? |
| 15:05 | <MikeSmith> | ah I pushed it to my fork |
| 15:06 | <MikeSmith> | annevk: I'm not |
| 15:06 | <MikeSmith> | we can another another test case for that |
| 15:06 | <annevk> | MikeSmith: I'm looking at your fork... |
| 15:06 | <annevk> | MikeSmith: and I thought this was supposed to be that test |
| 15:07 | <MikeSmith> | fuck I didn't even commit it |
| 15:07 | <MikeSmith> | will just commit it and push it now |
| 15:07 | <MikeSmith> | without the trailing slash in the "url" field |
| 15:07 | <MikeSmith> | because otherwise as you note it's pretty pointless |
| 15:08 | <MikeSmith> | I put "A pathless URL. Expected URL should have a slash appended." for the "name" field |
| 15:09 | <MikeSmith> | OK pushed it now |
| 15:09 | <MikeSmith> | will send a pull request to Chris later too |
| 15:09 | <annevk> | cool |
| 15:09 | <MikeSmith> | will try to mess around later with the iframe thing too |
| 15:10 | <MikeSmith> | today |
| 15:11 | <MikeSmith> | after doing some day-job stuff that needs getting done by the end of the day |
| 15:13 | <zcorpan> | annevk: indeed we tried to use <a xml:base href> first but chrome doesn't support that |
| 15:14 | <zcorpan> | annevk: i didn't dare go into dynamic <base> territory |
| 15:14 | <zcorpan> | annevk: iframe seemed like a working cross-browser approach |
| 15:14 | <annevk> | guess we could split the tests or so |
| 15:14 | <annevk> | to not hit Opera's limit |
| 15:15 | <zcorpan> | the iframes are removed after the test has run, so the limit shouldn't be hit |
| 15:16 | <zcorpan> | MikeSmith: Found 497 tests is what i get in both opera and firefox |
| 15:19 | <zcorpan> | i guess tests that don't use a base don't need an iframe |
| 15:19 | <zcorpan> | so it can be optimized a little |
| 15:20 | <annevk> | yeah that's what I said |
| 15:23 | <zcorpan> | i wrote the initial test case, which masinter fiddled with a bit and then chris made took over |
| 15:23 | <zcorpan> | s/made// |
| 15:25 | <zcorpan> | http://simon.html5.org/test/url/relative-resolution.html is before chris |
| 15:26 | <hallvors> | zcorpan: all 497 tests are currently added in separate IFRAMEs from one JS thread, before onloads start firing and the framework starts removing IFRAMEs again, hence you run into the limit |
| 15:27 | <zcorpan> | hallvors: ah. but the other iframes get processed when some are removed, i guess? |
| 15:28 | <hallvors> | I think the limitation that was implemented is that after a certain number of frames we stop creating documents inside the new ones |
| 15:28 | <hallvors> | so actually only the first n IFRAMEs will have documents that fire onload events and complete their tests |
| 15:30 | <zcorpan> | the test runs to completion for me, which means they do get load event and a DOM that the parent can poke at |
| 15:55 | <annevk> | a bunch of tests in urls.json are simply not run yet it seems |
| 15:55 | <annevk> | e.g. 498 I cannot find back when they're run |
| 15:56 | <annevk> | MikeSmith: while you're patching, replacing "expect_port": "0", with "expect_port": "", would also fix a bunch of failures |
| 15:57 | <annevk> | MikeSmith: maybe I'll submit a patch for that |
| 16:00 | <annevk> | sweet, tests found a bug in the spec |
| 16:30 | <annevk> | hmm |
| 16:30 | <annevk> | data:text/html,<style>:target{background:lime}</style><a id=x href=%23x>test</a> |
| 16:30 | <annevk> | should we support that? |
| 16:32 | <Ms2ger> | How about data:text/html,<style>:target{background:lime}</style><a id=x href=#x>test</a> ? |
| 16:35 | <annevk> | that wouldn't display anything I think |
| 16:35 | <annevk> | fragment identifiers are supported on all URLs |
| 16:35 | <annevk> | http://lists.w3.org/Archives/Public/public-html/2012Nov/0188.html he's aware of my work, but not its purpose with respect to HTML? |
| 16:35 | <annevk> | weird |
| 16:38 | <GPHemsley> | are data: pages allowed to have relative URLs? |
| 16:39 | <annevk> | not per the URL spec at this moment |
| 16:40 | <GPHemsley> | I think that makes sense |
| 16:40 | <annevk> | I can see a case for supporting just #, but that seems kinda hairy and you might as well handle that in HTML rather than in URL |
| 16:40 | <GPHemsley> | oh, yeah, hmm |
| 16:40 | <GPHemsley> | how would you even write that URL? |
| 16:40 | <GPHemsley> | I don't know that you can |
| 16:41 | <annevk> | I just did |
| 16:41 | <GPHemsley> | where? |
| 16:41 | <darobin> | in his head |
| 16:41 | <annevk> | http://krijnhoetmer.nl/irc-logs/whatwg/20121126#l-523 |
| 16:41 | <GPHemsley> | that's not a URL, that's a link |
| 16:42 | <annevk> | you asked where |
| 16:42 | <GPHemsley> | I meant an absolute data: URL with a fragment |
| 16:42 | <annevk> | o_O |
| 16:42 | <GPHemsley> | i.e., linking to #x from outside the page |
| 16:43 | <GPHemsley> | data:text/html,<style>:target{background:lime}</style><a id=x href=%23x>test</a>#x |
| 16:43 | <GPHemsley> | (which obviously doesn't work) |
| 16:43 | <annevk> | that would work |
| 16:43 | <GPHemsley> | oh |
| 16:43 | <annevk> | well, depending on what you mean |
| 16:43 | <GPHemsley> | right, because it all has to be percent-encoded? |
| 16:43 | <GPHemsley> | very nice |
| 16:44 | <GPHemsley> | so yeah, that makes sense |
| 16:45 | <GPHemsley> | BTW, if this is actually in a spec: "An absolute URL is an authority-based URL if, when resolved |
| 16:45 | <GPHemsley> | and then parsed, there are two characters immediately after |
| 16:45 | <GPHemsley> | the <scheme> component and they are both "//" (U+002F) |
| 16:45 | <GPHemsley> | characters." |
| 16:46 | <GPHemsley> | that wording suggests that "//" is a single character and that there should be two of them ("////") |
| 16:47 | <annevk> | all that is going away soon |
| 16:47 | <annevk> | once Hixie updates HTML to use URL |
| 16:47 | <annevk> | dunno about W3C HTML5 against which Roy objects, but that's darobin's problem |
| 16:47 | <GPHemsley> | heh |
| 16:48 | <annevk> | I kinda like how he suggests to retrofit charset though to mean character encoding |
| 16:48 | <darobin> | I reckon anything involving using URL would just sail through as a change |
| 16:49 | <darobin> | taking Ian's changes is more like Silvia's problem actually :) |
| 16:49 | <annevk> | the resource / representation thing only matters if you believe in content negotiation... |
| 16:52 | <annevk> | darobin: that's not exactly why she volunteered |
| 16:52 | <annevk> | at least per http://blog.gingertech.net/2012/08/15/why-i-became-a-html5-editor/ |
| 16:53 | <darobin> | annevk: she volunteered to handle WHAT WG integration — if she didn't want to do it I'm sure she'd let us know :) |
| 16:53 | <annevk> | zcorpan: you didn't update the obsolete header in http://wiki.whatwg.org/wiki/Web_ECMAScript |
| 16:53 | <darobin> | I really don't care about the resource / representation thing, and I hate conneg with a passion |
| 16:54 | <darobin> | I guess those two facts may be related |
| 16:54 | <darobin> | anyway, *shrug* |
| 16:54 | <zcorpan> | annevk: fixed |
| 16:58 | <annevk> | oh Roy is at Adobe too |
| 16:59 | <annevk> | I wonder if they all get together sometime over there, must be interesting |
| 17:00 | <annevk> | darobin: I thought the idea was to improve the signal/noise ratio on public-html? |
| 17:00 | Ms2ger | sniggers |
| 17:01 | <annevk> | oh soon |
| 17:06 | <darobin> | annevk: tee hee |
| 17:19 | <TabAtkins_> | Darn, someone mentioned me over the thanksgiving weekend, but it's lost in the scrollback. :/ |
| 17:20 | <darobin> | TabAtkins_: man, that's just evil. People shouldn't do that to you |
| 17:20 | <smaug____> | TabAtkins_: you know, we do have logs ;) |
| 17:20 | <TabAtkins_> | darobin: I know! Those jerks. |
| 17:20 | <TabAtkins_> | smaug____: Bah. |
| 17:20 | <darobin> | smaug____: you and your "helpful" suggestions... |
| 17:21 | <annevk> | TabAtkins_: http://krijnhoetmer.nl/irc-logs/whatwg/20121121 |
| 17:22 | darobin | wonders if he can file a bug against Unicode for not having air quotes |
| 17:23 | <TabAtkins_> | annevk: Hah, it was you calling me the Big Spammer. |
| 17:24 | <TabAtkins_> | annevk: I'm fine with append. Probably better, actually, since add() is part of the Set API, so it's probably better to stay away from it if we're forging toward a MultiMap API. |
| 17:25 | <TabAtkins_> | annevk: I have no idea why tc39 decided on .size rather than .length. I assume it has something to do with not wanting to collide with the de facto "is an array" tests that just check the existence of .length on the object. |
| 17:27 | <TabAtkins_> | Unfortunately, I don't think #webkit has any similar logging. |
| 17:27 | <TabAtkins_> | If it does, it's not in the Topic. |
| 18:20 | <MikeSmith> | TabAtkins_: do you use ninja for building on mac? |
| 18:31 | <TabAtkins_> | MikeSmith: I don't build on mac. |
| 18:31 | <TabAtkins_> | I only work on Linux. |
| 18:31 | <annevk> | Hixie: what would you use as terminology for "obtaining a resource from a URL"; e.g. the bit where a http URL is turned into a HTTP request for instance, or where an about URL is token matched |
| 18:31 | <MikeSmith> | ah ok |
| 18:31 | <Ms2ger`> | TabAtkins_, do you build on Linux? |
| 18:32 | <Ms2ger`> | If so, did you need to sacrifice goats to have it work? |
| 18:36 | <annevk> | URL syntax / URL resource retrieval |
| 18:36 | <annevk> | with most URLs not having URL resource retrieval I suppose |
| 18:47 | <annevk> | in 2000 you defined URLs like this http://tools.ietf.org/html/rfc2818#section-2.4 |
| 18:57 | <TabAtkins_> | Huh, Ms2ger is gone. That's strange. |
| 18:58 | <TabAtkins_> | Anyway, Ms2ger, yes I build on Linux. It all worked out great as soon as I started following the "New Git Workflow" wiki page. |
| 19:06 | <marcosc_> | Hixie: if I have srcset=", , ," the first candidate's url is "," right? (i.e., it does not matter that it's a comma) ... just want to confirm I didn't screw something up |
| 19:10 | <annevk> | marcosc_: afaict, yup |
| 19:11 | <marcosc_> | thanks annevk |
| 19:30 | <jgraham> | Did someone sort out the URL tests? |
| 19:30 | <jgraham> | Creating 500 iframes is just obnoxious |
| 19:31 | <jgraham> | Better to create a small pool and reuse them |
| 19:42 | <zcorpan> | jgraham: good idea |
| 19:43 | <zcorpan> | actually, someone said that the tests can be sync |
| 19:43 | <zcorpan> | so the pool could be 1 iframe |
| 20:03 | <annevk> | ah you can just clear an <iframe>? |
| 20:18 | <Hixie> | jgraham: yeah... i don't really know what else it could be, though |
| 20:18 | <Hixie> | annevk: "fetch"? :-) |
| 20:18 | <Hixie> | marcosc_: sounds right |
| 20:19 | <annevk> | Hixie: so yeah, but we need some kind of URL scheme whitelist then in navigate |
| 20:19 | <annevk> | Hixie: if it's in the whitelist, it can be fetched, otherwise, ask an "external" application |
| 20:19 | <Hixie> | yeah right now the browser is supposed to just know |
| 20:19 | <Hixie> | don't forget about registerProtocolHAndler() though |
| 20:19 | <Hixie> | it can turn one into another |
| 20:20 | <Hixie> | (changes the URL too) |
| 20:20 | <annevk> | Hixie: I was hoping that was part of navigate |
| 20:20 | <annevk> | Hixie: e.g. XHR uses fetch directly and I don't think it should hook into registerProtocolHandler |
| 20:20 | <Hixie> | sounds right |
| 20:22 | <annevk> | okay so fetch is going to be the main algorithm, with obtain a resource from a URL (or some such) as subalgorithm with obtain a resource from a data URL (and others) as subsubalgorithms |
| 20:23 | <annevk> | fetch will have the same whitelist as navigate, except instead of launching an app fetch will act as if there was a network error |
| 20:25 | <annevk> | then we need some spec to define "resource" + "resource headers", with shortcuts for MIME type, encoding, HTTP status, and HTTP status text, so everything works in a HTTP context (for XMLHttpRequest) |
| 20:26 | <annevk> | then we're getting pretty close to defining <a> and friends :-) |
| 20:41 | <annevk> | Hixie: fwiw, here's the whitelist I made http://wiki.whatwg.org/wiki/URL#Schemes |
| 20:42 | <Hixie> | roger |
| 21:07 | <marcosc_> | Hixie: thanks |
| 21:31 | <marcosc_> | Hixie, is the use case for testing img@srcset sufficient to warrant the addition of an IDL attribute to check which is the selected source? (otherwise, it's kinda impossible to check what's currently on screen with JS) |
| 21:32 | <marcosc_> | being able to query: img.currentSrc would be nice, as one does with media elements |
| 21:53 | <annevk> | foolip: I read http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Nov/thread.html#msg112 any updates on javascript: from your side? what you think should work and should not? |
| 21:58 | <SimonSapin> | annevk: about data: parsing. When implementations disagree, should we specify strict or more lenient? Examples: data:;Base64,cGFzcw data:; base64,cGFzcw |
| 21:59 | <annevk> | SimonSapin: usually we let it depend on the implementations |
| 22:00 | <SimonSapin> | isn’t one of the goal to specify what to do on invalid input too? |
| 22:01 | <annevk> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2011May/0229.html seems to argue for moving javascript to the navigate layer |
| 22:02 | <annevk> | SimonSapin: yes, but if say only Opera does the strict behavior, we go with lenient, but if only Opera is lenient, we might go with strict |
| 22:02 | <SimonSapin> | oh, so try to find a majority? how do you judge which implementations are relevant or how much? |
| 22:03 | <TabAtkins_> | More or less, market share. |
| 22:03 | <jgraham> | Not just a majority |
| 22:03 | <TabAtkins_> | But it's not strictly that (or else Opera would almost never count). |
| 22:04 | <jgraham> | If there are 3 implementations and 2 do the same, but are willing to chanhe but one is not, you pick the one that you can converge on |
| 22:04 | <SimonSapin> | admittedly I’m searching for corner cases, many of which nobody use or care about |
| 22:06 | <SimonSapin> | I mean, who is gonna write src="data: B%61se64,foo" and mix both base64 alphabets? |
| 22:08 | <SimonSapin> | (There is "normal" base64 and "URL safe" base64, rfc2397 doesn’t say which should be used) |
| 22:08 | <jgraham> | You know you are doing something properly interesting when there are N+1 behaviours (N implementations plus the spec), N-2 implementors have stated that they won't change their implentation, and 1 implementor doesn't give feedback |
| 22:09 | <jgraham> | And by "interesting" I think I mean "related to document loading" |
| 22:10 | <annevk> | SimonSapin: so I guess it depends on whether you convert scheme data + "? + query to bytes first before you start the MIME parser or not |
| 22:10 | <annevk> | SimonSapin: browsers seem to differ |
| 22:10 | <annevk> | SimonSapin: data:text/ht%4DL,<b>test |
| 22:11 | <jwalden> | it's easier to allow lenient behavior later, when strict was the initial setting, than it is to go the other way |
| 22:11 | <jwalden> | which to me usually argues for strict behavior |
| 22:11 | <jwalden> | if you find people are really screwing with you and writing crazy data URLs, you can change at that point |
| 22:14 | <SimonSapin> | The RFC has a literal ";base64" string, no variation (casing, spaces, …) seems to be allowed. Some implementation today are more lenient, but I have no idea if someone relies on that. |
| 22:15 | <annevk> | SimonSapin: note that the URI RFC does call for removing escapes such as %4D but that browsers do not do that when parsing and that therefore you get them as literals when parsing scheme data |
| 22:16 | <annevk> | SimonSapin: it seems that both Gecko and Chrome do not treat data:text/ht%4DL as data:text/htML so maybe it's okay to not unescape at that point |
| 22:18 | <SimonSapin> | The data: RFC has some unprecise points, but nothing majorly broken so far |
| 22:18 | <annevk> | yeah, it's just a few minor things |
| 22:19 | <SimonSapin> | is it worth taking the whole thing over? |
| 22:21 | <annevk> | I think it's worth fixing, not really sure what the best way is |
| 22:23 | <Hixie> | marcosc_: historically testing hasn't been a strong enough reason to add a feature, but if you can get the vendors on board... |
| 22:27 | <SimonSapin> | wow, IETF has impressive documents in STD, like the Echo Protocol and the Discard Protocol |
| 22:31 | <annevk> | it seems in the early days the IETF did not have very high requirements for a STD |
| 22:31 | <annevk> | e.g. http://tools.ietf.org/html/std23 :-) |
| 22:31 | <SimonSapin> | annevk: was something wrong with the UTF-8 RFC? (I did not read it) |
| 22:32 | <SimonSapin> | yeah, I’m glad we reserved low TCP ports for these :) |
| 22:33 | <annevk> | SimonSapin: Unicode did not tie down error handling and I felt like making the set of encodings complete |
| 22:33 | <annevk> | SimonSapin: some of that could be done via reference maybe, but I'm not sure it would become clearer in the end |
| 22:34 | <Hixie> | annevk: yeah (re js: in the navigate layer), that's an interesting idea |
| 22:34 | <SimonSapin> | oh yeah, utf* is in Unicode … but also RFCs? |
| 22:35 | <annevk> | SimonSapin: I have the feeling there's some tension between Unicode and IETF |
| 22:35 | <SimonSapin> | "The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet. " (UTF-9) |
| 22:35 | <TabAtkins_> | lolwut |
| 22:36 | <SimonSapin> | did we actually have nonet-based hardware at some point? |
| 22:36 | <TabAtkins_> | Apparently the PDP-10 had a 36-bit word. |
| 22:36 | <TabAtkins_> | So a nonet was a useful size for the byte. |
| 22:37 | <hober> | and 18-bit addressing. great machine for representing cons cells on. :) |
| 22:37 | <TabAtkins_> | hober: Just because you have a couple extra bits for type tagging? |
| 22:38 | <annevk> | because April 1 TabAtkins_! |
| 22:39 | <TabAtkins_> | Oh jeez, of course. |
| 22:39 | <SimonSapin> | oh, I fell right for it |
| 22:41 | <annevk> | SimonSapin: in my experience it's easier to define the better version than to argue to the status quo and then define the better version |
| 22:41 | <TabAtkins> | At least UTF-9 is probably the sanest possible implementation of such a thing. |
| 22:41 | <TabAtkins> | Dunno what's going on with UTF-18. |
| 22:42 | <annevk> | SimonSapin: I suspect either way we'll end up fixing the data URL spec |
| 22:43 | <SimonSapin> | annevk: what bothers me is in some cases I have no idea how to decide what’s better. "base64" case-sensitive or not? Both sound fine… |
| 22:43 | <TabAtkins> | case-sensitive is best if you can get away with it. |
| 22:43 | <TabAtkins> | Just because it's simpler. |
| 22:44 | <annevk> | UTF-5! http://www.unicode.org/mail-arch/unicode-ml/Archives-Old/UML021/0846.html |
| 22:44 | <annevk> | there was also UTF-7.5 at some point, lost the reference |
| 22:44 | <SimonSapin> | TabAtkins: … do you mean insensitive? |
| 22:45 | <TabAtkins> | SimonSapin: No, sensitive. That way you can just do a straight string or byte comparison, no need to lowercase beforehand or whatever. |
| 22:46 | <SimonSapin> | TabAtkins: of course. I confused the two in my head |
| 22:46 | <TabAtkins> | Heh, np. |
| 22:46 | <annevk> | SimonSapin: since you need to lowercase the MIME string anyway (as you parse, since lowercasing parameter values is probably not okay), lowercasing might be better here... |
| 22:46 | <annevk> | SimonSapin: but again, what do implementations do? |
| 22:47 | <annevk> | SimonSapin: otherwise, do as jwalden said above and just note in the source of the text where you might want to change things based on feedback |
| 22:48 | <SimonSapin> | oh well … test case: data:;Base64,cGFzcw Firefox: pass, Chromium: cGFzcw, Opera: pas (missing an s) |
| 22:48 | <SimonSapin> | the test case is missing == padding |
| 22:48 | <GPHemsley> | So... container formats are annoying. Do you suppose it's my job to include instructions on how to differentiate among all the different Ogg-based audio and video formats? |
| 22:48 | <TabAtkins> | Yes. |
| 22:50 | <GPHemsley> | That would require implementing an at-least-rudimentary Ogg parsing algorithm |
| 22:50 | <annevk> | GPHemsley: again, only those we want to see implemented |
| 22:50 | <GPHemsley> | annevk: Well, there are a bunch of those. |
| 22:50 | <SimonSapin> | actual padding is ==, but = is enough to make Opera happy |
| 22:51 | <annevk> | GPHemsley: I'd ask implementors; maybe the course of action is just to determine it's "Ogg" and then find out in the Ogg library |
| 22:51 | <SimonSapin> | Ogg library sounds less insane |
| 22:53 | <annevk> | SimonSapin: in any event, it seems like you're hitting all the right edge cases :-) |
| 22:53 | <SimonSapin> | annevk: I’m gonna start with a test suite |
| 22:54 | <annevk> | SimonSapin: btw, I recommend testing one thing at a time; e.g. data:;base64,cGFzcw (lowercase B) gives "pass" in Chrome too, so that might be the right answer for the base64 algo |
| 22:54 | <SimonSapin> | I’m not sure why base64 even *has* padding, you can get by without it by counting the input length |
| 22:56 | <Hixie> | anyoen know offhand what default font IE uses on canvas? |
| 22:56 | <annevk> | maybe look at http://www.whatwg.org/html#atob too |
| 22:56 | <annevk> | SimonSapin: ^^ |
| 22:56 | <TabAtkins> | SimonSapin: When dealing with concatenated base64, you need padding. |
| 22:56 | <SimonSapin> | TabAtkins: concatenating encoded messages without re-encoding? |
| 22:57 | <TabAtkins> | Yes, concatting multiple base64-encoded things into a single text file. |
| 22:58 | <SimonSapin> | hum, I see nothing in rfc4648 about decoding the handling character anywhere but at the end |
| 22:58 | <SimonSapin> | s/decoding the handling character/handling the padding character/ |
| 22:59 | <TabAtkins> | Shrug, it's what wikipedia says. |
| 22:59 | <GPHemsley> | annevk, SimonSapin: Sent an e-mail to the list. |
| 23:00 | <Hixie> | GPHemsley: fwiw, i think combining video and audio together makes sense |
| 23:00 | <Hixie> | (the html spec doesn't distinguish them) |
| 23:00 | <GPHemsley> | ah, good |
| 23:00 | <GPHemsley> | but they are distinct from images, correct? |
| 23:01 | <Hixie> | yes |
| 23:02 | <SimonSapin> | GPHemsley: I don’t know anything about sniffing, but re-inventing a Ogg parser for this sounds "like a jackhammer to squach a fly" |
| 23:02 | GPHemsley | thinks he needs to reword the anonymous wiki registration message to make clear that accounts are only need to edit the wiki. |
| 23:02 | <GPHemsley> | SimonSapin: Oh, I am opposed to it, too. :) |
| 23:03 | <GPHemsley> | Of the five or so accounts I've created, only one of them has actually been used. |
| 23:03 | <GPHemsley> | (maybe it's more than five) |
| 23:03 | <GPHemsley> | on person wanted two accounts: one for them, and one for their company. |
| 23:03 | <annevk> | haha nice find MikeSmith |
| 23:04 | <GPHemsley> | I created one, asked about the other, haven't heard back |
| 23:04 | <SimonSapin> | (that expressions sounds even better in english than french) |
| 23:04 | <annevk> | first splits Microdata from HTML5 http://lists.w3.org/Archives/Public/public-html/2009Dec/0299.html then argues for making it useless https://www.w3.org/Bugs/Public/show_bug.cgi?id=20082 |
| 23:05 | <SimonSapin> | "(not as a chair or editor of RDFa)" |
| 23:05 | <MikeSmith> | annevk: that find goes to Maciej actually |
| 23:06 | <MikeSmith> | or at least the credit for pointing it out first |
| 23:06 | <MikeSmith> | annevk: http://lists.w3.org/Archives/Public/public-html/2012Nov/0186.html |
| 23:08 | <annevk> | it's sad that we can't free othermaciej to work on other things than lawyering |
| 23:09 | <othermaciej> | I would enjoy working on real things |
| 23:09 | <TabAtkins> | GPHemsley: Regarding your questions a few days ago about EOT, EOT1 is trivial - just a simply documented header on top of the TTF format. EOT2 is much more complex, and has weirder patent issues due to the in-built MTX compression. EOT2 never made significant progress in the W3C because of that. EOT1 was rejected in favor of WOFF1 largely for policitical reasons. |
| 23:27 | <SimonSapin> | annevk: does synchronous XHR sounds like good way to test data: ? |
| 23:28 | <annevk> | maybe synchronous <iframe> that does a postMessage() to its parent? |
| 23:29 | <annevk> | XHR'ing data URLs is not widely supported yet |
| 23:29 | <SimonSapin> | hum, how would that work? |
| 23:29 | <SimonSapin> | have the whole script with postMessage be part of the data: URL? |
| 23:29 | <annevk> | never mind |
| 23:30 | <annevk> | so I guess the problem is that some browsers don't do XHR'ing data URLs and some browsers don't allow same-origin access to <iframe> with a data URL |
| 23:30 | <annevk> | otherwise you could do <iframe>.contentDocument.... after the data URL loaded |
| 23:31 | <GPHemsley> | TabAtkins: I didn't know there were two. I imagine IE implements both? |
| 23:34 | <SimonSapin> | annevk: is there an intersection between these sets of browsers? |
| 23:35 | <annevk> | SimonSapin: sorry, dunno |
| 23:35 | <annevk> | matjas: http://wiki.ecmascript.org/doku.php?id=strawman:name_property_of_functions |
| 23:38 | <SimonSapin> | annevk: so XHR, <iframe>.contentDocument … other potential ways to test data: from JS? |
| 23:39 | <annevk> | SimonSapin: if you include script in them you can run a Worker based on a data URL |
| 23:40 | <annevk> | SimonSapin: I suspect if it failed to parse/compile you'd get an error of some kind and otherwise the script could post a message back, might be a simple way |
| 23:40 | <annevk> | SimonSapin: cannot really think of anything else right now, maybe tomorrow :) |
| 23:41 | <SimonSapin> | thanks :) |
| 23:57 | <TabAtkins> | GPHemsley: Yes, they do. Actually a few variants, too. |