| 07:20 | <annevk> | Say we introduce new Range(); what would the version with arguments look like? Range(startnode, startoffset, endnode, endoffset)? |
| 07:20 | <annevk> | Any others? |
| 07:37 | <rniwa> | annevk: hi annevk |
| 07:50 | <annevk> | hey rniwa |
| 07:51 | <annevk> | your nick is confusing in the font I'm using, tried auto-completing on the letter m :) |
| 07:51 | <rniwa> | annevk: yeah |
| 07:51 | <rniwa> | apparently w also looks like m in some fonts |
| 07:51 | <rniwa> | annevk: confusingly, miwa is also a valid japanese last name |
| 07:51 | <annevk> | :) |
| 07:52 | <rniwa> | annevk: my machine was labeled "miwa" when i worked from tokyo office this spring |
| 07:52 | <annevk> | hey I was wondering, is it the plan that UndoManager moves back into HTML or will it be a separate specification? |
| 07:52 | <rniwa> | annevk: that's why use RNiwa on my website |
| 07:52 | <annevk> | haha |
| 07:52 | <rniwa> | annevk: not sure. got to check with Hixie |
| 07:52 | <rniwa> | annevk: but i think it'll be separate for a whole at least |
| 07:53 | <annevk> | because if not you need to include stuff like partial interface Document { ... } |
| 07:53 | <rniwa> | annevk: I probably need to cross-post it on public-webapps at some point though |
| 07:53 | <annevk> | to define the undoManager attribute in terms of IDL |
| 07:53 | <rniwa> | annevk: yeah... that'll be quite annoying |
| 07:54 | <annevk> | should be real easy... |
| 07:54 | <rniwa> | annevk: I think adding undoManager property is simple enough that I don't need that for now |
| 07:54 | <rniwa> | annevk: like i've been avoiding to completely write all the details to avoid work in the case someone suggests a radical change in the API |
| 07:54 | <rniwa> | s/completely write/write out/ |
| 07:55 | <annevk> | partial interface Document { readonly attribute UndoManager undoManager; }; |
| 07:55 | <annevk> | fair enough |
| 07:55 | <rniwa> | annevk: I guess I can do that |
| 07:55 | <rniwa> | annevk: probably also to Element |
| 07:55 | <annevk> | yeah |
| 10:55 | <annevk> | Oh sweet |
| 10:55 | <annevk> | not all Range tests use testharness |
| 11:00 | <karlcow> | a new summit to explore (in the future) for annevk http://pruned.blogspot.com/2011/09/mountain-for-netherlands.html |
| 11:05 | <annevk> | I'm afraid if we get something like that it'll be like Fuji (not that I ever climbed that one) |
| 12:26 | <annevk> | the fuck http://www.w3.org/Bugs/Public/show_bug.cgi?id=14122 |
| 12:51 | <annevk> | I wonder what the guy who keeps complaining about Workers and the DOM thinks the feedback is for? IRC? |
| 12:51 | <annevk> | s/feedback/feedback box/ |
| 13:18 | <zcorpan> | marked them as dup |
| 13:22 | <annevk> | whoa, AryehGregor has made some crazy cool tests |
| 15:51 | <AryehGregor> | annevk, what's crazy cool about my tests, other than being so ridiculously elaborate that no one but me can understand the implementation? |
| 15:51 | <AryehGregor> | Well, and they're thorough, I guess. I'm curious which tests you thought were crazy cool, though. |
| 15:56 | <annevk> | the thorough tests :) |
| 15:57 | <annevk> | but yeah, figuring out what the bugs are from those tests is kind of awkward |
| 15:57 | <annevk> | AryehGregor, so the reason you cannot correct range boundary points after a rename yourself is because you do not have access to a the list of associated range objects? |
| 15:59 | <AryehGregor> | annevk, right. |
| 15:59 | <AryehGregor> | Only the browser has a full list of Range objects. |
| 15:59 | <AryehGregor> | And only it can, because anything else would expose GC behavior. |
| 16:00 | <annevk> | authors could keep track of everything they create themselves |
| 16:00 | <AryehGregor> | In principle, yes, but it wouldn't behave right for ranges they don't create. It's also tedious and error-prone. |
| 16:00 | <annevk> | is this mostly a problem for Selection? |
| 16:00 | <annevk> | or Editing for that matter |
| 16:01 | <AryehGregor> | If it were just Selection, there'd be no big problem, because there's only one and you can always fix it. |
| 16:01 | <AryehGregor> | In practice, Selection is the big use-case, yeah. |
| 16:01 | <AryehGregor> | Which is why the status quo is okay. |
| 16:02 | <AryehGregor> | dglazkov seemed to think that a rename method on Element would be useful for his component model stuff, whatever that is. |
| 16:02 | <AryehGregor> | I don't personally know of non-editing use-cases. I'm not strongly committed to such a feature at all. |
| 16:03 | <annevk> | okay |
| 16:03 | <annevk> | postponed it is |
| 16:04 | <annevk> | AryehGregor, shall I move your Range- tests into http://dvcs.w3.org/hg/webapps |
| 16:04 | <annevk> | ? |
| 16:11 | <AryehGregor> | annevk, feel free. |
| 16:12 | <annevk> | Are you planning on helping out with editing Range by the way? |
| 16:21 | <MikeSmith> | http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html |
| 16:21 | <MikeSmith> | "extends HTMLMediaElement to allow JavaScript to generate media streams for playback" |
| 16:30 | <AryehGregor> | annevk, maybe, if I find the time. |
| 17:47 | <asmodai> | http://www.buildwindows.com/ -- showing some HTML 5 support in new Windows build tools |
| 17:47 | <asmodai> | right now that is |
| 17:53 | <espadrine> | asmodai: thanks! |
| 17:54 | <asmodai> | I am not sure I like the calls to the native Windows API through JS |
| 18:01 | <asmodai> | apparently they showed off some IE 10 earlier, ought to be able to browse back to that in the stream timeline |
| 18:06 | <espadrine> | asmodai: I wish, but I guess it mostly was the usual "look at the new http://ie.microsoft.com/testdrive/ tests we did" |
| 18:06 | <jarek> | Hi |
| 18:06 | <asmodai> | Ah ok |
| 18:07 | <jarek> | what's the recommend way for iterating over a HTMLCollection element? |
| 18:07 | <asmodai> | Well, for what it is worth, it seems one of the more recent builds of IE 10 scored like 300+ on html5test.com |
| 18:07 | <jarek> | HTMLCollections don't seem to have forEach function |
| 18:10 | <miketaylr> | Array.prototype.slice.call(document.all) :P |
| 18:11 | <miketaylr> | (which will return an Array) |
| 18:11 | <jarek> | yeah, I have just stumbled upont this: http://stackoverflow.com/questions/222841/most-efficient-way-to-convert-an-htmlcollection-to-an-array |
| 18:11 | <jarek> | how about: |
| 18:11 | <jarek> | HTMLCollection.prototype.forEach = function(callback) { |
| 18:11 | <jarek> | for(var i=0, j=this.length; i<j; i++) { |
| 18:11 | <jarek> | callback(this[i]); |
| 18:11 | <jarek> | } |
| 18:11 | <jarek> | } |
| 18:12 | <Philip`> | jarek: That will break if callback modifies the DOM in a way that affects the collection's contents |
| 18:13 | <Philip`> | which seems non-ideal for a general-purpose function |
| 18:14 | <jarek> | could Array.prototype.slice be significantly slower or faster than using regular "for var i=0; i<collection.length; i++" loop? |
| 18:15 | <jarek> | no, wait... it just converts HTMLCollection to Array, I still have to iterate over it :/ |
| 18:15 | <robreact> | just use a for loop |
| 18:15 | <Philip`> | I'd expect that in almost every case, they'll be so fast so you won't care about any difference |
| 18:16 | <Philip`> | Write whatever's most correct and readable, and only worry about optimisation if profiling indicates it's a bottleneck |
| 18:18 | <jarek> | I see, I guess I will just use regular for loop |
| 18:18 | <jarek> | converting HTMLCollection to an array would have some disadvantages |
| 18:18 | <jarek> | like it will no longer update when DOM is modified |
| 18:19 | <jamesr> | you could argue that's an advantage |
| 18:19 | <jamesr> | depending on what you are doing |
| 18:38 | <timeless> | jarek: you can use Array.prototype.concat(collection).forEach(function(){}) in gecko... |
| 18:39 | <jarek> | what's the difference between element.childElementCount and element.children.lenght? |
| 18:40 | <timeless> | in gecko, the latter has an extra roundtrip |
| 18:41 | <timeless> | each <.> for non js objects can be thought of as "expensive" |
| 18:42 | <timeless> | (the same is probably true for other impls..) |
| 18:42 | <jarek> | so using element.childElementCount is a better practice then? Or is performance gain really insignificant? |
| 18:42 | <timeless> | dunno, you'd have to measure it |
| 18:51 | <dglazkov> | good morning, Whatwg! |
| 18:54 | <jamesr> | good morning, dglazkov! |
| 18:56 | <dglazkov> | looking at whatwg wiki change list, it's primarily: |
| 18:56 | <dglazkov> | a) annevk leaving notes |
| 18:56 | <dglazkov> | b) annevk clearing spam |
| 19:31 | <annevk> | jarek, the plan is to nuke childElementCount |
| 19:31 | <annevk> | jarek, so avoid it |
| 19:32 | <jarek> | annevk: I thought that once an API get's defined in DOM, it can't be removed in any feature revisions |
| 19:32 | <annevk> | future you mean? |
| 19:33 | <jarek> | s/feature/future |
| 19:33 | <annevk> | given the mess that is DOM Level 3 Core, we abandoned that idea |
| 19:33 | <jarek> | childElementCount was added in DOM3? |
| 19:33 | <annevk> | after DOM3 even |
| 19:33 | <annevk> | did not get enough peer review and was pushed through for no good reason :( |
| 19:35 | <smaug____> | "peer review"? |
| 19:36 | <smaug____> | I thought browser vendors were ok with Element Traversal spec |
| 19:38 | <annevk> | I think nobody realized we had children.length already |
| 19:38 | <annevk> | Actually, nobody there did realize |
| 19:38 | <annevk> | And that is how childElementCount got through |
| 19:38 | <annevk> | I tried to get it removed |
| 19:42 | <smaug____> | hmm, apparently I reviewed the element traversal patch |
| 19:50 | <jarek> | is there a way to check how much space is left in widow.localStorage and window.sessionStorage? |
| 19:50 | <jarek> | I remember reading that those objects have quota of 5mb on most browsers |
| 19:51 | <annevk> | nope |
| 21:12 | <AryehGregor> | Nice. |
| 21:12 | <AryehGregor> | Thanks, Google Docs. |
| 21:12 | <zewt> | google docs is one of google's ... less impressive products. heh |
| 21:12 | <AryehGregor> | As soon as I try to input a Unicode character using Ctrl-Shift-u, it totally breaks. |
| 21:12 | <AryehGregor> | So that I have to refresh the page. |
| 21:13 | <zewt> | (granted, my impression is mostly from trying to use it on android; their android app is fairly bad) |
| 21:13 | <AryehGregor> | Since of course, they need to make up their own text handling instead of using the platform. |
| 21:31 | <gsnedders> | AryehGregor: "Unicode character" being non-ASCII? |
| 21:32 | <AryehGregor> | gsnedders, well, I assume it would do the same if I tried Ctrl-Shift-u65 or something. |
| 21:32 | <AryehGregor> | It was the Ctrl-Shift-u that made it go haywire. |
| 21:32 | <AryehGregor> | Because platform conventions are for chumps, right? |
| 21:32 | <timeless> | hsivonen: ping |
| 21:33 | <timeless> | validator.w3 has "Result: Passed, 1 warning(s)", it'd be really nice if that warning(s) was a link to the part of the page with the warning |
| 21:33 | <timeless> | in my case, i can't find any warnings on the output page :( |
| 21:33 | <gsnedders> | AryehGregor: Oh, wait. I read "u" as "v". |
| 21:36 | <jgraham> | Alternative view: Google docs is one of their more impressive products and the web continues to suck as a platform for that kind of thing |
| 21:42 | <AryehGregor> | It's persistently annoying how it always works a little different than I expect. Maybe it just has bad Linux support, though. |
| 21:42 | <AryehGregor> | But really, things like Ctrl-Shift-u work just fine on every other website, why do they have to mess it up? |
| 21:45 | timeless | wonders what ctrl-shift-u is |
| 21:45 | <AryehGregor> | The way to enter arbitrary Unicode code points in GNOME. |
| 21:45 | <AryehGregor> | I use it all the time. |
| 21:45 | <timeless> | technically it's in gtk+ fwiw |
| 21:45 | <AryehGregor> | Dashes, RLMs and LRMs, arrows, accented characters, etc. |
| 21:45 | <AryehGregor> | I stand corrected. |
| 21:45 | <AryehGregor> | (I knew that, theoretically.) |
| 21:47 | <zewt> | AryehGregor: well, then there's Twitter's page, which screws up ... all menu hotkeys |
| 21:47 | <zewt> | i've always found it very strange that browsers *let* pages do that |
| 21:47 | <zewt> | (cancel keydowns for major browser hotkeys) |
| 21:48 | <timeless> | AryehGregor: this sounds more like a browser fault than a web page fault |
| 21:48 | <timeless> | the right fix for this stuff is for there to be a way for a web page to say to the UA |
| 21:48 | <timeless> | "i'd like to handle the following actions {list}" |
| 21:48 | <timeless> | "please let the user map them however, and tell me when the user has fired one" |
| 21:48 | <timeless> | that way if you want to use f99 to trigger <bold>, you could |
| 21:48 | <timeless> | and your UA could persist that preference |
| 21:49 | <timeless> | and if i want to use <tab> to trigger <bold>, i could, and my UA would persist that preference |
| 21:49 | <timeless> | please just make that happen :) |
| 21:50 | <timeless> | a UA today is in control to the extent that it should enable you to tell it "don't pass ctrl-shift-u to the web page" |
| 21:51 | <timeless> | and "please map <x> to ctrl-shift-u for the web page" |
| 21:51 | <timeless> | but sadly no UAs do this :( |
| 21:51 | <timeless> | (well, ignoring accessibility agents) |
| 21:51 | <zewt> | well, user keymappings are pretty niche |
| 21:51 | <timeless> | zewt: well |
| 21:51 | <zewt> | not that i'm personally against features that happen to fit my niche, but |
| 21:51 | <timeless> | users with limited keysets are becoming much more common |
| 21:51 | <zewt> | understandable for it not to be the highest priority |
| 21:51 | <timeless> | not everyone has a 104 key keyboard these days |
| 21:51 | <jgraham> | That sounds like it wouldn't work |
| 21:52 | <timeless> | your average found doesn't have one certainly |
| 21:52 | <timeless> | jgraham: why not? |
| 21:52 | <jgraham> | What would the page write for help text? |
| 21:52 | <zewt> | jgraham: you're already in trouble there with mac keyboards :P |
| 21:52 | <timeless> | jgraham: well, if it detects a UA that supports it |
| 21:53 | <timeless> | it'd just register events "bold", "underline", etc. |
| 21:53 | <jgraham> | zewt: Right, but when there are only two options it's more or less OK |
| 21:53 | <timeless> | and then have a link to the UAs help for mapping them |
| 21:53 | <jgraham> | Most people know if they are using a mac |
| 21:53 | <timeless> | i recently dealt w/ a "web app" which insisted i use IE6- or FF3- |
| 21:53 | <jgraham> | Generally these things that are supposed to be autoconfigured by the UA haven't really worked out |
| 21:53 | <jgraham> | see also:accesskey |
| 21:54 | <timeless> | it's really a bad idea for web pages to be forced to hard code understandings of UAs |
| 21:54 | <timeless> | yeah, accesskey was a nice failure |
| 21:54 | <timeless> | but part of it was that it was yet another way to capture user keystrokes |
| 21:54 | <timeless> | instead of a way to let users be in control |
| 21:55 | <zewt> | user control is often sort of a last-ditch fallback |
| 21:55 | <timeless> | a simple mapping of <event, description> for registration should work |
| 21:55 | <timeless> | possibly with default mappings |
| 21:55 | <timeless> | zewt: it's rarely done, let alone done well |
| 21:55 | <zewt> | given the choice between "everything works" and "everything's broken, but the user can fix it", the former is almost always better, of course |
| 21:55 | <zewt> | the latter becomes the fallback when people can't figure out how to implement the former |
| 21:55 | <jgraham> | Indeed |
| 21:55 | <zewt> | (because, sometimes, it's hard) |
| 21:56 | <timeless> | the former only works for 3 months around product launch |
| 21:56 | <timeless> | and only in the target environment |
| 21:56 | <timeless> | which ceases to be available at month 4 |
| 21:56 | <zewt> | depends on how competently it's designed |
| 21:56 | <jgraham> | Users don't want to be "in control" in the sense of having lots of options |
| 21:56 | <jgraham> | They want to have everything work by default |
| 21:56 | <jgraham> | and have a simple story to follow when they get stuck |
| 21:56 | <timeless> | on a keyboardless device |
| 21:57 | <timeless> | how do you want the user to deal w/ sending ctrl-shift-u? |
| 21:57 | <jgraham> | Not "oh you can go to (some UA dependent config screen) and (do something complex with a long list of options)" |
| 21:57 | <zewt> | of course, that can mean having an interface competent enough so that the UA (not the user, whenever possible) can negotiate a workable interface with scripts |
| 21:57 | <jgraham> | AIUI ctrl-shift-u isn't a webapp feature, it's an OS feature |
| 21:58 | <timeless> | AryehGregor: how is this thing breaking precisely? |
| 21:58 | <timeless> | is the app receiving the unicode character and dying because of it? |
| 21:58 | <jgraham> | I would expect webapps not to break OS features, sure |
| 21:58 | <timeless> | or is it preventing it from being triggered in the first place? |
| 21:58 | <AryehGregor> | timeless, very weirdly. |
| 21:58 | timeless | assumed the latter |
| 21:58 | <jgraham> | Just like I expect them to work with the compose key or IMEs |
| 21:58 | <AryehGregor> | No, it breaks from when it gets Ctrl-Shift-u. |
| 21:58 | <timeless> | define breaks more precisely, please? |
| 21:59 | <zewt> | is it trying to capture something else? eg. is it seeing the ctrl-u and screaming "underline!" and cancelling the event? |
| 21:59 | <timeless> | zewt: that would be my bet.. |
| 21:59 | <AryehGregor> | timeless, sorry, GTG. |
| 21:59 | <AryehGregor> | Try it and see. |
| 21:59 | <AryehGregor> | It was really weird. |
| 21:59 | timeless | doesn't want to install linux just to test |
| 21:59 | <zewt> | not matching keyboard events precisely enough is a very common bug |
| 21:59 | <jgraham> | Keyboad events are a world of hurt |
| 21:59 | <jgraham> | that's not webapps fault |
| 22:00 | <timeless> | no, it's UA + DOM |
| 22:00 | <jgraham> | It's a browser/specs problem |
| 22:00 | <zewt> | the platform's fault |
| 22:00 | <timeless> | generally |
| 22:00 | <jgraham> | I'm not convinced that DOM3 events makes it better |
| 22:00 | <jgraham> | in fact that spec seems to be a disaster |
| 22:01 | <timeless> | jgraham: out of curiosity, can you actually point to web apps that document their keybindings in places easily reachable by normal users? |
| 22:02 | <timeless> | the only ones i can think of are google gmail/reader/news, and they don't do that, they randomly toss up a hint which is a link to them |
| 22:02 | <zewt> | thankfully they got rid of that "hint text" nonsense in gmail |
| 22:02 | <zewt> | that was horribly distracting |
| 22:02 | <timeless> | really? |
| 22:02 | <jgraham> | http://docs.google.com/support/bin/answer.py?answer=179738 |
| 22:03 | <timeless> | they recently added it to news |
| 22:03 | <zewt> | gone in mine, anyway |
| 22:03 | <zewt> | nothing worse than having mail open on a side monitor and having text periodically changing in it when you're trying to do something else |
| 22:03 | <jgraham> | Dunno how easy that is to find, but searching for "google docs key" worked |
| 22:03 | <timeless> | jgraham: that doesn't count as easily reachable |
| 22:04 | <timeless> | i was trying to ask as in <from inside the app> |
| 22:04 | <timeless> | using google-search is very much outside of that |
| 22:04 | <zewt> | keyboard bindings are fundamentally hard because browser don't agree on keystroke namespaces--which keys are the browser's and which are the page's |
| 22:04 | <jgraham> | It's not really more outside the app than using the help menu is |
| 22:04 | <timeless> | and i'm more interested in *non*-google apps anyway |
| 22:04 | <jgraham> | In a desktop application |
| 22:04 | <zewt> | though that's been slowly improving ... i think current opera actually got rid of *all* (?) alt- shortcuts (which I think was overkill) |
| 22:05 | <jgraham> | (which also has search these days) |
| 22:05 | <timeless> | jgraham: well |
| 22:05 | <timeless> | an app can have no help |
| 22:05 | <zewt> | and chrome has very few alt- shortcuts compared to ff/ie |
| 22:05 | <timeless> | and someone can write a "tips-and-tricks" book |
| 22:05 | <timeless> | i'm mostly asking whether apps generally document these things at all |
| 22:06 | <timeless> | (as opposed to third party documenters) |
| 22:06 | <zewt> | timeless: it's something they should take a hint from desktop apps for |
| 22:06 | <zewt> | the practice of putting keyboard shortcuts next to corresponding menu items is as clear as you can get |
| 22:07 | <zewt> | and avoids clutter, since it's only visible when you happen to have that menu open |
| 22:07 | <zewt> | and avoids the "go read the docs" syndrome (you shouldn't have to read a manual to know what shortcuts are) |
| 22:07 | <zewt> | (particularly important because nobody writes manuals :) |
| 22:08 | <timeless> | hey |
| 22:08 | timeless | seems to recall having met someone who did |
| 22:08 | <zewt> | a UI that's intuitive enough to not need a manual is always better than any UI with a manual :P |
| 22:09 | timeless | ponders |
| 22:09 | <zewt> | of course, there's the fundamental problem that web apps don't have a standard UI like desktop apps do |
| 22:09 | <zewt> | which has a cost |
| 22:33 | <Philip`> | On the subject of moaning about Google: I wish they didn't keep changing their search results to randomly different shades of blue, it's terribly distracting |
| 22:34 | <aho> | a/b test all the things! :v |
| 22:40 | <zewt> | it's felt to me like there once was someone influential on the google search team who stood against making a mess of it, and that person left the team about a year or two ago |
| 22:41 | <zewt> | because all of a sudden they started going apeshit with distracting nonstop changes |