| 00:21 | <AryehGregor> | "I believe what implementors present at TPAC agreed to is that we do not like mutation events and want them to die in a fire." Why? |
| 00:22 | <AryehGregor> | Bad performance, hard to implement, underdefined? |
| 00:25 | <Dashiva> | Yes |
| 00:25 | <Dashiva> | All three |
| 00:25 | <Dashiva> | There's been some work to define an alternate solution that satisfies the practical use cases without suffering from the same problems |
| 00:53 | <AryehGregor> | Whoa, paths on Windows are a maximum of 256 characters in the standard APIs? |
| 00:53 | <AryehGregor> | That's amazingly lame, even for Windows. |
| 00:55 | <TabAtkins> | AryehGregor: The mortal sin of mutation events is that they're defined to fire sync, which means that you immediately get re-entrancy problems - a function may mutate the DOM, then the mutation event runs, possible changing the DOM underneath the function. Mutation events can even fire syncly during other mutation events. This is crazytimes. |
| 00:55 | <AryehGregor> | Ouch. |
| 00:56 | <TabAtkins> | Yeah, mutation-events-inside-mutation-events are a sure route to stale pointer issues in teh browser implementation. |
| 00:56 | <othermaciej> | they also suck for perf |
| 00:56 | <othermaciej> | since dynamically allocating events for every DOM mutation is super expensive |
| 00:56 | <TabAtkins> | Further, mutation events suffer from the same problem as the key* family, where a single type of event is fired for *everything*, and you have to decide inside the listener if youa ctually wanted to listen to it or not. |
| 00:57 | <Philip`> | AryehGregor: No, it's not limited to 256 characters |
| 00:58 | <Philip`> | It's limited to 260 (including the drive identifier and terminating null) |
| 00:58 | <AryehGregor> | Ah, that's better, then. |
| 00:58 | <TabAtkins> | They'd be much less painful if they were async and were changed so you could listen to specific things, like "I want to be notified when this specific attribute on this specific element is changed". |
| 00:58 | <Philip`> | MAX_PATH is 260, so lots of applications have fixed-size buffers that won't cope with longer paths, I think |
| 00:58 | <TabAtkins> | (Similar to how key* would be better if you could say "I want to listen for when the user presses an arrow key". |
| 00:59 | <TabAtkins> | Philip`: Specifically, Explorer. |
| 01:00 | <zewt> | explorer could deal with it if Microsoft updated it to use whatever the newer APIs are that don't have that limitation; I imagine they don't since no other applications support it (chicken/egg) |
| 01:00 | <zewt> | it's pretty funny that you can create file trees in explorer that you can then not delete |
| 01:01 | <zewt> | (without playing filename puzzle games to reduce path lengths) |
| 01:01 | <AryehGregor> | What I really want is an API that lets me run some code immediately before or after an element is added to the DOM that matches a particular CSS selector. |
| 01:01 | <AryehGregor> | E.g., if I have something where I want to change the state somehow immediately when it's added to the page, for whatever reason. |
| 01:01 | <TabAtkins> | "immediately before" is hard. |
| 01:01 | <Hixie> | by immediately you mean synchronously? |
| 01:01 | <AryehGregor> | Like because I want the default appearance to differ between scripting and non-scripting UAs. |
| 01:01 | <Hixie> | if so, that's the problem with mutation events. |
| 01:01 | <TabAtkins> | Unless you make the DOM mutatino APIs async. |
| 01:02 | <AryehGregor> | I want something that behaves like inserting a <script> tag immediately before or after the open or close tag of a particular element. |
| 01:02 | <AryehGregor> | So that I don't have to, you know, actually do that. |
| 01:02 | <AryehGregor> | This is particularly significant with CSP, where you can't use inline script. |
| 01:03 | <Hixie> | "use xbl" :-) |
| 01:03 | <AryehGregor> | So you have no way to emulate the effect at all that I know of. |
| 01:04 | <TabAtkins> | component model |
| 01:04 | <TabAtkins> | /component model, that is |
| 01:28 | <zewt> | heh, seems like neither browser with tab-modal alerts really handles background prompting very well |
| 01:29 | <zewt> | opera only sets the tab to "new" (blue tab text), which isn't noticable at all; ff4 is on the other side of the spectrum, letting the tab steal focus outright, which seems like too much |
| 01:29 | <zewt> | i'd think they'd mimic windows's taskbar notification flash, which seems about the right level of attention-grabbing |
| 01:58 | <zewt> | Showing results for w3 xml. Search instead for w3 xbl <- google seriously needs an I-know-how-to-type-so-stop-correcting-me option |
| 07:41 | <annevk> | Hixie, yeah, activation behavior didn't really seem appropriate |
| 07:42 | <Hixie> | hm? |
| 07:46 | <annevk> | Hixie, to define in DOM Core |
| 07:46 | <Hixie> | oh i didn't mean activation behaviour |
| 07:46 | <Hixie> | that's defined in html |
| 07:46 | <annevk> | ooh, wait, interaction events |
| 07:46 | <Hixie> | i meant the actual mapping of devices to events |
| 07:46 | <annevk> | yeah, that shouldn't either |
| 07:46 | <Hixie> | right |
| 07:46 | <Hixie> | still needs a spec though |
| 07:47 | <annevk> | mouse events should be part of CSS hit testing imo |
| 07:47 | <Hixie> | if doug wants to write it, that would be awesome |
| 07:48 | <annevk> | Shelley Powers volunteers to write the WHATWG Weekly |
| 07:49 | <Hixie> | is she willing to do it politely and objectively? |
| 07:50 | <annevk> | dunno, and she hasn't been on IRC yet |
| 07:50 | <annevk> | but what we do mostly with first-time contributors on the blog is that an admin quickly reviews it |
| 07:50 | <annevk> | so that should be fine |
| 07:50 | <Hixie> | worksforme |
| 07:51 | <Hixie> | if she can actually do it usefully that would be awesome |
| 07:51 | <Hixie> | you and mark have done a really useful job :-) |
| 07:56 | <foolip> | Microsoft committed to implementing SMPTE-TT? |
| 07:56 | <foolip> | http://lists.w3.org/Archives/Public/public-html/2011Mar/0017.html |
| 07:56 | <foolip> | "But in any case I at least am implementing support for SMPTE-TT." |
| 07:57 | <annevk> | the title of xkcd comics is often the best :) |
| 07:57 | <othermaciej_> | I don't think Sean Hayes is on the IE team |
| 07:57 | <othermaciej_> | though he has in the past referred to implementing TTML in Silverlight |
| 07:58 | <annevk> | and with that I mean title="", not <h2> or whatever he is using |
| 07:58 | <foolip> | I do hope we can actually agree on 1 format for text... |
| 07:58 | <foolip> | the world will rightfully hate us otherwise |
| 07:58 | <annevk> | it was already known he worked on other formats |
| 07:58 | <annevk> | but he's not with the IE guys |
| 07:59 | <foolip> | phew, there is still hope :) |
| 07:59 | <annevk> | Kris from Microsoft to Hixie |
| 07:59 | <annevk> | "Nice to see you participate and listen to feedback on the html5 spec." |
| 07:59 | <foolip> | annevk, link? |
| 07:59 | <Hixie> | o_O |
| 08:00 | <annevk> | I guess maybe he said that because it was on public-html-testsuite and he meant participating there |
| 08:00 | <annevk> | otherwise it would be really weird |
| 08:00 | <annevk> | foolip, http://lists.w3.org/Archives/Public/public-html-testsuite/2011Mar/0001.html |
| 08:01 | <othermaciej_> | yes, I think there was an implied "on the testing list" there |
| 08:02 | Hixie | has been on the testing list since probably before kris |
| 08:08 | <annevk> | fwiw, I replied to Shelley: http://blog.whatwg.org/weekly-same-origin#comment-42803 |
| 08:24 | <hsivonen> | Interop doesn't look too good here: http://hsivonen.iki.fi/test/moz/about-blank-load-location.html |
| 08:26 | <karlcow> | hsivonen: what is supposed to do? I open it in firefox, safari and opera and have the same blank square |
| 08:29 | <hsivonen> | karlcow: it uses console.log |
| 08:29 | <hsivonen> | karlcow: logs once in Firefox |
| 08:29 | <hsivonen> | karlcow: twice in Opera and Chrome |
| 08:30 | <karlcow> | ah ok thanks. |
| 08:30 | <hsivonen> | logs once in IE9 but it a crazier than expected way |
| 08:32 | <hsivonen> | I wonder if the test in buggy and fails in an unexpected way in IE9 |
| 08:32 | <hsivonen> | the IE9 result makes no sense otherwise |
| 08:34 | <annevk> | look at that |
| 08:34 | <annevk> | above zero in Sweden! |
| 08:35 | <annevk> | only at night it is painfully cold |
| 08:37 | <karlcow> | annevk: I have been now in Oslo for 10 days, and it is somehow tropical compared to Montreal. :D |
| 08:38 | <annevk> | right... |
| 08:38 | <annevk> | I still need to get there however |
| 08:38 | <annevk> | and vote |
| 08:38 | <annevk> | and pack |
| 08:38 | <hsivonen> | well, *this* is interesting. IE9 mode doesn't create a body for about:blank synchronously |
| 08:38 | <annevk> | and more |
| 08:39 | <hsivonen> | I wonder if that's Web compatible |
| 08:39 | <hsivonen> | now I need to test my hypotheses in multiple IE modes |
| 08:39 | <hsivonen> | grr |
| 08:39 | <annevk> | lol MikeSmith |
| 08:39 | <zcorpan> | it's only 14 modes to test, right? or how many are there again? |
| 08:39 | <annevk> | "great tea abuser" hahaha |
| 08:40 | <annevk> | green* |
| 08:40 | <MikeSmith> | heh |
| 08:40 | <hsivonen> | It's extremely hard for me to believe that IE9 standards mode could be Web-compatible here |
| 08:41 | <Ms2ger> | They don't need to |
| 08:41 | <hsivonen> | because Gecko, WebKit and Presto all go through the trouble of making document.body non-null for about:blank synchronously |
| 08:41 | <hsivonen> | Ms2ger: right. but it sucks when trying to figure out what I should make Gecko do |
| 08:42 | <zcorpan> | annevk: is there a bugzilla component for html5diff? |
| 08:42 | <Ms2ger> | I thought there was |
| 08:42 | <zcorpan> | there is |
| 08:43 | <zcorpan> | 17 open bugs |
| 08:44 | <hsivonen> | hmm. If I use developer tools in IE9 to force Browser Mode to IE9 and Document Mode to Quirks, I still get null document.body after parsing iframe before the event loop has spun |
| 08:44 | <annevk> | zcorpan, I think those are from Marcos |
| 08:44 | <hsivonen> | now I'm really confused |
| 08:45 | <annevk> | zcorpan, he still needs to close them |
| 08:45 | <hsivonen> | what's the closest thing to console.log that I could use in IE6 without disrupting the event loop? |
| 08:45 | <hsivonen> | I don't trust alert() |
| 08:46 | <hsivonen> | maybe I need to write my own in-test-case logging facility |
| 08:46 | <hsivonen> | again |
| 08:47 | <jgraham> | hsivonen: I suspect you do |
| 08:47 | <zcorpan> | annevk: filtering out marcos leaves 4 open bugs |
| 08:47 | <jgraham> | annevk: It's about -4 here |
| 08:47 | <hsivonen> | about:blank is such a pain |
| 08:49 | zcorpan | creates an email label to keep track of html5diff emails |
| 08:51 | <hsivonen> | about:blank in iframe is so sane in IE9 that I wish the Web would agree with us standardizing that behavior |
| 08:51 | <Ms2ger> | It's sane? Then probably not |
| 08:52 | <hsivonen> | which reminds me that I need to test this stuff in window.open, too, before I draw conclusions |
| 08:55 | <foolip> | "the Ian has also removed the relation" |
| 08:55 | <foolip> | sounds like Ian is either a machine or a derogatory term :) |
| 08:56 | <jgraham> | It sounds like he is some sort of Terminator |
| 08:56 | <jgraham> | hired to kill off family members |
| 08:57 | <foolip> | imagine the movie version of Ian editing the spec! |
| 09:01 | <hsivonen> | whoa! whoa! even IE6 is saner than the other browsers on this!!! |
| 09:01 | <hsivonen> | could it be that the quirkiness of about:blank is Gecko's fault instead? |
| 09:04 | <zcorpan> | John Gregg and @sideshowbarker delivers? sounds creepy |
| 09:06 | <MikeSmith> | I didn't deliver anything, I just throw it into the machine and turn some knobs |
| 09:06 | <hsivonen> | aaaargh! it seems that window.open is crazy in IE |
| 09:06 | <hsivonen> | and other browser generalized the craziness to iframed browsing contexts |
| 09:09 | <annevk> | zcorpan, who said it isn't? |
| 09:10 | <hsivonen> | is there any way to set a "load" event handler in a window.open call so that the event handler gets set before window.open() returns? |
| 09:11 | <annevk> | modify the about:blank page? :) |
| 09:12 | <hsivonen> | annevk: I don't have the source for IE |
| 09:16 | karlcow | will abuse himself with green tea |
| 09:19 | <zcorpan> | hsivonen: you just need to kidnap some ie team employee's kids and require the source for ie in exchange |
| 09:21 | <hsivonen> | why doesn't Opera have a truthy addEventListener on the object returned by window.open? |
| 09:22 | <karlcow> | you gotta love tools :) wonderful. http://www.nzeldes.com/HOC/Posographe.htm |
| 09:23 | <hsivonen> | this is weird. top-level windows in Opera have addEventListener but windows returned by window.open don't |
| 09:24 | <zcorpan> | weird indeed |
| 09:28 | <zcorpan> | hsivonen: seems to be that we don't create a script environment for the opened window if it's blocked by the popup blocker |
| 09:28 | <zcorpan> | hsivonen: addEventListener exists if you open() in response to a click |
| 09:29 | <hsivonen> | zcorpan: thanks |
| 09:30 | <zcorpan> | we don't try very hard to hide side-effects of the popup blocker |
| 09:30 | <hsivonen> | zcorpan: if I disable the blocker, Opera is more similar to Gecko than to Chrome and IE9 but still different |
| 09:32 | <hsivonen> | where when I say "Gecko", I meant Gecko configured to target window.open to tabs |
| 09:32 | <hsivonen> | which is different from opening real windows! |
| 09:33 | <zcorpan> | hsivonen: if you like testing, opera has a pref for opening windows instead of tabs |
| 09:35 | <hsivonen> | zcorpan: yay, more configurations |
| 09:35 | <hsivonen> | the worst part of this is the Gecko-specific unit tests that depend on *exactly* what Gecko does now |
| 09:36 | <hsivonen> | and I don't mean unit tests designed to test this thing in particular |
| 09:36 | <hsivonen> | but random tests for other things |
| 09:37 | <hsivonen> | currently in Gecko, about:blank and document.open() on *.mail.live.com are special-cased to use the old parser |
| 09:38 | <zcorpan> | hsivonen: what's the problem with the new parser? |
| 09:38 | <hsivonen> | zcorpan: the problem with about:blank is that the new parser takes 2 task queue tasks to finish minimum and our test cases want about:blank processing to take one task queue task |
| 09:39 | <zcorpan> | hsivonen: i meant with mail.live.com |
| 09:39 | <Ms2ger> | Script processing? :) |
| 09:40 | <hsivonen> | zcorpan: I'll leave it to the Hotmail team to disclose the details if they want to |
| 09:40 | <zcorpan> | is it confidential? |
| 09:41 | <hsivonen> | zcorpan: it not clear to me what the confidentiality expectation is, so I'm erring on the side of it being confidential |
| 09:43 | <zcorpan> | ok |
| 09:48 | <jgraham> | Sorry, what? |
| 09:48 | <hsivonen> | IE6 is so much more annoying than I remembered |
| 09:48 | <jgraham> | You swicth back to the old parser for one specific page? |
| 09:49 | <jgraham> | Jesus wept |
| 09:49 | <hsivonen> | jgraham: well, before this week it was only one: about:blank |
| 09:49 | <hsivonen> | jgraham: now it's also all document.open()ed pages on *.mail.live.com |
| 09:50 | <jgraham> | hsivonen: I assume since you can't talk about it that you also don't have a bug number? |
| 09:50 | <hsivonen> | jgraham: about:blank is only one specific page but it's the hardest one there is |
| 09:50 | <Ms2ger> | The bug is public |
| 09:51 | <hsivonen> | jgraham: I have several bug numbers |
| 09:51 | <hsivonen> | jgraham: https://bugzilla.mozilla.org/show_bug.cgi?id=627729 https://bugzilla.mozilla.org/show_bug.cgi?id=636692 https://bugzilla.mozilla.org/show_bug.cgi?id=636690 |
| 09:51 | <jgraham> | hsivonen: Thanks |
| 09:52 | <hsivonen> | jgraham: It's UA-sniffed code on Hotmail. It's not served to Chrome. Probably not served to Opera, either. |
| 09:52 | <jgraham> | hsivonen: Hmm, OK |
| 09:54 | zcorpan | has experienced repeated reloading in hotmail in opera at some point |
| 09:54 | jgraham | has tried to avoid experiencing hotmail |
| 09:55 | <hsivonen> | I'm in awe at people who've actually managed to develop JS programs for IE6 |
| 09:56 | <zcorpan> | jgraham: i guess i should say that i've seen my wife experience repeated reloading in hotmail in opera at some point. she has now switched to gmail |
| 10:02 | <hsivonen> | aargh. attachEvent wants the "on" bit in event names |
| 10:02 | <hsivonen> | that explains a lot |
| 10:05 | <zcorpan> | heh |
| 10:07 | <hsivonen> | awesome. IE9 has regressed the ability to listen for the load event of window.opened windows even the attachEvent way that worked in IE6 |
| 10:09 | <hsivonen> | hmm. Opera is weird |
| 10:09 | <hsivonen> | if I open about:blank using window.open, I get a load event |
| 10:09 | <hsivonen> | if I open something else (same-origin), I don't get a load event |
| 10:27 | <hsivonen> | I guess I should also test if the initial about:blank shows up in the history API or something |
| 10:27 | <hsivonen> | sigh. |
| 10:31 | <_bga> | Hixie are you here? |
| 10:34 | <jgraham> | _bga: He is probably asleep |
| 10:35 | <_bga> | ok |
| 11:44 | <hsivonen> | is the non-joint history exposed to JS? |
| 11:47 | <hsivonen> | ah. "The actual entries are not accessible from script." |
| 11:59 | <annevk> | "the Ian", lol where is that from? |
| 12:00 | <annevk> | I wish I had gotten some replies on the DOM Core stuff |
| 12:01 | <annevk> | I guess later today I can sort out what Björn pointed out |
| 12:02 | <annevk> | though I'm somewhat skeptical there is new information there |
| 12:02 | <annevk> | should probably also write a blog post on Web Notifications as some kind of introduction |
| 12:03 | <annevk> | lots of technical posts before my blog turns into a collection of travel stories |
| 12:07 | <hsivonen> | looks like about:blank is going to eat up my day :-( |
| 12:08 | <annevk> | your experience does show that the HTML parser really is intertwined with most everything |
| 12:08 | <annevk> | not sure that's a good thing |
| 12:08 | <Ms2ger> | I'm sure. No. |
| 12:09 | <annevk> | back later, going to get high (in the sky) bahaha bad joke |
| 12:35 | <hsivonen> | zcorpan: where can I find the Opera pref for targeting window.open to window instead of tab? |
| 12:36 | <hsivonen> | also, does Chrome have an option for doing the opposite? |
| 12:39 | <karlcow> | hmm the dfn element doesn't really makes it easy to build glossary automagically. It needs a bit of markup-fu to make it more useful. |
| 12:39 | <karlcow> | s/makes/make/ |
| 14:43 | <foolip> | hsivonen, missing "to" in "WebKit used handle things" |
| 14:55 | annevk | can now place prank calls pretending to be gsnedders |
| 14:56 | <zcorpan> | hsivonen: i don't know what the opera:config pref is called, but it's in prefs, advanced, tabs, additional options |
| 14:58 | <hsivonen> | foolip: fixed. thanks |
| 14:59 | <hsivonen> | zcorpan: thanks |
| 15:12 | <zcorpan> | hsivonen: "Sync plus incr other" is not defined |
| 15:12 | <zcorpan> | hsivonen: meant to be "Sync plus async other"? |
| 15:18 | <hsivonen> | zcorpan: yes. fixed. thanks. |
| 15:23 | <annevk> | zcorpan, can I forward html5-diff comments to you now? |
| 15:23 | <zcorpan> | annevk: sure |
| 15:23 | <annevk> | playing with CVS with someone else also playing with it is pain :) |
| 15:23 | <zcorpan> | hsivonen: about:blank is sad panda |
| 15:24 | <zcorpan> | annevk: we'll have to take turns :P |
| 15:25 | jgraham | would point out the irony of a VCS not allowing multiple people to work simultaneously, but realises that the letters CVS make the point moot |
| 15:25 | <zewt> | cvs in 2011? my condolensces |
| 15:25 | <annevk> | I plan on just leaving it alone for some time now :) |
| 15:25 | <annevk> | zewt, everything on dev.w3.org is in CVS |
| 15:25 | <zcorpan> | ok |
| 15:26 | <annevk> | I'm leaving in two weeks and we're not publishing so that seemed reasonable to me |
| 15:26 | <annevk> | especially since you're all set up now |
| 15:26 | <zewt> | would getting version control updated to something not completely obsolete require three years of procedures and a unanimous vote |
| 15:27 | <annevk> | new stuff is done here mostly: http://dvcs.w3.org/hg/ |
| 15:28 | <jgraham> | I think it took a little less than 3 years |
| 15:28 | <jgraham> | Basically staff got to decide so it happened fast |
| 15:31 | <karlcow> | zewt: nah. but there can be many dependencies on a system. |
| 15:38 | <hsivonen> | zcorpan: I updated the result table to include Opera 11 targeting window.open to windows |
| 15:38 | <hsivonen> | nothing new there, fortunately |
| 16:19 | <Clotaire> | Hello everybody |
| 16:20 | <Clotaire> | i am a french man and i am writting a tutorial on HTML5 and CSS3 on http://www.siteduzero.com |
| 16:27 | <jgraham> | http://spacewar.oversigma.com/html5/ |
| 16:35 | <zcorpan> | hsivonen: but not same behavior as tab, which seems like a bug |
| 16:35 | <zcorpan> | oh wait |
| 16:35 | <zcorpan> | i read teh table wrong |
| 16:42 | <Clotaire> | it is a official W3C developper here ? |
| 16:42 | <Clotaire> | i just want to ask some questions |
| 16:42 | <wilhelm> | Several, I presume. |
| 16:42 | <Clotaire> | like ? |
| 16:43 | <zcorpan> | just ask your question |
| 16:44 | <jgraham> | There isn't such a thing as an official W3C developer |
| 16:44 | <jgraham> | Although there are various kindds of staff |
| 16:44 | <jgraham> | and Mike Smith |
| 16:45 | <Clotaire> | i am talking about an "official developper", does mean a person who work directly in de structure as programmer |
| 16:45 | <jgraham> | Clotaire: Seriously, ask whatever question you have |
| 16:45 | <jgraham> | and people will either answer or try to point you to the right person |
| 16:47 | <Clotaire> | my preocupation is about the HTML5 geolocalisation API |
| 16:48 | <Ms2ger> | That's not an HTML5 API, do continue |
| 16:55 | <Rik`> | Wingat: if you want to talk in French, maybe #openweb can help |
| 16:56 | <Rik`> | ##openweb actually |
| 16:57 | <karlcow> | strange question from Clotaire. What is an official W3C developer. |
| 16:57 | <Wingat> | tank you verry much |
| 16:57 | <karlcow> | he left |
| 16:58 | <Rik`> | karlcow: Clotaire is now known as Wingate |
| 16:58 | <karlcow> | aaaah |
| 16:58 | <Wingat> | sorry if my questions are idiotic |
| 16:58 | <jgraham> | Rik`: Wingat, in fact |
| 16:58 | <karlcow> | no no not idiotic, just strange |
| 16:58 | <Rik`> | jgraham: I was about to past another one |
| 16:58 | <Ms2ger> | Both, in fact |
| 16:58 | <Wingat> | Wingate is my real nick |
| 16:58 | <Wingat> | but it is register |
| 16:58 | <karlcow> | trying to understand what you mean by official w3c developer |
| 16:58 | <Wingat> | and i have forgotten how to sign in |
| 16:58 | <zewt> | mime type developer/w3c |
| 16:59 | <Wingat> | with a register nick |
| 16:59 | <Rik`> | zewt: I'm not sure I want to sniff a W3C developer… |
| 16:59 | <karlcow> | Wingat: en français, si tu es plus confortable, c'est possible aussi |
| 16:59 | <zewt> | D: |
| 17:00 | <Wingat> | Ah okey :) |
| 17:00 | <Wingat> | merci |
| 17:00 | <Wingat> | enfin un frère ! |
| 17:00 | <Wingat> | alors comment on se connecte avec un nick enregistré ? |
| 17:03 | <karlcow> | Wingat: http://freenode.net/faq.shtml#userregistration |
| 17:30 | <TabAtkins> | Untitled sections aren't actually a "problem", right? I mean, titling them is ideal, but the mere fact that something is a <nav> is better than nothing. |
| 17:33 | <Workshiva> | In fact, last I checked the spec encourages outline tools to provide sensible names for untitled non-generic sections |
| 17:34 | <jgraham> | TabAtkins: No, that was the fundamental mistake in that article |
| 17:34 | <TabAtkins> | K. I'm chatting with the dude, and I was just making sure before I pressed the point. |
| 17:34 | <Workshiva> | "User agents should provide default headings for sections that do not have explicit section headings." |
| 17:48 | <zcorpan> | http://webaim.org/projects/screenreadersurvey3/#html5 |
| 17:50 | <jgraham> | zcorpan: Aren't the results of a survey on that topic rather uninformative? |
| 17:50 | <zcorpan> | maybe |
| 17:52 | <jgraham> | In general it seems like questions along the lines of "do you think that x is good" aren't good at determining if x is good. Moreso if it is "going to be good" |
| 17:53 | <jgraham> | I suppose it is useful to find our if you are doing well at PR though |
| 17:54 | <zcorpan> | seems more than half find longdesc useful |
| 17:55 | <Philip`> | I suppose it shows that the "HTML5 is a step backwards for accessibility because it's removing accessibility-related markup" message is not that widespread amongst this group of people |
| 17:55 | TabAtkins | needs to write up his proposal to add @src to canvas, so it can act as a drop-in <img> replacement with structured accessibility fallback. |
| 17:56 | <jgraham> | zcorpan: It shows that more than half of people said they found it useful when asked in a survey. That is quite different from them actually finding it useful |
| 17:56 | <zcorpan> | right |
| 17:56 | <jgraham> | Most of those people may never have come across a longdesc, for all we know |
| 17:57 | <jgraham> | And the wording of the question would allow "how helpful is a method of providing a long description for complex images to you" |
| 17:58 | <jgraham> | Since a problem that many people who use screenreaders have is that they can't see (or can't see well) it seems natural for them to answer that such a thing would be useful without having any clue about longdesc in particular |
| 18:09 | <zcorpan> | maybe you would get slightly more accurate answers if the question was "How useful is longdesc to you" and one of the alternatives is "I don't know what longdesc is" |
| 18:10 | <zcorpan> | and another "I know what longdesc is but have never encountered a page that uses it" |
| 18:11 | <Philip`> | What about people who have encountered it and used it but don't know it as the technical term "longdesc"? |
| 18:11 | <zcorpan> | i guess the question could be asked in terms of how longdesc is exposed in the user's primary screen reader |
| 18:13 | <jgraham> | The right way to do it would be to instrument some peoples screenreaders for objective questions |
| 18:13 | <jgraham> | and only ask about subjective things |
| 18:13 | <TabAtkins> | Instrumentation is always the answer. |
| 18:14 | <jgraham> | Even for apparently subjective things like "did you find that task easy" instrumentation can help you work out whether it was really easy or hard |
| 18:14 | <jgraham> | and normalise against different people |
| 18:15 | <jgraham> | since you can measure how long things took, how many steps they went through, etc. |
| 18:15 | <zewt> | trying to derive useful information from that is something of a black art, though |
| 18:15 | <zcorpan> | speaking of easy and hard, MS Office 2010 has seriously regressed in ease of use |
| 18:15 | <jgraham> | zewt: Maybe |
| 18:16 | <jgraham> | But much less of a black art than reading tealeaves aka what people said in an interview |
| 18:17 | <jgraham> | (one presumes people like Freedom Scientific alrady have all this information but are not willing to share it) |
| 18:17 | <jgraham> | (or at least some of it) |
| 18:18 | <jgraham> | (one could presumably do the same thing with nvda in a more open way, but it would of course need funding and so on) |
| 18:59 | <Hixie> | bga_: here now |
| 19:01 | <zcorpan> | gotta love people who come here with a question but never ask it |
| 19:01 | <bga_> | sec :) |
| 19:02 | <bga_> | serios question about webworkers |
| 19:02 | zcorpan | was referring to Wingat |
| 19:05 | <bga_> | Hixie you know that each message passing cost is serialization + atomic queue + deserialization |
| 19:05 | <Hixie> | the workers spec lets you send structured data |
| 19:05 | <bga_> | but serialization/deserialization is very slow |
| 19:06 | <Hixie> | and browsers can implement it as copy-on-write |
| 19:06 | <Hixie> | so it doesn't have to be slow |
| 19:06 | <bga_> | hm |
| 19:07 | <Hixie> | it actually doesn't even have to block, though the most optimal implementation performance-wise is a little subtle and requires careful thought to get right |
| 19:09 | <zcorpan> | Hixie: seemingly the most optimal impl has not been implemented anywhere, it might be worthwhile to give a hint in the spec about the matter |
| 19:09 | <Hixie> | well the browsers still only do strings, right? |
| 19:09 | <zcorpan> | no |
| 19:10 | <Hixie> | oh, cool |
| 19:10 | <Hixie> | who does structured data? |
| 19:10 | <zcorpan> | opera and webkit at least |
| 19:10 | <Hixie> | shows what i know |
| 19:13 | <bga_> | if js will have weak references and abstract operation globalDelete(varName) => message passing will be better |
| 19:13 | <zcorpan> | firefox too |
| 19:13 | <Philip`> | SpiderMonkey implements the structured clone algorithm, though I don't know if/where it's used |
| 19:14 | Philip` | only knows since he uses that for message passing between threads in his non-web-based application |
| 19:15 | <bga_> | anyway erlang has classis actors model (WebWorkers - actors model too) and global atomic dictonary |
| 19:16 | <bga_> | yeah we want to avoid extra crictical sections and rece contition but global dictonary is usefull |
| 19:16 | <bga_> | *race |
| 19:16 | <zcorpan> | firefox does strings for window.postMessage, webkit and opera does stuctured clone there too |
| 19:17 | <zcorpan> | Hixie: btw, has it been pondered about the security implications of sending Files in window.postMessage? |
| 19:18 | <Hixie> | yes |
| 19:18 | <zcorpan> | ok |
| 19:18 | <Hixie> | (as far as i can tell there are no implications since you could always just proxy all the calls back and forth anyway) |
| 19:19 | <zewt> | seems sensible that if a user grants a site access to a file, the site should be able to transfer that permission to other origins anyway |
| 19:20 | <zcorpan> | yeah that was my conclusion as well, although i haven't thought about it a great deal yet. (we haven't implemented cloning of Files yet) |
| 19:21 | <zewt> | i was wondering at one point about the fact that it seems like IDB is allowed to store File references, when permission to access a file shouldn't actually persist |
| 19:21 | <zewt> | (don't recall what the answer to that was off-hand) |
| 19:22 | <Hixie> | storage lets you store files |
| 19:22 | <bga_> | heh copy-on-write means incoming object is recursive Proxy :( |
| 19:22 | <bga_> | slow access |
| 19:22 | <zewt> | but File is normally a reference to a file, not the actual file contents, right? |
| 19:23 | <zcorpan> | does anyone support structured clone for the history api's data argument? |
| 19:23 | <zcorpan> | zewt: yes |
| 19:23 | <zcorpan> | zewt: you can read the contents with FileReader |
| 19:23 | <zewt> | yeah, I know how it works with eg. file inputs |
| 19:24 | <zewt> | where the File object essentially acts as your token giving you permission to access the file it references |
| 19:25 | <zewt> | the curious part is if you're allowed to store a File in IDB, then it's allowing you to persist that token long-term ... which is useful, but seems at odds with the security model |
| 19:25 | <bga_> | fast passing and slow access vs. slow passing and fast access |
| 19:27 | <AryehGregor> | Okay, now my tests work very nicely in all browsers: http://aryeh.name/spec/dom-range/test/Range-deleteContents.html |
| 19:28 | <Hixie> | AryehGregor: any idea what webmartians is referring to when he says you insulted him? |
| 19:28 | <AryehGregor> | Hixie, I didn't see that yet. |
| 19:28 | <Hixie> | it doesn't seem like you did |
| 19:28 | <Hixie> | so i am confused |
| 19:28 | <zewt> | bga: can also selectively COW, eg. make copies of smaller objects but COW for big arrays, ImageData, etc |
| 19:28 | <TabAtkins> | I'm also confused. |
| 19:28 | <AryehGregor> | Which guy was he again? |
| 19:28 | <zcorpan> | TabAtkins: all pass in opera, yay |
| 19:28 | <TabAtkins> | zcorpan: Huh? |
| 19:28 | <AryehGregor> | Maybe that was directed at me? |
| 19:29 | <zcorpan> | uh |
| 19:29 | <zcorpan> | yeah |
| 19:29 | <zcorpan> | sorry |
| 19:29 | <AryehGregor> | Also, they run much faster now, since I run them in parallel. |
| 19:29 | <zewt> | heh, I had a response written in that "deprecate alert" thread with "webmartians", but discarded it after his last post; wrote him off as an idiot |
| 19:29 | <TabAtkins> | Unrelated: I love Ahem. Testing line-breaking with it is much better, as you don't have to rely on oddities of precise glyph sizes. |
| 19:29 | <zewt> | AryehGregor: i fixed that for you last night; did you get the link? |
| 19:29 | <AryehGregor> | Oh, did he get annoyed when I said that we need actual use-cases and not just citations of Windows API features? |
| 19:30 | <AryehGregor> | zewt, yeah, I was just looking at that. |
| 19:30 | <AryehGregor> | Your fix didn't seem to work for me as-is. |
| 19:30 | <AryehGregor> | I think because mine was still timing out in Chrome. |
| 19:30 | <zewt> | worked for me in all browsers, and doesn't need to create all of the tests at once |
| 19:30 | <AryehGregor> | Anyway, partly I just copied your changes, even though they seemed insignificant compared to what I wound up with at the end of last night (I think we made similar changes in parallel). |
| 19:30 | <AryehGregor> | But whatever, it works now and it's fast. |
| 19:30 | <TabAtkins> | Hixie: Could you fix the Live DOM Viewer so that pressing Tab while in the markup pane generates a tab, rather than moving focus? |
| 19:31 | <zewt> | AryehGregor: FWIW, the response I had typed up and discarded re: timed-out alerts was essentially: saying there are no use cases is a very narrow view, and it's very easy to find use cases |
| 19:31 | <AryehGregor> | Although there's a new WebKit failure I need to track down. |
| 19:31 | <Hixie> | TabAtkins: isn't that a UA choice? |
| 19:31 | <AryehGregor> | zewt, do you have a name I should credit, or is "zewt" good? |
| 19:31 | <TabAtkins> | Hixie: Theoretically, but in reality tab always changes focus. |
| 19:31 | <zewt> | ... *but*, by the time you hit any of those use cases, you're doing things way too complex to use that old API and you should be using a real prompt library |
| 19:31 | <AryehGregor> | zewt, well, that may be, but they still have to be stated by someone. |
| 19:31 | <Philip`> | TabAtkins: Use spaces instead? |
| 19:31 | <Hixie> | TabAtkins: copy and paste a tab from somewhere else :-) |
| 19:31 | <TabAtkins> | Philip`: UNACCEPTABLE |
| 19:31 | <Hixie> | TabAtkins: i expect he's testing tabbing and whitespace |
| 19:32 | <Hixie> | line wrapping of tabs and white-space i should say |
| 19:32 | <AryehGregor> | TabAtkins, on GNOME, Ctrl+Shift+u9 works. |
| 19:32 | <TabAtkins> | Actually, I just use tabs to indent code, and I have to train myself not to press tab when using LDV. |
| 19:32 | AryehGregor | uses that all the time |
| 19:32 | <Philip`> | I thought it was just his usual tab-over-space perversion |
| 19:32 | <Hixie> | ah |
| 19:32 | <Hixie> | well |
| 19:32 | <Hixie> | consider this part of your course in not using tabs to indent code |
| 19:32 | <TabAtkins> | Hixie: You're wrong and I hate you. |
| 19:32 | <zewt> | AryehGregor: (glenn maynard) |
| 19:32 | <Hixie> | we shall cure you in due course! |
| 19:32 | <AryehGregor> | zewt, oh, that's you. |
| 19:32 | <zewt> | AryehGregor: it doesn't work for you in Chrome? which version--works for me in 9, anyway |
| 19:32 | <AryehGregor> | zewt, your version did, but not when I copied the changes to my version. |
| 19:33 | <AryehGregor> | My version loaded the iframes more slowly. |
| 19:33 | <AryehGregor> | So it timed out. |
| 19:33 | <AryehGregor> | Worked when I upped the timeout. |
| 19:33 | <zewt> | oh, your webserver is sending different cache headers, I think |
| 19:33 | <AryehGregor> | But now that I do it in parallel, I don't need to up the timeout, yay. |
| 19:33 | <AryehGregor> | Yeah. |
| 19:33 | <zewt> | the file is being cached off mine, but revalidated over and over on yours |
| 19:33 | <AryehGregor> | I use lighttpd, and I can't change the cache headers except by editing the central config file and restarting the webserver, AFAICT. |
| 19:33 | <zewt> | heh |
| 19:33 | <AryehGregor> | (but on the other hand, I save a couple GB RAM compared to Apache+mod_php, so . . .) |
| 19:34 | <AryehGregor> | Oh, WebKit doesn't deleteContents() doctypes, it looks like. |
| 19:34 | <AryehGregor> | So I did find a not-completely-trivial bug, yay. |
| 19:34 | <AryehGregor> | (well, granted, it's pretty trivial) |
| 19:34 | <zewt> | a pretty-trivial-but-not-completely-so bug |
| 19:35 | <ttepasse> | Huh? rel=next and such are dropped? |
| 19:35 | <zewt> | that's probably a bugzilla priority |
| 19:47 | <zcorpan> | ttepasse: next wasn't dropped |
| 19:48 | <Hixie> | the "Cryptographically strong random numbers" thread doesn't seem to have included any feedback on a spec i work on, so I am not going to be replying to it |
| 19:48 | <Hixie> | please let me know if i missed anything there |
| 19:48 | <zcorpan> | why is external in the rel list to begin with? it doesn't do anything anywhere |
| 19:50 | <zewt> | http://stackoverflow.com/questions/1145880 : | |
| 19:51 | <zewt> | people sure find strange contortions to try to avoid harmless validator warnings |
| 19:55 | <AryehGregor> | Does Live DOM Viewer work in IE 9 yet, or does the XSS protection stuff still interfere? |
| 19:56 | <AryehGregor> | zewt, wouldn't type="email" or type="url" work to solve the problem even better? |
| 19:57 | <zewt> | if it's as supported as the attribute he's using, probably |
| 19:57 | <zewt> | (no idea whether it is) |
| 19:57 | <Hixie> | zewt: commented |
| 19:59 | <zewt> | AryehGregor: not so much the particular attribute that bugs me, but the fact that many people treat the end goal of using a validator as "quieting the warnings" instead of "fixing problems" |
| 19:59 | <AryehGregor> | Live DOM Viewer works in IE9, yay. |
| 19:59 | <AryehGregor> | zewt, that's why validator warnings need to be used with caution. |
| 19:59 | <zewt> | like people triaging but trackers with the unspoken goal of "close as many tickets as possible" instead of "fix as many problems as possible" |
| 20:00 | <AryehGregor> | I hate that, yeah. |
| 20:00 | <AryehGregor> | Oh, IE still won't load saved URLs in Live DOM Viewer. |
| 20:00 | <zcorpan> | holy cow http://wiki.whatwg.org/wiki/RelExtensions has a lot of rels |
| 20:00 | <AryehGregor> | Oh well. |
| 20:00 | <zcorpan> | i guess that's good; the wiki page is working as intended |
| 20:00 | zcorpan | didn't expect that |
| 20:01 | <zewt> | didn't expect a wiki page to work? :P |
| 20:01 | <zcorpan> | yeah |
| 20:01 | <AryehGregor> | You should have more faith in wikis. |
| 20:02 | <zewt> | would be more useful sorted by status/keyword instead of keyword, I think |
| 20:02 | <AryehGregor> | (although I might be biased ;) ) |
| 20:02 | <zewt> | wait, can this thing sort? |
| 20:02 | <zewt> | hey, it can |
| 20:02 | <zewt> | (who knew) |
| 20:03 | <volkmar> | vertical progress bars have been removed from the specs or i didn't found where it was mentioned? |
| 20:05 | <zcorpan> | http://mathiasbynens.be/notes/touch-icons - time to spec "apple-touch-icon"? |
| 20:07 | <zewt> | is there anything in it that's not heavily vendor-specific? |
| 20:07 | <bfrohs> | Zewt, Android uses it too |
| 20:08 | <zewt> | yeah but it's just mimicking it for compatibility (and I assume it doesn't do eg. the precompose effects) |
| 20:09 | <zcorpan> | zewt: you must be new here |
| 20:10 | <zewt> | well there's a useful comment if ever there was one, heh |
| 20:10 | <Hixie> | zcorpan: i was thinking about the rel registry thing when taking out all the rel values recently |
| 20:11 | <Hixie> | zcorpan: i think maybe the way to go is to have the wiki page be a place to avoid clashes, but then for the "approval" process to be integrating the rel values into the spec |
| 20:11 | <zewt> | i suppose <link rel=icon> having an equivalent to precomposed could be useful |
| 20:11 | <Hixie> | zcorpan: since we have a living spec model now, that's actually viable |
| 20:12 | <zewt> | but less so, since with iOS you know in advance what the composed effects are, to know if you need to disable them--in the general case you don't |
| 20:25 | <zcorpan> | Hixie: i guess that makes sense |
| 20:27 | <Hixie> | i doubt the w3c would ever go for that though, and it'd be silly to have two mechanisms |
| 20:51 | <syskk> | I want to know if the navigator.geolocation.getCurrentPosition(callback) callback was triggered because the user clicked on "Share position" in the browser or if it was automatically triggered because the user previously shared it and checked Always share with this website |
| 20:52 | <syskk> | is that possible? or any workaround? |
| 20:52 | <TabAtkins> | Why do you need that information? |
| 20:52 | <syskk> | TabAtkins: I want to automatically redirect the user when he clicks share position but I don't want the redirection to happen if it's triggered automatically |
| 20:53 | <TabAtkins> | I still don't understand. What is the redirection supposed to accomplish? Why do you want different behavior, if in both cases you're getting the geo info? |
| 20:54 | <syskk> | I have a welcome page where the user can either chose to enter a zip code or give geolocation through browser. Once I get that info, the user is redirected to another page but if he comes back to the change location page he will be auto redirected if he previously checked Always share location and won't be able to enter his zip code for example |
| 20:56 | <TabAtkins> | Sounds like your "welcome" and "change location" pages have different functionality. Perhaps they should actually be different pages? |
| 20:56 | <zewt> | remember that browsers don't have to ask at all; they might be configured to always allow it |
| 20:56 | <syskk> | right, change location could never automatically redirect |
| 20:57 | <syskk> | still it would be nice if the callback was triggered by the browser or by a user action |
| 20:58 | <TabAtkins> | Is there a way to detect if you're currently sharing your location? It does seem like a useful scenario. |
| 20:58 | <syskk> | maybe itd be possible to do using the timestamp |
| 20:59 | <zewt> | I havn't used the geoloc API; I'd expect it'd be useful to be able to passively query it, eg. ask for the location if permission is available, without prompting the user if it's not, eg. for secondary, background features where you don't necessarily want to actively nag the user about them |
| 20:59 | <syskk> | well, he knows it when he clicks share position |
| 21:00 | <TabAtkins> | syskk: I meant you, the page author. Looks like there's not. |
| 21:00 | <syskk> | zewt has a point too |
| 21:00 | <TabAtkins> | So yeah, sounds like useful functionality. |
| 21:00 | <TabAtkins> | Both for your and zewt's scenarios. |
| 21:00 | <syskk> | TabAtkins: I misread you. thought you said "doesn't seem" |
| 21:00 | <TabAtkins> | Send the suggestion to public-geolocation⊙wo |
| 21:01 | <TabAtkins> | Or I could, if you'd prefer. |
| 21:01 | <zewt> | most asking-of-permission in current APIs are largely based on "ask the first time the user uses a site feature", but that doesn't always obviously apply for "passive" features... |
| 21:02 | <AryehGregor> | Is there some convenient way for an iframe to pass some info up to its parent, other than by modifying its own DOM? |
| 21:02 | <zewt> | web messaging? |
| 21:03 | <zewt> | (havn't used it so I don't know how implemented it is) |
| 21:03 | <AryehGregor> | This is for my deleteContents() tests, I want to report back what the Range is selecting after the deletion. |
| 21:03 | <AryehGregor> | I could just encode the information in the DOM somehow, but that's . . . kind of icky. |
| 21:03 | <AryehGregor> | I'd prefer that it be a separate test, anyway. |
| 21:03 | <zewt> | http://dev.w3.org/html5/postmsg/#web-messaging |
| 21:04 | <AryehGregor> | I'd prefer not to rely on a new feature like that unless it's simple and everyone's implemented it interoperably and so on. Otherwise it might cause extra failures or something tiresome like that. |
| 21:04 | <syskk> | I think one way around would be to check the position's timestamp |
| 21:05 | <zewt> | don't know if there's anything else--I think that's exactly what that API is meant to solve (not just for iframes, of course) |
| 21:05 | <jgraham> | AryehGregor: It's same origin |
| 21:05 | <syskk> | if timestamp < now, position was shared in a previous request |
| 21:05 | <jgraham> | So you can just make a function call |
| 21:05 | <AryehGregor> | Like how? |
| 21:05 | <jgraham> | well top is the top-level iframe |
| 21:05 | <jgraham> | so top.foo() |
| 21:05 | <jgraham> | but don't use top |
| 21:06 | <jgraham> | Because your whole test might be run in an iframe |
| 21:06 | <AryehGregor> | Should I be running this code in the iframe or the main page? |
| 21:06 | <AryehGregor> | And what should I use if not top? |
| 21:06 | <jgraham> | I think opener? |
| 21:06 | <jgraham> | but that might just be window.open created windows |
| 21:06 | <AryehGregor> | Hmm, I just realized that I can't really compare node equality across iframes anyway. |
| 21:06 | <arnehass> | AryehGregor: I believe you can use parent.functionName() in the iframe to call on a functionName situated in the parent page |
| 21:07 | <AryehGregor> | I guess I'll just have to do the DOM modification thing, although it's a bit weird. |
| 21:07 | <arnehass> | haven't played to much with it thought, since I don't really like iframes... |
| 21:08 | <TabAtkins> | syskk: I'll send a request to the public-geolocation list, as there's no way to reliably know the information you need. There are scenarios that can trigger both false positive and false negatives. |
| 21:08 | <TabAtkins> | syskk: What your email? I'll cc you. |
| 21:08 | <jgraham> | AryehGregor: Oh yes, parent it is |
| 21:08 | <jgraham> | Why do you want to compare node equality? |
| 21:08 | <jgraham> | What do you even mean equality? |
| 21:09 | <AryehGregor> | jgraham, deleteContents() should change the range's start and end positions to a particular place. |
| 21:09 | <AryehGregor> | I need to verify those are the same for the expected and actual. |
| 21:09 | <AryehGregor> | Which means the start/end nodes must be in the same place in their respective DOMs. |
| 21:10 | <AryehGregor> | Hmm, I can make it separate tests if I can run a function from the iframe in the parent. |
| 21:10 | <AryehGregor> | Can I do something like iframe.contentWindow.someFunction()? |
| 21:10 | <jgraham> | AryehGregor: Yes |
| 21:10 | <AryehGregor> | Okay, good. |
| 21:10 | <jgraham> | same origin all these things are unrestricted |
| 21:11 | <syskk> | TabAtkins: thanks! olalonde⊙gc |
| 21:11 | <AryehGregor> | Hmm. I just realized that I'm not actually testing anything in the cases where the range isn't in the actual document. Oops. |
| 21:11 | AryehGregor | needs to fix that |
| 21:12 | <zewt> | the danger of writing tests that aren't regression tests: they're hard to test. heh |
| 21:15 | <AryehGregor> | See, I knew my tests weren't good enough. |
| 21:18 | <zewt> | need to write meta-tests to test the tests |
| 21:21 | <AryehGregor> | jgraham, iframe.contentWindow doesn't seem to have the methods I put on it in the iframe. |
| 21:22 | AryehGregor | Googles it |
| 21:23 | <AryehGregor> | Oh, wait, maybe that's just a WebKit bug. |
| 21:23 | <AryehGregor> | Boo. |
| 21:34 | <TabAtkins> | syskk: You still here? I've read the Geolocation spec more carefully, and found that your case is already addressed. |
| 21:34 | <TabAtkins> | syskk: getCurrentPosition takes three args - a success callback (for when the user grants their location), an error callback (for when they don't), and an options object. |
| 21:36 | <TabAtkins> | syskk: In the options, you can define a timeout. If you set the timeout to 0, the function will return a cached Position if possible (if they'd previously granted permission, and the last Position isn't too old); otherwise, it just immediately fires the error callback without prompting the user. |
| 21:36 | <syskk> | TabAtkins: doesn't really help. the success callback is called regardless if the user chose to always share position |
| 21:36 | <TabAtkins> | Nope, it isn't. Check step 3 of the algorithm at http://dev.w3.org/geo/api/spec-source.html#api_description |
| 21:37 | <syskk> | ok I will |
| 21:37 | <TabAtkins> | "If the value of the timeout variable is 0, invoke the errorCallback (if present)..." |
| 21:37 | <Moo-_-_> | hmm |
| 21:38 | <TabAtkins> | In order to properly grab the cached Position when it exists, you also have to set a maximumAge on the options object with an appropriately high value. |
| 21:38 | <zewt> | hmm, but if there's no cached position (eg. GPS isn't started up), you can't distinguish it "don't already have permission" (don't know if that matters for his case) |
| 21:38 | <Moo-_-_> | may I propose new <notsafeinworktag> for HTML? |
| 21:39 | <TabAtkins> | zewt: Yeah, that's the one caveat - it doesn't address the case where the user has granted you permission previously (or instructed the browser to auto-grant permission to everyone), but you haven't yet extracted a position, or it's just *really* old. |
| 21:40 | <syskk> | TabAtkins: that's what I thought earlier. I can check the timestamp of the cache object and compare with the current time. I think this could solve the problem |
| 21:41 | <zewt> | (without squinting too hard at what you're suggesting, it's making brittle-hack alarm bells go off) |
| 21:41 | <TabAtkins> | zewt: It sounds like it was an *intended* hack, though. |
| 21:41 | <zewt> | TabAtkins: syskk's hack, not yours |
| 21:42 | <jamesr_> | can i suggest a <badidea> tag in HTML for new tag proposals? |
| 21:42 | <zewt> | zero-timeouts for "nonblocking retrieve from cache but don't wait" is ordinary enough |
| 21:42 | <zewt> | jamesr: we already have a syntax for that, <!-- you write them like this --> |
| 21:43 | <TabAtkins> | syskk: You don't need to check the timestamp at all. If the success callback fires, you *know* you got a cached position, not a live one. If the error callback fires, you get a Position with its 'code' attribute set to TIMEOUT. |
| 21:44 | <zewt> | AryehGregor: i'm fiddling around with your iframe stuff (since I havn't needed to mess with iframes very much), and I feel like I'm doing something dumb, because it seems like the <script>s aren't being executed at all |
| 21:44 | <TabAtkins> | Geolocation.getCurrentPosition(function(){ /* Permission was already granted. */}, function(){ /* It wasn't granted. /*}, {maximumAge:9999999999999, timeout:0}); |
| 21:44 | <zewt> | alert(), console.log, even straight-up syntax errors show nothing (in Chrome and FF4) |
| 21:44 | <AryehGregor> | zewt, that sounds unlikely. |
| 21:44 | <AryehGregor> | alert() and console.log might be suppressed, maybe? |
| 21:44 | <zewt> | hit some cache glitches but dealt with those |
| 21:44 | <AryehGregor> | From iframes, that is. |
| 21:45 | <AryehGregor> | Maybe it also doesn't log errors from iframes? |
| 21:45 | <AryehGregor> | I dunno. |
| 21:45 | <zewt> | alert maybe, console.log seems unlikely |
| 21:45 | <zewt> | and syntax errors more unlikely |
| 21:45 | <AryehGregor> | Try having your script put some visible content in the iframe. |
| 21:45 | <AryehGregor> | See if that works. |
| 21:45 | <zewt> | i know I hit some caching glitches, but I hacked around those to make sure it was reloading |
| 21:45 | <syskk> | TabAtkins: clicking the "Share location" in FF/chrome does trigger the success callback so no way to know. I'll do some test and see if I can get something out of the error callback like you suggest |
| 21:46 | <zewt> | gah |
| 21:46 | <zewt> | it's interpreting the files at text instead of html. that would do it, heh |
| 21:46 | <TabAtkins> | syskk: Sounds like a bug, then. |
| 21:46 | zewt | fixes MIME type |
| 21:46 | <AryehGregor> | Yeah, I noticed that on your site. |
| 21:48 | <jgraham> | alert and console should work from iframes |
| 21:49 | <zewt> | yeah, it just wasn't loading the file as HTML at all |
| 21:50 | <zewt> | AryehGregor: instead of running the scripts in the iframes, might be simpler to move those entire scripts to the main script and pass them a window object to work on |
| 21:50 | <AryehGregor> | Hmm, maybe. |
| 21:52 | <zewt> | wonder if you can you create an iframe with no data, to just get a new empty window/document without needing a dummy external resource |
| 21:52 | <TabAtkins> | syskk: I'm still sending an email to the list, just modifying it based on the new understanding. |
| 21:53 | <TabAtkins> | <iframe src="data:text/html,<!doctype html>"></iframe> |
| 21:53 | <TabAtkins> | (Need the doctype to forced the page into standards mode.) |
| 21:53 | <TabAtkins> | Alternately, <iframe srcdoc=""></iframe> |
| 21:53 | <zewt> | then you get rid of the entire caching issue as a bonus |
| 21:54 | <syskk> | TabAtkins: yep. thanks |
| 21:57 | <jgraham> | <iframe src="about:blank"> might work |
| 21:57 | <jgraham> | But abut:blank is a bit special |
| 21:57 | <TabAtkins> | That'll give you a yucky quirks-mode page. |
| 21:57 | <TabAtkins> | Also: it's crazy. |
| 22:00 | <TabAtkins> | syskk: Sent, and cc'd you. |
| 22:00 | <TabAtkins> | And now, I'm off for the day to go man the booth at GDC. |
| 22:18 | <AryehGregor> | Yay, my tests found another spec bug. |
| 23:12 | <jamesr> | heycam, yt? |