| 00:00 | <abarth> | jgraham: is there an updated dom2string that knows how to print out doctypes better? |
| 00:00 | <gsnedders> | abarth: no |
| 00:01 | <abarth> | :( |
| 00:01 | <abarth> | that makes us fail all the doctype tests |
| 00:02 | <gsnedders> | How? |
| 00:02 | <gsnedders> | Oh, the tests checking PUBLIC/SYSTEM DOCTYPEs? |
| 00:03 | <abarth> | yeah |
| 00:03 | <abarth> | looks like they're in the dom |
| 00:05 | <gsnedders> | Hmm, I wonder why I didn't notice that before when redoing it |
| 00:05 | <gsnedders> | Hmm, is there any way to tell apart missing from empty in the DOM? |
| 00:06 | <abarth> | null versus the empty string? |
| 00:06 | <abarth> | i'll have an updated version in a second |
| 00:07 | gsnedders | wonders where the most up-to-date public version of that script is |
| 00:07 | <MikeSmith> | gsnedders: would hope it'd be in the upstream source repo |
| 00:08 | <MikeSmith> | gsnedders: is this about html5lib/ |
| 00:08 | <MikeSmith> | ? |
| 00:08 | <gsnedders> | MikeSmith: I don't think the browser runner is there though |
| 00:08 | <MikeSmith> | I see |
| 00:09 | <abarth> | gsnedders: i think i have it |
| 00:10 | <abarth> | gsnedders: i might not have the null / empty thing right since webkit borks that up |
| 00:13 | <abarth> | gsnedders: the diff is in here https://bugs.webkit.org/show_bug.cgi?id=42794 |
| 00:18 | <gsnedders> | abarth: FWIW, I was going to make some changes to the runner |
| 00:18 | <gsnedders> | (Mainly removing hacks needed by old versions of the Gecko HTML5 Parser) |
| 00:21 | <abarth> | gsnedders: let me know if you upate the runner |
| 00:21 | <abarth> | gsnedders: we changed a thing or two so that it prints out all the diffs |
| 00:21 | <abarth> | gsnedders: so we can track progressions in more detail |
| 00:23 | <gsnedders> | abarth: Also, wrt the copyright notice, Simon Pieters was the original author, and for what I did last year it should probably include Opera Software |
| 00:44 | <abarth> | gsnedders: i'm happy to make the copyright notice say whatever you like |
| 00:45 | <abarth> | gsnedders: i grabbed the notice from the web site where i got the code |
| 00:52 | <gsnedders> | abarth: Um, yeah, I should probably change that. It isn't right for all tests. |
| 00:53 | <gsnedders> | (Well, the license is, the copyright year/name is wrong for a few) |
| 00:55 | gsnedders | notices abarth managed to comment before he did :) |
| 00:55 | <gsnedders> | abarth: Also: your patch is wrong. |
| 00:55 | <gsnedders> | (See my comment) |
| 00:55 | <abarth> | my patch is wrong! |
| 00:55 | <abarth> | impossible |
| 00:56 | <abarth> | all the tests pass :) |
| 00:56 | <gsnedders> | Yes, code can still be wrong when the tests pass. Sadly. |
| 00:56 | gsnedders | weeps a thousand tears |
| 01:30 | <MikeSmith> | nimbupani: you around? |
| 01:31 | <nimbupani> | MikeSmith: yep. |
| 01:31 | <MikeSmith> | hey, did you do the design for the html5readiness.com site? |
| 01:31 | <nimbupani> | yes :) |
| 01:31 | <MikeSmith> | very nice stuff |
| 01:31 | <nimbupani> | thanks! :) |
| 01:32 | <nimbupani> | paul_irish helped too. |
| 01:32 | <MikeSmith> | cool |
| 01:32 | <MikeSmith> | well, it's smart for not just the colors and layout, but for the information design |
| 01:32 | <nimbupani> | MikeSmith: thank you, have had a lot of people decrying it for information design :( |
| 01:33 | <MikeSmith> | yeah, well, everybody loves to second-guess design choices |
| 01:33 | <nimbupani> | :) |
| 01:33 | <MikeSmith> | but the fact that it lets me toggle a display of yearly progress is a big win for me |
| 01:34 | <MikeSmith> | I have used that page recently in some presentations |
| 01:34 | <nimbupani> | oh nice! I am glad it was of use! |
| 01:34 | <MikeSmith> | showing the year-by-year thing always seems to gets lots of oohs and ahs from the audience |
| 01:35 | <nimbupani> | ha ha ha :) yeah I am glad one of the people who saw the first version suggested it! |
| 01:36 | <MikeSmith> | I was also thinking about your tweet about lack of diversity of various kinds at conferences |
| 01:36 | <nimbupani> | :) yeah my pet peeve :D |
| 01:37 | <MikeSmith> | I think I rememeber Chris Messina wrote some about that a couple years back, about lack of gender diversity in particular, iirc |
| 01:37 | <nimbupani> | yep. I remember seeing that. |
| 01:37 | <nimbupani> | my view is there should be, in general more diversity, not just gender. |
| 01:37 | <MikeSmith> | yeah, I read your post about that |
| 01:38 | <MikeSmith> | speaking as somebody who organizes events now and then, I can say it's hard to do |
| 01:38 | <nimbupani> | MikeSmith: I bet. I know :( |
| 01:38 | <nimbupani> | but I think the onus is on the organizers :( |
| 01:38 | <nimbupani> | only because the audience does not know better. |
| 01:39 | <nimbupani> | but the organizers should :) |
| 01:39 | <MikeSmith> | yeah, true -- in my case, like with a lot of things I also just get lazy or rushed and tend to fall back on what takes me the least amount of time and trouble |
| 01:39 | <MikeSmith> | anyway, I am trying to help a bit for planning of some events in Japan later this year |
| 01:40 | <nimbupani> | MikeSmith: haha status quo wins over all of us! |
| 01:40 | <nimbupani> | oh k |
| 01:40 | <MikeSmith> | and I am looking for HTML5 presenters |
| 01:40 | <MikeSmith> | so if you have specific ideas, lemme know |
| 01:40 | <MikeSmith> | either by e-mail (mike⊙wo) here or whatever |
| 01:41 | <MikeSmith> | would you be interested yourself in speaking at an event in Japan? |
| 01:41 | <nimbupani> | MikeSmith: yes I think I would be :) |
| 01:41 | <MikeSmith> | cool |
| 01:42 | <nimbupani> | will email you when/if I have ideas. my currently festering idea is to evangelize being curious as a web developer :) |
| 01:42 | <MikeSmith> | heh |
| 01:43 | <MikeSmith> | curiosity is what a certainly really motivating |
| 01:43 | <nimbupani> | instead of depending on other people to do your (= web dev) thinking on what is right and what is not. |
| 01:43 | <MikeSmith> | s/what a // |
| 01:43 | <MikeSmith> | nimbupani: yeah |
| 01:44 | <nimbupani> | which results in people who say "just use safari" |
| 01:44 | <nimbupani> | or "just ignore IE" |
| 01:44 | <nimbupani> | or parroting thoughts/myths instead of evaluating |
| 01:44 | <nimbupani> | and puts pressure on browser vendors to implement vendor-prefixes that people find "cool" rather than what is useful. |
| 01:45 | <nimbupani> | or in case of Win 7 phone implement support for webkit prefixes :/ |
| 01:45 | <MikeSmith> | ah yeah |
| 01:46 | <nimbupani> | i will email you a draft of a sort-of article I wrote (it is pending publication, so do not want to post it here). |
| 01:46 | <MikeSmith> | yeah, please do |
| 01:46 | <MikeSmith> | the topic of "not parroting thoughts/myths instead of evaluating" is certainly something that I think Web designers in Japan in particular would benefit from seeing a presentation on |
| 01:47 | <nimbupani> | k sent. |
| 01:47 | <nimbupani> | :) |
| 01:47 | <MikeSmith> | cheers |
| 07:25 | <zcorpan_> | micheil: what oddities? http://krijnhoetmer.nl/irc-logs/whatwg/20100722#l-11 |
| 07:26 | <micheil> | zcorpan_: see the link below |
| 07:26 | <micheil> | I'm going to further test it today |
| 07:27 | <zcorpan_> | micheil: how to test this? |
| 07:28 | <micheil> | well, first I'm going to see if I get the same result as the bug reporter there |
| 07:28 | <micheil> | then I'm going to try and figure out why a high-bit packet is being sent on close |
| 07:28 | <micheil> | I'm guessing it's \x00 vs \u0000 |
| 07:29 | <Hixie> | man, the websockets feedback to the whatwg list is much more useful than the websockets feedback to the hybi list |
| 07:30 | <micheil> | Hixie: also, re Sec-WebSocket-Protocol |
| 07:30 | <micheil> | should I mail the list about changing from space separated to comma separated, as it's generally commas for other http-type headers |
| 07:31 | <micheil> | (plus it means we could theoretically have multiple word subprotocols) |
| 07:31 | <micheil> | so, when constructing, rather then doing: Array.prototype.join.call(protocols, " "); it's Array.prototype.join.call(protocols, ", "); |
| 07:32 | <Hixie> | what benefit does that give us? |
| 07:32 | <micheil> | Sec-WebSocket-Protocol: xmpp, jabber, plaintext |
| 07:32 | <micheil> | I think it's just really a better way to write it. |
| 07:32 | <Hixie> | the cost is increased complexity (you now have to strip both commas and spaces), there presumably has to be some gain to counteract the cost |
| 07:33 | <micheil> | plus it then also directly indicates that it is an array |
| 07:33 | <Hixie> | why is it better? |
| 07:33 | <micheil> | because, the API interface is then similar to the http interface |
| 07:33 | <micheil> | s/http/network |
| 07:33 | <Hixie> | that's silly, you're the reason the API interface isn't like the network interface :-P |
| 07:34 | <micheil> | hmm, well, anyway, the thing about using ", " was actually mentioned to me by another developer |
| 07:34 | <Hixie> | i had it as a space-separated list and you said it should be an array, and now you're saying because it's an array it shouldn't be a space-separated list :-P |
| 07:34 | <Hixie> | commas are silly imho |
| 07:34 | <Hixie> | i see no advantage |
| 07:34 | <micheil> | okay |
| 07:35 | <Hixie> | it just makes it more likely that servers will be buggy, e.g. they'll treat spaces before the commas as meaningful, or some such |
| 07:35 | <micheil> | so, in DOM Interface, it's now: DOMString | Array, yes? |
| 07:35 | <micheil> | or is it just an array full stop? |
| 07:35 | <zcorpan_> | Hixie: one advantage (or not?) is that an array stringifies to joining with commas in browsers |
| 07:36 | <zcorpan_> | not comma-space, just comma |
| 07:36 | <micheil> | the only reason I was given for why that should be changed was because that'd bring it inline with the same format used for, say, the Cookie / Set-Cookie header |
| 07:37 | <zcorpan_> | it'd still refuse the connection when the server replies with one of the protocols when the browser expects the whole thing though |
| 07:37 | <zcorpan_> | so maybe it's better that the server is able to detect a legacy client earlier and just close the connection |
| 07:37 | <Hixie> | micheil: DOMString or Array, yes |
| 07:37 | <micheil> | Hixie: okay, good |
| 07:38 | <Hixie> | zcorpan_: not sure why comma's easier than spaces? |
| 07:38 | <micheil> | zcorpan_: the way I'm currently detecting versions is by checking for various Sec-* headers |
| 07:38 | <zcorpan_> | Hixie: not saying it's easier, just saying that existing browsers would stringify ['foo','bar'] to 'foo,bar' |
| 07:39 | <zcorpan_> | micheil: i'm talking about -76 vs the version with protocol negotiation |
| 07:39 | <micheil> | zcorpan_: ? |
| 07:39 | <zcorpan_> | micheil: firefox and chrome dev don't support protocol negotiation |
| 07:40 | <zcorpan_> | micheil: if you pass in an array in the second argument, they'll just stringify it |
| 07:40 | <micheil> | also, Hixie re zcorpan_ on toString: |
| 07:40 | <micheil> | node> ["a","b"].toString() |
| 07:40 | <micheil> | 'a,b' |
| 07:40 | <micheil> | zcorpan_: good point |
| 07:41 | <zcorpan_> | micheil: but when the server responds with 'a', the browser will refuse the connection since it's not the expected 'a,b' |
| 07:41 | <micheil> | zcorpan_: I'll have to add that to my todo list when writing a protocol / feature test suite. |
| 07:41 | <Hixie> | zcorpan_: doesn't much matter, they'd fail when the server responds anyway |
| 07:41 | <micheil> | zcorpan_: hmm... |
| 07:41 | <zcorpan_> | Hixie: indeed |
| 07:41 | <micheil> | zcorpan_: if these are dev versions, then we can always get them patched, no? |
| 07:42 | <Hixie> | zcorpan_: in fact that would argue for using spaces, since then the server that really wants to handle the briefly deployed dev versions can just look for commas and return the whole thing |
| 07:42 | <zcorpan_> | micheil: might be too late for the next release, although i can only speak for opera of course |
| 07:42 | <Hixie> | zcorpan_: that's pretty obscure though |
| 07:42 | <micheil> | Hixie: also, what is the value of thisArg in context of ws.onopen or ws.addEventListener("open", fn); |
| 07:42 | <micheil> | ? |
| 07:42 | <zcorpan_> | Hixie: yeah, that's what i said also :) |
| 07:42 | <Hixie> | micheil: ws, i guess. See DOM3 Events and WebIDL for details. |
| 07:43 | <Hixie> | zcorpan_: k :-) |
| 07:43 | <micheil> | Hixie: okay |
| 07:43 | <micheil> | zcorpan_: I'll have a look at the current implementation for mozilla, and see if I can provide a patch for it. |
| 07:43 | <micheil> | if we can get the spec to back up which ever way we choose to go. |
| 07:44 | <micheil> | because the second arg in new WebSocket is fairly new, isn't it? |
| 07:45 | <Hixie> | websockets itself is fairly new :-P |
| 07:45 | <micheil> | >_> |
| 07:45 | <micheil> | y'know what I meant though. |
| 07:45 | <zcorpan_> | micheil: well it'd old enough to be implemented in the browsers |
| 07:46 | <micheil> | so, has the api gone: WebSocket( url ) => WebSocket( url, protocol ) |
| 07:46 | <micheil> | or was protocol always there? |
| 07:46 | <Hixie> | protocol has been there for ages |
| 07:46 | <micheil> | okay |
| 07:46 | <Hixie> | (it's optional btw) |
| 07:46 | <micheil> | okay, good point |
| 07:47 | <Hixie> | you can do spec archeology by poking at svn blame for the source document |
| 07:47 | <micheil> | http://svn.whatwg.org/webapps/ is the repo url for the WebSockets stuff, yeah? |
| 07:47 | <Hixie> | yah |
| 07:49 | <micheil> | hmm.. not sure why I can never seem to checkout a copy of the repo |
| 07:49 | <Hixie> | might be too big? |
| 07:50 | <micheil> | no, I had a bad flag. |
| 07:50 | <micheil> | $ git svn clone -s SVN_REPO_URL LOCAL_DIR |
| 07:50 | <Hixie> | the svn repo itself is 671MB |
| 07:50 | <micheil> | then there's a subnote in small text about 6 lines below: -s is indicating that the repo has standard trunk/branch/tags structure |
| 07:50 | <kennyluck> | /list |
| 07:51 | <micheil> | Hixie: what revision are you up to? |
| 07:51 | <Hixie> | r5178 |
| 07:51 | <micheil> | k |
| 07:51 | <micheil> | so I've got about 30 minutes to kill |
| 07:52 | <micheil> | I'm getting about 2 rev's / minute |
| 07:53 | <micheil> | erm, / second |
| 07:54 | <micheil> | Hixie: I'm putting a mirror up at http://github.com/miksago/whatwg-webapps-mirror |
| 07:55 | <micheil> | just so that I can easily browse exactly what lines changed and also provide references when quoting changes to other devs. |
| 07:56 | <Hixie> | cool |
| 08:00 | <jgraham> | abarth: (just reading the backlog) actually I do have a new version of the runner, but it is not released yet. I will see what changes you made |
| 08:00 | <abarth> | ok |
| 08:01 | <abarth> | i'm told they're not quite right |
| 08:01 | jgraham | blames gsnedders for misleading you :) |
| 08:01 | <jgraham> | Well when I say "new version" I mean "I rewrote it from scratch without looking at the previous version" |
| 08:02 | <jgraham> | Although I think my rewrite might be more like the way Opera likes things and less like the way Webkit like things |
| 08:03 | <jgraham> | (we tend to have one testcase per file rather than lots of tests in a single file. It is slower but nicer if you get crashes or so one) |
| 08:04 | <abarth> | oh, that sounds fine |
| 08:04 | <abarth> | runner.html is pretty hard to hack on |
| 08:04 | <abarth> | the control flow is kind of screwy |
| 08:05 | <abarth> | lots of different tests are fine too |
| 08:05 | <abarth> | it doesn't really matter |
| 08:05 | <abarth> | there are >20k layout tests |
| 08:05 | <abarth> | the parser tests aren't a big fraction of the time it takes to run the tests :) |
| 08:07 | <jgraham> | Yeah :) |
| 08:10 | <micheil> | jgraham: hmm.. the mozilla code base implements an autoclose for nsWebSocket.cpp |
| 08:12 | <jgraham> | micheil: You intended that for someone else? |
| 08:12 | <micheil> | no |
| 08:13 | <jgraham> | Oh |
| 08:13 | <jgraham> | Well I'm not sure what you're telling me then |
| 08:14 | <micheil> | okay |
| 10:18 | <hsivonen> | othermaciej: the ascii-ref poll has been configured to open in the future, so it's not yet open. Is that intentional? |
| 10:18 | <othermaciej> | hsivonen: no; will fix |
| 10:19 | <othermaciej> | done |
| 10:19 | <othermaciej> | thank you for letting me know |
| 10:19 | <hsivonen> | othermaciej: thanks |
| 10:20 | <jgraham> | We have a *poll* about ascii-ref? |
| 10:20 | jgraham | mutters |
| 10:22 | <Cheery> | I wrote a new toy. could test it in the evening. |
| 10:23 | <Cheery> | (again, websocket stuff) |
| 10:23 | <hsivonen> | so considering what Hixie said about cache-control pragma, has anyone done research on which meta pragmas are needed for Web compat but aren't in HTML5 already? |
| 10:23 | <hsivonen> | it seems to me that IE8 and IE9 don't support cache-control no-cache as a meta. Do I have the right testing result? |
| 10:24 | <mcarter> | Cheery, what new toy did you write? |
| 10:27 | <othermaciej> | jgraham: I have suggested to my fellow co-chairs that any additional issues which are purely editorial in nature; which have no impact on normative requirements; and which have no specific other reason to be high priority (such as courting needless controversy); should perhaps not be considered blockers for Last Call |
| 10:28 | <Cheery> | I hooked json encoder/decoder to the websocket, then I wrote a thing that broadcasts mouse motion events. |
| 10:28 | <othermaciej> | jgraham: not sure if I was successful in making the case for this, but I think it is reasonable to still work through the current set of open issues |
| 10:28 | <Cheery> | mcarter: and shows that data on the canvas. |
| 10:28 | <jgraham> | othermaciej: That sounds sensible |
| 10:28 | hsivonen | wonders how WebKit, Gecko and Presto came to have meta support for caching stuff |
| 10:29 | <hsivonen> | that is whether someone implemented it for completeness or for compat |
| 10:29 | <mcarter> | Cheery, cool. Does it just show the mouse cursor positions on the canvas, or something else? |
| 10:34 | <othermaciej> | all meta support http-equiv we added was for compat, often based on specific bugs reported on sites |
| 10:34 | <hsivonen> | othermaciej: thanks. |
| 10:34 | <hsivonen> | othermaciej: I guess that means that HTML5 needs to support the caching-related stuff |
| 10:35 | <hsivonen> | othermaciej: does WebKit support anything other than charset, caching and refresh? |
| 10:36 | <othermaciej> | actually I am not 100% sure all these are needed |
| 10:37 | <othermaciej> | but the ones we support include: default-style, refresh, set-cookie, content-language, x-dns-prefetch-control, x-frame-options |
| 10:37 | <othermaciej> | (and charset with separate magical code) |
| 10:38 | <othermaciej> | I'm not sure we ever added cache-control / pragma support |
| 10:38 | <othermaciej> | though I remember it being requested |
| 10:38 | <hsivonen> | othermaciej: maybe the test case I'm using is wrong. but it indicates that Chrome and Safari support cache-control no-cache |
| 10:39 | <othermaciej> | from casual inspection I do not see code that would do that |
| 10:39 | <hsivonen> | interesting |
| 10:39 | <hsivonen> | the test is http://landfill.mozilla.org/ryl/meta-cache-control.cgi |
| 10:40 | <othermaciej> | pressing enter in the URL field is equivalent to a reload in Safari |
| 10:40 | <othermaciej> | so it revalidates |
| 10:40 | <othermaciej> | opening the document again in a new tab gets the cached copy |
| 10:40 | <hsivonen> | oh |
| 10:49 | <hsivonen> | jgraham: is Opera now supposed to support Debian package updating on Ubuntu? Opera itself tells me that a new version is available and I should run the system updater, but the system updater doesn't offer a new Opera build. |
| 10:50 | <jgraham> | hsivonen: I am not sure |
| 10:50 | <hsivonen> | fwiw, I have the Opera final releases repo disabled and the beta releases repo enabled |
| 10:51 | <hsivonen> | I'd expect the beta repo to offer the latest final when a later beta isn't available... |
| 10:51 | <jgraham> | I honestly have no idea how our desktop distribution system is supposed to work. It is clearly not simple enough in any case |
| 10:52 | <jgraham> | At least on linux |
| 10:52 | <hsivonen> | indeed. the only Opera updating workflow that doesn't suck for me is the one on Maemo |
| 10:52 | <hsivonen> | Mac, Ubuntu and S60 all suck |
| 10:53 | <hsivonen> | Mac: downloads update but doesn't apply it reliably |
| 10:53 | <hsivonen> | Ubuntu: see above |
| 10:54 | <hsivonen> | S60: To make space, one needs to uninstall previous version and then install the new version. After this, all history, speed dial content and passwords are gone. |
| 10:55 | <zcorpan_> | the facebook cross-origin xhr attack made me think if there is a better way to protect against unintended cross-origin xhr than just exposing the origin somewhere for the script to remember to check |
| 10:55 | <zcorpan_> | e.g. force setting a property on the xhr object before making the request |
| 10:56 | <zcorpan_> | xhr.acceptOrigins = 'http://example.org'; |
| 10:57 | <hsivonen> | enabling the final release repo in addition to the beta repo makes the update manager offer 10.60 final |
| 10:57 | <hsivonen> | I suggest making the beta repo offer than one, too |
| 11:10 | <hsivonen> | cool. Opera on Ubuntu now respects my Gnome font antialiasing prefs |
| 11:10 | <hsivonen> | tabs on top in Opera don't integrate fully into Ambiance/Radiance, though |
| 11:10 | <hsivonen> | visually that is |
| 11:44 | <gsnedders> | abarth: (if you see this): one of the things I aws going to do was make the control flow sane |
| 11:44 | <gsnedders> | :) |
| 12:00 | <MikeSmith> | Ms2ger: I cc'ed you on the spec bug I filed because iirc you're maintaining the indexes of elements and attributes and events in the spec |
| 12:04 | <Ms2ger> | MikeSmith, I wrote the initial versions, but Hixie maintains them |
| 12:04 | <MikeSmith> | ok |
| 12:05 | <MikeSmith> | well, feel free of course to remove yourself from the Cc |
| 13:12 | <Cheery> | http://boxbase.org/fun/netsquares/ |
| 13:13 | <Cheery> | This far it's only working on chrome 6 |
| 13:13 | <Cheery> | and possibly, on firefox 4 alpha |
| 13:14 | <Cheery> | (though, weren't it possible to support the newer and older draft?) |
| 13:15 | <Cheery> | gah. weird behavior. :/ |
| 13:15 | <Lachy> | Cheery, doesn't work in Chromium |
| 13:15 | <Lachy> | or Minefield |
| 13:15 | <Lachy> | what is it supposed to do? |
| 13:15 | <Cheery> | Lachy: it should show cursor on the screen. |
| 13:16 | <Cheery> | with all other cursors of the users connected |
| 13:17 | <jgraham> | Cheery: Can't connect to server |
| 13:17 | <Cheery> | jgraham: it's disconnected for now. I'm fixing things. :) |
| 13:18 | <Cheery> | now. lets try again |
| 13:18 | <Lachy> | oh, I see. |
| 13:19 | <Lachy> | it works in chromium now. |
| 13:19 | <Lachy> | doesn't work in Opera or Firefox |
| 13:19 | <Cheery> | opera or firefox tried? |
| 13:19 | <Cheery> | just while ago? |
| 13:20 | <Rik`> | it kind of works on Firefox |
| 13:20 | <Cheery> | well some connection opens, but it yells on data decoding. |
| 13:20 | <Rik`> | I see some movements but then I'm disconnected |
| 13:20 | <Cheery> | lets see what is going on. :) |
| 13:20 | <Cheery> | Rik`: you're likely the source of: |
| 13:20 | <Cheery> | TypeError: int() argument must be a string or a number, not 'NoneType' |
| 13:20 | <Cheery> | coords[1] = int(data[1]) |
| 13:21 | <zdenekkostal> | not connected in Opera 10.60 (about 1 minute ago) |
| 13:21 | <Lachy> | Cheery, is it using websockets? |
| 13:21 | <Rik`> | maybe :) |
| 13:21 | Lachy | could look at the source, but too lazy |
| 13:21 | <Cheery> | http://boxbase.org/fun/netsquares/netsquares.js |
| 13:22 | <Cheery> | http://boxbase.org/fun/netsquares/server.py |
| 13:22 | <micheil_away> | hey, Rik` there was talk earler today about the multiple protocols in the DOM api & protocol negotiation early, what's the chances of this landing in FF4? |
| 13:22 | <Rik`> | micheil_away: I haven't followed that, do you have pointers ? |
| 13:24 | <micheil_away> | yeah, there's been a DOM api change: WebSocket( DOMString, [ DOMString | Array ] ) |
| 13:24 | <micheil_away> | the second argument being the protocols |
| 13:25 | <Cheery> | okay. I did a change, just waiting for port to get freed |
| 13:25 | <micheil_away> | then when the server responds, it picks one of the protocols, which were sent in the handshake as a (i think we agree ) comma separated list |
| 13:25 | <micheil_away> | so, Sec-WebSocket-Protocol: protoA,protoB,protoC |
| 13:25 | <Cheery> | Rik`: could you try it out again? |
| 13:26 | <Cheery> | micheil_away: so the accepted protocol is returned back in onopen ? |
| 13:26 | <micheil_away> | Rik`: then the server would respond with something like: Sec-WebSocket-Protocol: protoA |
| 13:27 | <micheil_away> | the accepted protocol is then stored as a DOMString as a property of the WebSocket object / instance |
| 13:27 | <micheil_away> | so, ws.protocol = DOMString, following the previous example, ws.protocol = "protoA" |
| 13:27 | <Cheery> | Rik`: it seems now it's working on you? |
| 13:28 | <Cheery> | hmm.. |
| 13:28 | <Cheery> | YAY! |
| 13:28 | <Rik`> | Cheery: yep |
| 13:28 | <Cheery> | message was: '["move",null,null]' |
| 13:28 | <Rik`> | the mouse moves are really fast sometimes so I'm not sure it's working perfectly but it's ok |
| 13:29 | <Cheery> | they are quite fast |
| 13:30 | <Rik`> | micheil_away: those changes are one day old, right ? |
| 13:30 | <Cheery> | I wonder what the heck passes me null,null JSON: :) |
| 13:30 | <micheil_away> | I think so, not sure on the commas one yet. |
| 13:31 | <Rik`> | micheil_away: then I think we want to implement it, but there's not a bug open about that yet |
| 13:31 | <micheil_away> | Hixie: could you give a definitive answer? |
| 13:31 | <Cheery> | there comes many of them at once when someone drives the mouse over the canvas. |
| 13:32 | <Cheery> | offsetX, offsetY.. does every browser provide those with mousemove -event? |
| 13:32 | <jgraham> | hsivonen: I just added a simple script to html5lib tests directory that converts tokenizer tests to treebuilder-style tests (basically parses the input in html5lib and dumps the output) |
| 13:33 | <jgraham> | Dunno if that is of interest to you |
| 13:33 | <hsivonen> | jgraham: cool. thanks |
| 13:34 | <micheil_away> | Rik`: so far I can see the multiple protocols there, which have been in for a few days |
| 13:34 | <micheil_away> | as for the change in the header format, not yet. |
| 13:34 | <Cheery> | hmm. |
| 13:34 | <Cheery> | I feel it was enough testing out. :) |
| 13:34 | <jgraham> | hsivonen: (of course if html5lib is buggy, the generated tests will be buggy too. But you can always check if html5lib passes the tests at the tokenizer level) |
| 13:38 | <Cheery> | anyway. the chromium 5 (which is using older protocol), is still having troubles running my app. |
| 13:38 | <Cheery> | the only trouble is that ubuntu is providing chromium 5 but not chromium 6 :E |
| 13:39 | <Cheery> | should I still implement the support for that older protocol too? |
| 13:40 | <Cheery> | even if it all is just drafts. |
| 13:40 | <hsivonen> | Cheery: the sooner the old protocol is forgotten, the better |
| 13:46 | <Cheery> | I wonder about communicating through TCP. JSON is all right but I wonder whether there'd be more compact data transfer language. |
| 13:46 | <Philip`> | How much bandwidth are you currently using? |
| 13:47 | <Cheery> | I don't know. though that last web app worked just fine with few users it had. :) |
| 13:47 | <Philip`> | You should probably measure that before thinking about how to optimise it :-) |
| 13:48 | <Cheery> | well yeah. though I'd still like more compact language for data transfer. ;) |
| 13:48 | <micheil_away> | Cheery: I had feedback from another developer that just doing the JSON.stringify / JSON.parse was enough latency to make things slow |
| 13:49 | <micheil_away> | (this was an app sending a packet every mouse move) |
| 13:49 | <Cheery> | yes it was. |
| 13:49 | <Cheery> | though I see it worked all right. :) |
| 13:50 | <micheil_away> | ? |
| 13:50 | <micheil_away> | this developer actually switched to some comma separated custom protocol |
| 13:50 | <Cheery> | my app was sending mouse move packets too. |
| 13:50 | <micheil_away> | Cheery: other question: do you need every mousemove packet? |
| 13:51 | <micheil_away> | or can you set a " |
| 13:51 | <micheil_away> | frame rate" |
| 13:51 | <Cheery> | well that were just a tryout. |
| 13:51 | <micheil_away> | okay |
| 13:51 | <Cheery> | http://boxbase.org/fun/knights/ <- I've got this thing, which I plan to transform into a multiplayer platformer. |
| 13:52 | <micheil_away> | http://remysharp.com/2010/07/21/throttling-function-calls/ may help |
| 13:53 | <Cheery> | micheil_away: hehe. I weren't doing that. :) |
| 13:53 | <micheil_away> | k |
| 13:54 | <Cheery> | Since I've got continuous access to server, I don't need to do throttling. |
| 13:54 | <micheil_away> | well, depends |
| 13:54 | <micheil_away> | there is a need at times where it makes sense |
| 13:54 | <Cheery> | there's one worse issue, but I could only fix it by using datagram packets. |
| 13:55 | <micheil_away> | for instance, rather then sending 600 packets for a movement of 600px, you could get away with sending 300 or 150 packets, and then doing client side animation. |
| 13:55 | <Cheery> | TCP must absolutely send every damn packet that is requested to be sent. |
| 13:56 | <micheil_away> | true, where as UDP is very much fire and forget |
| 13:56 | <micheil_away> | doesn't have quite the same packet encoding overhead |
| 13:56 | <micheil_away> | less headers, etc. |
| 13:58 | <Cheery> | the \x00 \xff -thing.. |
| 13:58 | <micheil_away> | that'd be very low. |
| 13:59 | <micheil_away> | I don't think that'd have much effect |
| 13:59 | <Cheery> | is that coming from the websocket protocol or is it the thing of TCP? |
| 13:59 | <micheil_away> | \x00 \xff is from the Websocket protocol |
| 14:00 | <karlushi> | *sigh* http://en.akihabaranews.com/54850/e-book/sharp-isalso-working-on-e-books-tech |
| 14:00 | <karlushi> | > Sharp new big e-Book thingy is their latest e-Book platform and e-Book format called here XMDF or ever-eXtending Mobile Document Format. |
| 14:00 | <karlushi> | > Sharp is here developing its own format based on XMDF |
| 14:01 | <Cheery> | micheil_away: because of \x00 and \xff, one won't be able to encode numbers in little endian. |
| 14:02 | <micheil_away> | I'm not sure on that. |
| 14:02 | <micheil_away> | another question for Hixie / HyBi |
| 14:03 | <Cheery> | though it'd be maybe good for the data to be in non-binary form when sent. |
| 14:04 | <Cheery> | for example, one could use base16 or base32 or base64 -numbers. |
| 14:05 | <Philip`> | Cheery: The protocol has length-prefixed binary frames |
| 14:05 | <Philip`> | which avoids the need for escaping |
| 14:06 | <Cheery> | Philip`: they're late addition? |
| 14:06 | <Cheery> | how do I enable those? |
| 14:06 | <Philip`> | They're not supported yet |
| 14:06 | <Philip`> | They're just there for compatibility with a future version that will support binary data |
| 14:07 | <Cheery> | good |
| 14:07 | <Cheery> | now I can use hexadecimals and then return on little endian representation when useful |
| 14:07 | <jgraham> | I wish someone would explain that to the people on the hybi list |
| 14:08 | <Philip`> | (I think the idea was that current servers will just skip those frames) |
| 14:08 | <jgraham> | They insist that websockets has refused to add binary frames |
| 14:09 | <jgraham> | Which is quite untrue; there is a clear timetable ("as soon as browsers support binary data") |
| 14:13 | <Cheery> | XsBddatatext herei9abcl9abcdef0, where \x00 and \xff not supported in strings. |
| 14:14 | <Cheery> | jgraham: browsers do not support binary data? |
| 14:15 | <jgraham> | Cheery: Not in javascript |
| 14:16 | <jgraham> | (I mean you can use strings of course, but it is painful) |
| 14:17 | <Cheery> | I guess I'll put my protocol to throw flat strings and integers for now. Could put in floating points and such, but they aren't necessary. |
| 14:21 | <hsivonen> | "However, it has been used successfully in a small number of internal business applications (also known as ‘dark matter’)." |
| 14:26 | <Cheery> | so. now I specified a protocol I can use before they'll come up with a real binary data. |
| 14:26 | <Cheery> | I'll encode strings and integers for now. |
| 14:27 | <Cheery> | picking character at once. |
| 14:28 | <Cheery> | if it's a character in '123456789', read the next characters as hexadecimal and treat it as an integer |
| 14:28 | <Cheery> | but.. |
| 14:29 | <Cheery> | if it's a character in 'abcdefghi', read the next characters as hexadecimal, and take that count of string in the next characters. |
| 14:32 | <Cheery> | I may or may not provide 4 characters to mark up the protocol action. |
| 14:32 | <Cheery> | so it's like RPC. :) |
| 14:47 | <Cheery> | hm.. I wonder how websocket handles UTF-8 |
| 14:48 | <Philip`> | It doesn't handle UTF-8, it just handles Unicode text |
| 14:48 | <Philip`> | (which it handles by encoding as UTF-8) |
| 14:50 | <Cheery> | or hmm.. maybe I'll just resort to JSON: :) |
| 14:51 | <Cheery> | that's less error-prone. |
| 14:53 | <jgraham> | Yes, it seems simple unless you really need something else for e.g. perf. reasons |
| 14:54 | <Cheery> | well the thing is. if someone needs performance, there's no point using websockets. He'll need UDP. :) |
| 14:55 | <Philip`> | Depends how much performance they need |
| 14:55 | <Philip`> | and whether they are able to cope with packet loss |
| 15:40 | <hsivonen> | Interesting. Opera 10.53 on Windows tried to put tabs to the right of the app menu in order to save space, but Opera 10.60 puts the tabs under the menu |
| 15:41 | <hsivonen> | yet, in Opera 10.60, the trash icon doesn't go under the three OS window buttons although it would now fit there |
| 15:41 | <hsivonen> | deliberate or bug? |
| 15:41 | <hsivonen> | if deliberate, what convinced Opera no longer to try to compress the title bar and the tab bar as much as in 10.53? |
| 15:48 | <jgraham> | hsivonen: No idea. My 10.60 on Linux looks like you describe 10.53 as looking afaict |
| 15:53 | <hsivonen> | jgraham: whoa. For me on Ubuntu, Opera has never tried to compress the title bar and the tab bar |
| 15:53 | <hsivonen> | presumably because the window manager owns the title bar |
| 15:53 | <hsivonen> | and on Linux, the trash icon goes all the way to the right for me |
| 15:53 | <jgraham> | Oh |
| 15:54 | <jgraham> | I think I misunderstood your description |
| 15:54 | <jgraham> | I still have the system title bar |
| 15:54 | <hsivonen> | on Ubuntu, the tabs are to the right of the app menu, but the app menu isn't in the title bar |
| 15:55 | <jgraham> | (but then I even have that in Chromium where I had to turn it back on explicitly iirc) |
| 15:55 | <hsivonen> | while in 10.53 on Windows, the app menu was in the title bar *and* the top of the tab bar went into the title bar and to the right of the menu |
| 15:56 | <hsivonen> | Chrome doesn't integrate well with Radiance or Ambiance |
| 15:56 | <hsivonen> | it's even worse than it used to be with Human |
| 15:57 | <hsivonen> | Firefox isn't perfect, either: https://bugzilla.mozilla.org/show_bug.cgi?id=580970 |
| 15:58 | hsivonen | notes that Opera 10.60 fixed the scrollbar appearance on Gnome, which is nice |
| 15:58 | <hsivonen> | Chrome still has ugly scrollbars |
| 15:58 | <daedb> | hsivonen: The trash can does go under the os window buttons in 10.60 (on Windows), at least for me. |
| 15:59 | <hsivonen> | daedb: interesting. for me it doesn't. neither on Windows 7 nor on XP |
| 15:59 | <Workshiva> | Can you get chrome to show stacktraces in js console? |
| 16:00 | <daedb> | hsivonen: I'm still on Vista, but I don't think its' supposed to be different in Vista and 7 so I dunno what's going on here :) |
| 16:01 | <hsivonen> | fwiw, my Windows 7 is running without D3D, so I have non-glass window decorations |
| 16:03 | <daedb> | Maybe that's the difference then, since I have glass on. |
| 16:11 | <boblet> | hey all, does anyone have an opinion on my use of <mark> to wrap in-document permalink #s? e.g. hover over any of the section titles: http://oli.jp/2009/html5-faq/ |
| 16:13 | <Lachy> | boblet, that doesn't seem like the intended purpose of <mark> |
| 16:16 | <boblet> | Lachy: yeah, I’m wondering myself. however it’s not text that is important, is highlighted for reference purposes, and is only relevant when you want a chapter permalink to copy |
| 16:16 | <boblet> | hrm |
| 16:17 | <Lachy> | I think you're stretching the meaning well beyond any intended meaning. |
| 16:17 | <boblet> | ideally I’d add them via generated content, but no code in gen content & I don’t want to link the whole heading |
| 16:18 | <boblet> | Lachy: hehe, it happens when you think about stuff too much (at least for me) |
| 16:18 | <boblet> | Lachy: thanks for your input |
| 16:19 | <Lachy> | the problem is that those links aren't generally any more relevant in that context, than any other link on the page. |
| 16:19 | <Lachy> | and so marking them doesn't really serve a useful purpose to the user |
| 16:20 | <boblet> | I was treating the relevance as action- rather than information-specific (the action of getting a permalink) |
| 16:20 | <boblet> | good point |
| 16:21 | <Lachy> | no, mark is dependant on the informational context, not the user's current input action. |
| 16:21 | <boblet> | I wonder how others usually do this — should check Joe Clark’s site I guess |
| 16:23 | <boblet> | Lachy: how would you expose section or comment permalinks? just using <a> huh? |
| 16:23 | <Lachy> | I've seen similar things done on other sites just using <a href="#" class="...">¶</a> |
| 16:25 | <Lachy> | boblet, e.g. http://www.tbray.org/ongoing/When/201x/2010/07/13/Lock-Free-Array-Update |
| 16:25 | <boblet> | yeah |
| 16:26 | <boblet> | thinking too much again. harumph |
| 16:29 | <AryehGregor> | Why aren't hidden form controls barred from constraint validation? |
| 16:30 | <zcorpan_> | hidden how? |
| 16:36 | <AryehGregor> | With the hidden attribute. |
| 16:37 | <zcorpan_> | i think that was discussed on the list a few weeks or months ago |
| 16:39 | <zcorpan_> | if we make hidden="" make it barred, then people can do silly stuff like <input type=url hidden style=display:inline> |
| 16:39 | <zcorpan_> | maybe it's better to have a separate attribute |
| 16:47 | <foolip> | Does anyone else remember seeing a JavaScript WebSRT parser the last few weeks? |
| 16:47 | <foolip> | Can I have dreamt it? Surely my dreams aren't that boring! |
| 16:48 | <jgraham> | foolip: Clearly it's a sign that you should write one |
| 16:49 | <foolip> | meh, I remember thinking "great, now I don't have to write one" |
| 16:50 | <jgraham> | Well dreams often make reality diaappointing |
| 16:50 | <jgraham> | sigh |
| 16:50 | <jgraham> | disappointing |
| 16:53 | <foolip> | gah, now searching for it turns up my own questions about it |
| 16:53 | <foolip> | next time what I just wrote here I guess :) |
| 16:53 | <Philip`> | Maybe http://www.storiesinflight.com/js_videosub/index.html ? |
| 16:54 | <jgraham> | http://www.delphiki.com/html5/video/ mentions WebSRT support too |
| 16:55 | <foolip> | jgraham, yes, I just found that one |
| 16:56 | <foolip> | delphiki is a regex parser |
| 16:57 | <foolip> | http://www.storiesinflight.com/js_videosub/includes/videosub-0.9.5.js is doing string splitting |
| 16:58 | <foolip> | so still none using the tokenizer+parser model in the spec |
| 17:00 | <Philip`> | People writing parsers with a few lines of regexps instead of implementing the 126-step algorithm in the spec? |
| 17:01 | <Philip`> | I am shocked |
| 17:01 | <foolip> | so did I |
| 17:01 | <foolip> | but I want the parser in the spec so I can compare it to e.g. the mplayer parser and leave spec feedback |
| 17:06 | <Philip`> | Looks like it should be straighforward but really boring to implement |
| 17:06 | <foolip> | exactly, so why won't someone else do it for me :) |
| 17:12 | <zcorpan_> | something for a summer intern |
| 17:26 | <jgraham> | It would be a bit easier if Hixie didn't use goto everywhere |
| 17:30 | <Philip`> | You just need to mentally decompile it into pseudocode, and then it's much easier to understand |
| 17:31 | <Philip`> | (Structured pseudocode with loops, in particular) |
| 17:31 | <jgraham> | Yeah, but there's no good reaon it couldn't start out that way |
| 17:34 | <Philip`> | That probably would help, at least for people who appreciate Dijkstra's advice, i.e. everyone in the world |
| 17:35 | <Philip`> | It's nice if you can look at a line in the algorithm and statically determine "how might I have got here?" |
| 18:39 | <dandaman> | so im working on this site where a lot of the time clicking a button will hide and then reveal another table(using inline styles with javascript) |
| 18:39 | <dandaman> | the problem is, everytime i do that, the table its on keeps getting resized |
| 18:39 | <dandaman> | to fit the new content |
| 18:39 | <dandaman> | which is fine |
| 18:39 | <dandaman> | but i'd rather it not change around, is there a way to make it fit the largest thing that will be shown without setting the overall table to a set amount of pixels |
| 18:40 | <dandaman> | (the largest thing begins hidden) |
| 18:40 | <TabAtkins> | No. |
| 18:40 | <TabAtkins> | You have to do measurements and set the size explicitly for that use-case. |
| 18:40 | <dandaman> | not the answer i was looking for, but if it isnt possible then sad face |
| 18:40 | <dandaman> | thanks though |
| 18:41 | <TabAtkins> | np |
| 18:41 | <dandaman> | problem is, its for a mobile page so the pixel size is going to be different every time |
| 18:41 | <TabAtkins> | You can duplicate the content in something off-screen and measure it there. |
| 18:56 | <dandaman> | TabAtkins: have any idea about the touchstart and touchend events for mobile browsers? |
| 19:05 | <TabAtkins> | Nope. |
| 19:36 | <gsnedders> | Dojo 1.5 is out. I guess I should rejoice. |
| 19:39 | <dandaman> | can anyone recommend me an html5 tutorial? |
| 19:39 | <miketaylr> | sure |
| 19:39 | <TabAtkins> | What are you looking to learn, specifically? |
| 19:40 | <dandaman> | making stuff look good, like buttons that look like tabs through random borders |
| 19:40 | <dandaman> | transitioning between pages |
| 19:40 | <dandaman> | (preferably slide transitions since this site will be on mobile phones) |
| 19:40 | <TabAtkins> | Those have next to nothing to do with HTML5. ^_^ |
| 19:40 | <dandaman> | i thought they were related |
| 19:40 | <dandaman> | what do they have to do with? |
| 19:40 | <TabAtkins> | CSS, and general web design. |
| 19:40 | <dandaman> | so i should be looking into a css3 tutorial |
| 19:41 | <dandaman> | right? |
| 19:41 | <miketaylr> | CSS transitions? |
| 19:49 | <dandaman> | miketaylr: tes |
| 19:49 | <dandaman> | yes* |
| 19:49 | <miketaylr> | dandaman: opera has some good resources, i.e. http://dev.opera.com/articles/view/css3-transitions-and-2d-transforms/ |
| 19:49 | <dandaman> | thanks |
| 19:54 | <Cheery> | anyone tried music synthesis on javascript? |
| 19:54 | <Cheery> | (the audio plugin has been around a while, so I wonder.. why not?) |
| 19:59 | <paul_irish> | Cheery: http://weblog.bocoup.com/web-audio-all-aboard and http://weblog.bocoup.com/worlds-1st-html-audio-generated-music |
| 20:02 | <Cheery> | Wth? he doesn't even have samples? |
| 20:04 | <paul_irish> | i'm sure there are samples linked but the problem is you need a custom build of firefox as this is all an experimental API |
| 20:04 | <paul_irish> | http://www.w3.org/2005/Incubator/audio/ is the group where they are doing work on this front |
| 20:05 | <Cheery> | okay. |
| 20:05 | <Cheery> | that's a bit more than what I thought about. |
| 20:05 | <Cheery> | but it's all right. |
| 20:06 | <Cheery> | web is slowly getting there where C64 already were. |
| 20:06 | <Cheery> | ;P |
| 20:17 | <AryehGregor> | Okay, so the spec says that this should fail to submit: data:text/html,<!doctype html><body onload="document.getElementById('a').value='foo'"><form><input id=a maxlength=2><input type=submit></form> |
| 20:17 | <AryehGregor> | And this: data:text/html,<!doctype html><form><input id=a><input type=submit></form><a href="" onclick="document.getElementById('a').maxLength = 2; return false">Enter "foo" into the input, click here, then try to submit</a> |
| 20:17 | <AryehGregor> | Opera submits anyway, and this seems best for back-compat. |
| 20:17 | <AryehGregor> | Chrome doesn't submit, per spec, and has seemingly gotten at least one complaint. |
| 20:27 | <wirepair> | works in firefox |
| 20:27 | <wirepair> | appends a ? to the end of the url too |
| 20:27 | <AryehGregor> | Firefox doesn't implement HTML5 forms, so, yeah. |
| 20:28 | <wirepair> | ah. |
| 20:28 | <AryehGregor> | It will submit in all legacy browsers. |
| 20:28 | <AryehGregor> | (At least, as far as I know, no release version of Firefox up to and including Firefox 4.0 beta implements HTML5 form *validation*.) |
| 20:33 | <gsnedders> | It'd be nice to have a collected IDL in an appendix. |
| 20:35 | <gsnedders> | Hixie: "An error occured while submitting your comment. Please let ian⊙hc know." |
| 20:35 | <Hixie> | what section? |
| 20:36 | <gsnedders> | Nothing in error log, so nothing more to say. |
| 20:36 | <gsnedders> | #index |
| 20:36 | <Hixie> | people keep getting errors but i can't work out why |
| 20:36 | <gsnedders> | This is in multipage |
| 20:37 | <Hixie> | oh i see why |
| 20:37 | <Hixie> | you don't have a bugzilla account |
| 20:37 | <gsnedders> | Uh, yes I do. |
| 20:37 | <Hixie> | ok, it isn't geoffers⊙gc |
| 20:37 | <gsnedders> | That is true |
| 20:38 | <Hixie> | i should find a way to handle that case |
| 20:39 | <Hixie> | (it's trying to cc you but failing) |
| 20:39 | <Hixie> | i wonder if that's what other people have run into |
| 20:40 | <AryehGregor> | Is it supposed to use your Bugzilla account somehow? It always files me as WHATWG Contributor. |
| 20:41 | <Hixie> | it cc's your account if you're logged in to the spec's system |
| 20:47 | <Hixie> | gsnedders: try again? |
| 20:49 | <gsnedders> | Hixie: You now haev another bug :) |
| 20:49 | <Hixie> | it worked? cool |
| 20:49 | <Hixie> | thanks |
| 20:49 | <Hixie> | i made it so it looks for the message about not knowing the e-mail address and if it sees it just tries again without ccing you |
| 20:49 | <gsnedders> | Hixie: Now, go and fix the other bug :P |
| 20:49 | <Hixie> | websocket first |
| 21:15 | <MikeSmith> | GPHemsley: you gave me a heads-up a while back that some of the circled-i links from http://dev.w3.org/html5/markup/ back to the HTML5 spec were broken |
| 21:16 | <MikeSmith> | fwiw, I've fixed them all now |
| 21:27 | <volkmar> | i saw a tweet from @html5 about spec links for forms attributes but it looks like the link is broken |
| 21:27 | <volkmar> | or i'm missing something |
| 21:29 | <Philip`> | volkmar: http://twitter.com/html5/status/19280941985 ? |
| 21:29 | <Philip`> | MikeSmith: ^ |
| 21:30 | <volkmar> | Philip`: yep, i got "sorry not found" |
| 21:30 | <MikeSmith> | hmm |
| 21:30 | <Philip`> | I guess the list archive might just be slow |
| 21:31 | <MikeSmith> | I have had the same problem with other mail-archive links recently |
| 21:31 | <jgraham> | Hixie: I see what you mean about HyBi being quiet until you post... alhough I suppose it could be a coincidence (since the volume was picking up a bit over the last few days) |
| 21:31 | <MikeSmith> | I will let the W3C systems team know |
| 21:31 | <jgraham> | (but today has been absurd) |
| 21:34 | <MikeSmith> | volkmar: all of the twitter @html5 links go to here: |
| 21:34 | <MikeSmith> | to individual messages here: |
| 21:34 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-html-diffs/latest |
| 21:35 | <volkmar> | MikeSmith: ok, thanks |
| 21:36 | <MikeSmith> | volkmar: btw, do you know if there's been any discussion at Mozilla yet about implementing the HTML5 context-menu feature? |
| 21:36 | <MikeSmith> | http://dev.w3.org/html5/spec/interactive-elements.html#context-menus I mean |
| 21:37 | <volkmar> | MikeSmith: not i've heard of |
| 21:37 | <volkmar> | but i'm surely not the person to ask |
| 21:37 | <volkmar> | i'm mostly working on forms |
| 21:38 | <MikeSmith> | volkmar: is there a master page at the mozilla wiki that lists implementation status/plans for features-yet-unimplemented |
| 21:38 | <MikeSmith> | i mean, like your forms-feature page |
| 21:40 | <volkmar> | MikeSmith: the best way to know that is bugzilla |
| 21:40 | <volkmar> | https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc=context-menu&short_desc_type=casesubstring&resolution=---&resolution=DUPLICATE |
| 21:41 | <volkmar> | https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc=context-menu&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&short_desc_type=casesubstring&resolution=--- |
| 21:41 | <volkmar> | ^ this one is better |
| 21:41 | <volkmar> | so, i would say no one is working on it |
| 21:41 | <MikeSmith> | cool |
| 21:41 | <MikeSmith> | thanks |
| 21:41 | <MikeSmith> | yeah |
| 21:42 | <MikeSmith> | I do see this, though - |
| 21:42 | <Hixie> | jgraham: it's happened three or four times |
| 21:42 | <MikeSmith> | https://bugzilla.mozilla.org/show_bug.cgi?id=578849 |
| 21:42 | <MikeSmith> | volkmar: Google Chrome team seems to also be working on a context-menu API |
| 21:43 | <MikeSmith> | it makes me wonder if developers are browser projects are actually aware of the context-menu feature already in HTML5 |
| 21:43 | <Hixie> | uri? |
| 21:44 | MikeSmith | realize that bug is for a jetpack feature |
| 21:44 | <Hixie> | yeah |
| 21:44 | <MikeSmith> | Hixie: will look now |
| 21:44 | <Hixie> | i don't think that's web-facing |
| 21:44 | <TabAtkins> | Hixie: We have a context-menu API for Chrome Extensions. |
| 21:44 | <Hixie> | sure, but that's not web-facing either |
| 21:44 | <othermaciej> | is HTML5's built-in context menu support not good enough for Chrome Extensions? |
| 21:44 | MikeSmith | was going to say, about the Chrome thing, I think TabAtkins is on top of it already |
| 21:45 | <othermaciej> | we are considering just using the HTML5 feature for Safari Extensions but if it's not going to be good enough we may as well invent our own thing too |
| 21:45 | <MikeSmith> | othermaciej: from what I've seen of the Chrome Extensions context-menu API so far, it looks like it could be done using what's in the HTML5 spec instead |
| 21:46 | <MikeSmith> | but maybe TabAtkins has some feedback from the dev team about why it may not actually be |
| 21:46 | <dglazkov> | aboodman: ^^^ |
| 21:47 | <dglazkov> | aboodman: <-- can tell you _everything_ |
| 21:48 | MikeSmith | is anxious to hear from aboodman |
| 21:49 | <MikeSmith> | anyway, if what's in the HTML5 spec is not sufficient, it'd seem like a way to address that would be for implementors to provide some feedback to help make it sufficient |
| 21:50 | <Hixie> | yeah |
| 21:50 | <MikeSmith> | especially given the fact that we already know a lot of stuff that starts out not-web-facing eventually does become web-facing |
| 21:50 | <MikeSmith> | e.g., stuff starting out only in XUL etc. |
| 21:53 | MikeSmith | reads "Please disallow "javascript:" URLs in browser address bars" message |
| 21:55 | <MikeSmith> | btw, the W3C mailing-list-archive Archived-At: http://www.w3.org/mid/ thingy appears to be broken at the moment |
| 22:03 | <TabAtkins> | MikeSmith: (re: non-web-facing stuff migrating to web-facing) Indeed, especially since Chrome Extensions are only *barely* not web-facing - they're just web pages that are given access to a few specialized js apis. |
| 22:12 | <MikeSmith> | TabAtkins: yep |
| 22:43 | <zcorpan_> | Hixie: thanks for addressing websocket feedback |
| 22:46 | <Lachy> | nice security bug in Safari http://jeremiahgrossman.blogspot.com/2010/07/i-know-who-your-name-where-you-work-and.html |
| 22:46 | <AryehGregor> | You'd think people'd be more careful when implementing such obviously security-sensitive stuff. :/ |
| 23:18 | <Hixie> | zcorpan_: np |
| 23:32 | <JonathanNeal> | What's a good website to run outliner on? |
| 23:32 | <TabAtkins> | Try html5doctor.com |
| 23:34 | <JonathanNeal> | Excellent, that will help me debug. Thank you. |
| 23:37 | <zcorpan_> | wonder if i should point willy to the whatwg wiki |
| 23:43 | <Hixie> | zcorpan_: for what? |
| 23:43 | <JonathanNeal> | woot http://sandbox.thewikies.com/html-templates/outliner.php?url=http://html5doctor.com |
| 23:44 | <micheil> | Hixie: would it be an idea for the websocket protocol spec to have it's version incremented to draft77, as to avoid any confusion between 76 (which is in chrome 5), and > 76 |
| 23:45 | <Hixie> | it's version is r5190 |
| 23:45 | <micheil> | or would it be possible to introduce a Sec-WebSocket-Version, which indicates what version of the protocol is supported? |
| 23:45 | <Hixie> | 76 is out of date |
| 23:45 | <Hixie> | loooong out of date |
| 23:45 | <micheil> | as there's no other way to detect |
| 23:45 | <Hixie> | there's only one version |
| 23:45 | <Hixie> | nothing to detect |
| 23:45 | <micheil> | okay, well, yeah |
| 23:46 | <micheil> | but there are various versions in various browsers |
| 23:46 | <Hixie> | (s/it's/its/) |
| 23:46 | <Hixie> | (yikes) |
| 23:46 | <Hixie> | well, sure |
| 23:46 | <Hixie> | but they'll go away |
| 23:46 | <micheil> | eg 75 in Safari 5 and 76 in latest chrome |
| 23:46 | <Hixie> | doesn't help anyone if i add Sec-WebSocket-Version today for that problem |
| 23:47 | <Hixie> | and you can easily distinguish the two if you really want to support safari 5 |
| 23:47 | <Hixie> | just look at what headers it has |
| 23:47 | <micheil> | well, we can already switch 75 and 76 based on the Sec-* headers |
| 23:47 | <micheil> | but for > 76 like, r5190, we can't do that. |
| 23:47 | <Hixie> | *shrug* |
| 23:47 | <micheil> | and as r5190 isn't yet implemented by a client, it would be possible to add a Sec-WebSocket-Version |
| 23:47 | <Hixie> | the idea is for there to be a single version |
| 23:48 | <micheil> | true, but browsers are never ideal |
| 23:48 | <Hixie> | adding features just to be able to distinguish test versions for the few months before we're done is pointless |
| 23:48 | <Hixie> | it would mean bytes being included in requests for decades after it's useful |
| 23:48 | <micheil> | hm.. okay |
| 23:49 | <AryehGregor> | Do you expect to be completely done in a few months? |
| 23:49 | <Hixie> | the best thing to do if you want to solve the problem is to implement the updated protocol in all the browsers |
| 23:49 | <Hixie> | AryehGregor: we're more or less done now, as far as i can tell |
| 23:49 | <micheil> | Hixie: I'd be way out of my depth there. |
| 23:49 | <AryehGregor> | k, good to know. |
| 23:49 | <micheil> | considering I'm a JavaScript programmer, not a C / C++ programmer |
| 23:51 | <Hixie> | that's solvable :-) |
| 23:51 | <zcorpan_> | Hixie: for documenting pros and cons of websocket proposals |
| 23:51 | <Hixie> | zcorpan_: if he needs a wiki, he's welcome to use the websocket one |
| 23:52 | <Hixie> | zcorpan_: but i believe the hybi wg have their own |
| 23:54 | <JonathanNeal> | Hey Hixie, whatcha think? |
| 23:55 | <Hixie> | about? |
| 23:55 | <zcorpan_> | Hixie: uh, don't you think you got r5190 backwards? |
| 23:55 | <JonathanNeal> | ^ http://sandbox.thewikies.com/html-templates/outliner.php?url=http://html5doctor.com |
| 23:55 | <zcorpan_> | Hixie: surely we don't want the controls to appear on the top when there are captions |
| 23:55 | <zcorpan_> | Hixie: instead the captions should move so they don't appear behind the controls |
| 23:56 | <Hixie> | hm |
| 23:56 | <Hixie> | the captions can be positioned precisely |
| 23:56 | <Hixie> | i suppose we could make the captions avoid the controls when they're line-snapped controls |
| 23:57 | <zcorpan_> | the captions get moved if there are already captions where you want to position them precisely, don't they? |
| 23:57 | <Hixie> | yeah, true |
| 23:59 | <zcorpan_> | i think i'd just move the captions up while the controls are visible, as if the root box had margin-top: -(height-of-controls) |