| 00:07 | <jamesr_> | heycam: are you around? |
| 00:14 | <heycam> | hi jamesr_ |
| 00:14 | <jamesr_> | heycam: i heard a rumor you wrote some spec text for mozRequestAnimationFrame. is that true and if so where could i find it? i have some feedback on the proposal |
| 00:15 | <heycam> | jamesr_, yeah i started writing it up. let me find it... |
| 00:17 | <heycam> | http://people.mozilla.org/~cmccormack/anim-timing/Overview.html |
| 00:18 | <heycam> | that it claims script-based and native animations can be synchronized might be a bit strong. there might've been some issues there -- but it's been a couple of months since i've looked at it, so it's swapped out of my head atm... |
| 00:19 | <heycam> | that write-up doesn't include the event-based way of doing it, only callback functions |
| 00:20 | <jamesr_> | yes, i don't think the event-based way is very useful |
| 00:21 | <heycam> | I will try to bring it a WG soon so that there can be somewhere official to send comments. but in the meantime, here is fine. |
| 00:22 | <jamesr_> | heycam: ok. i'm implementing essentially that without the timestamps |
| 00:22 | <jamesr_> | which WG will it be? |
| 00:22 | <jamesr_> | (implementing in WebKit, that is) |
| 00:23 | <heycam> | without the timestamps? so the callback script looks up animationStartTime? |
| 00:24 | <heycam> | I did think of dropping that argument at one point; can't remember why I decided against it. |
| 00:24 | <jamesr_> | without the parameter to the callback and without window.animationStartTime |
| 00:24 | <jamesr_> | so just void requestAnimationFrame([callback]) where callback is void sample() |
| 00:24 | <heycam> | oh. so how does the callback get accurate timing about when it's being sampled for? (or it doesn't, i guess.) |
| 00:25 | <jamesr_> | it don't :) |
| 00:25 | <heycam> | is the issue that it's never going to be really accurate, because who knows how long the script will run for |
| 00:25 | <jamesr_> | yup |
| 00:25 | <heycam> | so you may as well just let the script just look at Date() or whatever |
| 00:25 | <jamesr_> | indeed. i'm not sure that the UA can make a better guess at the time to use than the script author can |
| 00:25 | <heycam> | it might be that the script author is never going to put in the effort to determine average callback function running times |
| 00:26 | <heycam> | but that the UA could do so reasonably easily |
| 00:26 | <heycam> | so the UA still might be able to give a reasonable approximation, with a rolling average |
| 00:26 | <jamesr_> | i don't think that average callback function running time isn't a useful input |
| 00:26 | <jamesr_> | but having a callback system instead of using setTimeout() is a big improvement, so i'm still very interested in the proposal |
| 00:26 | <heycam> | right, i think that is the more important aspect of it too |
| 00:27 | <heycam> | in SVG, you have SVGElement.getCurrentTime() (i think it is), which gives the current document time |
| 00:27 | <heycam> | (i.e. starting from 0s) |
| 00:27 | <jamesr_> | what's the relationship between that and Date.now()? |
| 00:27 | <heycam> | so at least if you wanted to sync with SVG animations, you could do something... |
| 00:27 | <heycam> | document time starts at 0 from the load event dispatch |
| 00:27 | <heycam> | and it's actually pausable |
| 00:28 | <heycam> | or pauseable |
| 00:28 | <jamesr_> | O_o |
| 00:28 | <heycam> | :) |
| 00:28 | <heycam> | that's SMIL for you |
| 00:28 | <heycam> | anyway, i doubt many people use that |
| 00:28 | <jamesr_> | no wonder SMIL has taken over the web |
| 00:28 | <heycam> | ^_^ |
| 00:28 | <jamesr_> | anyway do you know what WG this would be discussed in? i want to make sure it's one i subscribe to |
| 00:29 | <heycam> | it would be good to have a mailing list conversation about the benefits or not of the callback time argument |
| 00:29 | <heycam> | to me, Web Apps seems most appropriate |
| 00:29 | <jamesr_> | yeah, i'd like for more people to weigh in |
| 00:29 | <heycam> | but they've got a pretty big charter |
| 00:29 | <jamesr_> | the last thread about this was on public-webapps |
| 00:29 | <heycam> | dunno how amenable they are to just adding things |
| 00:29 | <heycam> | oh, ok |
| 00:29 | <jamesr_> | and someone from w3c requested that public-fx be cc'd on such discussions |
| 00:29 | <heycam> | oh right, probably doug |
| 00:30 | <heycam> | i think doug was thinking that the FX TF (and thus either CSS or SVG WGs) were better than web apps |
| 00:30 | <heycam> | because it deals with animation stuff |
| 00:30 | heycam | shrugs |
| 00:30 | <jamesr_> | yeah, but not many people are on public-fx |
| 00:32 | <heycam> | anyway, whenever that gets decided I can let you know |
| 00:32 | <heycam> | might mail some W3C people now to get the ball rolling |
| 00:32 | <jamesr_> | cool |
| 00:33 | <jamesr_> | i'm on public-webapps and public-fx so i should see any emails you send to one/both of those and will reply with feedback |
| 00:33 | <heycam> | ok, great |
| 00:33 | <jamesr_> | and will probably have a webkit-prefixed implementation to play with by that time as well |
| 00:34 | <heycam> | nice! |
| 01:00 | <MikeSmith> | http://emobile.jp/products/hw/s31hw/ |
| 01:00 | <MikeSmith> | Android handset that doubles as a 7.2Mbps wifi router |
| 01:02 | <MikeSmith> | creates access point that up to 5 devices can connect to at same time |
| 01:09 | <nattokirai> | 4 |
| 01:10 | <TabAtkins> | I just figured out yesterday, after spending several days refusing to buy the expensive wifi at a hotel, that my phone can become a wifi router. |
| 01:17 | <AryehGregor> | Hixie, what sort of tests do you want for <http://www.w3.org/Bugs/Public/show_bug.cgi?id=10624>;? Manual tests that ask the user to make backwards selections? Tests of the whole anchorNode/anchorOffset/focusNode/focusOffset functionality, even the parts I didn't touch? |
| 01:17 | <AryehGregor> | It seems like it can't be programmatically tested without support for extend(). |
| 01:18 | <AryehGregor> | (in which case manual tests would still be desirable to check that it actually creates the expected selections when the user clicks and drags forwards or backwards, and those could be automated if we had a way to synthesize clicks or keypresses) |
| 01:19 | <TabAtkins> | Bwahaha, from @atopal: "Hilarious: people are threatening to switch to Firefox because of Goole's H.264 move." |
| 01:20 | <AryehGregor> | lol. |
| 01:26 | <roc> | jamesr_, heycam: the animationStartTime is also useful for keeping multiple JS animations in sync |
| 01:27 | <roc> | having all animations able to use the same time value seems useful even if we don't know exactly when the final frame will be presented |
| 01:29 | <roc> | jamesr_: actually I'd be disappointed if webkitRequestAnimationFrame doesn't support webkitAnimationTime or something like that from the beginning |
| 01:29 | <roc> | because if you don't, then we'll never be able to do it |
| 01:30 | <jamesr_> | roc: i think if you have multiple JS animations you want to keep in sync you would update them all in the same callback |
| 01:30 | <roc> | but you might be using different libraries |
| 01:30 | <MikeSmith> | TabAtkins: really? which phone? |
| 01:30 | <roc> | or have imported multiple scripts |
| 01:31 | <jamesr_> | but if they use Date.now() then it should still work |
| 01:31 | <roc> | no because multiple calls to Date.now() will return different results |
| 01:31 | <jamesr_> | ah, true |
| 01:31 | <heycam> | if you have written all the different callbacks, you can coordinate this saved animation frame time somewhere |
| 01:31 | <jamesr_> | so the problem with animationTime is that it's not useful for 'native' animations |
| 01:31 | <heycam> | but i guess it's just if you have independent scripts that it matters |
| 01:32 | <jamesr_> | you can set something on the window yourself, i suppose |
| 01:32 | <roc> | jamesr_: yes it is |
| 01:32 | <TabAtkins> | MikeSmith: Nexus S. |
| 01:32 | <jamesr_> | i don't think it is in our impl |
| 01:32 | <roc> | heycam: coordinating a single saved animation time with multiple callbacks is pretty hard |
| 01:32 | <roc> | jamesr_: it wasn't hard in our implementation |
| 01:33 | <roc> | why would it be hard in yours? |
| 01:33 | <heycam> | roc, hmm you would need to know which is the "first" callback, so that it could store the current time? |
| 01:33 | <roc> | right |
| 01:33 | <roc> | and there is no way to know that |
| 01:33 | <jamesr_> | roc: i actually implemented it |
| 01:33 | <jamesr_> | but the behavior wasn't what we wanted |
| 01:33 | <roc> | can you explain in more detail? |
| 01:33 | <jamesr_> | i can probably explain better in long form (i.e. email) |
| 01:33 | <jamesr_> | busy atm |
| 01:34 | <roc> | that'd be great |
| 01:41 | <Hixie> | AryehGregor: yeah i'd go for a lot of manual tests |
| 01:52 | <MikeSmith> | seems that changes are still being made for ES 5.1 https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003882.html |
| 02:24 | <Sirisian> | Is Ian Fette here? |
| 02:28 | <jamesr_> | nope |
| 02:30 | <Sirisian> | darn. He's the WebSocket editor. Been wondering why there's no binary protocol yet after all this time. IRC stalking is hard :\ |
| 02:34 | <hober> | it's after ordinary (Pacific Time) business hours; don't be surprised that Googlers aren't around |
| 02:35 | <Sirisian> | Yeah |
| 02:41 | <Sirisian> | hober, do you know what name he uses? |
| 02:41 | <Sirisian> | So I can recognize him when he joins |
| 02:41 | <Hixie> | ianfette, but try #chromium instead, he's more often there i believe |
| 02:41 | <Sirisian> | I just joined there |
| 02:42 | <Sirisian> | oh I see that's the name he uses |
| 02:42 | Sirisian | plays the waiting game |
| 02:43 | <Sirisian> | oddly enough I built an IRC bot a long time ago that alerts me when a person joins IRC. I could probably use it for this occasion :/ |
| 02:44 | <heycam> | Sirisian, irc clients often have that functionality built in. try "/notify ianfette". |
| 02:46 | <jamesr_> | you could email |
| 02:46 | <Sirisian> | someone just said that |
| 02:49 | <cutepy> | hi, my i have a project to create a document sharing system. I would like to know how to convert pdf files uploaded by users to html |
| 02:52 | <heycam> | cutepy, you might try http://code.google.com/p/wkhtmltopdf/ or http://princexml.com/ |
| 02:58 | <cutepy> | does any one know how to convert pdf to html 5 using HTML5Lib |
| 07:04 | <hsivonen> | AryehGregor, othermaciej: I believe the patent grant you want is http://www.webmproject.org/license/bitstream/ |
| 07:05 | <othermaciej> | hsivonen: a link to that was posted earlier; thanks for mentioning it again |
| 07:18 | <MikeSmith> | this looks like a rare event |
| 07:18 | <MikeSmith> | *this looks like one of those rare conferences that might actually be worth going out of one's way to attend: |
| 07:18 | <MikeSmith> | http://www.wikicfp.com/cfp/servlet/event.showcfp?eventid=12537©ownerid=9119 |
| 07:18 | <MikeSmith> | maybe |
| 07:20 | <MikeSmith> | by way of Allen Wirfs-Brock blog: http://www.wirfs-brock.com/allen/posts/57 |
| 07:20 | <MikeSmith> | Portland |
| 07:22 | <MikeSmith> | that and http://splashcon.org/2011/cfp/due-april-08-2011/101-wavefront |
| 07:22 | <MikeSmith> | ACM Splash Wavefront |
| 07:25 | <MikeSmith> | actually the Wavefront one looks even more interesting |
| 07:25 | <MikeSmith> | "The Wavefront program is looking for submissions about real systems from working software developers, not only academic researchers." |
| 07:33 | <MikeSmith> | program commitee: Allen Wirfs-Brock, Alex Russell, Brendan Eich, Dean Tribble, Douglas Crockford, Ward Cunningham |
| 08:06 | MikeSmith | now notices that Adam Barth and Collin Jackson on the program committee for USENIX WebApps conference |
| 08:06 | <MikeSmith> | http://www.usenix.org/events/webapps11/cfp/ |
| 08:43 | <annevk> | a search for roc does not give me his blog |
| 08:43 | <annevk> | waddup Google? |
| 08:44 | <annevk> | someone else found the Mark Pilgrim quote: http://weblogs.mozillazine.org/roc/archives/2010/03/amor_robustum.html |
| 08:45 | <annevk> | wait no, that's not the quote |
| 08:45 | <annevk> | damnit |
| 08:58 | <MikeSmith> | yippee |
| 08:59 | <MikeSmith> | Henri landed my patch to the htmlparser code in mozilla-central |
| 08:59 | <annevk> | W3C is contributing code to Mozilla? |
| 08:59 | <MikeSmith> | for the track element |
| 08:59 | <MikeSmith> | well, I am |
| 08:59 | <annevk> | omg so biased |
| 08:59 | <MikeSmith> | heh |
| 09:00 | <MikeSmith> | I'm happy to contribute code to Opera as well |
| 09:00 | <annevk> | :) |
| 09:00 | <kennyluck> | hah. I am biased towards Mozilla too. |
| 09:00 | <MikeSmith> | this one was a really minor "contribution" |
| 09:00 | <MikeSmith> | simple patch |
| 09:01 | <MikeSmith> | but hey, it's a start |
| 09:02 | <annevk> | finally I found it |
| 09:02 | <annevk> | http://krijnhoetmer.nl/irc-logs/whatwg/20100318#l-65 |
| 09:02 | <annevk> | some OCD right there |
| 09:05 | <MikeSmith> | Peter`: I thought fullscreen had already been implemented in Gecko |
| 09:06 | <MikeSmith> | btw, just found out about this today: |
| 09:06 | <MikeSmith> | https://wiki.mozilla.org/User:Jgoulie |
| 09:06 | <MikeSmith> | IAP HTML5 Game Programming Course and Competition |
| 09:06 | <Ms2ger> | Oh, Opera's implementing CSS gradients too? Cool |
| 09:07 | <annevk> | http://xkcd.com/846/ hahaha the tooltip-text song |
| 09:07 | <annevk> | Ms2ger, yeah |
| 09:07 | <MikeSmith> | course at MIT this week featuring Boris Zbarsky, Dave Herman, Chris Heilmann, more |
| 09:08 | <annevk> | Ms2ger, I tweeted about that somewhere last year |
| 09:08 | <annevk> | MikeSmith, wow |
| 09:08 | <Ms2ger> | Heh |
| 09:08 | <MikeSmith> | annevk: yeah |
| 09:08 | <MikeSmith> | they didn't advertise it very well |
| 09:09 | <annevk> | not even a blogpost at http://weblogs.mozillazine.org/bz/ |
| 09:09 | <Ms2ger> | Twitter is pretty much the last thing I get to, if I ever get to it |
| 09:09 | <MikeSmith> | hopefully they'll do it again (or something similar) soon |
| 09:12 | <annevk> | so many great quotes hidden in the IRC logs |
| 09:12 | <MikeSmith> | I wonder if that course was free |
| 09:13 | <MikeSmith> | if it was, that's pretty amazing |
| 09:13 | <annevk> | maybe rather than just highlighting we should have reddit-style +/- for lines |
| 09:13 | <Rik`> | Ms2ger: link for Opera gradients ? |
| 09:13 | <annevk> | and then some way to aggregate all the ones with lots of attention |
| 09:13 | <Rik`> | MikeSmith: I think the course was not well advertised because it has been decided very recently |
| 09:14 | <MikeSmith> | Rik`: I see |
| 09:14 | <MikeSmith> | would be good to do it again |
| 09:14 | <Ms2ger> | http://www.w3.org/mid/op.vo55l8rnbbdj5y⊙poo |
| 09:14 | <MikeSmith> | I guess they have limited space though |
| 09:16 | <Rik`> | yeah for gradients \o/ |
| 09:22 | <annevk> | Ms2ger, http://html5.org/specs/dom-range.html is up to date too now |
| 09:22 | <annevk> | Ms2ger, seems bitbucket fixed the issue |
| 09:24 | <annevk> | do people still want an Atom feed for HTML5 changes? |
| 09:24 | <Ms2ger> | It only worked once a day, IIRC |
| 09:24 | <annevk> | it should always just work, the problem was that the copy on bitbucket I was fetching was not always updated |
| 09:25 | <annevk> | I was thinking the other day that it would be pretty easy to generate an Atom feed now I get pings with check-in information from the specification |
| 09:26 | <Ms2ger> | The problem was, I think, that the bitbucket copy was cached as soon as you first wget'd it |
| 09:26 | <jgraham> | MikeSmith: You can always make binary patches for Opera :) e.g. http://my.opera.com/d.i.z./blog/2008/05/22/a-road-to-working-xpath |
| 09:26 | <Ms2ger> | Anyway, it works, so I'm happy :) |
| 09:26 | <Ms2ger> | And AryehGregor rocks |
| 09:27 | <annevk> | Ms2ger, well, from what I remember wget'ing it from somewhere else gave the same outdated information; including downloading it from the browser |
| 09:27 | <MikeSmith> | jgraham: hold god (just read that post) |
| 09:27 | <MikeSmith> | I seem to have remember reading that before |
| 09:27 | <MikeSmith> | wild stuff |
| 09:29 | <annevk> | he's actually doing QA on gradients among other things |
| 09:29 | <jgraham> | Yeah, our hiring process is tough ;) |
| 09:30 | <MikeSmith> | this reminds me of the guys in russia who hacked Opera Mini for benQ |
| 09:30 | <MikeSmith> | somehow |
| 09:30 | <MikeSmith> | I used to chat with those guys on IRC sometimes |
| 09:30 | <MikeSmith> | they added tabbed browsing |
| 09:30 | <MikeSmith> | and other stuff |
| 09:32 | <MikeSmith> | and then there's this http://besen.sourceforge.net/ |
| 09:33 | <MikeSmith> | complete ECMAScript Fifth Edition Implemention in Object Pascal |
| 09:34 | <Ms2ger> | What's next, an HTML parser in basic? |
| 09:44 | <jgraham> | Well, elisp |
| 09:46 | <jgraham> | hober: On the subject of which, how is that going? |
| 09:48 | <hsivonen> | Is Delphi itself still supported? |
| 11:08 | <annevk> | re that twitter discussion |
| 11:09 | <annevk> | I think I would pick RF tech over "standard" tech |
| 11:35 | <hsivonen> | :-( looks like Thunderbird doesn't support format=flowed for text/plain composition |
| 11:37 | <hsivonen> | Is Apple's Mail really special for its support for text/plain; format=flowed composition? |
| 11:38 | <hsivonen> | I'd have thought that by now others would have caught up |
| 11:44 | <annevk> | pretty sure Opera supports that |
| 11:49 | <hsivonen> | http://diveintohtml5.org/video.html will need some new notation for indicating that Chrome no longer supports H.264 as of a certain release |
| 11:53 | <annevk> | it seems my fever is finally reducing |
| 11:53 | <annevk> | teehee |
| 11:53 | <annevk> | time to fix html5-diff for tomorrow |
| 11:54 | <hsivonen> | whoa. I didn't know <a href> allows spaces around the URL |
| 11:54 | <hsivonen> | that seems scary, but I guess it's all compatible |
| 11:54 | <annevk> | they are stripped |
| 11:55 | <annevk> | hsivonen, http://html5.org/tools/web-apps-tracker?from=4991&to=4992 was the change -- long time ago |
| 11:56 | <annevk> | based on a request by Maciej: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9354 |
| 11:57 | <annevk> | I really like how easy that is to figure out |
| 12:00 | <MikeSmith> | http://twitter.com/#!/__DavidFlanagan/status/24953286842916865 "console.log() for Web Workers! https://github.com/davidflanagan/WorkerConsole/raw/master/WorkerConsole.js"; |
| 12:05 | <hsivonen> | Creative Commons license and even a NonCommercial one for software. FAIL. |
| 12:07 | <MikeSmith> | Dmitry Soshnikov's "ECMA-262-3 in detail" and "ECMA-262-5 in detail" are nice stuff |
| 12:07 | <MikeSmith> | http://jsmentors.com/Dmitry-A-Soshnikov.html |
| 12:08 | <MikeSmith> | and http://dmitrysoshnikov.com/ecmascript/javascript-the-core/ |
| 12:14 | <hsivonen> | Is there a Web site that checks if a browser supports WebM and tells the user to upgrade (if using an old version of a browser whose latest version supports WebM) or to switch browsers (if using a browser that doesn't have a WebM-enabled version) and that WebM-only Web sites can point visitors to? |
| 12:14 | <hsivonen> | Something like an outsourced help page so that every WebM-using site doesn't need to have one of its own |
| 12:15 | <Moo--> | hsivonen: If I were a web site developer I would not create WebM-only sites |
| 12:15 | <annevk> | hsivonen, if you make such a page I can host it on html5.org |
| 12:16 | <Moo--> | hsivonen: also, could it possible to have automatic plug-in download like Chrome Frame which makes IE/Safari download the related WebM-plugin? "This pages need the following plug-in to play the video..." |
| 12:17 | <annevk> | only 100 check-ins since last time |
| 12:17 | <annevk> | with about 4 noteworthy changes |
| 12:18 | <annevk> | admittedly there is a new global attribute, new element, and a new value for dir="", but still overall it confirms once again HTML5 is done |
| 12:19 | <hsivonen> | Moo--: We need authors who are gutsy enough to go WebM-only. |
| 12:19 | <hsivonen> | Moo--: It would make sense to point to downloadable codecs for IE and Safari if IE supported them and a codec pack was available for Safari. |
| 12:20 | <hsivonen> | Moo--: I just tested, and IE9PP7 doesn't support WebM when the DirectShow filters are installed. |
| 12:20 | <Moo--> | hsivonen: hmm... then you need some wrapper javascript and IE plug-in, not just codecs? The same ugly things you need to do today for Flash content. |
| 12:21 | <hsivonen> | Moo--: and it seems neither Perian nor the WebM project has made a release of a QuickTime component that supports WebM decoding |
| 12:21 | <hsivonen> | Moo--: or you can tell IE users to download Opera, Firefox 4 or Chrome (with these browsers appearing in a random-shuffled order) |
| 12:21 | <Rik`> | hsivonen: it seems Perian has WebM support in SVN |
| 12:22 | <hsivonen> | Rik`: yeah, but it doesn't make sense to tell J. Random User to pull from SVN and compile |
| 12:22 | <Rik`> | of course |
| 12:22 | <Rik`> | but at the same time, it does not make sense to ask to install Firefox 4 |
| 12:22 | <Moo--> | hsivonen: we do what we always do - we wait :) |
| 12:23 | <hsivonen> | Rik`: well kinda. Firefox 4 beta is way more J. Random User-friendly than pulling from SVN |
| 12:23 | <hsivonen> | but the real solution is of course actually shipping Firefox 4 as non-beta |
| 12:24 | <Rik`> | and what will iPhone users do ? |
| 12:25 | <zcorpan> | MikeSmith: seems console is available in workers in opera although it doesn't actually log anything to the console |
| 12:25 | <hsivonen> | "Sorry, you have bougth into Apple's Curated Computing platform that doesn't allow a third party to deliver a WebM-enabled browser to you. Please petition Apple to support WebM." |
| 12:26 | <Rik`> | except websites with only a few users, who will say that ? |
| 12:26 | <hsivonen> | Let's find out. |
| 12:28 | <Rik`> | it's not pragmatic at all to support a format that only has around 20% marketshare |
| 12:28 | <Rik`> | *to only support |
| 12:29 | <Rik`> | in a couple of years, maybe |
| 12:29 | <hsivonen> | Some appreciation of freedom over pragmatics is needed to get freedom |
| 12:30 | <Rik`> | I'm just saying that it's too soon to launch such an effort |
| 12:30 | <hsivonen> | Once the Firefox userbase upgrades, the market share of WebM-enabled browsers in Finland will be around 66% |
| 12:31 | <annevk> | MikeSmith, http://dev.w3.org/html5/html4-differences/ |
| 12:31 | <annevk> | (and everyone else who cares) |
| 12:31 | <Rik`> | I'm really waiting for hardware acceleration for WebM |
| 12:31 | <Rik`> | (and by that I mean hardware acceleration shipping, not planned) |
| 12:32 | <hsivonen> | I wonder how well the latest Firefox 4 beta for Android plays WebM |
| 12:32 | <hsivonen> | beta 2 wasn't good enough to recommend using for WebM playback |
| 12:32 | <Ms2ger> | annevk, you still have getSelection listed |
| 12:33 | <Rik`> | I think Paul was playing with that in the office and it was consuming a lot of battery |
| 12:33 | <Rik`> | but the playback was ok |
| 12:33 | <annevk> | Rik`, I don't think such an effort can be too soon; might just not have as much traction in the beginning as later |
| 12:33 | <smaug____> | hsivonen: I think beta 2 wasn't hw accelerated, but latest beta might be |
| 12:33 | <annevk> | Rik`, the message is important |
| 12:34 | <hsivonen> | annevk: thanks for the hosting offer. Let's see if I can get something done. |
| 12:36 | <Rik`> | is there any effort by Google to push WebM to the W3C ? |
| 12:37 | <Ms2ger> | Roc said standardization was being worked on, iirc |
| 12:37 | <annevk> | hmm, Ms2ger is not in the acknowledgments |
| 12:37 | <annevk> | Ms2ger, he did, on this IRC channel last night |
| 12:38 | <annevk> | Ms2ger, updated draft |
| 12:39 | <annevk> | Ms2ger, also mentioned UndoManager is gone for now |
| 12:39 | <Ms2ger> | Thanks |
| 12:42 | <smaug____> | UndoManager gone? |
| 12:42 | <jgraham> | From HTML5? |
| 12:42 | <jgraham> | Oh, that is good |
| 12:43 | <jgraham> | At least I couldn't work out what you were supposed to implement from the spec |
| 12:43 | <smaug____> | It is still there |
| 12:43 | <smaug____> | annevk: what did you mean? |
| 12:43 | <Ms2ger> | Not from WHATWG HTML |
| 12:43 | <jgraham> | Oh |
| 12:43 | <smaug____> | ah |
| 12:43 | Ms2ger | feels like fireworks |
| 12:44 | <zcorpan> | http://html5.org/r/5735 |
| 12:44 | <smaug____> | UndoManager needs still some work to become useful... |
| 12:44 | <jgraham> | Well in that case, I still can't work out what you are supposed to implement given the spec text |
| 12:44 | <annevk> | smaug____, it is removed from the W3C copy of HTML5 |
| 12:44 | <annevk> | smaug____, that is what I wrote in html5-diff |
| 12:44 | <Ms2ger> | jgraham, file a bug :) |
| 12:44 | <annevk> | (sorry for not being clear here) |
| 12:45 | <jgraham> | Ms2ger: Yeah, I should. But it would be like those bugs from the crazies |
| 12:45 | smaug____ | doesn't follow W3C HTML5 work at all |
| 12:45 | <jgraham> | "I have no idea what this section is on about" |
| 12:46 | <annevk> | smaug____, I thought you preferred that variant? |
| 13:10 | <hsivonen> | Interesting. http://www.sonyinsider.com/2011/01/11/hands-on-with-sony-bravia-internet-browser/ suggests Opera on Bravia would ship with Java support but without Flash support |
| 13:12 | <hsivonen> | and indeed, only Sony Ericsson--not the big Sony itself--is listed as Adobe's bundling and porting partner |
| 13:13 | <tmzt> | will there be a standard way to dispatch messages from a server in a javascript application on the client? websocket messages or the like with an event callback api? |
| 13:13 | <hsivonen> | looks like Sony isn't letting Opera's logo be part of what the user sees |
| 13:14 | <Rik`> | tmzt: you have WebSockets and Server-sent events |
| 13:15 | <Rik`> | http://dev.w3.org/html5/websockets/ and http://dev.w3.org/html5/eventsource/ |
| 13:28 | <tmzt> | Rik`: I see, so from my bad reading of the EBNF, events are json without the {} enclosure? |
| 13:29 | <tmzt> | is there an alternative mime type for binary events or multiple streams on one http connection? |
| 13:29 | <Rik`> | I'm not familiar with this |
| 13:33 | <annevk> | nope |
| 13:33 | <annevk> | multiple streams you could implement at the server I guess... |
| 13:45 | <annevk> | the amount of negative comments on http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html is somewhat sad |
| 13:46 | <jgraham> | It's weird, like Gecko doesn't exist |
| 13:46 | <jgraham> | Or Opera for that matter |
| 13:49 | <jgraham> | Although reading the comments, a more likely interpretation is that people are idiots |
| 13:49 | <hsivonen> | jgraham: well, Gecko with WebM support doesn't exist as far as Web authors are concerned, because it hasn't shipped yet |
| 13:50 | <hsivonen> | jgraham: the likely explanation is that commenters came in from Daring Fireball links and similar fanboi venues |
| 13:50 | <hsivonen> | jgraham: on days like this, it's amusing to read jd's twitter stream for commentary |
| 13:51 | <jgraham> | hsivonen: I forget that people actually use Firefox 3.6 |
| 13:51 | <annevk> | I wish Gruber was a bit more idealistic at times |
| 13:51 | <jgraham> | But even so, most of the comments make no sense |
| 13:52 | <hsivonen> | jgraham: https://twitter.com/#!/jdowdell/status/24939070509547520 |
| 13:52 | <hsivonen> | annevk: if Apple shipped WebM, Gruber would be idealistic in a heartbeat |
| 13:52 | <Rik`> | when Apple removes support for an old technology, it's visionary :) |
| 13:53 | jgraham | is reminded of http://news.ycombinator.com/item?id=2062507 |
| 13:53 | <gsnedders> | http://tech.slashdot.org/comments.pl?sid=1946532&cid=34842284 |
| 13:53 | <hsivonen> | also, the obligatory "nothing to see here" jd tweet: https://twitter.com/#!/jdowdell/status/24978153059389440 |
| 13:54 | <jgraham> | gsnedders: Your point being that we don't ship h.264 (at least on desktop)? |
| 13:54 | <gsnedders> | jgraham: We do on a single device. |
| 13:54 | <jgraham> | Oh, you said that |
| 13:55 | <annevk> | hsivonen, yeah, only very rarely is he not quite in alignment with Apple PR |
| 13:55 | <gsnedders> | But yeah, further to the misinformation above |
| 13:55 | <annevk> | hsivonen, still pretty good writing and links though |
| 13:55 | <jgraham> | Seriously, I have no idea why people read Gruber |
| 13:55 | <annevk> | jgraham, but you do not like reddit either :) |
| 13:56 | <annevk> | hsivonen, his tweets are funny |
| 13:57 | <annevk> | topmost Slashdot comment sides Opera with Safari and MSIE |
| 13:57 | <annevk> | +5 Interesting |
| 13:57 | <annevk> | o_O |
| 13:57 | <jgraham> | annevk: True. But Gruber is basically just an apple evangalist who happens to be not directly employed by apple. |
| 13:58 | <jgraham> | In general consuming marketing materials for fun or information seems bad |
| 13:59 | <Rik`> | jgraham: so you're saying that no one should read "evangelists" ? |
| 14:00 | <Ms2ger> | No, that no one should read Gruber :) |
| 14:00 | <jgraham> | Rik`: I'm saying "consuming marketing materials for fun or information seems bad" |
| 14:01 | <jgraham> | Gruber clearly produces marketing materials |
| 14:01 | <Rik`> | well, I've read Chrome marketing material about dropping H264 for information, which is bad, right ? |
| 14:01 | <Rik`> | and I assume you have done that too |
| 14:01 | <hsivonen> | jgraham: Gruber also posts interesting links. Also, his commentary on Flash is insightful, because when commenting on Flash, insightfulness aligns with Apple's agenda |
| 14:02 | <annevk> | jgraham, his interests overlap with mine and his commentary is really quite good I think |
| 14:02 | <annevk> | jgraham, I do think he should be more of an open web evangelist, but alas, not his thing |
| 14:03 | <hsivonen> | is this a good time to point out that Opera Mini 5.1 beta for S60 is bad at loading Daring Fireball? |
| 14:03 | <hsivonen> | fails about 2 times out of 3 for no apparent reason |
| 14:03 | <jgraham> | Rik`: Mostly I got that information from here |
| 14:03 | <annevk> | hsivonen, bugs.opera.com/wizard is a much better place |
| 14:03 | <hsivonen> | annevk: been there already |
| 14:07 | <annevk> | http://news.ycombinator.com/item?id=2093219 covers the Gruber thing too it seems |
| 14:07 | <annevk> | maybe I should read Hacker News more often |
| 14:13 | <Rik`> | http://www.salsitasoft.com/blog/2011/01/12/chrome-drops-h264/ |
| 14:13 | <Rik`> | this looks like a fair overview |
| 14:15 | <annevk> | he misses H264 royalties for tools |
| 14:22 | <hsivonen> | annevk: "Let's use Handbrake / Miro Video Converter / etc." don't really help make the point about tool royalties... |
| 14:26 | <annevk> | I think it is really quite simple. If any vendor has to put up more money than the cost of engineering support for the technology the technology is not suitable for the web. |
| 14:27 | <hsivonen> | great. back when my server broke, in the course of the recovery, I forgot to tweak how Apache handles .gz |
| 14:28 | <Rik`> | also, I'm wondering why everyone is saying that Apple prefers H264 over WebM |
| 14:29 | <Rik`> | I've read that they pay more in royalties for H264 than they receive money |
| 14:29 | <annevk> | I suspect they prefer it because all their hardware and software revolves around it. |
| 14:29 | <rimantas> | because iP*s can decode h.264 in hardware |
| 14:30 | <hsivonen> | Rik`: they are said to "prefer" what they ship over what they don't ship |
| 14:31 | <Rik`> | but Apple is often changing technologies |
| 14:32 | <hsivonen> | Rik`: I'm sure people would say Apple prefers WebM if Steve got on stage and said www.apple.com henceforth serves WebM to Safari |
| 14:32 | karlcow | is rediscovering http://www.w3.org/MarkUp/html3/blockquotes.html |
| 14:33 | <karlcow> | and http://www.w3.org/MarkUp/html3/credits.html |
| 14:33 | <Ms2ger> | Yay HTML3 |
| 14:34 | <annevk> | Opera had support for it |
| 14:34 | <annevk> | <bq> |
| 14:34 | <Rik`> | hsivonen: Apple has also often changed his mind |
| 14:34 | <annevk> | gsnedders got most of it killed |
| 14:34 | Ms2ger | wants <bbq> |
| 14:34 | <Ms2ger> | Yay gsnedders! |
| 14:34 | <Rik`> | Steve one day said "we'll never do a phone" |
| 14:35 | <hsivonen> | Rik`: sure, but it's reasonable for people to say that Apple prefers H.264 in the present tense |
| 14:35 | <karlcow> | <ribs><sauce flavor="texas"/></ribs> |
| 14:35 | <Rik`> | hsivonen: they said that and the next sentence is "Apple will never drop H264 in favor of WebM" |
| 14:36 | <jgraham> | Our "support" for <bq> has implementing a weird interface that was like HTMLElement in all but name, or something |
| 14:36 | <hsivonen> | Rik`: well, that's not a sensible thing to say |
| 14:37 | <karlcow> | I like the fact that <credit> was inside <bq>. It is useful sometimes. |
| 14:38 | <karlcow> | still craving for a better way to make quotes with attribution in html. :) |
| 14:42 | <hsivonen> | karlcow: it's easier if you just let go of semantics and write the attribution in a user-readable way |
| 14:43 | <karlcow> | hsivonen: agreed with the user-readable way :) |
| 14:44 | <karlcow> | as for semantics, there are moments where it is useful for some categories of people to have a better model. I gave up trying to convince the htmlwg a long time ago. I'm doing my own things. ;) |
| 14:45 | <karlcow> | which is non conformant according to the spec :) |
| 15:19 | <AryehGregor> | annevk, were you looking for this quote by mpilgrim? (I couldn't find it in the #whatwg logs, but I didn't look very hard.) http://weblogs.mozillazine.org/roc/archives/2010/03/amor_robustum.html |
| 15:20 | <annevk> | I found it earlier today |
| 15:20 | <annevk> | roc is quoting Gruber there |
| 15:20 | <annevk> | mpilgrim's quote is here: http://krijnhoetmer.nl/irc-logs/whatwg/20100318#l-65 |
| 15:30 | <jgraham> | roc's argument equally applies to what mpilgrim said |
| 15:40 | <gsnedders> | annevk: We had support of it insofar as it got the HTMLQuoteElement interface, but that was it. We hardly had support for it to start with. :P |
| 16:02 | <annevk> | hsivonen, I was wondering whether to bite; glad you did |
| 17:26 | <annevk> | http://daringfireball.net/linked/2011/01/12/slashdot-comment now he's pushing it |
| 17:26 | <annevk> | wtf |
| 17:28 | <TabAtkins> | Dude what. |
| 17:28 | <TabAtkins> | Nothing in that entire comment made any sense. |
| 17:31 | jgraham | will be good and resist mentioning the pro-Gruber statements earlier about him having good commetary and a sensible position on flash |
| 17:31 | <jgraham> | Although it seems I will meta-mention it |
| 17:32 | <annevk> | I think your attempt at doing that just failed, yes :) |
| 17:32 | <jgraham> | But seriously, wtf barely covers it |
| 17:34 | <jgraham> | And now back to your regularly scheduled light entertainment: http://superuser.com/questions/231273/what-are-the-windows-a-and-b-drives-used-for |
| 17:37 | Ms2ger | feels old |
| 17:37 | <Ms2ger> | Damn you, jgraham |
| 17:38 | <gsnedders> | I, /I/, feel old. |
| 17:38 | <TabAtkins> | omg |
| 17:40 | <jgraham> | I made gsnedders feel old? That but be the sound of victory! What do I win? |
| 17:40 | <gsnedders> | jgraham: Nah, I felt old when I saw it on Twitter last nigh t;P |
| 17:40 | <gsnedders> | *night |
| 17:41 | <jgraham> | So even the ews feels old? |
| 17:41 | <jgraham> | *news |
| 17:41 | <jgraham> | The ewes are an entirely differnt matter |
| 17:50 | <bga_> | when webkit will supports Float64Array? Anybody know? |
| 17:53 | <Ms2ger> | The Chrome team did manage to flood my feed reader, that much is clear |
| 18:40 | <mven> | hixie got a quick question for you in the html5 label element spec |
| 18:40 | <Hixie> | sure |
| 18:41 | <mven> | i'm used to putting labels right next to my inputs like so: <label for="myInput">My Name</label><input type="text" id="myName" /> |
| 18:41 | <mven> | however |
| 18:42 | <mven> | in the html5 see that labels are wrarpped around the input now |
| 18:42 | <Ms2ger> | Both are fine |
| 18:42 | <mven> | is there a significant difference in doing it the way I've always had and can i keep doing it even if I start using the html5 doctype ? |
| 18:43 | <TabAtkins> | Labels were always wrappable around the input. That just makes it so that you don't have to use @for. |
| 18:44 | <TabAtkins> | Check the first paragraph of that section of the spec: "The caption can be associated with a specific form control, known as the label element's labeled control, either using for attribute, or by putting the form control inside the label element itself." |
| 18:45 | <mven> | Ahh |
| 18:45 | <AryehGregor> | So it seems like HTML5 assumes strings are sequences of Unicode characters, while in JavaScript they're actually sequences of 16-bit numbers which are typically interpreted as UTF-16 code units. |
| 18:45 | <AryehGregor> | Is this bad? |
| 18:46 | <TabAtkins> | What do you mean by "typically interpreted as"? Strings *are* UTF-16-encoded byte sequences in javascript. What's the distinction you're trying to draw? |
| 18:46 | <Ms2ger> | WebIDL should probably handle that |
| 18:46 | <AryehGregor> | TabAtkins, a string in JavaScript doesn't have to be valid UTF-16. |
| 18:46 | <Hixie> | mven: what tab said. HTML4 already allowed that. |
| 18:46 | <TabAtkins> | AryehGregor: Ah, kk. True. |
| 18:46 | <AryehGregor> | Ms2ger, WebIDL doesn't apply to random functions that accept strings. I'm thinking of atob() and btoa() here. |
| 18:46 | <Ms2ger> | Why not? |
| 18:46 | <AryehGregor> | Does it? |
| 18:46 | <AryehGregor> | I have to read WebIDL sometime. |
| 18:46 | <AryehGregor> | Oh, hmm. |
| 18:47 | <AryehGregor> | Yeah, I guess it does, doesn't it? |
| 18:47 | <mven> | cool. thanks for the clarifications guys |
| 18:47 | AryehGregor | looks at WebIDL |
| 18:47 | <TabAtkins> | Random functions, no. Defined functions with typed arguments, yes. |
| 18:48 | <AryehGregor> | Okay, where are they hiding the ED of WebIDL? |
| 18:48 | <Ms2ger> | http://dev.w3.org/2006/webapi/WebIDL/ |
| 18:48 | <TabAtkins> | Argh I hate the years in w3c urls. |
| 18:49 | <TabAtkins> | SO MEANINGLESS. |
| 18:49 | <othermaciej> | AryehGregor: there's no reason it wouldn't apply, just add an interface that applies on top of Window |
| 18:49 | <AryehGregor> | Yeah, I forgot that all these functions are defined with WebIDL interfaces. |
| 18:49 | <othermaciej> | TabAtkins: I've been hating the dates since, like, 2000 |
| 18:49 | <Ms2ger> | Old man. |
| 18:49 | <AryehGregor> | Okay, so it looks like users of WebIDL have to explicitly say that they want to convert a DOMString to a sequence of Unicode characters. |
| 18:50 | <AryehGregor> | For correctness, I guess either I should say that or do it in code units. |
| 18:50 | <Ms2ger> | I guess that makes sense |
| 19:03 | <AryehGregor> | Why is [1, 3] === [1, 3] false? |
| 19:03 | <TabAtkins> | Arrays are compared by object identity. |
| 19:03 | <AryehGregor> | Ah. |
| 19:03 | <TabAtkins> | Javascript's equality is so broken. |
| 19:03 | <Workshiva> | eh |
| 19:03 | <Ms2ger> | s/'s equality // |
| 19:04 | <Workshiva> | It's a very simple model, objects are always compared by identity |
| 19:04 | <TabAtkins> | I forget, does 1 === 1? |
| 19:04 | TabAtkins | supposes he can check for himself... |
| 19:04 | <miketaylr> | yes |
| 19:05 | <Workshiva> | === just avoids type conversion |
| 19:05 | <TabAtkins> | And you called it simple. Pfft. |
| 19:05 | <hober> | well, === is basically CL's eq, whereas == is CL's equal. |
| 19:05 | <hober> | you *want* [1,3] === [1,3] to be false |
| 19:05 | <TabAtkins> | Maybe. Perhaps I just want "same type, and same data". |
| 19:06 | <TabAtkins> | That is, == without the type conversion. |
| 19:06 | <TabAtkins> | Which is what I thought === *was*, until I recently discovered I was mistaken. |
| 19:06 | <Workshiva> | That way lies madness |
| 19:06 | <hober> | woth a read: http://www.nhplace.com/kent/PS/EQUAL.html |
| 19:06 | <Ms2ger> | Also, operator overloading |
| 19:06 | <TabAtkins> | Yup, I'm a Lisper. I love my 5 builtin equality functions. |
| 19:07 | <TabAtkins> | Though, honestly, who ever uses EQL? |
| 19:25 | <AryehGregor> | Ms2ger, here's a test for you: http://dvcs.w3.org/hg/html/raw-file/6243b5d14211/tests/submission/AryehGregor/selection-dir.html |
| 19:25 | <Ms2ger> | Yay :) |
| 19:49 | <AryehGregor> | Now I get to define Selection.extend(), yay. |
| 19:51 | <Ms2ger> | Good luck |
| 19:51 | <Ms2ger> | And much appreciated |
| 19:51 | <AryehGregor> | :) |
| 19:52 | <Ms2ger> | What's the "(maybe not in order)" about? |
| 19:53 | <AryehGregor> | Just that the correct offsets are selected period, even if they're not backwards like they should be. |
| 19:53 | <AryehGregor> | In particular, IE9 beta passes that test but fails subsequent ones. |
| 19:53 | <AryehGregor> | It's partly a sanity check to make sure that the user actually selected what they were supposed to. |
| 19:53 | <Ms2ger> | Okay |
| 20:03 | <AryehGregor> | Is there a way to get the (x, y) coordinates of the caret, or to scroll it into view, or to scroll a Range or Selection into view? |
| 20:04 | <AryehGregor> | (this is largely unrelated to what I'm doing) |
| 20:05 | <Ms2ger> | Range.getBoundingClientRect(), maybe? |
| 20:05 | <Ms2ger> | Or Range.startContainer(.parentNode).scrollIntoView |
| 20:06 | <AryehGregor> | The latter doesn't work for a large element with scrollbars, as you'd get in a contenteditable type scenario. |
| 20:07 | <Ms2ger> | Indeed |
| 20:07 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11166 about the reset insertion mode algorithm seems to be wrong. Not sure who filed it, but the IP was someone at Opera. jgraham maybe? Anyway, I'd love a second opinion in case I am wrong about it being wrong. |
| 20:21 | <Ms2ger> | assert_equals(selection.anchorNode, p); assert_equals(selection.anchorNode, p); |
| 20:21 | <Ms2ger> | I hope those both have the same result :) |
| 20:21 | <AryehGregor> | Oops. |
| 20:22 | <AryehGregor> | Copy-paste fail. |
| 20:22 | <Ms2ger> | I gathered |
| 20:27 | <AryehGregor> | Updated. |
| 20:31 | <paul_irish> | this is totally pendantic.. but.. do "elements" exist in HTML? or would you say "elements" are only in the DOM that's constructed from the tags 'n such parsed from the HTML? |
| 20:32 | <TabAtkins> | Yes, elements exist in the DOM. |
| 20:32 | <paul_irish> | but HTML has no elements. |
| 20:32 | <Peter`> | and tags are strings |
| 20:32 | <TabAtkins> | The HTML text contains tags. |
| 20:32 | <nimbupani> | so what do you call a <em>text</em> |
| 20:32 | <Peter`> | The DOM representation of the HTML text contains elements |
| 20:32 | <TabAtkins> | Tags and their contents are parsed into elements. |
| 20:32 | <nimbupani> | in HTML |
| 20:32 | <TabAtkins> | An em element? |
| 20:33 | <nimbupani> | :) |
| 20:33 | <paul_irish> | heheh but thats the HTML serialization of an em element! |
| 20:33 | <nimbupani> | paul_irish pwnedddddd |
| 20:33 | <pesla> | paul_irish: So HTML in itself doesnt have elements |
| 20:33 | <Ms2ger> | There's HTML the serialization and HTML the DOM language |
| 20:33 | <Ms2ger> | The former has tags, the latter has elements |
| 20:34 | <TabAtkins> | What's the purpose of the pedantry? |
| 20:34 | <paul_irish> | terminology fights that go nowhere. |
| 20:34 | <nimbupani> | to do in-ur-face on people who are pedantic about tags and elements |
| 20:34 | <paul_irish> | and that. |
| 20:34 | <TabAtkins> | What's the purpose of the terminology fights? |
| 20:34 | paul_irish | shrugs. |
| 20:34 | <nimbupani> | TabAtkins you are sounding too zen for me. |
| 20:35 | <paul_irish> | its so just zen. |
| 20:35 | <TabAtkins> | <em> is a tag. <em>foo</em> is an element. Done. |
| 20:35 | <Peter`> | He just came back from vacation, evidently was a good one :) |
| 20:35 | <TabAtkins> | <br> is a tag and an element. |
| 20:35 | <Hixie> | man, that's a lot of discussion over a simple request to be able to seek by frames rather than by time |
| 20:35 | <TabAtkins> | Or perhaps you could say it "represents" a tag and an element. |
| 20:35 | <TabAtkins> | Hixie: That's what happens when you start with the solution. |
| 20:36 | <Hixie> | hear hear |
| 20:36 | <paul_irish> | only because... you can't type an element if you dont serialize it to html |
| 20:36 | <Ms2ger> | It is two tags and some text, and it represents one element |
| 20:36 | <AryehGregor> | Hixie, the problem with writing lots of manual tests is that no one will run them. |
| 20:37 | <Hixie> | AryehGregor: they won't get run as often, but they'll still get run |
| 20:37 | <Hixie> | the problem with not having any manual tests is that nobody can run them :-) |
| 20:37 | <Ms2ger> | See the spam on p-html-testsuite |
| 20:37 | Hixie | resists the temptation to say "back in my day, we only had manual tests, and we liked it!" :-P |
| 20:38 | <Ms2ger> | Hixie, that's what MS still does |
| 20:38 | <Hixie> | wow, that explains a lot |
| 20:38 | <jgraham> | You could call it some text tagged as <em> |
| 20:38 | <Ms2ger> | jgraham, <em> or em? :) |
| 20:39 | <jgraham> | Wait, who's writing manual tests? |
| 20:39 | <jgraham> | Please stop... |
| 20:39 | <Ms2ger> | Untestable without user interaction, sorry |
| 20:39 | <Hixie> | jgraham: selection ui tests |
| 20:40 | <Hixie> | jgraham: not really any way to test the effect of user interaction on the selection API other than having some user interaction, currently. |
| 20:41 | <TabAtkins> | All right, time to write some slides. |
| 20:41 | <Hixie> | jgraham: AryehGregor and i were just discussing this privately, saying how it would be great to have a testing API that let you fake out the user interaction from a test, though |
| 20:41 | <jgraham> | Well we could all use watir or similar. Doesn't that have support for all major browsers these days? |
| 20:41 | <AryehGregor> | jgraham, I was trying to convince Hixie that I shouldn't write lots of tests like this: http://dvcs.w3.org/hg/html/raw-file/6243b5d14211/tests/submission/AryehGregor/selection-dir.html |
| 20:41 | <Ms2ger> | Mochitest has that! |
| 20:42 | <AryehGregor> | I know. |
| 20:42 | <AryehGregor> | But it would be nice if spec tests were cross-browser. ;) |
| 20:42 | <Ms2ger> | I know you know :) |
| 20:42 | <Ms2ger> | Pff ;) |
| 20:42 | <AryehGregor> | And preferably in JavaScript, unlike Watir. Although currently it's impossible to have both of those. |
| 20:42 | <Hixie> | i'd be extremely happy to have the tests be automated so long as they still work in isolation, just like regular JS tests |
| 20:42 | <AryehGregor> | What do you mean by "work in isolation"? |
| 20:43 | <Hixie> | AryehGregor: as in, you don't have to run a massive harness just to run one file |
| 20:43 | <jgraham> | I don't exactly like watir. But I don't like manual tests more |
| 20:43 | <jgraham> | Hixie: Why is that a requirement? |
| 20:43 | <Hixie> | i don't like manual tests, but i don't like the lack of any tests more. :-) |
| 20:43 | <jgraham> | (ideally they should be possible to run both ways) |
| 20:44 | <AryehGregor> | Is there any Watir equivalent in, say, Python? |
| 20:44 | <jgraham> | I find there is very little difference between manual tests and missing tests |
| 20:44 | <jgraham> | Neither get run often enough |
| 20:44 | <Hixie> | jgraham: i almost never care about the aggregate result, i always care about specific tests (e.g. because i'm trying to reverse engineer a specific feature, or because i'm trying to file a bug with a reproducible case, or because i'm trying to debug a specific failure) |
| 20:45 | <AryehGregor> | How about Selenium? Is that too evil or heavyweight? |
| 20:45 | <jgraham> | Hixie: That isn't the typical case for a browser developer |
| 20:45 | <AryehGregor> | Yeah, tests are mostly for browser developers, not spec writers . . . |
| 20:45 | <Hixie> | jgraham: so? |
| 20:46 | <Hixie> | jgraham: given that it's trivial to support... |
| 20:46 | <jgraham> | Hixie: You are atypical and we should weigh your needs accordingly :) |
| 20:46 | <jgraham> | What is trivial to suuport? |
| 20:46 | <Hixie> | and browser developers need to be able te debug failing tests, you know :-) |
| 20:46 | <AryehGregor> | Selenium is maybe too opaque. |
| 20:46 | <Hixie> | jgraham: making tests that run in isolation as well as en-masse |
| 20:46 | <jgraham> | If you are arguning that automated tests should *also* work when run manually, I agree |
| 20:47 | <Hixie> | yes |
| 20:47 | <gavin> | whether or not you need a harness is separate from whether or not a single test can be run |
| 20:47 | <Hixie> | we seem to be in violent agreement |
| 20:47 | <jgraham> | gavin: In this specific case a "harness" is an external program that provides user input |
| 20:47 | <jgraham> | You should generally be able to do without that |
| 20:48 | <jgraham> | Because the test should describe the set of steps to take |
| 20:48 | <AryehGregor> | I really wish we could just spec some basic JS APIs like Mochitest has and use those if the browser is invoked in some magic way (to avoid security issues). |
| 20:48 | <jgraham> | Although they might be impractical to actually do manually |
| 20:49 | <jgraham> | AryehGregor: This stuff is, at least, complex. I'm not sure if that is possible or impossible |
| 20:49 | <jgraham> | But it's not clear how it works if e.g. navigation of a top level browsing context is part of the test |
| 20:50 | <AryehGregor> | Well, first things first. |
| 20:50 | <AryehGregor> | Just basic synthesis of clicks and keypresses would go a very long way. |
| 20:50 | <Hixie> | http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.html#InterfaceImageData takes something that HTML specs, and respecs it dropping almost all the conformance criteria, and then says it's trying to be compatible with HTML. |
| 20:50 | <Hixie> | sigh. |
| 20:51 | <Ms2ger> | SVG. |
| 20:51 | <jgraham> | AryehGregor: The problem is you can end up with lots of 20% solutions |
| 20:52 | <AryehGregor> | Sure. |
| 20:52 | <AryehGregor> | Although I'd say that keypresses and clicks are more like 80% solutions. |
| 20:52 | jgraham | would be interested to see if that matches our internal tests |
| 20:52 | <benschwarz> | Hixie: !ping |
| 20:53 | <heycam> | Hixie, yeah it does seem like it would be better if that just referenced the ImageData from HTML5 instead of half copying it |
| 20:53 | <AryehGregor> | Internal tests are testing different things on average than spec tests. |
| 20:53 | <Hixie> | benschwarz: here |
| 20:53 | <benschwarz> | Hixie: on the code areas, there are only a few options… what do you think we should do? |
| 20:53 | <benschwarz> | scrolling them is awkward |
| 20:53 | <benschwarz> | plus, not very good on a mobile device |
| 20:54 | <jgraham> | AryehGregor: True. But it is a pain for us to implement two different solutions for the two cases |
| 20:54 | <AryehGregor> | More or less of a pain than speccing and implementing a fuller API? |
| 20:54 | <Hixie> | benschwarz: dunno. I had the same problem on my blog and ended up with a terrible half-assed solution (i made the paragraphs have a fixed width but let more or less everything else be as wide as it wanted, which looks pretty ugly when you have nested lists) |
| 20:54 | <AryehGregor> | You can wrap the minimal specced API around your thorough internal API. |
| 20:55 | <Hixie> | benschwarz: adding a scroll bar is definitely the wrong solution, it's horrible UI (and feels stupid, especially when the page has lots of whitespace) |
| 20:55 | <benschwarz> | Hixie, yeah I'd like to avoid that. I did look at :hover states to widen them, clip them otherwise, but again, doesn't work on all devices |
| 20:55 | <Hixie> | benschwarz: maybe we should suck it up and let the examples overflow to the left? or something? I mean, it will look a bit ugly, but... |
| 20:55 | <Hixie> | benschwarz: we can also make the font size smaller |
| 20:56 | <benschwarz> | Hixie: I was thinking I could keep it the same, widen the box a little, and pull them left (like the notes) |
| 20:56 | <Hixie> | benschwarz: yeah, that might work. Though the notes being pulled to the left looks like they're slipping out or something. |
| 20:57 | <benschwarz> | Hixie: maybe they're pulled a little too much, but either way it breaks up the vertical jungle of code |
| 20:57 | <Hixie> | yeah |
| 20:58 | <Hixie> | maybe pull the examples as a whole out instead? |
| 20:58 | <Hixie> | there's no really a strong need to style the notes in the dev edition |
| 20:58 | <Hixie> | they're only notes because they're non-normative, and the devs won't care |
| 20:58 | <Hixie> | so we can just let them look like normal prose, and then pull the examples out to break the flow a bit |
| 20:58 | <Hixie> | but dunno |
| 20:58 | <Hixie> | i'm no designer :-) |
| 20:59 | <Hixie> | just look at the current spec :-) |
| 21:00 | <benschwarz> | Hixie: I need to read the spec and think about the roles of those elements |
| 21:01 | <Hixie> | k |
| 21:02 | <Ms2ger> | What about pre-line? |
| 21:04 | <Hixie> | benschwarz: fwiw, the longest line in an example is the ridiculous line in the <span> element's section, but that one _should_ wrap, that's fine |
| 21:05 | <Hixie> | benschwarz: other than that, the next longest lines are the one that first mentions "Preferred delivery time" in the Forms section, and the one in the Conversations section, though that last one can wrap without problem |
| 21:06 | <Hixie> | benschwarz: looks like the maximum line length you should expect is about 160 characters monospace, with most being 120 or less |
| 21:06 | <benschwarz> | pretty wide :) |
| 21:07 | <benschwarz> | I've pulled down the font-size |
| 21:07 | <Hixie> | most lines in the spec seem to be 71 characters, but i haven't got a quick way to limit my search to <pre> blocks |
| 21:08 | <benschwarz> | Hixie: fair enough |
| 21:08 | <Hixie> | benschwarz: if you come across any gratuitously long lines, though, let me know and i'll shrink them |
| 21:09 | <benschwarz> | I will |
| 21:09 | <Hixie> | benschwarz: there's a few that are long because that's just the best way to convey what they say, but most don't fall into that category |
| 21:09 | <benschwarz> | Hixie: no worries |
| 21:10 | <benschwarz> | we don't have to have the answers to everything right now |
| 21:10 | <benschwarz> | its about a line in the sand |
| 21:12 | <benschwarz> | Hixie: I have to leave for work :) |
| 21:12 | <benschwarz> | really, its a :( |
| 21:12 | <benschwarz> | I'd rather get this spec right |
| 21:13 | <benschwarz> | Laters all! |
| 21:26 | <Hixie> | anyone here know anything about ICE/STUN btw? |
| 21:27 | <TabAtkins> | I am frankly surprised that "ice stun" turned up such good results. |
| 21:27 | <TabAtkins> | (I know nothing.) |
| 22:27 | <AryehGregor> | Hixie, put it this way: there's such a thing as having too many tests. You reach that point when the cost of running the extra tests outweighs the benefit of realistically catching any extra bugs. For manual tests, that threshold is very, very low, since they're so expensive to write and run. |
| 22:28 | <AryehGregor> | How about when I run out of things to do, you assign me to write a basic spec for cross-browser UI testing, like with click simulation or whatever? |
| 22:29 | <AryehGregor> | I imagine it wouldn't be hard to implement the few most basic things in at least one browser. |
| 22:30 | <AryehGregor> | (not that I'm saying I'll do that part, but maybe someone will be interested in doing it quickly) |
| 22:33 | <AryehGregor> | (I'm still writing some more manual tests here, but I think it's a bad idea to write more than a few.) |
| 22:55 | <gsnedders> | AryehGregor: Does Watir, etc. not do this? |
| 22:56 | <AryehGregor> | gsnedders, Watir requires you to use Ruby, yes? That's a pretty massive minus. |
| 22:56 | <AryehGregor> | We'd really want JavaScript tests that can be run straight from the browser, like Mochitests. |
| 22:57 | <AryehGregor> | It's also a bit weird for the tests for a spec to depend on a particular program implementation in a particular non-standard language. |
| 22:58 | gsnedders | forgets the reason for moving from using stuff on the opera object to using Watir for testing stuff in Opera |
| 22:59 | <AryehGregor> | Does anyone know how WebKit does it? |
| 23:01 | <AryehGregor> | othermaciej, how does WebKit do tests that require synthesizing user input like keypresses or mouse clicks? |
| 23:01 | <othermaciej> | AryehGregor: depends |
| 23:01 | <othermaciej> | AryehGregor: when it's a good enough test, we fake it with dom events |
| 23:02 | <othermaciej> | AryehGregor: when real user events are needed, we have methods in our regression test tool that can send a real-looking event |
| 23:02 | <AryehGregor> | Are these methods called from simple JavaScript code within WebKit, like Gecko does it, or is it some external program? |
| 23:04 | <jamesr_> | javascript bindings (exposed only to tests) |
| 23:04 | <othermaciej> | AryehGregor: JS |
| 23:04 | <AryehGregor> | Ah, so like Gecko, then. |
| 23:04 | <othermaciej> | some of these tests can also be run via manual steps with instructions |
| 23:05 | <othermaciej> | but not all |
| 23:05 | <AryehGregor> | It would be nice to expose some of those in a safe way to spec tests, yes? There are lots of things you can't do automated tests for without them. |
| 23:05 | <jamesr_> | define(safe) |
| 23:05 | <AryehGregor> | For instance, require a command-line option that specifies the URL prefixes that are allowed to use them, say. |
| 23:06 | <AryehGregor> | So you could whitelist http://dvcs.w3.org/ or whatever. |
| 23:06 | <jamesr_> | that doesn't sound safe to me - not even https? |
| 23:06 | <AryehGregor> | Yeah, I guess that's not safe enough. |
| 23:06 | <AryehGregor> | Also, lots of people have commit access to there. |
| 23:07 | <AryehGregor> | Well, it's only got to be as safe as running the tests that browsers already have. |
| 23:07 | <AryehGregor> | But it's doable, even if it would require downloading the test locally and running the browser with a command-line switch pointing at the exact local file you want to run (but I hope we can make it more convenient than that). |
| 23:08 | <jamesr_> | the tests that webkit has right now that synthesize native events are run off of local disk in a different binary from the typical browser binary (DumpRenderTree instead of Safari.app or Chrome.app or whatnot) |
| 23:08 | <gsnedders> | jamesr_: So how do you test the code you actually ship? |
| 23:09 | <jamesr_> | for handling native events? i can't speak for safari but in chrome we also have tests for this at higher levels |
| 23:09 | <othermaciej> | gsnedders: we assume the framework works the same regardless of the app linking it, which is essentially true |
| 23:10 | <othermaciej> | WebKit.framework is used by many apps, not just Safari.app, we usually assume WebKit bugs won't have a specific effect only in Safari.app and not in a minimal WebKit-based test tool |
| 23:11 | <gsnedders> | othermaciej: What about platform specific bugs? You have stuff like DumpRenderTree for ARM/iOS? |
| 23:11 | gsnedders | guesses the answer is "no comment" |
| 23:11 | <othermaciej> | our regression tests are run automated on every platform of interest before shipping to those platforms |
| 23:11 | <othermaciej> | we have bots that run on different versions of Mac OS X even |
| 23:13 | <gsnedders> | At the same number of builds across all platforms? |
| 23:13 | <othermaciej> | I'm not sure I understand the question |
| 23:15 | <gsnedders> | For every build run on 10.6/x86, is that build also run on all other platforms? Or do (at least some) other platforms not get tested on all builds? |
| 23:15 | <othermaciej> | the way it works is that on every SVN commit, the code is built on all target platforms and then all target platforms run the regression tests |
| 23:15 | <othermaciej> | at least on the open source side |
| 23:15 | <othermaciej> | I'm sure companies may also have internal testers for other build setups |
| 23:17 | <jamesr_> | in chrome land the bots run as fast as they can (so not necessarily on every commit, but in the limit they test every commit/platform combination if things cycle quickly enough). why do you ask? |
| 23:18 | <gsnedders> | Curiousity as to what competitors are doing. :) |
| 23:19 | <jamesr_> | it's all on the internets. build.webkit.org |
| 23:20 | <gsnedders> | Yeah, I know. But certain detail is easier to find out by asking than looking and trying to work out. |
| 23:21 | <othermaciej> | the best way to find out all the details is to hack on WebKit for a while |
| 23:22 | <gsnedders> | That's not really the most practical while working for a competitor :) |
| 23:22 | <gsnedders> | (And I can't say I ever actually touched any of this with what I did with WebKit when I was involved) |
| 23:27 | <Hixie> | AryehGregor: yeah, that's not a bad idea actually, if you can get the browsers on board (the testing api thing) |
| 23:28 | <Hixie> | othermaciej: i'm not sure i agree with your definition of "amicable", but anyway, i submitted his proposal |
| 23:28 | <Hixie> | committed, i should say |
| 23:28 | <othermaciej> | I just mean "amicable" in the sense of "no need for further bureaucratic nonsense before we can close the issue" |
| 23:29 | <othermaciej> | as opposed to "Ian Hickson and Julian Reschke are totally best pals" |
| 23:39 | <jamesr_> | gsnedders: i hack on firefox on occasion. it's good for you :) |
| 23:46 | <MikeSmith> | it's a shame we've had no implementor movement on UndoManager |
| 23:46 | <hober> | othermaciej: someone should write a webcomic in which ian and julian are buddy cops |
| 23:46 | <othermaciej> | Lethal Specification |
| 23:46 | <MikeSmith> | heh |
| 23:47 | <MikeSmith> | which one is Mel GIbson? |
| 23:47 | <othermaciej> | Weberly Hills Cop |
| 23:47 | <MikeSmith> | Hixie is Magneto and Julian is Professor Xavier |
| 23:48 | <MikeSmith> | one day the will reconcile enough at least to do battle together against those who wish to destroy us all |
| 23:53 | <Hixie> | anyone want to help me out writing the CCP for -129? It's a kitchen-sink issue that's gonna take forever to tease apart and provide status-quo rationales for. |
| 23:53 | hober | looks up ISSUE-129 |
| 23:53 | <Hixie> | the existing CP is http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5 |
| 23:54 | <AryehGregor> | Wow, there are really a lot of e-mails in the <video> FPS thread. |
| 23:54 | <Hixie> | yeah. beats me why. |
| 23:54 | <Hixie> | well, other than what was said before, "it's waht you get when you start with a solution" |
| 23:54 | <Hixie> | but still |
| 23:54 | <hober> | Hixie: I'll help out |
| 23:54 | <Hixie> | sweet |
| 23:55 | hober | will have some free time while gearing up for the SF move |
| 23:55 | <Hixie> | i guess i'll set something up on the whatwg wiki |
| 23:55 | <hober> | sounds good |
| 23:55 | <Hixie> | from what i understand, the best plan of attack is to break it down so that we discuss each of the originating bugs as a separate "sub-issue" |
| 23:55 | <hober> | *nod* |
| 23:56 | <Hixie> | and then we'll have to make sure that we've covered everything they did in their rationale, and then that we've covered everything they're proposing to change (that last one is the hardest, i think, since all they provided was new text for an entire section, without saying what they're changing exactly) |
| 23:56 | <hober> | basically, it'll be a total pain in the ass |
| 23:57 | <hober> | :) |
| 23:57 | <Hixie> | yeah |