| 05:47 | <jamesr> | http://probablyinteractive.com/url-hunter |
| 09:14 | jgraham | is very confused about whether there is actually a concept of things being OK but not "authorised" and if so what the word "authorised" implies |
| 09:20 | <jgraham> | Also, and unrelatedly, if objects-as-keyword arguments have to evaluate all the expected keys in a defined order first, can we end up with a problem if vendors add extensions? At the very least any extensions should be evaluated last |
| 09:28 | <Ms2ger> | Do we avoid that if we only allow data properties? |
| 09:29 | <jgraham> | The proposal to only allow data properties wasn't popular |
| 09:29 | <jgraham> | in particular with the TC39 people |
| 09:30 | <Ms2ger> | Was with me |
| 09:31 | <jgraham> | Ms2ger: Well if you fancy arguing with Brendan and Allen, feel free |
| 09:33 | Ms2ger | waits for a spec |
| 09:49 | <hsivonen> | jgraham: what's the context of "authorized"? |
| 09:51 | <jgraham> | hsivonen: The "option 3" discussion |
| 09:52 | <jgraham> | http://www.w3.org/mid/D9DDF34C-2949-4CB1-8E88-CD25444E1CDF⊙mc infers a distinction between things that are OK and things that are authorized presumably based on http://www.w3.org/mid/085c01cbdd27$b7719b50$2654d1f0$@com |
| 09:53 | <jgraham> | But I found each additional explaination in that thread has only added to, not reduced, my confusion |
| 10:46 | <karlcow> | I wonder if authorization relates to http://en.wikipedia.org/wiki/Authorization#Publishing |
| 11:16 | <hsivonen> | karlcow: is that based on some kind of legal loophole around a work having to be fixed in a tangible medium to be under copyright? |
| 11:17 | <karlcow> | hsivonen: legal frameworks are difficult and change from countries to countries. So I have no ideas about that. |
| 11:17 | <karlcow> | I guess it is the same type of photos of a person when in the street. |
| 11:18 | <karlcow> | In USA no issue |
| 11:18 | <karlcow> | In Quebec, you do not have the right |
| 11:18 | <karlcow> | In France there is a right to images in some circumstances |
| 11:19 | <karlcow> | For text in France, there are two rights: Patrimonial (property) and Moral |
| 11:19 | <karlcow> | the moral right never ceases |
| 11:19 | <hsivonen> | I can imagine that lecture thing to be some kind of English thing that wouldn't fly in France |
| 11:19 | <karlcow> | and you can forbid someone to publish a text if you think it is misrepresenting the idea of the text or something like that. IANAL |
| 11:20 | <karlcow> | hsivonen: yes probably |
| 11:21 | <karlcow> | It's all silly, really. It is inherited from a time where it might have made sense. But now it seems more and more idiotic. :/ |
| 11:54 | <annevk> | http://wiki.whatwg.org/wiki/Special:RecentChanges isn't search already a keyword on its own? |
| 11:55 | <zcorpan> | foolip: maybe we should also make things more forgiving e.g. make setting currentTime in HAVE_NOTHING just work by doing the seek when it's possible to seek |
| 11:56 | <foolip> | zcorpan, I agree, but that's kind of an orthogonal issue |
| 11:56 | <zcorpan> | yes |
| 11:56 | <foolip> | and there would be less reason to allow that if the spec wasn't racy |
| 11:56 | <zcorpan> | true |
| 12:01 | <annevk> | yay ojan |
| 12:02 | <annevk> | also, not yay me |
| 12:02 | <annevk> | >1000 |
| 12:02 | <annevk> | :/ |
| 12:06 | zcorpan | has 3333 unread mailing list emails |
| 12:07 | jgraham | has one two threee more lots |
| 12:07 | <zcorpan> | biggest chunk is public-html-bugzilla almost exactly a third |
| 12:08 | <annevk> | well i'm not subscribed to that one and I don't have a QA day job :) |
| 12:44 | <annevk> | copyright threads :/ |
| 12:44 | <annevk> | if only rigo would listen to timbl |
| 13:38 | <matjas> | any ideas on how to feature detect <details> support? |
| 13:38 | <matjas> | now that Chrome false positives on `'open' in document.createElement('details')` |
| 13:39 | <Rik`> | it's really annoying that Chrome is breaking so many feature detections |
| 13:40 | <matjas> | I was thinking of injecting a <details><summary>foo</summary>bar</details>, triggering onclick on the summary and see if the height changes |
| 13:41 | <hsivonen> | looks like the Chrome team needs a serious policy-level solution to this problem |
| 13:41 | <hsivonen> | it's not even the first time |
| 13:41 | <hsivonen> | do they score higher on html5test.com because of this? |
| 13:41 | <zewt> | matijsb: last I played with it, synthetic click events didn't fire default behavior in FF (bug, IMO) |
| 13:42 | <matijsb> | matjas: ^ :) |
| 13:42 | <Ms2ger> | html5test checks 'open' in element |
| 13:42 | <zewt> | my policy is to nick complete at 3 characters and any ambiguities at that point are a bug in other people's nicks :P |
| 13:43 | <annevk> | zewt, I don't think it's a bug |
| 13:44 | <zewt> | annevk: i remember ... some spec (dom events?) saying that most events shouldn't run defaults for synth events, but that click was an explicit exception |
| 13:44 | <annevk> | zewt, in fact, default behavior should only happen if the code path that dispatched the event also contains the default behavior |
| 13:44 | <annevk> | if(target.dispatchEvent(ev) default() |
| 13:44 | <annevk> | zewt, that spec is silly |
| 13:44 | <annevk> | zewt, http://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 |
| 13:45 | <zewt> | that doesn't make sense to me; the entire point of dispatching a click event would be to cause its click action to be run |
| 13:45 | <zewt> | you shouldn't have to examine the object you're fake-clicking and hardcode all of the possible default behaviors (which I've had to do, eg. manually copying window.location.href = a.href) |
| 13:48 | <annevk> | why else would dispatchEvent return a value? |
| 13:48 | <zewt> | so you can run your own default behavior after the browser runs its |
| 13:48 | <annevk> | hmm |
| 13:49 | <zewt> | i've always viewed browser default event behavior as being part of event dispatch ... that is, not logically equivalent to the browser using dispatchEvent() and checking the return |
| 13:49 | <zewt> | of course, it's moot and totally equivalent most of the time, when browsers refuse to run default behavior for nontrusted events |
| 13:50 | <zewt> | and since there are so few events where you can actually do that I'm not religiously attached to that view of events or anything |
| 13:51 | <zewt> | i'm not sure what the trusted flag is for otherwise, though... |
| 13:51 | <zewt> | i've always viewed the trusted flag as letting the default browser event handler tell whether the event originally came from the browser and not a script |
| 13:52 | <zewt> | if default behavior is logically outside of dispatch anyway, that doesn't matter |
| 13:53 | <annevk> | because of hixie I started viewing it the dispatchEvent() way |
| 13:53 | <annevk> | I don't really care what way is correct |
| 13:53 | <annevk> | but I'd appreciate consistency |
| 13:53 | <annevk> | so if synthetic click should work, synthetic submit should too |
| 13:54 | <annevk> | but making neither work is fine with me too |
| 13:55 | <zewt> | i don't think firing submit always submits--I have some code here that explicitly does dispatchEvent(e); if(!e.stopped) form.submit(); but I don't remember if that was needed on all browsers or what (oldish code) |
| 13:55 | <zewt> | or if the code's just wrong |
| 13:57 | <annevk> | e.stopped? |
| 13:57 | <zewt> | er that's a prototype thing (mirrors preventDefault) |
| 14:00 | <zewt> | on a quick test FF3.6 seems to submit on synth submit events, chrome 9 seems not to? |
| 14:00 | <zewt> | i sure love the web |
| 14:00 | <annevk> | the bug above has the cross-browser info |
| 14:05 | <zewt> | fwiw, the use case here is capturing things that need auth (clicks and form submits on registered-only features, etc), running a login handler in an overlay, then redispatching after login is completed |
| 14:07 | <zewt> | (but it handles IE, so it's not nearly that simple, heh) |
| 14:09 | <annevk> | you can also do that by <a>.click() and and <form>.submit() |
| 14:09 | <zewt> | no you can't--those don't dispatch events |
| 14:10 | <annevk> | you listen to the event, prevent it, do auth, then invoke those |
| 14:10 | <zewt> | that would skip event handlers |
| 14:11 | <zewt> | if you're capturing document.onclick, doing the login stuff, then you call target.click(), none of the event handlers below it would ever run |
| 14:12 | <annevk> | volkmar, hey, what was the in-range/out-of-range bug again? |
| 14:16 | jgraham | is disappointed at WebKit for breaking <details> |
| 14:18 | <zewt> | annevk: if event defaults are outside of dispatch, what's the purpose of trusted? |
| 14:18 | Ms2ger | is disappointed at WebKit in general |
| 14:19 | <annevk> | allows complex sites to see where the event came from |
| 14:19 | <annevk> | i.e. whether it was library or UA-generated |
| 14:19 | <annevk> | could be used e.g. to enable debugging code if you use synthetic events for automated testing |
| 14:21 | <zewt> | i'd just set a custom property to do that in my test code, don't need browser help for it |
| 14:22 | <annevk> | the browser does not need isTrusted exposed to do what it does now either |
| 14:23 | <zewt> | even less so if default behavior is thought of as outside dispatch |
| 14:24 | <annevk> | i don't think that was the reason why it was exposed |
| 14:24 | <annevk> | but i don't think it matters much |
| 14:24 | <annevk> | if you have many libraries and lots of people working on the code it might be good to know where the event came from in certain situations |
| 14:27 | <volkmar> | annevk: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12151 |
| 14:28 | <annevk> | ta |
| 14:39 | <AryehGregor> | So, how fair is the IEBlog post just now on hardware acceleration? |
| 14:39 | <AryehGregor> | It looks like they're saying IE beats everyone fair and square, and I don't notice any obvious problems with their account. |
| 14:39 | <AryehGregor> | But I don't have a machine handy with IE9 and a decent graphics card to test on. |
| 14:41 | <Rik`> | AryehGregor: testing with only one demo, produced by themselves ? |
| 14:41 | <AryehGregor> | Rik`, but was the demo unfair? |
| 14:42 | <annevk> | seems a bit early to tell |
| 14:42 | <annevk> | but so far their track record has been that they publish about what works and keep everything else hidden |
| 14:46 | <jgraham> | AryehGregor: It is impossible to tell without actually analysing it. e.g. they could be selecting particular operations they know they are fast at, or making the scores highly non-linear to accentuate small differences |
| 14:48 | <AryehGregor> | Or they could also have a better GPU acceleration implementation? |
| 14:48 | <AryehGregor> | Is there any evidence against that? |
| 14:48 | <jgraham> | I have no evidence either way |
| 14:49 | <AryehGregor> | Seems like it's important for other browser vendors to investigate. |
| 14:50 | <jgraham> | Sure. But that blog post doesn't strongly affect my opinion of whether their implementation is good |
| 14:50 | <jgraham> | because, without actually doing that investigation, there is very little information |
| 14:53 | <AryehGregor> | Wow, and I thought SSL warnings gave too little info: http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-47-13-metablogapi/6428.image_5F00_1DC874E0.png |
| 14:53 | <AryehGregor> | That's a whole new league of useless. |
| 14:58 | <zewt> | annevk: brings to mind a use case for calling preventDefault before dispatchEvent |
| 14:58 | <Ms2ger> | Normal people don't read those dialogs, so it doesn't matter |
| 14:59 | <zewt> | there's no way of knowing whether a browser will run default behavior on a synth event (short of hardcoding the cases); the reliable thing to do is to always preventDefault before every synth event to guarantee it won't be |
| 15:00 | <zewt> | i sure wish FF would stop making me do a four-step song and dance every time I want to load an SSL page with a self-signed cert; I'll take a "yes/no" dialog over that any day, heh |
| 15:01 | <AryehGregor> | Yeah, the way browsers handle SSL errors is incredibly broken all down the line. |
| 15:02 | <zewt> | wish from the beginning there had been a separate protocol name, eg. "httpe", which was https with no certificates |
| 15:02 | <zewt> | then people who just want encryption would use it and the entire https certificate prompting thing would be much less of an issue |
| 15:03 | <zewt> | (in practice, I'm guessing something like SPDY will be the real-world fix) |
| 15:05 | <AryehGregor> | I'm hoping that STS will encourage browsers to treat security errors in non-STS contexts less severely. |
| 15:05 | <zewt> | havn't heard of that |
| 15:06 | <AryehGregor> | http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security |
| 15:09 | <zewt> | what's really needed is a mechanism to allow encryption with no cert without prompting at all--I doubt browsers will ever do that with https |
| 15:11 | <zewt> | if it's an excuse to get people to stop with the absurd "click here, now click here, now do the chicken dance and sing show tunes" game for self-signed sites, that'd be a step forward, though |
| 15:12 | <jgraham> | Maybe you should should rig up the Wii Fit to your browser so it could *actually* make you dance |
| 15:12 | <AryehGregor> | What they need to do is have a more nuanced approach, not the all-or-nothing way they do it now. |
| 15:13 | <zewt> | i'm not sure nuance works for security when it meets real-world users :) |
| 15:13 | <AryehGregor> | Anyway, the current way they do it is complete garbage, since it strongly assumes the site is malicious when everyone knows there's an approximately 100% chance that it's perfectly fine. |
| 15:14 | <zewt> | and the message it sets is essentially "unsigned encryption is less secure than plaintext", which is idiotic |
| 15:16 | <jgraham> | I think the theory is that unsigned encryption when you think you are securely connected is less good than a connection that is known to be untrusted |
| 15:16 | <zewt> | yeah, I understand the rationale for prompting with https |
| 15:17 | <zewt> | to prevent an MITM using an unsigned/self-signed cert |
| 15:17 | <jgraham> | Well given the rationale, I don't think it's idiotic |
| 15:17 | <jgraham> | Although it porbably makes inaccurate assumptions about user's mental models |
| 15:17 | <jgraham> | *probably |
| 15:17 | <zewt> | the rationale is fine; the way it solved it is broken, it's the end result that's idiotic |
| 15:18 | <jgraham> | If you think the rationale is fine, what is the better soluton? It seems to me that the rationale is likely flawed |
| 15:19 | <zewt> | there should have been a separate origin which was SSL without signing (and not displayed to the user as secure) |
| 15:19 | <Ms2ger> | "Is", not "would have been" ;) |
| 15:19 | <jgraham> | What was the backwards-compatible solution? :) |
| 15:19 | <jgraham> | s/was/is/ |
| 15:20 | <zewt> | there's no backwards-compatible solution, which is why I said "should have been" rather than "should be" :) |
| 15:20 | <jgraham> | Then it seems silly to complain about it |
| 15:21 | <zewt> | hardly; it needs to be fixed going forward--like I said, I suspect the real solution will happen if SPDY, or something out of it, gains traction |
| 15:21 | <zewt> | it's always SSL, so I think that's effectively what would happen |
| 15:21 | <jgraham> | A good solution might be just to not distinguish http and no-cert https in the UI |
| 15:22 | <jgraham> | and complain loudly only if a site goes from cert-?no cert |
| 15:22 | <zewt> | well, yeah, ideally the "http" user-visible protocol would have been able to seamlessly upgrade to an SSL connection, but I understand why that didn't happen |
| 15:23 | <jgraham> | There is no really good reason for the string "http" to appear in the UI |
| 15:23 | <zewt> | Ms2ger: (not sure what you meant, btw) |
| 15:24 | <zewt> | heh chrome's magic-http-hiding thing drives me nuts, since I'll try to copy a hostname out of the address bar and it'll tack "http://" on it |
| 15:24 | <jgraham> | zewt: See if O11's approach drives you less nuts |
| 15:25 | <zewt> | it's definitely less magic, which is good |
| 15:27 | <zewt> | also not a fan of how both browsers put the path in an unreadable low-contrast grey |
| 15:27 | <zewt> | the address bar is every browser's favorite playground for overly-clever gimmicks, heh |
| 15:51 | <Olemiss> | Hey guys, I have a quick question... Is it ok to use the information on Whatwg on a Wiki? |
| 15:53 | <Olemiss> | For instance, if I wanted to create an article on Wikipedia about a feature of Html5, would I get in trouble if I copied some information from Whatwg? |
| 15:53 | <Ms2ger> | Not at all |
| 15:54 | <Ms2ger> | You can do whatever you like with it |
| 15:54 | <Olemiss> | Alright, great... is there anywhere on the whatwg site that says so? |
| 15:55 | <Olemiss> | I just want my facts to be straight, and theres nothing better than the source. |
| 15:57 | <jgraham> | Olemiss: The WHATWG wiki is MIT licensed. The spec is under a special license included in the file |
| 15:57 | <jgraham> | I don't know about anything else |
| 15:57 | <Philip`> | The wiki should say licensing details at the bottom of every page |
| 15:57 | <Olemiss> | Yeah, thats what I figured, ill look deeper |
| 16:03 | <hsivonen> | hmm. what's the deal with Wikipedia not appearing to have guidelines about importing non-PD but Free content from elsewhere into Wikipedia? |
| 16:04 | <hsivonen> | I'd have expected Wikipedia to have guidelines about importing MIT/BSD content |
| 16:34 | <MikeSmith> | hsivonen: http://www.mozillazine.org/articles/article177.html seems not to work |
| 17:01 | <twisted_> | hmm weird, Safari just outperformed Chrome 10 with the http://ie.microsoft.com/testdrive/Performance/MazeSolver/Default.html |
| 17:01 | <twisted_> | Chrome took 264seconds, Firefox 4 176s, Safari 216 seconds |
| 17:02 | <Peter-> | The performance has been improved through a patch last week, it almost doubled |
| 17:02 | <Peter-> | (for WebKit that is) |
| 17:03 | <annevk> | zewt, if you always call preventDefault() you cannot use the mechanism yourself |
| 17:04 | <annevk> | zewt, however, recent DOM Core no longer resets the "canceled flag"; unless you invoke initEvent() |
| 17:41 | <zewt> | annevk: it's unfortunate to not be able to tell whether an event will or did have default behavior executed... |
| 17:42 | <zewt> | even if everyone consistently follows the "allow defaults for click" approach, it's still really fuzzy, eg. it probably still generally only works for button = 0 (can't synthetize a right click and open a context menu) |
| 17:43 | smaug____ | needs to find some time to review d&d. Looks like the latest changes haven't been reviewed. |
| 17:44 | <Ms2ger> | And DOM Core ;) |
| 17:44 | <zewt> | so yeah, it's an annoying limitation but I think I agree that treating default behavior as being run by the caller to dispatch and not as part of dispatch itself makes more sense |
| 17:45 | <zewt> | (or at least, is much less complex to get right) |
| 17:53 | <Ms2ger> | http://rly.cc/Moi8M, in case anybody is interested in /. |
| 18:29 | <annevk> | hmm, so maybe we should nuke CustomEvent? |
| 18:29 | <annevk> | it's not really widely implemented |
| 18:30 | <annevk> | Erik has some cool ideas |
| 18:30 | <zewt> | how does it differ from just creating a basic Event? |
| 18:35 | <zewt> | i guess there's ... really no difference |
| 22:01 | <zewt> | TabAtkins: well, almost off-list... |
| 22:29 | <TabAtkins> | Sigh. Yeah... |
| 23:17 | <Hixie> | heycam: what's the use case for http://dev.w3.org/2006/webapi/WebIDL/#idl-static-operations ? |
| 23:17 | <Hixie> | are there features in the platform (other than URL) that use this? |
| 23:17 | <zewt> | http://zewt.org/~glenn/test-hashchange-ff4.html browser back after a history.pushState doesn't seem to fire onhashchange in ff4rc1 ... anyone feel like double-checking/confirming before I file it? |
| 23:18 | <heycam> | Hixie, sicking is using it for something in indexed db |
| 23:18 | <Hixie> | aw man |
| 23:18 | <sicking> | yes! |
| 23:18 | <heycam> | you don't like it? |
| 23:18 | <Hixie> | it's so... not like the rest of the platform |
| 23:18 | <sicking> | zewt: are you actually changing the hash? |
| 23:18 | <zewt> | yes |
| 23:18 | <sicking> | oh, i see what you mean |
| 23:19 | <zewt> | history.pushState({}, window.title, url + "#1"); |
| 23:19 | <sicking> | zewt: are you sure it's supposed to fire? |
| 23:19 | <heycam> | Hixie, JS has built in methods like that... Object.whatever, e.g. |
| 23:19 | <sicking> | zewt: iirc there's some comment in the code specifically stating that we should not fire |
| 23:19 | <zewt> | i think it is (on browser back, not due to the pushState itself), but i'm not positive so i'm asking here |
| 23:19 | <sicking> | zewt: oooh |
| 23:19 | <Hixie> | heycam: i guess |
| 23:19 | <zewt> | noticed since it broke my app that works in c9 |
| 23:20 | <sicking> | zewt: you want it to fire when pressing "back". Not when calling pushState |
| 23:20 | <Hixie> | heycam: yeah, ok |
| 23:20 | <Hixie> | heycam: fair enough |
| 23:20 | <sicking> | zewt: ? |
| 23:20 | <Hixie> | heycam: nevermind :-) |
| 23:20 | <heycam> | Hixie, ok :) |
| 23:20 | <zewt> | right--browser back is a navigation, regardless of how the history entry was created |
| 23:21 | <sicking> | zewt: file a bug, cc me and ":jlebar" |
| 23:21 | <sicking> | zewt: won't get fixed for FF4, but maybe we can fix it for FF4.0.1 |
| 23:22 | <zewt> | :| |
| 23:22 | <zewt> | k |
| 23:23 | <Hixie> | zewt: that part of the spec changed back and forth a lot unfortunately |
| 23:23 | <Hixie> | zewt: so browser vendors probably had a hard time keeping track |
| 23:23 | <sicking> | zewt: i know. It's just too much risk to take at this point. The code is done FF4RC was just released |
| 23:23 | <sicking> | which reminds me |
| 23:23 | <zewt> | odd, it would be strange not to fire onhashchange depending on how the history entry was changed (which is what seems to be happening, anyway) |
| 23:23 | <Hixie> | (it's the main reason i am so reluctant to change anything, which is why i'm always pushing back ever on somewhat good ideas) |
| 23:24 | <Hixie> | (when they involve changing rather than adding) |
| 23:24 | <sicking> | hear ye, hear ye. Go download FF4RC and let me know if you find any problems. Or file a bug |
| 23:24 | <sicking> | getfirefox.com/beta |
| 23:24 | <zewt> | ... is the about screen supposed to not have the build identifier anywhere? heh |
| 23:25 | <zewt> | (i'm sure that when I type in "ff4rc1" people will know what I mean, but I usually just copy and paste from that dialog) |
| 23:27 | <smaug____> | zewt: about:support should give all sorts of information, like the build identifier |
| 23:28 | <zewt> | odd to move it, fyi the bug tracker still points at help->about |
| 23:28 | <smaug____> | and I was wrong :) |
| 23:28 | <smaug____> | it doesn't have the buildid |
| 23:29 | <zewt> | FF4 does, but FF3.x doesn't |
| 23:29 | <zewt> | (so if it's not in help->about, there's no version-agnostic place to point people to get it) |
| 23:29 | smaug____ | doesn't use release builds, so about:support gives a bit different information |
| 23:37 | <zewt> | sicking: https://bugzilla.mozilla.org/show_bug.cgi?id=640387 |
| 23:39 | <sicking> | Hixie: fwiw, I generally much prefer having a bug filed against me that I can fix in an update, than leave major problems in an API in an effort not to change the spec |
| 23:40 | <Hixie> | sicking: yeah if the change is a major problem it's a different matter, and i'll try to fix it |
| 23:41 | <sicking> | Hixie: and it's generally not that hard to track the spec if you just file a bug (and ideally attach a testcase) against existing implementations. |
| 23:41 | <Hixie> | (i was referring more to design preferences) |
| 23:42 | <Hixie> | sicking: i wish i had the bandwidth to do that. |
| 23:42 | <Hixie> | speaking of design preferences, why is URL.createObjectURL() called createObjectURL()? |
| 23:42 | <sicking> | Hixie: as opposed to? |
| 23:42 | <Hixie> | dunno |
| 23:42 | <Hixie> | it returns a URL string, not an Object |
| 23:42 | <Hixie> | createURLForObject()? |
| 23:42 | <zewt> | yay for user-agent sniffing for bug workarounds |
| 23:43 | <Hixie> | i don't really mind what it's called, just curious where the name came from |
| 23:43 | <sicking> | Hixie: it started as createFileURL(), but then we realized that we probably want to use it for streams |
| 23:43 | <Hixie> | yeah i'm writing the Stream version as we speak |
| 23:43 | <sicking> | Hixie: hence s/File/Object/ to make it more generic |
| 23:43 | <Hixie> | fair enough |
| 23:44 | <sicking> | Hixie: I would have been fine with createURLForObject too, but it's essentially shipped at this point, renaming doesn't seem worth it |
| 23:44 | <Hixie> | yeah, not suggesting we change it |
| 23:45 | <Hixie> | as far as names go i'm always happy to defer to whoever is writing the relevant spec |
| 23:45 | <sicking> | Hixie: is there a reason you can't just let streams use URL.createObjectURL? |
| 23:45 | <Hixie> | that's what i'm doing |
| 23:45 | <zewt> | heh i coincidentally have code onscreen to workaround the createObjURL/createBlobURL thing in earlier FF builds right now |
| 23:45 | <sicking> | Hixie: i concur |
| 23:45 | <sicking> | Hixie: sweet! |
| 23:45 | <Hixie> | :-) |
| 23:45 | <zewt> | (since I'm in the "work around browser nits" part of my setup code for the pushState workaround) |
| 23:46 | <Hixie> | i wish pushState was better designed |
| 23:46 | <sicking> | Hixie: i doubly concur :( |
| 23:46 | <Hixie> | i mean, i _wrote the spec_ and i'm not sure i understand it |
| 23:46 | <Hixie> | it's sad |
| 23:46 | <sicking> | Hixie: err.. though.. i owe the list a long email |
| 23:47 | <zewt> | (guess I can remove the createBlobURL compatibility at this point) |
| 23:47 | <sicking> | Hixie: we made a number of changes compared to the spec after talking it over with google |
| 23:47 | <Hixie> | oh, good |
| 23:47 | <Hixie> | maybe it can be saved yet |
| 23:47 | <sicking> | IMHO it's much better now, but still confusing. Though *mostly* confusing in name |
| 23:47 | <zewt> | i'm just happy to have replaceState at all, since that's something that's bugged me for a long time (don't expect to actually get away from hashes any time soon) |
| 23:48 | <Hixie> | if you don't have time to write a long e-mail, please send a short one reminding me to reverse engineer it |
| 23:48 | <zewt> | no longer need to carefully choose which things to stash in the URL based on not wanting to spam the history |
| 23:48 | <sicking> | Hixie: http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/ |
| 23:49 | <Hixie> | those changes make sense |
| 23:49 | <Hixie> | having popstate delayed until after load was to make sure you didn't miss any sent before your code was ready, but if you add window.history.state that solves that problem |
| 23:50 | <Hixie> | i'll file a bug to update the spec |
| 23:50 | <erlehmann> | hashes break semantics. i rage every single time friends of mine send me hash urls and i cannot read the content. |
| 23:50 | <sicking> | Hixie: sweet, thanks! |
| 23:50 | <erlehmann> | s/hash/hashbang/gi |
| 23:50 | <sicking> | Hixie: i did realize another big flaw though. Which we did not have time to fix, but which *might* be salvagable |
| 23:50 | <Hixie> | sicking: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12277 |
| 23:51 | <zewt> | that's irrelevant for totally javascript-based web apps that don't use anchors at all, and hashes are the only way to do what they do until History is widely-deployed, so you'll have to bear with it for a while yet, heh |
| 23:51 | <erlehmann> | ._. |
| 23:51 | <zewt> | ____________ |
| 23:52 | <sicking> | Hixie: the problem is that if you have a page which uses the state argument. And the user clicks a <a href="#hash"> somewhere in the page. That doesn't just scroll, it also creates a history entry that doesn't have the state |
| 23:53 | <Hixie> | sicking: yeah, you can work around that using onhashchange and replaceState() |
| 23:53 | <Hixie> | sicking: not clear what the right solution is in the API though |
| 23:54 | <sicking> | Hixie: ideally all history entries which just represent hash-navigation should share state |
| 23:54 | <sicking> | Hixie: onhashchange and replaceState isn't really enough |
| 23:54 | <erlehmann> | sicking, in chrome it is difficult to use the address bar when devs are abusing the history (as you may have seen on hacker news) – new URLs tend to overwrite my input as soon as it loses focus. does mozilla have any remedy for that? |
| 23:54 | <sicking> | Hixie: you can add the state on the newly created history entry, but if you later need to change the state (using replaceState), you can only modify the state for the current entry, not the previous one |
| 23:55 | <Hixie> | sicking: ah, yeah. if you need to share the state that's a bigger problem. |
| 23:55 | <Hixie> | sicking: you can work around that too by storing an index instead of the state, but that's lame, granted. |
| 23:55 | <sicking> | Hixie: s/share/modify/ ? |
| 23:55 | <Hixie> | sicking: modify shared state |
| 23:56 | <sicking> | erlehmann: first i hear of it. Don't know how our frontend code will behave |
| 23:56 | <sicking> | Hixie: right, the index thing won't work on restarts |
| 23:56 | <sicking> | Hixie: or getting kicked out of bfcache |
| 23:57 | <Hixie> | sicking: it will if it's an index into localStorage, but granted. |
| 23:57 | <sicking> | Hixie: true |
| 23:57 | <Hixie> | sicking: can you file a bug on this? or add a comment to http://www.w3.org/Bugs/Public/show_bug.cgi?id=12277 ? |
| 23:57 | <erlehmann> | sicking, >http://www.webmonkey.com/2011/03/url-hunter-a-cool-game-but-not-html5/<; |
| 23:57 | <sicking> | Hixie: i'll file a separate bug on it |
| 23:58 | <Hixie> | sicking: thanks |
| 23:58 | <erlehmann> | oh wait. that is using anchors. |
| 23:58 | <erlehmann> | err fragments |
| 23:59 | <Hixie> | sicking: do you know who has implemented this stuff? were you talking to chrome people at google about this? just curious how much of a compat constraint we have here. |
| 23:59 | <sicking> | erlehmann: wow, that's hilarious |
| 23:59 | <sicking> | Hixie: i was talking to darin fisher and another google guy. The safari people still need to buy into it though. |
