| 00:06 | <TabAtkins_> | AryehGregor: Pretty sure we do that too (pre-resolving domains). |
| 00:07 | <AryehGregor> | Do you store which domains every site includes resources from, though? |
| 00:07 | <TabAtkins_> | I have no idea. |
| 00:56 | <Yuhong> | hsivonen: In http://hsivonen.iki.fi/doctype/test-quirks.php, the support for X-UA-Compatible do not work properly. |
| 01:01 | <Hixie> | heycam: in http://www.w3.org/mid/20110317224558.GI1187⊙wmia , what's the difference between having or not having the [NoInterfaceObject] decorator on the suggested IDL? |
| 01:02 | <Hixie> | seems like the suggested idl is different in meaning than the [Supplemental] idl |
| 01:10 | <AryehGregor> | Is there a way to get Flash to not insist on being on top of everything else on the page? |
| 01:10 | <aho> | wmode=opaque (like a canvas with background color) |
| 01:11 | <aho> | wmode=transparent (like canvas) |
| 01:11 | <aho> | default is wmode=window, which basically means draw on top of that target rectangle inside the browser window |
| 01:12 | aho | pokes AryehGregor |
| 01:12 | <AryehGregor> | aho, thanks. |
| 01:13 | <AryehGregor> | I'll try that. |
| 01:13 | <aho> | use opaque if possible. it's a bit faster than transparent. (both are very slow.) |
| 01:14 | <roc> | if you set CSS opacity:/join #auckland |
| 01:14 | <AryehGregor> | Oh, right, we use <iframe> for YouTube, so we probably can't change it. |
| 01:14 | <AryehGregor> | roc, uh, mispaste? |
| 01:14 | <roc> | sorry |
| 01:15 | <AryehGregor> | aho, it causes a big slowdown in video playback, or what? |
| 01:15 | <zewt> | #auckland, where people who set CSS opacity gather |
| 01:15 | <AryehGregor> | http://stackoverflow.com/questions/4050999/youtube-iframe-wmode-issue |
| 01:15 | <aho> | well, it means that the plugin needs to copy that stuff from whatever surface it is using, then hand it over to the browser, which in turn does the compositing voodoo |
| 01:16 | <aho> | so... there is some friction involved |
| 01:16 | <aho> | native things like canvas and video don't necessarily have to do an extra copy step |
| 01:17 | <aho> | (you currently get one with webgl with most implementations though) :> |
| 01:17 | <heycam> | Hixie, if we gain this "mixin interface" concept, then they would automatically be [NoInterfaceObject], since they would never exist outside being mixed in somewhere |
| 01:17 | <heycam> | Hixie, which is why I left it off that last example, if that's why you're asking |
| 01:18 | <heycam> | Hixie, without [NoInterfaceObject] on that middle example, then window.WindowPerformance would exist |
| 01:18 | <heycam> | (since I set that name there) |
| 01:18 | <Hixie> | heycam: is there any difference between interface A {x}; [NoInterfaceObject] interface B {y}; A implements B; and interface A {xy} ? |
| 01:19 | <heycam> | Hixie, yes: currently we have this "mixin prototype object" that gathers up all of the things from the RHS of implements statements |
| 01:20 | <heycam> | that will probably go away with these mixin interface changes |
| 01:20 | <heycam> | so that y would go directly on A.prototype |
| 01:20 | <Hixie> | the idea of [Supplemental] is that there is no difference, so if there is a difference, then removing [Supplemental] isn't solving the problem. But we can switch from [Supplemental] once the mixin stuff is done. |
| 01:20 | <heycam> | yeah |
| 01:20 | <heycam> | ok |
| 01:21 | <heycam> | so my suggested change to them (the middle one) does then have an impact |
| 01:21 | <heycam> | since it'll cause this mixin protoype object to exist |
| 01:21 | <heycam> | well, it'll cause the "performance" property to go on that, instead of on Window.prototype |
| 01:21 | <Hixie> | yeah |
| 01:22 | <heycam> | I think for the moment it doesn't really matter, and once Web IDL is settled (finally) the mixin interface stuff should do what you and they want |
| 01:22 | <heycam> | (well I guess you also want [Supplemental] or something like it for the editorial reasons) |
| 01:29 | <Hixie> | yeah there are several use cases for it but here i'm just talking about the simple one they use it for :-) |
| 01:31 | <paradisaeidae> | Does this imply that html5 drag and drop functionality should by default be available to the svg dom? :: http://dev.w3.org/html5/spec/infrastructure.html#xml |
| 01:37 | <ajh_555> | Anyone know if backticks (``) are legal attribute value delimiters? What should UAs do when encountering them? |
| 01:37 | <ajh_555> | e.g. class=`foo` or onclick=`bar();` |
| 01:38 | <aho> | catching fire is an appropriate response :> |
| 01:39 | <gsnedders> | ajh_555: They aren't. They should become part of the attribute value. so the same as class="`foo`" |
| 01:39 | <gsnedders> | ajh_555: IE however allows them |
| 01:41 | <ajh_555> | Thanks gsnedders |
| 01:41 | <ajh_555> | my test matches what you are saying: http://dl.dropbox.com/u/105727/web/backticks.html |
| 01:43 | <aho> | tbh i'd be more worried about "smart quotes", which can be often seen in code posted on some blogs |
| 01:44 | <gsnedders> | aho: They aren't treated as quote chars by any UA I know of |
| 01:44 | <aho> | good :) |
| 01:51 | <ajh_555> | Odd that “even” IE9 allows backticks… I thought they were baking in fundamental HTML5 support. |
| 01:52 | <ajh_555> | Correct me if I’m wrong but things should break fairly obviously if you pasting smart quotes — troublesome to the dev, perhaps, but not a long-term XSS fret? |
| 01:53 | <zewt> | you're using smart quotes as apostrophes, by the way :) |
| 01:57 | <ajh_555> | Yeah, it’s a habit. I actually type them. |
| 01:58 | <zewt> | as apostrophes? why? heh |
| 01:58 | <ajh_555> | they’re typographically correct. I use smart quotes for quoting purposes too. |
| 01:58 | <ajh_555> | I guess I’m just kind of anal about design stuff sometimes. |
| 01:58 | <zewt> | it's really just plain wrong to use a close quote as an apostrophe; one of the sillier bugs in Unicode |
| 01:59 | <ajh_555> | How do you figure? |
| 01:59 | <zewt> | apostrophes and single quotation marks are two different things, and we have characters for them both; why use close quotes when you mean apostrophe? |
| 02:00 | <zewt> | (i have no honest hope of there ever being any kind of consistency in the world around quotation marks, so this is entirely academic, heh) |
| 02:01 | <ajh_555> | In practice though, both the right quote and apostrophe are mapped to U+2019 |
| 02:01 | <ajh_555> | so the problem isn’t that I’m using the same character, it’s that you think Unicode should distinguish them? |
| 02:02 | <ajh_555> | which I could potentially be convinced of, it makes sense. |
| 02:02 | <zewt> | U+0027 has always been apostrophe |
| 02:02 | <zewt> | it seems bizarre to me that Unicode introduces a close quotation mark, and then goes and aliases apostrophe on top of it again |
| 02:03 | <ajh_555> | well… that’s the dumb apostrophe… Elements of Typographic Style says that character doesn’t really have a typographic purpose |
| 02:03 | <ajh_555> | Yeah that is weird |
| 02:04 | <zewt> | seems like it does nothing but muddy everything, since ' will never, ever be "phased out" as an apostrophe--it's not like it's something unicode can "deprecate" with any meaning |
| 02:05 | <ajh_555> | yeah |
| 02:05 | <ajh_555> | alright i’m splitting, it’s been fun. cheers all |
| 02:05 | <zewt> | heh later |
| 03:56 | <zewt> | "SHOULD+"? "MUST-"? is the IETF just high? |
| 04:25 | <paradisaeidae> | HiAll: Does this imply that html5 drag and drop functionality should by default be available to the svg dom? :: http://dev.w3.org/html5/spec/infrastructure.html#xml |
| 04:43 | <Hixie> | ok, i sent out the mail about PeerConnection |
| 04:43 | <Hixie> | next on my list is figuring out some mechanism for keeping multiple audio and video tracks in sync |
| 04:44 | <Hixie> | (also known as "issue 152" to those following along in the htmlwg) |
| 05:16 | <jamesr___> | Hixie: where'd you send the mail about PeerConnection? i don't see anything on whatwg yet |
| 06:12 | <Hixie> | jamesr___: oops, it hit the size limit. moderated it out of the queue. :-) |
| 06:14 | <jamesr___> | hah! |
| 07:14 | <hsivonen> | AryehGregor: from past communication, I've drawn the conclusion that if one bothers to respond at all, it is prudent to make sure that everything is unambigously formulated as objections so that nothing accidentally gets treated as a side observation or expression of support for something |
| 07:33 | <matjas> | looks like there’s a typo in http://html5.org/tools/web-apps-tracker?from=5956&to=5957 that hasn’t been fixed yet |
| 07:34 | <matjas> | “given the value <code title="">image/*</code>, a user agent could offer the user the option of recording a clip using a headset microphone.” |
| 07:34 | <matjas> | i guess that should’ve been audio/*, not image/* again |
| 07:34 | <matjas> | is Hixie reading this or should i file a bug for this? :) |
| 07:35 | <zcorpan> | matjas: probably both |
| 07:36 | <matjas> | k |
| 07:38 | <Hixie> | matjas: did you file a bug? |
| 07:38 | <Hixie> | if not i can fix it now |
| 07:38 | <matjas> | Hixie: I was just doing it; haven’t submitted yet |
| 07:38 | <matjas> | Hixie: ok, that would be great |
| 07:38 | <Hixie> | k don't bother |
| 07:38 | <Hixie> | fixing it now |
| 07:38 | <Hixie> | thanks |
| 07:38 | <matjas> | \o/ |
| 07:40 | <Hixie> | should be fixed |
| 07:41 | <matjas> | yay, thanks |
| 07:41 | <matjas> | http://html5.org/r/5959 |
| 08:10 | <zcorpan> | Hixie: are the four bytes 0x00 0x00 0x00 0x01 the extension area? |
| 08:15 | <hsivonen> | whoa. plh objected to Hixie's CP for ISSUE 120 (RDFa prefixes) |
| 08:15 | <hsivonen> | that's rather unusual |
| 08:16 | <hsivonen> | do the Chairs now have a choice how to Decide when a person who can remove them from chairship objected? |
| 08:17 | <jamesr___> | whois plh ? |
| 08:17 | <hsivonen> | jamesr___: Philippe Le Hégaret, the Domain Leader |
| 08:20 | <zcorpan> | Hixie: being able to stop sending audio but continue sending video seems useful for conferencing |
| 08:22 | <jamesr___> | where did he register this objection? |
| 08:22 | <hsivonen> | jamesr___: http://www.w3.org/2002/09/wbs/40318/issue-120-objection-poll/results |
| 11:10 | <zcorpan> | i hope the html wg doesn't decide to publish next week |
| 12:11 | <hsivonen> | zcorpan: why? |
| 12:24 | <zcorpan> | hsivonen: i'll be on vacation so can't update html5-differences |
| 12:29 | <hsivonen> | zcorpan: I see |
| 15:26 | <TabAtkins> | zewt: Where's the "SHOULD+" and "MUST-" stuff from? |
| 15:27 | <zewt> | http://tools.ietf.org/html/rfc4835 |
| 15:28 | <TabAtkins> | ...okay, yeah, they're high. |
| 15:40 | <hsivonen> | AryehGregor: not sure if someone replied to you already about HW accel in Firefox, but there are at least 5 types of HW accel I can think of: |
| 15:40 | <hsivonen> | 1) Accelerating 3D drawing |
| 15:40 | <hsivonen> | 2) Accelerating 2D drawing |
| 15:40 | <hsivonen> | 3) Accelerating compositing |
| 15:40 | <hsivonen> | 4) Accelerating YUV to RGB conversion |
| 15:41 | <hsivonen> | 5) Accelerating video decompression |
| 15:42 | <hsivonen> | AryehGregor: Firefox accelates compositing on XP, Vista, Windows 7 and Mac. 2D drawing on Linux, Vista and Windows 7. |
| 15:42 | <hsivonen> | AryehGregor: s/Mac/Snow Leopard/ actually |
| 15:43 | <hsivonen> | 3D drawing on XP, Vista, Windows 7, Snow Leopard and Linux |
| 15:43 | <hsivonen> | and I *think* YUV to RGB somewhere but I don't know where |
| 15:43 | <hsivonen> | all subject to drivers |
| 15:44 | <hsivonen> | AryehGregor: so comparing XP and Windows 7, XP doesn't get the acceleration of 2D drawing |
| 15:44 | <hsivonen> | AryehGregor: I understand that IE9 in some cases accelerates video decompression, too |
| 15:48 | <zewt> | know where it fits video scaling into there? logically it's part of 2d drawing, but video scaling is too important to only support in vista (though I havn't checked, so maybe it does) |
| 15:48 | <zewt> | (it could be done as part of compositing, too) |
| 15:49 | <zewt> | (or with hardware yuv/rgb conversion, integrated with that--lots of ways to do video, heh) |
| 16:54 | <zewt> | ugh suddenly window.URL is webkit.webkitURL in chrome, more mess to work around... |
| 17:07 | <zewt> | seems like they're misapplying CSS -naming-prefixes to javascript objects... that, or they hit some real pages where suddenly having a global "URL" breaks pages (which I havn't seen, but wouldn't be all that surprised by) |
| 17:12 | <TabAtkins> | Well, if you're adding something experimental in JS, the naming convention is indeed to still do vendor prefixing. |
| 17:12 | <TabAtkins> | I dunno why we would have switched from plain URL to webkitURL, though. |
| 17:28 | <zewt> | for CSS it makes sense: there's no feature testing in CSS, so if browsers implement foo-property before it's fixed, and that property changes incompatibly, then using the final foo-property can break things later on, with the old and new versions both in the wild |
| 17:29 | <TabAtkins> | Actual feature-testing, as in trying out the property and seeing if it works, is often too expensive or impractical. Name detection is much cheaper and usually good enough, so why not make that easy? |
| 17:29 | <zewt> | but you can feature test this stuff in JS explicitly--if there's "webkitURL", then it should also be webkitBlob, webkitCanvas, webkitWorker, for every non-finalized spec |
| 17:30 | <TabAtkins> | The JS criteria for what makes a spec sufficiently stable to drop the prefix is *way* more permissive than the CSS one. |
| 17:30 | <TabAtkins> | Typically you just prefix if you're doing something experimental. As soon as it hits a spec that other browsers have given the thumbs up on, you drop the prefix. |
| 17:31 | <zewt> | er, but window.URL is also implemented in FF4 |
| 17:31 | <TabAtkins> | Yeah, as I said, I don't know why we did webkitURL. |
| 17:32 | <zewt> | i sort of get it for webkitNotifications (the only other one in window), since that's a really bleeding-edge spec ... though I might only think that since I havn't used it and I've used createObjectURL a lot |
| 17:33 | <zewt> | (though from what I recall reading that spec, it's nowhere near complete yet, at least according to its use case section) |
| 17:42 | <AryehGregor> | Where's the unofficial HTML version of ES5? |
| 17:43 | <AryehGregor> | Google is failing me. |
| 17:43 | <nimbupani> | https://github.com/sideshowbarker/es5-spec ? |
| 17:43 | <nimbupani> | oops http://es5.github.com/ |
| 17:43 | <AryehGregor> | Thanks. |
| 18:04 | <AryehGregor> | jgraham, do you mind if I hack your error reporting code to pretty-print values? Like so undefined and "undefined" don't look like the same thing? |
| 18:04 | <AryehGregor> | I mean for testharness.js, clearly. |
| 18:05 | <zewt> | heh reminds me of someone getting confused on www-dom recently, because eg. addEventListener(null, ...) ends up being addEventListener("null", ...) |
| 18:05 | <zewt> | everyone loves them some implicit conversions, right? |
| 18:30 | <zewt> | oops, opened an inspect window in chrome on the web-apps spec |
| 18:30 | <zewt> | may not be the smartest thing I've ever done |
| 19:01 | Hixie | starts looking at the video sync use cases |
| 19:12 | <TabAtkins> | Hixie: I blame you for not speccing cjk lists correctly. >_< |
| 19:12 | <Hixie> | i accept full blame |
| 19:12 | <Hixie> | the spec wasn't complete when i stopped working on it |
| 19:12 | <Hixie> | hence the 200+ e-mails i sent you :-) |
| 19:12 | <TabAtkins> | Heh, kk. |
| 19:13 | <Hixie> | i was planning on returning to it in 2018 or so |
| 19:13 | <TabAtkins> | ...you make plans that far ahead? |
| 19:13 | <Hixie> | though i doubt anyone on the wg actually believed me when i said that back in 2005 or so |
| 19:13 | <Hixie> | sure |
| 19:13 | <Hixie> | i planned the html work up to 2022 |
| 19:13 | <Hixie> | (and we're still on track) |
| 19:13 | <TabAtkins> | Other than "I want to have a lot of money when I retire", I've got no plans extending more than 2 or 3 years into the future. |
| 19:14 | <Hixie> | well specs take decades to get right |
| 19:14 | <Hixie> | it's hard not to plan ahead if one wants to succeed :-) |
| 19:18 | Hixie | ponders in-band tracks |
| 19:18 | <Hixie> | does anyone have any examples i can look at of video files with multiple in-band tracks? |
| 19:19 | <zewt> | multiple audio/sub tracks, or more esoteric examples? |
| 19:20 | <Hixie> | multiple audio or multiple video tracks |
| 19:20 | <Hixie> | not subs |
| 19:20 | <Hixie> | hohoho, look at this, media-frags already supports picking tracks |
| 19:20 | <Hixie> | eeeexcellent |
| 19:20 | <zewt> | multiple audio is common on dvds/bds with commentary and dub tracks... never seen multiple video tracks, ever |
| 19:21 | <TabAtkins> | Yay media fragments! Now if only someone would implement them... |
| 19:21 | <Hixie> | zewt: sorry i meant actual video files on the web |
| 19:22 | <Hixie> | zewt: agreed that dvds do this |
| 19:22 | <zewt> | well, the ones I have are based on dvds ... :) |
| 19:23 | <Hixie> | oh tools rip multitrack dvds to video files with multiple audio tracks? |
| 19:23 | <Hixie> | interesting |
| 19:23 | <Hixie> | good to know |
| 19:23 | <zewt> | most commonly with .mkv files, in practice |
| 19:48 | <zewt> | dreaming of the day there are sufficient APIs for people to make formatted editors that aren't glitchy and strange |
| 19:48 | <zewt> | even gmail's is seriously unpleasant to work with |
| 19:50 | <aho> | i once created a multi video track mkv... it was weird |
| 19:50 | <aho> | vlc opened two displays simultaneously |
| 19:51 | <aho> | mpc ignored the second track |
| 19:51 | <aho> | wasn't really sure what i had to expect tho :> |
| 19:51 | <zewt> | multitrack video seems of really questionable use ... since interleaving the tracks means it'll jack the bitrate way up when you're still just viewing one track |
| 20:00 | <AryehGregor> | Whoever decided that switch statements should default to falling through needs to be hit very hard on the head with a crowbar. |
| 20:00 | <AryehGregor> | Would requiring "continue;" to fall through be so hard? |
| 20:01 | <zewt> | i'd imagine so, since that means something else :) |
| 20:01 | <hober> | AryehGregor: but that would make Duff's device be so ugly |
| 20:01 | <hober> | :) |
| 20:01 | <AryehGregor> | Does "continue;" mean something else in a switch statement? |
| 20:01 | <AryehGregor> | hober, maybe that's a good thing . . . |
| 20:02 | <Hixie> | AryehGregor: what language? |
| 20:02 | <AryehGregor> | JavaScript, at the moment, but it's a general observation. |
| 20:02 | <Philip`> | You want to support "case 1: case 2: case 3: /* do something common */; break; case 4: case 5: ..." without explicit fallthrough syntax |
| 20:02 | <Hixie> | as far as i can tell the languages that default to fallthrough are the languages that don't have a good way of giving multiple values in the 'case' |
| 20:02 | <TabAtkins> | AryehGregor: Right now, 'continue' means "skip to the next iteration of the enclosing loop" if used in a switch, like it would anywhere else. |
| 20:03 | <AryehGregor> | Oh, that's a point. |
| 20:03 | <zewt> | the "switch fallthrough" thing always felt like one of those looks-like-a-huge-oroblem-but-it's-really-not scenarios |
| 20:03 | <AryehGregor> | case 0: case 1: something(); break; wouldn't work then. |
| 20:03 | <AryehGregor> | Sigh. |
| 20:03 | <AryehGregor> | Oh well. |
| 20:03 | <foolip_> | Philip`, ping about the spec splitting: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication |
| 20:03 | <zewt> | where people seem to complain about it a lot, but which I've never actually had trouble with |
| 20:03 | <Philip`> | It looks like C# allows "case 0: case 1: ...", and otherwise it requires an explicit "break" or explicit "goto case 3" |
| 20:04 | <zewt> | sort of like people who use yoda conditions because they think if(x = 1) is a big, confusing problem in C--but it's not ... |
| 20:04 | <Hixie> | pascal for instance doesn't have fallthrough but allows stuff like: 1, 2, 3: ...; 4, 5: ...; |
| 20:04 | <Philip`> | so you can do explicit fallthrough and also you can reorder cases without subtly breaking things |
| 20:04 | <zewt> | my condolensces for having knowledge about pascal cluttering up your mind |
| 20:04 | <zewt> | i havn't touched that language since highschool :) |
| 20:04 | <Hixie> | i was going to say perl doesn't even have switch statements, but wikipedia says perl doesn't have fallthrough but allows it via 'continue' |
| 20:04 | <TabAtkins> | Lisp does the same thing with CASE. |
| 20:04 | <Hixie> | wonder if they're talking about perl6 |
| 20:04 | <TabAtkins> | I mean COND. |
| 20:04 | <aho> | personally, i think fallthrough would be fine if it were a keyword that is :> |
| 20:05 | <Hixie> | zewt: as someone who switches between languages a lot, the '=' vs '==' has been the source of an ungodly number of bugs in my code |
| 20:05 | <Philip`> | Perl 5.10 has 'use feature "switch";' |
| 20:05 | <Hixie> | really! |
| 20:05 | <Hixie> | i had no idea |
| 20:05 | <Philip`> | http://perldoc.perl.org/perlsyn.html#Switch-statements |
| 20:06 | <Hixie> | ooo |
| 20:06 | <aho> | Hixie, using = in a context where == (or ===) is typically used usually generates some kind of warning |
| 20:06 | <zewt> | (perl--even more condoleces than pascal) |
| 20:06 | <aho> | and you have to add some extra paraens to supress it |
| 20:06 | <aho> | eg if ((x=5)) |
| 20:06 | <zewt> | aho: unless you're stuck in MSVC :| |
| 20:06 | <zewt> | unless they've added that in 2010, last I used was 2008 |
| 20:07 | <Philip`> | zewt: 2008 warns about it |
| 20:07 | <Philip`> | (under /W4, it seems) |
| 20:07 | <zewt> | does it not disable the warning if you parenthesize? |
| 20:07 | <Philip`> | http://msdn.microsoft.com/en-us/library/7hw7c1he(v=vs.80).aspx |
| 20:07 | <zewt> | trying to remember what the oddness was, or maybe we just never enabled that warning in that compiler |
| 20:08 | <Philip`> | Oh, apparently parentheses don't disable it |
| 20:08 | <zewt> | ah yeah |
| 20:08 | <zewt> | so i'd have disabled the warning |
| 20:08 | <zewt> | since that's even more broken :| |
| 20:08 | <Philip`> | Is adding '!= 0' that hard? |
| 20:11 | <zewt> | normally it ends up with things like if((f = fopen()) != NULL) |
| 20:11 | <zewt> | granted, I've been less inclined to do that anyway in more recent years |
| 20:13 | <Hixie> | aho: i usually do it in js |
| 20:13 | <aho> | jslint complains about that if you dont add extra parens :> |
| 20:13 | <aho> | well, at least i'm fairly sure it does |
| 20:13 | <gsnedders> | jslint complains about many random things. |
| 20:13 | <aho> | (i never made that mistake for some reason) :> |
| 20:13 | <Hixie> | zewt: objectpascal is actually a really nice language. |
| 20:14 | <Hixie> | but yeah, i don't use it much :( |
| 20:14 | <hober> | my first non-basic, high-level language :) |
| 20:14 | <aho> | if (x = 3) -> "Expected a conditional expression and instead saw an assignment." |
| 20:15 | <Hixie> | and perl is a really powerful language but very easy to screw up |
| 20:15 | <aho> | if ((x = 3)) <- same... aww |
| 20:15 | <Hixie> | anyway |
| 20:15 | <zewt> | perl is great as an example of how to never design a language, and that's about it :) |
| 20:15 | <aho> | if (!!(x = 3)) <- fine... yuck :D |
| 20:16 | <zewt> | heh |
| 20:16 | <gsnedders> | For some reason I got complained at when myself/a friend rewrote a sed script in Perl. |
| 20:16 | <zewt> | i've sometimes done that to quiet MSVC's warning on implicit int -> bool conversions |
| 20:16 | <Hixie> | perl is fantastic for really short code, like one-liners or short throwaway text file munging code |
| 20:16 | <zewt> | the only thing I use perl for is for things sed/awk used to be for; and even then, only for commandline throwaways, not for anything I'll have to come back to |
| 20:17 | <Hixie> | it's also good for things where you're going to do a ton of string manipulation, cos it has really good text handling primitives |
| 20:17 | <Hixie> | it's not great for complicated logic, where you really need a strongly typed language |
| 20:18 | <Hixie> | (that's one area where objectpascal really shines) |
| 20:18 | <zewt> | low-level: C++. high-level: python. embedding: lua. web: javascript. |
| 20:19 | <Hixie> | none of those have good typing systems |
| 20:20 | <gsnedders> | Haskell ftw! |
| 20:20 | gsnedders | hides from jgraham |
| 20:20 | <Hixie> | i haven't done much with functional languages other than scheme, i really should at some point |
| 20:20 | <Hixie> | unfortunately i rarely have purely functional problems to solve |
| 20:20 | <Hixie> | usually it's really stateful things like web apps |
| 20:20 | <Hixie> | or ui |
| 20:20 | karlcow | votes for human language and poetry |
| 20:21 | <zewt> | everything i've ever seen about functional languages just seems totally academic |
| 20:21 | <zewt> | so i've mostly ignored them |
| 20:21 | <Hixie> | human language is what i use as my main programming language in my job |
| 20:21 | <Hixie> | but the compilers are really slow |
| 20:21 | <gsnedders> | :) |
| 20:21 | <Hixie> | and tend to complain a lot more :-P |
| 20:21 | <karlcow> | ahaha |
| 20:22 | <Hixie> | bbiab, food. |
| 20:23 | <zewt> | who gives more, longer and more nonsensical complaints: people, or an angry C++ compiler and some templates |
| 20:40 | <Philip`> | I like functional languages (or at least OCaml; I haven't tried using Haskell) for writing compilers |
| 20:41 | <Philip`> | since they seem good at dealing with complex tree-structured data types |
| 20:42 | <Philip`> | (because of pattern matching, and static typing that can tell when you've handled all the cases) |
| 20:52 | <kennyluck> | I used to think human language is stupid. I guess I still think it is. |
| 20:53 | <TabAtkins> | Don't get me started on human language. |
| 20:55 | <TabAtkins> | Do any of the browsers support mathml-in-html yet? |
| 20:56 | <paul_irish> | FF does |
| 20:56 | <TabAtkins> | Excellent. |
| 20:57 | <paul_irish> | There is no summary of the <device>, stream API, etc activity that's going on, is there? |
| 20:57 | <paul_irish> | those discussions are terribly difficult to keep track of. |
| 20:57 | <TabAtkins> | No. |
| 20:57 | <TabAtkins> | Though, I guess Hixie's recent mega-email kinda works. |
| 20:58 | <paul_irish> | aye |
| 20:58 | <nimbupani> | TabAtkins: so does Opera >_> |
| 20:58 | <nimbupani> | at least the ragnarok build |
| 21:01 | <TabAtkins> | paul_irish: No one ever said standards is easy. |
| 21:08 | <paul_irish> | true story |
| 21:14 | <AryehGregor> | Looks like the HTML serialization algorithm doesn't know about <xmp> or <plaintext>. |
| 21:14 | <Hixie> | not much to do with <plaintext> |
| 21:15 | <Hixie> | though i guess we could omit optional end tags after it or something if we cared |
| 21:16 | <TabAtkins> | I'm sad that the CSS spec post-processor barfs on <xmp>. I had to remove my use of it. ;_; |
| 21:16 | <AryehGregor> | Actually, not much you can do about <xmp> either . . . you can easily create unserializable DOMs this way. |
| 21:16 | <AryehGregor> | TabAtkins, port it to an HTML5 parser. |
| 21:16 | <Yuhong> | hsivonen: In http://hsivonen.iki.fi/doctype/test-quirks.php, the support for X-UA-Compatible faking do not work properly. |
| 21:16 | <TabAtkins> | I don't want to spend the time porting Bert's processor, though it would probably be worthwhile... |
| 21:17 | <jgraham> | AryehGregor: Of course not. I have been meaning to do it but haven't got around to it |
| 21:17 | <jgraham> | AryehGregor: I don't think reporting "this browser passes all tests for this feature" is good |
| 21:17 | <AryehGregor> | jgraham, okay, let me do that then. I've got a decent one (IMO :) ) written up for my reflection harness. |
| 21:17 | <AryehGregor> | Why not? |
| 21:18 | <jgraham> | If a browser already passes all tests the tests aren't good enough, probably |
| 21:18 | <jgraham> | and it creates *really bad* incentives |
| 21:18 | <AryehGregor> | Firefox already passes my base64 tests, and that's legit. |
| 21:18 | <AryehGregor> | Why does it create really bad incentives? |
| 21:18 | <AryehGregor> | I mean, what incentives, specifically? |
| 21:19 | <jgraham> | Because it makes things very binary. Either you pass everything and get praise or pass less than everything and get nothing |
| 21:19 | <AryehGregor> | It's still per-feature. |
| 21:19 | <jgraham> | So there is a strong incentive not to submit tests that you fail |
| 21:19 | <AryehGregor> | Well, there's already an incentive to not submit tests you fail. |
| 21:19 | <AryehGregor> | Just look at Microsoft. |
| 21:19 | <jgraham> | Even stronger than if there is a continum |
| 21:19 | <AryehGregor> | But your competitors will have a *very* strong incentive to submit tests that you fail. |
| 21:20 | <AryehGregor> | So let's just assume no one will submit any tests except the ones they pass. |
| 21:20 | <AryehGregor> | Still no problem. |
| 21:20 | <AryehGregor> | I mean, why is that a problem, really? |
| 21:20 | <jgraham> | I don't like that assumption. In particular I personally don't wanthat |
| 21:20 | <AryehGregor> | Why not? What's wrong with it? |
| 21:20 | <AryehGregor> | It doesn't matter who writes the tests, as long as they're written. |
| 21:21 | <zewt> | i'd expect that if test results are submitted with tests omitted, the assumption would be that those tests failed |
| 21:21 | <jgraham> | I would hate to develop good tests that I was prevented from submitting for PR reasons |
| 21:21 | <Philip`> | It seems bad to design the process around the idea that all participants are purely rational and will always follow the designed incentives |
| 21:21 | <AryehGregor> | That's a personal reason. I'm asking for a reason from the perspective of the test suite's quality. |
| 21:21 | <zewt> | perhaps reported differently, eg. "implicitly-failed" |
| 21:21 | <Philip`> | People are much more random than that |
| 21:22 | <AryehGregor> | What problem will it cause for the test suite's quality if that's our assumption? |
| 21:22 | <TabAtkins> | Philip`: If they're significantly random, then no incentives are useful, so we can ignore them when designing incentives. |
| 21:22 | <jgraham> | The asdsumption that someone else will write an equivalent test is highly dubious |
| 21:22 | <jgraham> | *assumption |
| 21:22 | <jgraham> | Different organisations have shown different levels of commitment to the testsuite |
| 21:22 | <AryehGregor> | Philip`, no, you can't completely rely on people following incentives, but incentives are still helpful. |
| 21:22 | <Hixie> | (fwiw, if you have written valid tests and the company you work for prevents you from submitting them for any reason, PR or otherwise, send me your resume.) |
| 21:23 | <AryehGregor> | jgraham, you only need two. |
| 21:23 | <jgraham> | Different organisations have different internal structures |
| 21:23 | <AryehGregor> | Also, yeah. |
| 21:23 | <AryehGregor> | I'm pretty sure Google and Mozilla people are not going to be prevented from submitting tests just because it makes them look worse. |
| 21:23 | <Yuhong> | Yea, MS is the most non PR 2.0 compliant browser vendor, and has been for a while now. |
| 21:23 | <AryehGregor> | I mean, your alternative basically creates no incentives for anyone to do anything. |
| 21:24 | <AryehGregor> | Is that really superior? |
| 21:24 | <Philip`> | TabAtkins: Microsoft seems pretty random and it seems AryehGregor is trying to design a process to incentivise Microsoft differently |
| 21:24 | <Hixie> | if anyone stops anyone at google submitting tests for pr reasons, i and probably many others will go non-linear. |
| 21:24 | <AryehGregor> | Philip`, no, Microsoft is already acting according to my incentives for PR reasons without those incentives existing yet. :) |
| 21:24 | <Hixie> | i would imagine the same applies to mozilla, and certainly the same applied at opera when i was there. |
| 21:24 | <AryehGregor> | (in that they only submit tests that make them look good and other browsers bad) |
| 21:24 | <jgraham> | My scheme is designed to stop all the badness associated with reporting results of an unfinished testsuite |
| 21:24 | <Hixie> | i mean, just look at acid2... howcome and i actually made opera fail on it worse than it originally did :-) |
| 21:24 | <AryehGregor> | (I wonder how many tests they didn't submit because too many competitors pass them) |
| 21:25 | <jgraham> | I don't think that creating incentives to releasing tests is the problem |
| 21:25 | <AryehGregor> | jgraham, you seem to be very against using the test suite to promote any kind of inter-browser competition. |
| 21:25 | <AryehGregor> | As far as I see it, that's one of the most important purposes of the test suite, and the key to getting it to be complete. |
| 21:25 | <Philip`> | AryehGregor: A Microsoft person approved all the canvas tests, even though they fail lots of them, so they don't seem to be acting purely to gain 100% scores |
| 21:26 | <Hixie> | (having said all that, i'm kinda with jgraham that test suites should just report results neutrally without granting extra praise if you hit particular thresholds like 100%) |
| 21:26 | <jgraham> | AryehGregor: I am happy for parts of the testsuite where there is reasonably ood coverage to be used in that way |
| 21:26 | <AryehGregor> | Philip`, they also corrected some of their submitted tests even when that made IE fail them. They're not going to try to get perfect scores if they have to do something dishonest publicly, that people can call them out on. |
| 21:26 | <jgraham> | *good |
| 21:27 | <AryehGregor> | jgraham, I'm fine with only reporting results where we feel there's good coverage. |
| 21:27 | <Philip`> | AryehGregor: They say things in blog posts where people call them out on dishonesty all the time |
| 21:27 | <jgraham> | AryehGregor: So, going back to the original problem, you need a way to highlight "this test fails in all browsers and so could well be buggy" |
| 21:27 | <AryehGregor> | Hixie, why? The percentage doesn't really mean anything. You could fail every test due to one trivial bug, or you could fail almost no tests despite major bugs, depending on how the tests are written. |
| 21:27 | <zewt> | they also edit blog comments by other people to say things they didn't say :) |
| 21:27 | <AryehGregor> | Philip`, well, yes. But there are limits. |
| 21:28 | <jgraham> | My scheme does that without requiring laxy-journalist-friendly tables |
| 21:28 | <jgraham> | *lazy |
| 21:28 | <Hixie> | AryehGregor: because the percentage doesn't really mean anything, and nor does passing every test. |
| 21:28 | <AryehGregor> | zewt, no, that was probably just one guy. |
| 21:28 | <AryehGregor> | jgraham, that's orthogonal. I agree we should flag such tests, no matter what approval or reporting scheme we use. |
| 21:28 | <Hixie> | AryehGregor: the only thing that means anything is failure of an individual test, and all it means is that either the test, the spec, or the browser has a bug |
| 21:28 | <AryehGregor> | Although most of them are probably just "nobody implements this yet". |
| 21:29 | <AryehGregor> | Hixie, passing every test means there are no bugs known to the test suite maintainers in the implementation of that feature. That means something. |
| 21:29 | <Hixie> | only that the test suite is incomplete :-) |
| 21:29 | <jgraham> | AryehGregor: No |
| 21:29 | <AryehGregor> | If tests fail due only to spec or test bugs, you'd expect the implementer to figure that out and fix the tests. |
| 21:29 | <Philip`> | Trying to reverse-engineer Microsoft's private motivations and behaviour based on their public behaviour doesn't seem particularly reliable |
| 21:29 | <jgraham> | It means the test suite isn't good enough |
| 21:29 | <zewt> | who's doing something evil enough on a microsoft domain for me to associate some of that with the company |
| 21:29 | <Philip`> | (particularly since they're many individuals with different motivations, not a monolithic group mind) |
| 21:29 | <AryehGregor> | Hixie, jgraham: so do you have suggestions on what to add to my base64 tests so that Firefox fails a test? |
| 21:30 | <AryehGregor> | It's a pretty simple feature, it's not rocket science to match the spec exactly. |
| 21:30 | <Hixie> | jgraham: not necessarily that it's not good enough -- if there are other things that are failing, then it might just be that the test suite is good enough given the current priorities |
| 21:30 | <AryehGregor> | Of course there might be unknown bugs, but nothing's perfect. You can at least check for all known possible bugs. |
| 21:31 | <jgraham> | AryehGregor: No. Myabe for that feature it is possible to match the spec exactly. But for more complex features I would expect all browsers to fail a bit for a long time |
| 21:31 | <AryehGregor> | Yes, I totally agree. |
| 21:31 | <Hixie> | AryehGregor: i don't think it's a priority to test more things in that test suite at this point, so i'd say the test suite for that feature is good enough; but if everything else was to pass as well, then yes, i'd think that we could add things. |
| 21:31 | <Hixie> | AryehGregor: for example, what happens if you pass a 2.1GB argument to the method? |
| 21:31 | <AryehGregor> | Hixie, behavior is undefined, hardware limitations clause. :) |
| 21:31 | <AryehGregor> | (Do *I* have to tell *you* that?) |
| 21:32 | <jgraham> | AryehGregor: All behaviour is undefined due to that clause :) |
| 21:32 | <Hixie> | AryehGregor: if it crashes, that's a bug regardless of the spec |
| 21:32 | <AryehGregor> | It's a QoI bug. |
| 21:32 | <AryehGregor> | Browsers are allowed to crash due to hardware limitations. |
| 21:32 | <Hixie> | AryehGregor: if it hangs, it's a bug regardless of the spec |
| 21:32 | <Hixie> | AryehGregor: etc |
| 21:32 | <AryehGregor> | Still a QoI bug. |
| 21:32 | <AryehGregor> | Not a spec bug. |
| 21:32 | <Hixie> | didn't say it was |
| 21:32 | <Yuhong> | "Microsoft seems to have a stronger corporate agenda dictating the actions of its standards bodies representatives. Hickson [from Google] looks very independent" |
| 21:32 | <Yuhong> | from http://news.cnet.com/8301-30685_3-20008935-264.html#ixzz1EBjhiiN4 |
| 21:32 | <Hixie> | who cares if it's a spec bug |
| 21:33 | <AryehGregor> | Well, these are spec tests, not QoI tests. We deliberately don't want to test hardware limitations for the same reason we don't want to spec them. |
| 21:33 | <Hixie> | what matters is whether there's a bug or not, not whether there's a spec bug or not :-) |
| 21:33 | <Hixie> | oh it's quite possible that the w3c wouldn't want to test this, sure |
| 21:33 | <zewt> | well, the practical "optimum" behavioor for passing a 2.1GB argument, if there isn't enough memory, is probably to just disable scripts on the page entirely--which is rather hard to test... |
| 21:33 | <jgraham> | AryehGregor: If you do contentWindow.atob in an iframe in Firefox, it will probably throw a DOMException that is an instanceof a DOMException in the top frame. Eventually WebIDL will say that is wrong |
| 21:34 | <Hixie> | browser vendors presumably would (in the scenario we're talking about, where every other bug has been found and all the features are tested to the same comprehensive level) |
| 21:34 | <AryehGregor> | jgraham, well, your harness is the one that should be testing for that. |
| 21:34 | <AryehGregor> | Anyway, we've gotten off-topic. |
| 21:34 | <zewt> | on irc? never! |
| 21:34 | <AryehGregor> | (actually, no, I guess my test would have to be run in an iframe, but whatever, it's not specced yet) |
| 21:34 | <Hixie> | Yuhong: that's an ooooold article :-) |
| 21:34 | <AryehGregor> | (anyway the harness could also do it) |
| 21:35 | <Yuhong> | Hixie: but proves my point. |
| 21:35 | <jgraham> | AryehGregor: It doesn't test the negative i.e. it only checks that the DOMException is defined in the global is is supposed to be |
| 21:35 | <AryehGregor> | Okay, so back to the topic: the goal of the test suite approval and reporting procedure should be to get as many high-quality tests as possible. Yes or no? |
| 21:35 | <jgraham> | Not that it is not an instance of any other DOMExceptions in different globals |
| 21:36 | <jgraham> | AryehGregor: Pedantically, no. It should be to get the best coverage of implementations and the spec possible |
| 21:36 | <AryehGregor> | Okay, fine. |
| 21:36 | <AryehGregor> | It's basically the same idea if you assume a high-quality test doesn't duplicate other tests. |
| 21:37 | <AryehGregor> | So, to do so, we should try to design the process to encourage people and organizations to write and submit tests, and to encourage implementations to change to conform to the tests. Right? |
| 21:37 | <AryehGregor> | Just making sure our goals are clear here. |
| 21:37 | <jgraham> | The second part isn't really related to the goal you set |
| 21:38 | <AryehGregor> | Yes, okay. |
| 21:38 | <jgraham> | Of course having people pass tests is good, but it is in tension with making the best possible testsuite |
| 21:39 | <AryehGregor> | So actually, the goal is to get implementations to converge on standard behavior. |
| 21:39 | <AryehGregor> | That's the point of everything here. |
| 21:39 | <AryehGregor> | The point of the test suite is actually to further that goal. |
| 21:39 | <jgraham> | Yes, the testsuite is a tool |
| 21:39 | <AryehGregor> | Good now? Let's not confuse ends and means. |
| 21:40 | <AryehGregor> | Okay, now there are at least two ways the test suite can further that goal: |
| 21:40 | <Hixie> | i'm not really sure i'd agree with "we should try to design the process"... |
| 21:40 | <Hixie> | who needs process |
| 21:40 | <AryehGregor> | 1) Giving implementers a tool to identify where they fail. |
| 21:40 | <zewt> | a secondary goal, I think--which is related to that in a roundabout way--is also finding where implementations are universally *not* converging on the spec (suggesting a spec issue) |
| 21:40 | <Hixie> | just have someone in charge of the test suite and delegate all authority to them, if they do a bad job then fork |
| 21:40 | <AryehGregor> | 2) Pressure implementers to pass more of the tests (and thus, if the tests are good, converge on standard behavior). |
| 21:40 | <zewt> | (eg. the storage mutex) |
| 21:41 | <AryehGregor> | Hixie, are you volunteering? If not, who do you propose? |
| 21:41 | <Hixie> | if you want to do it, i'm all for you doing it :-) or jgraham :-) anyone who wants to do it, basically |
| 21:41 | <AryehGregor> | zewt, I deliberately said "standard behavior" to include behavior that might not match any written spec (in which case the spec should be written or changed). |
| 21:42 | <AryehGregor> | Hixie, but for the purposes of (2), it helps if they're endorsed by the W3C, so that the general public will accept their legitimacy more readily. |
| 21:42 | <Hixie> | o_O |
| 21:42 | <zewt> | that's not what I said, though--converging on a single behavior (that differs from the spec) and not converging at all are different things |
| 21:42 | <Hixie> | they're tests |
| 21:42 | <Hixie> | they're not for the general public |
| 21:42 | <AryehGregor> | Then do you disagree with my (2) above? |
| 21:42 | <Hixie> | their legitimacy is determined by their technical value, not by PR |
| 21:42 | <jgraham> | AryehGregor: The canonical example of (2) is acid 3 |
| 21:42 | <AryehGregor> | And think tests should only be for (1)? |
| 21:43 | <Hixie> | 2) is not the goal of the test suite imho |
| 21:43 | <AryehGregor> | jgraham, yes. Acid3 was flawed because it tested only a very narrow slice of things. |
| 21:43 | <Hixie> | the market should take care of 2 on its own |
| 21:43 | <Hixie> | if the standard isn't worth implementing interoperably then it should not be implemented interoperably |
| 21:43 | <AryehGregor> | Interesting perspective. |
| 21:43 | <AryehGregor> | From that perspective, we simply shouldn't report test suite results. |
| 21:43 | <Hixie> | entirely 100% agreed |
| 21:44 | <AryehGregor> | Although W3C process will require that each test be passed by two implementations. |
| 21:44 | <AryehGregor> | But let's forget about that for now. |
| 21:44 | <Hixie> | the w3c process is antiquated |
| 21:44 | <jgraham> | AryehGregor: I'm not saying Acid 3 was perfect. I'm saying it is the canonical example of optimising for PR |
| 21:44 | <jgraham> | and it happened outside W3C |
| 21:44 | <AryehGregor> | True. |
| 21:44 | <Hixie> | yeah, acid tests are a whole different beast |
| 21:45 | <AryehGregor> | Hixie, so wait, why is it okay for Acid3 to be designed for PR but not a real test suite? |
| 21:45 | <zewt> | reporting test results is useful for developers, who want to know how reliably they can use a particular feature (in more detail than "which vendors claim to implement it") |
| 21:45 | <Hixie> | they're pretty much the worst example of what a test suite is |
| 21:45 | <zewt> | (that's a separate goal, of course, so secondary) |
| 21:45 | <jgraham> | zewt: It seems reasonable to do that at the level of caniuseit.com |
| 21:45 | <Lachy> | acid tests are absolutely terrible for QA. They're only good for PR |
| 21:46 | <zewt> | jgraham: that's very, very broad--it only says whether a feature is generally supported by each browser |
| 21:46 | <jgraham> | zewt: i.e. you get someone knowlegable to go through the test results and decide which are critical failures and which are minor issues and put things in big categories like "not implemented", "too buggy to use" "acceptable", "good" etc. |
| 21:46 | <zewt> | (which is also useful, obviously) |
| 21:47 | <jgraham> | zewt: It seems about as useful as saying that a browser got 78% on a particular testsuite without any reference to the quality of the tests or why it failed |
| 21:48 | <jgraham> | It is quite trivial to set up a situation where a worse implementation gets a better score when one deals in percentages |
| 21:48 | <AryehGregor> | That's why all-or-nothing is a better approach. |
| 21:48 | <zewt> | "78% on a particular testsuite" is pretty useless anyway, I'm talking about individual test pass/fail reports |
| 21:48 | <jgraham> | No, all or nothing is the worst approach |
| 21:48 | <zewt> | all-or-nothing is utterly useless... |
| 21:48 | AryehGregor | wtfs at this templating code in testharness.js |
| 21:48 | <AryehGregor> | zewt, why? |
| 21:49 | <jgraham> | AryehGregor: (I apologise for that code) |
| 21:49 | <zewt> | conversely, how is it useful? |
| 21:49 | <AryehGregor> | It's useful because if the browser passes all tests, you know it has no known bugs. |
| 21:49 | <AryehGregor> | If it passes any less than that, you have to get into very subjective evaluations of the importance of the various failures before you can pass judgment. |
| 21:49 | <zewt> | for example, every browser will always fail a storage test, because no browser (afaik) implements or has any plans of implementing the storage mutex. it's not useful to see "storage: failed"; it should be one test of many, telling what particular bits failed |
| 21:50 | <AryehGregor> | If no browser implements it, it should be removed from the spec and thus not tested. |
| 21:50 | <zewt> | that's a conclusion you make from (among other things) looking at the test results. |
| 21:50 | <jgraham> | AryehGregor: Arguably the only incenive that creates is to add just enough tests for already well-tested parts of the spec that the competion fail to get a perfect score |
| 21:50 | <AryehGregor> | Of course the individual test results would still be available for those who wanted them. |
| 21:51 | <AryehGregor> | I meant that on the official-looking page where it says "BROWSER STANDARDS CONFORMANCE RESULTS" it should only report all-or-nothing. |
| 21:51 | <zewt> | "pass/fail" for whole features seems useful for nobody *but* PR: "we passed this test and nobody else did!" |
| 21:51 | <jgraham> | zewt: It seems entirely unreasonable to expect a web developer to go through 100,000 tests to determine which features they can use |
| 21:51 | <AryehGregor> | Yeah, I'm saying that we should use pass/fail for PR while implementers use the actual lists of failures. |
| 21:51 | <zewt> | jgraham: i hope the tests are organized somewhat better than a soup of 100000 tests :) |
| 21:52 | <jgraham> | zewt: Even if it is just a few hundred tests for a feature |
| 21:52 | <Hixie> | "if the browser passes all tests, you know it has no known bugs" is clearly not true, since there are almost certainly known bugs without tests yet |
| 21:52 | <Hixie> | s/clearly/often/ |
| 21:53 | <AryehGregor> | Hixie, if it had publicly known bugs, anyone (e.g., its competitors) could submit new tests to make it fail. |
| 21:53 | <AryehGregor> | So you'd expect that to happen pretty soon. |
| 21:53 | <zewt> | jgraham: i'd find it useful to be able to look in detail at known cross-browser issues based on test results--is there really any reason to *not* make that information available? |
| 21:53 | <Hixie> | if you want to do pr, you should design something for pr, not use a test suite designed to check for correctness |
| 21:53 | <AryehGregor> | But we want browsers to get good PR only if they're correct. |
| 21:54 | <AryehGregor> | Acid3 gives them good PR only if they partially implement a bizarre subset of web features just enough to pass the tests. |
| 21:54 | <zewt> | AryehGregor: suggestion: if you want to make "having any tests failing at all" look bad, don't format it as "140/150 tests passed"; say "10 tests failed" |
| 21:54 | <jgraham> | AryehGregor: In any case I remain utterly unconvinced that a system that encourages people to not submit tests that make them fail and relies on other people coming up with the same test later to get the same coverage is a good idea |
| 21:55 | <jgraham> | It seems like the most stable equlibrium is at 100% pass for everyone and a poor quality testsuite |
| 21:56 | <AryehGregor> | jgraham, that will never happen if your competitor (or some random person) can find a bug and submit a test for it. |
| 21:56 | <AryehGregor> | So it's not stable at all. |
| 21:56 | <AryehGregor> | The only stable equilibrium is either everyone passing or everyone failing, for a given test. |
| 21:56 | <AryehGregor> | Actually, everyone passing is only a stable equilibrium if no one has any easily-spotted bugs. |
| 21:56 | <zewt> | often the workflow for projects, when they discover a bug, is to fix the bug and add a regression test (in their own test suite) for the bug at the same time--rather than adding a failing test and then coming back to fix it months later |
| 21:56 | <Hixie> | we don't want browsers to get PR at all from this |
| 21:56 | <Hixie> | or at least, i don't |
| 21:57 | <AryehGregor> | The problem with the scheme is that "everyone fails" might be too hard to get out of, for nontrivial features. |
| 21:57 | <jgraham> | AryehGregor: But it is quite stable because people are typically looking for bugs in thei own product not in others' and because people will know that if they submit a test that causes others to fail, the others will have an incentive to submit a test that makes them fail |
| 21:57 | <zewt> | so if you can get people to submit tests as part of that (eg. taking their regression test and submitting it as a spec test) as standard procedure, that'd probably lead to a lot of useful tests |
| 21:58 | <jgraham> | Hixie: Agreed. |
| 21:58 | <AryehGregor> | jgraham, random third parties can also submit tests, and so can people at places like Mozilla or Google where they won't stop you from doing it. |
| 21:58 | <jgraham> | AryehGregor: Even at Mozilla and Google there are incentives to look good on public tests |
| 21:58 | <AryehGregor> | zewt, that's helpful, but it's not going to get you really comprehensive tests. Regression tests have a different purpose from conformance tests. |
| 21:59 | <AryehGregor> | jgraham, I work for Google right now, and I have no incentive to make WebKit look good on tests. |
| 21:59 | <zewt> | regression tests are a subset of conformance tests; it's not enough, but it can be quite a lot |
| 21:59 | <jgraham> | AryehGregor: I presume there is some reason that people keep implementing parts of HTML5 in webkit just enough to score on tests but not enough to actually be used |
| 21:59 | <jgraham> | e.g. <details> |
| 22:00 | <AryehGregor> | jgraham, I don't know if that's why he's doing it. Maybe it would explain why their implementation is so terrible. |
| 22:01 | <AryehGregor> | But that's why results shouldn't be reported unless the test suite is reasonably comprehensive. |
| 22:01 | <AryehGregor> | Although for things where that implies good UI, it's kind of hard to test, granted. |
| 22:01 | <Hixie> | jgraham: make sure to keep tab in the loop when you spot things like this, he sits with the chrome team and can go sit on their keybord when they do that |
| 22:02 | <hober> | jgraham: what's wrong with the <details> impl? |
| 22:02 | <jgraham> | TabAtkins: Hixie thinks you are a cat |
| 22:02 | <jgraham> | hober: It seems to have no UI |
| 22:02 | <jamesr> | it's a hell of a lot easier to implement something to a specific set of tests than to somebody's vaguely stated requirements |
| 22:02 | <AryehGregor> | Hixie, I'm pretty sure he knows about their atrocious forms implementation, but he hasn't managed to stop it yet. |
| 22:02 | <AryehGregor> | jamesr, since when are HTML5 or related specs vague? |
| 22:03 | <jamesr> | rendering requirements are |
| 22:03 | <jamesr> | and test suites are always less vague than english |
| 22:03 | <Hixie> | yeah but that doesn't mean we get to just screw things up :-) |
| 22:04 | <AryehGregor> | Most of WebKit's forms implementation is not even subtly bad. It's inexcusably bad. |
| 22:04 | <AryehGregor> | Like a date-picker that behaves like a number-picker. |
| 22:04 | <jgraham> | jamesr: Implementing enough to pass feature detection, but not actually a useful form of the feature is just poisoning the well |
| 22:04 | <Hixie> | wow, i just tested <details> in chrome |
| 22:04 | <Hixie> | who the heck did that |
| 22:04 | <TabAtkins> | Yeah, our <details> thing was pretty crappy, since it screwed up modernizr. But we've got an actual impl going now. |
| 22:05 | <jamesr> | i think the date picker is pretty lulzy |
| 22:05 | <AryehGregor> | It's very clear that the forms stuff skipped the design phase. |
| 22:05 | <jamesr> | jgraham: i agree we shouldn't pass feature detection until the impl is at least passable |
| 22:05 | <AryehGregor> | Whereas Firefox's forms are really nice and well-designed. |
| 22:05 | <AryehGregor> | And Opera's are kind of mediocre, but at least they're not horrible. |
| 22:05 | <paul_irish> | AryehGregor: yeah.. though you've seen the WIP for the new datepicker? |
| 22:06 | <jgraham> | AryehGregor: I thought the implementation improved a lot recently? |
| 22:06 | <zewt> | can that be a test result summary: "at least it's not horrible" |
| 22:06 | <AryehGregor> | Whose, Opera's? |
| 22:06 | <Hixie> | i wish firefox did type=range |
| 22:06 | <jgraham> | (in Opera) |
| 22:06 | <AryehGregor> | I haven't checked recently. |
| 22:06 | <Hixie> | that's the main one i want to use |
| 22:06 | <paul_irish> | http://peter.sh/files/webkit-html5-date-picker.html |
| 22:06 | <Hixie> | that or type=color |
| 22:06 | <Hixie> | also really useful would be image borders |
| 22:06 | <paul_irish> | this is a few weeks back.. the <<< buttons got killed recently along with added polish |
| 22:06 | <jgraham> | AryehGregor: Please do. It must have been O11 where the new implemenation landed |
| 22:08 | <nimbupani> | TabAtkins: can I point typos in css3-values spec here? :) |
| 22:09 | <TabAtkins> | Could you hit me in a private message? I can make the edits, but there's no need to spam the rest of the channel. ^_^ |
| 22:09 | <nimbupani> | DONE.thnx. |
| 22:10 | <TabAtkins> | I'll get to them in a bit - just send them all to me now, don't wait for a response. |
| 22:10 | <nimbupani> | kay! |
| 22:12 | <jamesr> | jgraham: i agree that we (chrome) should do a better job on form control UI |
| 22:12 | <jamesr> | but you can't expect an automated test suite to enforce that |
| 22:12 | <Hixie> | yeah we need more manual test suites |
| 22:13 | <Hixie> | s/suites// |
| 22:13 | <Hixie> | more manual tests |
| 22:13 | <Hixie> | to test this kind of stuff |
| 22:13 | <Hixie> | make sure that the elements are rendering sanely |
| 22:13 | <jgraham> | jamesr: I don't expet an automated testsuite to enforce that |
| 22:13 | <Hixie> | make sure interaction is working right |
| 22:13 | <jgraham> | *expect |
| 22:14 | <AryehGregor> | How exactly is a test suite supposed to test UI if there are no UI requirements written down anywhere, in the spec or elsewhere? |
| 22:14 | <Hixie> | but still, shipping a feature as broken as <details> is on dev right now is pretty bad (haven't checked the release builds) |
| 22:14 | <Hixie> | AryehGregor: the spec has ui requirements |
| 22:14 | <jamesr> | AryehGregor: that's what i meant by rendering requirements being vague. they are some rendering requirements in the spec |
| 22:14 | <AryehGregor> | Ah, right. |
| 22:14 | <Hixie> | AryehGregor: "In the absence of style-layer rules to the contrary (e.g. author style sheets), user agents are expected to render an element so that it conveys to the user the meaning that the element represents" ... "The details element represents a disclosure widget from which the user can obtain additional information or controls" |
| 22:14 | <AryehGregor> | Well, each implementer has to make its own detailed rendering requirements in the usual UI design process. |
| 22:15 | <AryehGregor> | Oh, well, that's right. |
| 22:15 | <AryehGregor> | I was thinking of date-pickers and such. |
| 22:15 | <AryehGregor> | For <details> you're right. |
| 22:15 | <AryehGregor> | But I don't think the spec prohibits using a number-picker for a date-picker. |
| 22:15 | <AryehGregor> | (maybe it should) |
| 22:15 | <jgraham> | jamesr: Without knowing how Chrome development works I would expect this case to be caught by, say, code review. Or QA. |
| 22:15 | <AryehGregor> | Yeah, me too. But somehow it wasn't. |
| 22:16 | <Hixie> | also, re <details>, "If the [open] attribute is absent, the details are not to be shown" but despite the .open being implemented in chrome, the contents are still shown |
| 22:16 | <zewt> | that could be automatically tested, right? |
| 22:16 | <AryehGregor> | People have definitely complained to WebKit, but nothing has happened. |
| 22:16 | <Hixie> | AryehGregor: well, a number picker might make sense, i dunno. maybe some ubernerd wants a time_t skin for their browser. :-) |
| 22:16 | <AryehGregor> | zewt, how, looking at pixels? |
| 22:17 | <jgraham> | AryehGregor: getCompuedStyle, presumably |
| 22:17 | <AryehGregor> | That assumes they implement it by CSS . . . although I guess that's reasonable. |
| 22:17 | <AryehGregor> | Or not really. |
| 22:17 | <zewt> | i havn't looked at <details>--just seems like checking if something is shown is akin to testing display: none |
| 22:18 | <AryehGregor> | The <summary> is a child of <details>, but has to be shown even if it's closed. |
| 22:18 | <jgraham> | AryehGregor: Doesn't the rendering section require that? |
| 22:18 | <AryehGregor> | So you can't use display: none. |
| 22:18 | <AryehGregor> | Does it? |
| 22:18 | <AryehGregor> | "When the details element does not have an open attribute, this second container is expected to be removed from the rendering." |
| 22:18 | <Hixie> | (though "are not" is lame, i wonder why that's not a should... hmm...) |
| 22:19 | Hixie | files a bug |
| 22:20 | <Hixie> | huh, this 152 proposal from microsoft is terrible |
| 22:20 | <Hixie> | it doesn't even support audio descriptions when the video file contains them |
| 22:20 | <jgraham> | AryehGregor: "removed from the rendering" suggests it has 0 height |
| 22:20 | <Lachy> | that webkit date control prototype looks kind of nice, but unfortunately, still uses the same old basic UI that is tedious to use. |
| 22:20 | <AryehGregor> | "suggests" |
| 22:20 | <Hixie> | jgraham: fwiw the rendering section does have more details (in css terms) about how <details> is rendered |
| 22:21 | <jgraham> | AryehGregor: Well the rendering section requires more tealeaves than average |
| 22:21 | <AryehGregor> | Lachy, well, <select multiple> still displays in every browser (AFAIK) as something you can't actually use without knowing the magical Ctrl-/Shift-click secret. |
| 22:21 | <AryehGregor> | So I'm not optimistic about UI improving much beyond the basics. |
| 22:22 | <Lachy> | yeah, but select multiple is a relic from the past that doesn't get used too often these days. |
| 22:22 | <AryehGregor> | Only because it's so horrible. |
| 22:22 | <AryehGregor> | It would be useful if the UI weren't horrible. |
| 22:22 | <TabAtkins> | Opera Mini/Mobile (dunno which) actually rendered <select multiple> well, as a checkbox list. |
| 22:23 | <AryehGregor> | Yeah, I wish more browsers did. |
| 22:23 | <Lachy> | opera mini and mobile should use the same UI |
| 22:23 | <Hixie> | lynx too iirc |
| 22:23 | <zewt> | i wonder about ios/android webkits, since you don't have control- at all on a touchscreen |
| 22:23 | <Lachy> | at least, they do in recent versions. I will see what it looks like. |
| 22:29 | <TabAtkins> | Um, apparently Android totally screws up a <select multiple>. Wow. |
| 22:29 | <zewt> | i didn't feel like plodding through on my g1 to check. heh |
| 22:29 | <zewt> | hard to get motivated on hardware like that :) |
| 22:29 | <TabAtkins> | xanthir.com/test.html if you wanna look |
| 22:38 | Hixie | ponders how audio volume should work in a multitrack situation |
| 22:39 | <zewt> | for playing more than one track at once? |
| 22:39 | <Hixie> | yeah |
| 22:39 | <zewt> | very little prior art for that... |
| 22:39 | <Hixie> | suppose you have a video with a main audio track and an audio descriptions track |
| 22:39 | <Hixie> | all the implementations i've seen just have one volume control, i guess |
| 22:39 | <Hixie> | but that's not really the problem |
| 22:39 | <zewt> | yeah I can see the use cases for it, i've just never seen anything actually do it |
| 22:40 | <Hixie> | the problem is if we are exposing this as two objects, do they both get volume controls? and if so, what happens when you twist the volume knob? |
| 22:40 | <Hixie> | and what is saved as the user preference? |
| 22:41 | <zewt> | if it's a media player where i've selected "audio with descriptions", i'd still expect to get a single volume control |
| 22:41 | <Hixie> | yeah, it's the api i'm worried about, more than the ui |
| 22:41 | <Hixie> | or rather, how to make sure the api makes the ui work |
| 22:41 | <Hixie> | as people would expect |
| 22:42 | <zewt> | my initial reaction is separate volume controls: one for the whole audio element, and one per track |
| 22:42 | <zewt> | where the UI, and most users of the API, would only use the former |
| 22:42 | <Hixie> | if you've set the main audio to 50% and the audio description to 75%, and you twist the volume knob, can it take the other volumes any higher? |
| 22:42 | <zewt> | i've always only implemented volume control as attenuation |
| 22:43 | <Hixie> | and if so, does that mean that if you change the individual controls from the api, the master volume will appear to change? |
| 22:43 | <zewt> | so if channel 2 is set to 50%, it's not possible to turn the main volume control up to 200% and cancel it out |
| 22:43 | <Hixie> | or should the master volume only be able to reduce the volume, in which case the "real" volume is just multiplying each channel's volume by the master volume |
| 22:43 | <Hixie> | it seems like a poor user experience if the script sets the volume low that the user can't then bring it back up high |
| 22:43 | <zewt> | the latter: each volume control is [0,1], the final volume for each channel is their product, and the main volume control only affects the master attenuation |
| 22:44 | <zewt> | (don't know if this is necessarily the ideal approach--just a common, straightforward one) |
| 22:46 | <zewt> | hard to say if per-track volume controls are even important, without prior works to look at |
| 22:47 | <Hixie> | well if we use <audio> elements to represent multiple audio tracks, then they each get a volume control |
| 22:47 | <Hixie> | i guess we could force them equal, but that seems unintuitive from an API perspective |
| 22:47 | <Hixie> | the UI could drive them all together I guess |
| 22:47 | <zewt> | hmm, a use case I can think of where controlling each track's volume is useful: |
| 22:48 | <zewt> | if you have an intermittent description/commentary track, you might want to pull the volume of the main track down when someone makes a comment, then bring it back up |
| 22:48 | <zewt> | without doing so if the alternate track is disabled |
| 22:48 | <Hixie> | that's known as ducking |
| 22:48 | <Hixie> | we'd want to do that automatically, ideally |
| 22:48 | <zewt> | (i've done this myself, in games I've worked on) |
| 22:48 | <zewt> | that's tricky to do from an API perspective due to latency, though |
| 22:48 | <jgraham> | Doesn't this work the same way as the typical situation where you have one master volume control and one volume control per output device? |
| 22:49 | <Hixie> | jgraham: that would be the style zewt was suggesting |
| 22:49 | <jgraham> | Yes |
| 22:49 | <Hixie> | it's one option |
| 22:49 | <jgraham> | I would be surprised by other options |
| 22:49 | <jgraham> | Not by them existing |
| 22:49 | <jgraham> | But by their dissimilarity to the familar |
| 22:49 | <Hixie> | well don't forget from the user's perspective there's likely only going to be one knob at all |
| 22:50 | <zewt> | trying to make a one-knob UI with any other mechanism seems hairier |
| 22:50 | <Hixie> | the question is if the author made the volume low on all the tracks, should the user, manipulating a master knob, be able to make the audio audible |
| 22:50 | <jgraham> | I would expect a site that bothered to provide multiple tracks would also bother to have UI for controlling their relative volumes |
| 22:51 | <Hixie> | TVs don't |
| 22:51 | <Lachy> | Hixie, I'd expect the track volume to be exposed in an extra UI pane that the user can bring up, like an equaliser panel, or like the volume control window in Windows |
| 22:51 | <zewt> | not necessarily; it's more complex and possibly confusing for regular users |
| 22:51 | <zewt> | (i mean, they can always expose it as an advanced option, but as far as the standard UI goes) |
| 22:51 | <jgraham> | Pretty much all software does |
| 22:51 | <zewt> | (yeah what lachy said) |
| 22:51 | <jgraham> | Sure, I would expect the standard UI to be a single control |
| 22:52 | <jgraham> | But it seems silly to have multiple tracks if they can't be controlled seperately |
| 22:52 | <Hixie> | given the difficulties we've had getting browser vendors to expose UIs (see earlier discussion), i wouldn't count on even a single volume control being made available, frankly |
| 22:53 | <jgraham> | It also seems a bit silly to worry about the site doing something user-hostile |
| 22:53 | <Hixie> | but it seems bad to design the api on the basis that the UI will expose them all, either way |
| 22:53 | <Hixie> | worrying about sites doing user-hostile things is my day job :-P |
| 22:53 | <jgraham> | Presumably they can already screw with you by continually changing the volume |
| 22:53 | <TabAtkins> | Hixie: All the browsers expose a volume control on <video> and <audio> already. Only one, obviously. |
| 22:54 | <Hixie> | jgraham: it's the unintentional hostility i'm more worried about in this case |
| 22:54 | <jgraham> | (it seems more reasonable to assume that javascript-based video players will expose mixer UIs than browsers) |
| 22:54 | <Lachy> | for the API, the .volume property should just be the master volume, and then there could be an audio track API, perhaps exposed as a separate object, that lets scripts mute/unmute selected tracks and control their volume. |
| 22:55 | <Hixie> | which one should the UA remember as the preference? |
| 22:55 | <Hixie> | (in UAs that are so fine-grained) |
| 22:56 | <jgraham> | Hixie: That seems like a UA problem |
| 22:56 | <jgraham> | Why can't it remember all of them? |
| 22:56 | <zewt> | i'd expect the API for volume control to be identical for the master volume and each track: they're both just audio tracks--the master volume is just a track sourcing from the individual tracks |
| 22:57 | <Lachy> | are there use cases for also exposing APIs to controll the bass, treble, and surround sound mixers too? |
| 22:57 | <Hixie> | jgraham: it could, sure |
| 22:57 | <Hixie> | jgraham: just trying to understand what you had in mind |
| 22:58 | <zewt> | jgraham: provided tracks are tagged generically enough to meaningfully remember them |
| 22:58 | <Hixie> | Lachy: probably, but i'm hoping to deal with that separately |
| 22:58 | <jgraham> | zewt: Yeah it isn't quite a trivial problem |
| 22:58 | <zewt> | eg. saving the volume for "track 2 of foo.ogv" isn't too useful; but remembering the volume for "commentary tracks on origin http://whatever"; is more useful |
| 22:58 | <jgraham> | But neither is form autofill |
| 22:59 | <jgraham> | So possibly if it improves the user experience enough it will happen |
| 22:59 | <jgraham> | (possibly it won't be that useful though and the people who want it will have to install extensions or something) |
| 22:59 | <zewt> | Lachy: seems like that's pushing the scope out a lot more than volume |
| 22:59 | <zewt> | jgraham: in this case, i think playing multiple audio tracks simultaneously will be so rare browsers won't optimize it much |
| 23:00 | <zewt> | but who knows, heh |
| 23:00 | <Lachy> | Hixie, sure, but it's worth keeping in mind for the future. I'm thinking we could have an AudioControl object (or whatever name), in which we can have all the properties for controlling everything related to audio, and that could be exposed as HTMLMediaElement.audioMixer or something |
| 23:01 | <zewt> | yeah, that's what I had in mind above--eg. .volume, .onvolumechange, .mute, .unmute, etc., as an interface exposed for both the master channel and each individual track |