| 01:40 | <boblet> | If anyone’s around, I have a question about <nav> and breadcrumbs. I don’t think they’re suitable for <nav>, but some people seem to. Is this an “up to the author” case? |
| 02:15 | <Hixie> | boblet: would you want them skipped for AT users? |
| 02:17 | <boblet> | Hixie: I think so, but not being an AT user I’m not sure if that’s personal bias |
| 02:17 | <Hixie> | that's usually the criteria i use for deciding on <nav> |
| 02:18 | <boblet> | also I assumed this would be taken care of by link’s @rel |
| 02:19 | <boblet> | Hixie: so not a case of wrong, more an ‘up to the author’ thing eh |
| 02:37 | <Hixie> | boblet: well it's never wrong _not_ to use <nav> |
| 02:38 | <boblet> | Hixie: just more or less suitable huh |
| 02:38 | <boblet> | thanks, that’s a good point to keep in mind |
| 03:03 | <othermaciej> | would you want to skip it when reading the content, but possibly skip *to* it if you want to find navigation landmarks |
| 03:10 | <boblet> | othermaciej: yeah, I think so. would that be covered by not using nav, and adding @rel="up" as per links.html#link-type-up ? |
| 03:10 | <boblet> | I’m not sure how AT exposes navigation landmarks |
| 03:11 | <boblet> | (and am assuming that @rel = said landmarks) |
| 06:10 | <Aleoss> | Can someone explain the purpose of the <keygen> element? |
| 06:28 | <Aleoss> | Anyone? |
| 06:36 | <MikeSmith> | Aleoss: digital signatures |
| 06:37 | <MikeSmith> | for cases in the brick-and-mortar world where you would need to sign a document before you submit it |
| 06:38 | <MikeSmith> | e.g., for a bank or government form or whatever |
| 06:38 | <MikeSmith> | keygen generates a public/private keypair |
| 06:38 | <MikeSmith> | and submits the public key along with the document |
| 06:38 | <MikeSmith> | that's my understanding of it at least |
| 06:39 | <MikeSmith> | which take with a grain of salt because I've not actually implemented it nor even tested it |
| 06:39 | <Aleoss> | MikeSmith: Ok. So a private key is created on the client side and a public key is sent to the server and what can the server do with this key? Just keep it linked to that post data? What's different than having it in a session? |
| 06:39 | <MikeSmith> | it persists, I guess |
| 06:39 | <MikeSmith> | so it can be checked again later |
| 06:40 | <Aleoss> | MikeSmith: Sessions and client-side cookies can be checked later, that's the purpose of them. |
| 06:41 | <Aleoss> | MikeSmith: So what you're suggesting is that it is just re-inventing the wheel. |
| 06:41 | <MikeSmith> | so don't use it if you don't need it |
| 06:42 | <MikeSmith> | the reason it's implemented in browsers is that there are sites that use it |
| 06:42 | <MikeSmith> | browsers did not implement it because they like it |
| 06:42 | <MikeSmith> | at least other browsers did not |
| 06:42 | <MikeSmith> | Netscape did initiallly |
| 06:43 | <doublec> | Aleoss, more details here http://www.blooberry.com/indexdot/html/tagpages/k/keygen.htm |
| 06:43 | <MikeSmith> | and I think the difference from cookies is pretty obvious |
| 06:44 | <MikeSmith> | doublec: roc not around today? |
| 06:44 | <Aleoss> | So it's used for HTTPS only? |
| 06:44 | <doublec> | MikeSmith, he just left the office about 10minutes ago |
| 06:45 | <MikeSmith> | oh, just not on irc today, I guess |
| 06:45 | <MikeSmith> | something I wanted to ask him about, but it can wait |
| 07:08 | <MikeSmith> | roc: regarding TTML support in Flash - |
| 07:08 | <MikeSmith> | http://www.w3.org/2009/05/dfxp-results.html |
| 07:08 | <MikeSmith> | I sent that link to public-html also |
| 07:09 | <MikeSmith> | in reply your message from earlier this month |
| 07:09 | <MikeSmith> | I don't know what particular features any of those tests are actually exercising |
| 07:09 | <roc> | interesting |
| 07:10 | <MikeSmith> | yeah, it does at least show the level of support in Flash vs. level of support in Silverlight |
| 07:10 | <MikeSmith> | and who knew TTML had "animation" support? |
| 07:10 | <MikeSmith> | I'm not sure I even want to know what exactly that is |
| 07:21 | <benschwarz> | Hey guys |
| 07:22 | <benschwarz> | I just wrote and published an article about the w3c and applying design to their specification documents |
| 07:22 | <benschwarz> | http://www.germanforblack.com/articles/moving-towards-readable-w3c-specs |
| 07:24 | <Peter`> | MikeSmith: thank you! |
| 07:24 | <MikeSmith> | Peter`: thank me for what?.. |
| 07:25 | <Peter`> | Your reply following my sign-up |
| 07:25 | <MikeSmith> | ah, it's that Peter! |
| 07:25 | <Peter`> | Should have clearified, sorry :-) |
| 07:26 | <MikeSmith> | no problem |
| 07:27 | <MikeSmith> | benschwarz: "The reading experience is far from delightful".. you certainly won't get any arguments from anybody about that :) |
| 07:27 | <MikeSmith> | the only thing worse than reading specs is writing them |
| 07:27 | <MikeSmith> | only crazy people like writing specs |
| 07:27 | <benschwarz> | MikeSmith: pretty easy argument to "win" |
| 07:27 | <gsnedders> | I make a point to avoid anyone who writes specs |
| 07:28 | <benschwarz> | gsnedders: they're easy to spot :) |
| 07:28 | <benschwarz> | I might post it to one of the whatwg mailing lists |
| 07:28 | <gsnedders> | Wow, a lot of email to es-discuss this weekend. |
| 07:29 | <MikeSmith> | benschwarz: btw, I saw your "Take Back the Web" slides the other day |
| 07:30 | <MikeSmith> | somebody linked to them from twitter, iirc |
| 07:30 | <benschwarz> | MikeSmith: awesome dude. what did you think? |
| 07:31 | <MikeSmith> | I like the part about "fancy borders" |
| 07:31 | <MikeSmith> | it makes a point |
| 07:31 | <MikeSmith> | I loved that "Are we fucked" slide quite a bit too |
| 07:31 | <MikeSmith> | I think I may steal that idea |
| 07:32 | <MikeSmith> | I'll probably get complaints about it |
| 07:35 | <benschwarz> | Which whatwg email list should I post my article to? |
| 07:36 | <gsnedders> | whatwg, me thinks |
| 07:36 | <MikeSmith> | benschwarz: whatwg⊙wo it is, I think |
| 07:36 | <benschwarz> | no worries. |
| 07:37 | <benschwarz> | we wanted to offer the whatwg group to use some custom styles to improve the reading experience |
| 07:39 | <MikeSmith> | benschwarz: http://www.germanforblack.com/css-fonts-demo/index.html certainly does look better than the default style |
| 07:40 | <benschwarz> | If you use the userscript, you can have it always :) |
| 07:40 | <MikeSmith> | maybe we can add a link on each spec, "View this document in a style that's actually optimized for reading" |
| 07:41 | gsnedders | wonders about WCAG2 Compliance |
| 07:45 | <MikeSmith> | in other news, if you are clueful about use cases for browser-based audio applications, join the new Audio Incubator Group |
| 07:45 | <MikeSmith> | http://www.w3.org/2005/Incubator/audio/ |
| 07:45 | <MikeSmith> | of even if you're not clueful, but just curious |
| 07:45 | <MikeSmith> | which is certainly the category I fit into |
| 07:45 | <MikeSmith> | and I joined the group |
| 07:46 | <MikeSmith> | so we already have an existence proof that nobody will be turned away, no matter how clueless |
| 07:48 | <MikeSmith> | who are these Jedi A-hole dudes |
| 07:49 | <MikeSmith> | I want to hang out with them |
| 08:00 | MikeSmith | looks forward to someone picking up work on https://bugzilla.mozilla.org/show_bug.cgi?id=514437 soon |
| 08:00 | <MikeSmith> | = Implement HTML 5 progress element |
| 09:05 | <MikeSmith> | cool to see that Relaxed validator is back |
| 09:05 | <MikeSmith> | http://relaxed.vse.cz/relaxed/validate?group=Web |
| 09:06 | <MikeSmith> | nice for easily comparing error-message output to validator.nu and W3C Markup Validator output |
| 09:08 | annevk | is not really impressed so far with the tests Microsoft contributes |
| 09:09 | <annevk> | I reviewed their foreign content tests: http://lists.w3.org/Archives/Public/public-html-testsuite/2010May/0014.html |
| 09:09 | <annevk> | Most of those tests you do not actually want to pass... It's sad |
| 09:11 | <MikeSmith> | well, that's disappointing |
| 09:11 | <othermaciej> | as in, they test the opposite of what the spec ays? |
| 09:11 | <othermaciej> | *says |
| 09:12 | <annevk> | no, most tests seem to rely on IE bugs they still have not fixed |
| 09:12 | <MikeSmith> | (this is also disappointing: "Error during validation: java.net.UnknownHostException: relaxed2.vse.cz" ... that seems to be the message you get when you actually try to validate a page using the Relaxed validator...) |
| 09:12 | <annevk> | filtering out text nodes |
| 09:12 | <othermaciej> | I can't believe they haven't fixed that yet |
| 09:12 | <othermaciej> | makes it hard to use the "same markup"(tm) |
| 09:14 | <annevk> | heh yeah, I was thinking of blogging something like that but then I haven't actually tried IE9 yet so I'm not sure if the tests are actually representative (though I'd guess they only release stuff they pass, as they have done so far) |
| 09:15 | <annevk> | I would write a bunch of tests but I want someone to figure out the infrastructure first |
| 09:15 | gsnedders | pokes TabAtkins |
| 09:15 | <annevk> | I thought these Microsoft guys would handle that but so far I've just been reviewing lousy tests |
| 09:16 | <boblet> | baby steps, natch |
| 09:17 | <othermaciej> | maybe you should figure out the infrastructure |
| 09:18 | <othermaciej> | or at least enough of it to write the tests you want to write |
| 09:19 | <annevk> | I'm not good at designing a JS test framework :) |
| 09:19 | <boblet> | othermaciej: oh, re your comment “would you want to skip it when reading the content, but possibly skip *to* it if you want to find navigation landmarks” would this be accomplished by nav on breadcrumbs, or by no nav and role="up" on breadcrumb links instead? |
| 09:19 | <annevk> | (or picking one) |
| 09:19 | <boblet> | as that’s exactly what I think I’d like |
| 09:19 | <othermaciej> | boblet: you have many different choices of what elements to use |
| 09:20 | <othermaciej> | annevk: I guess we should find someone who is good at it |
| 09:20 | <othermaciej> | annevk: what about non-script tests? |
| 09:20 | <othermaciej> | like testing parsing |
| 09:20 | <othermaciej> | or should that be done in a script-driven way too? |
| 09:22 | <boblet> | in what situations do you all think nav for breadcrumbs is a good idea? (trying to work out if I’m missing a use case or not) I figure only if there is little other navigation and the breadcrumbs provide an important way to reach homepage and archive page parents that aren’t already offered |
| 09:23 | <annevk> | parsing we already did to some extent: http://html5.org/parsing-tests/testrunner.htm (not up to date with the latest tests) |
| 09:24 | <othermaciej> | I'm not really a web design expert |
| 09:24 | <othermaciej> | do you think breadcrumbs are part of the primary navigation aids on the page or part of the content? |
| 09:24 | <othermaciej> | annevk: maybe it would be a good idea to contribute that infrustructure and set of tests to the test suite, if they haven't been already |
| 09:25 | <boblet> | othermaciej: for me, no. but I’m guessing for some people yes. I’m wondering if there’s AT-side (intended) usage I don’t know about |
| 09:27 | <annevk> | yeah so e.g. Firefox nightlies fail a bunch because the tests changed and I never took a fresh copy from html5lib |
| 09:28 | <boblet> | are long-form boolean attributes (pubdate="pubdate") required in XHTML5? or is this just a stylistic difference? |
| 09:28 | <annevk> | othermaciej, yeah, the problem is that tests are currently maintained by the html5lib community; convincing everyone that our tests now live in a new repository and/or coordinating everything will the parser section stabilizes might not be our best use of time |
| 09:28 | <annevk> | boblet, you can write pubdate="" |
| 09:29 | <boblet> | annevk: oh thanks, just re-read 2.4.2 and noticing that for the first time. I’m still not sure if there’s a reason for the three styles other than author pref tho |
| 09:30 | <othermaciej> | annevk: I think the odds of major parser changes are low, though I guess they are still nonzero |
| 09:32 | <annevk> | boblet, there's only two styles, pubdate="" and pubdate="pubdate" and the latter is for backwards compatibility |
| 09:32 | <annevk> | othermaciej, guess we'll see when we resolve ISSUE-41 :p |
| 09:33 | <boblet> | facepalm |
| 09:33 | <othermaciej> | annevk: fair enough - though I am not sure anyone has made a proposal that involves parser changes |
| 09:37 | <boblet> | annevk: so “its value must either be the empty string” actually means “pubdate=""” and not “pubdate”? does that mean “pubdate” isn’t valid? |
| 09:37 | <annevk> | you're confusing syntax and semantics |
| 09:38 | <annevk> | <article pubdate> is a syntactic shorthand for <article pubdate=""> |
| 09:38 | <annevk> | as <div title> is short for <div title=""> |
| 09:38 | <boblet> | aah |
| 09:38 | <annevk> | nothing really special |
| 09:38 | <boblet> | the wording confused me |
| 09:39 | <annevk> | the difference becomes more obvious when you look at the DOM |
| 09:40 | <annevk> | in http://www.whatwg.org/specs/web-apps/current-work/complete/syntax.html#attributes-0 you can read "Just the attribute name. The value is implicitly the empty string." |
| 09:41 | <boblet> | oh nice — haven’t read this before |
| 09:47 | <boblet> | aah, so pubdate becomes pubdate="" in the DOM. gotcha |
| 09:47 | <boblet> | thanks annevk |
| 09:47 | <MikeSmith> | the problem with http://www.whatwg.org/specs/web-apps/current-work/complete/common-microsyntaxes.html#boolean-attributes is that it's stated in terms of the DOM |
| 09:48 | <MikeSmith> | which is not the terms in which authors think of it |
| 09:48 | <annevk> | yeah, it's like pubdate='' vs pubdate="" doesn't matter either for determining the value of the pubdate attribute |
| 09:48 | <boblet> | MikeSmith: filed a bug. will add a comment about that |
| 09:48 | <MikeSmith> | yeah, I saw it |
| 09:48 | <boblet> | (my bug report was naive :) |
| 09:50 | <MikeSmith> | the vast majority of authors are never going to make the leap that "its value must either be the empty string" applies to <article pubdate> |
| 09:50 | <MikeSmith> | they're not going to consider that attribute as having the empty string as its value |
| 09:51 | <MikeSmith> | they're instead going to just consider that as an attribute with no value |
| 09:51 | <MikeSmith> | because they naturally think in terms of the serialization |
| 09:51 | <annevk> | fortunately the vast majority of authors won't read the spec and therefore won't be confused |
| 09:52 | <annevk> | insofar lalaland isn't confusing |
| 09:52 | <MikeSmith> | yeah, well, the authors-won't-read-the-spec rationalization is not a particularly inspiring one |
| 09:53 | <MikeSmith> | Hixie added that "The value is implicitly the empty string." language because of an earlier bug I filed |
| 09:53 | <MikeSmith> | he just added it in the wrong place |
| 09:53 | <MikeSmith> | suboptimal place |
| 09:53 | <Hixie> | file more bugs :-) |
| 09:53 | <boblet> | Hixie: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9743 |
| 09:54 | <Hixie> | cool |
| 09:54 | <boblet> | annevk: oh noes! I broke it (by reading the spec) ;-) |
| 09:54 | <MikeSmith> | the quantum computing stuff is making my head spin |
| 09:54 | <MikeSmith> | it actually relies on quantum entanglement |
| 09:54 | <MikeSmith> | which I still don't actually believe exists |
| 09:55 | <annevk> | boblet, you're not vast majority ;) |
| 09:56 | <boblet> | annevk: sometimes I think life would be easier if I was :| |
| 09:56 | <boblet> | heh |
| 09:56 | <MikeSmithX> | I want to Einstein was right and this whole "spooky action at a distance" stuff is just a big hoax |
| 09:57 | <boblet> | l8r all, thanks for your help! learnin learnin’ |
| 09:58 | <othermaciej> | MikeSmithX: einstein just claimed there are underlying hidden variables, rather than a mysterious correlation |
| 09:58 | <othermaciej> | MikeSmithX: there are hidden variables theories that explain entanglement, they just have to be nonlocal |
| 10:00 | <MikeSmithX> | othermaciej: yeah, Rod van Meter here was telling me about the local variable stuff |
| 10:00 | <Philip`> | Science would be much easier if we could just believe what Einstein said instead of having to do actual experiments |
| 10:00 | <MikeSmithX> | heh |
| 10:01 | <othermaciej> | Bell's inequalities pretty much rule out Einstein's preferred view of local hidden variables |
| 10:01 | <othermaciej> | sorry |
| 10:01 | <MikeSmithX> | Rod mentioned Bell too |
| 10:01 | <othermaciej> | reality bites |
| 10:01 | <othermaciej> | logging off for a bit, brb |
| 10:02 | <MikeSmith> | Philip` and Maciej seem to know about everything |
| 10:02 | <MikeSmith> | it's depressing |
| 10:02 | <MikeSmith> | Philip`: please know about less stuff |
| 10:02 | <MikeSmith> | take some time off from learning now and then |
| 10:02 | <Hixie> | just keep a tab open on google and wikipedia |
| 10:03 | <Hixie> | you don't have to know everything, you just have to be one step ahead of everyone else |
| 10:03 | <MikeSmith> | the Web takes all the fun out of everything |
| 10:03 | <Hixie> | beg to differ :-P |
| 10:03 | <Philip`> | Also, pretend to type very slowly so that nobody knows you've been checking the Wiki before every sentence you write |
| 10:03 | <MikeSmith> | well, the Jedi A-Holes video gives me hope for the Web |
| 10:13 | <annevk> | it requires Flash |
| 10:14 | <MikeSmith> | annevk: it's nice to have a goal to work towards |
| 10:14 | <MikeSmith> | the goal being, make that video viewable natively cross-browser |
| 10:15 | <MikeSmith> | then we will have done something great for the world |
| 10:16 | <annevk> | one step closer to world peace |
| 10:16 | <annevk> | euh, world domination |
| 10:16 | <annevk> | I keep getting those mixed up |
| 10:16 | <zcorpan_> | annevk: <html><svg> is not error handling |
| 10:18 | <zcorpan_> | i'd like microsoft to test and implement escaping out of foreign lands |
| 10:18 | <annevk> | zcorpan_, <html><svg></svg><body> is |
| 10:19 | <zcorpan_> | yes |
| 10:19 | <annevk> | zcorpan_, so I'm not sure why you're saying it's not testing error handling |
| 10:20 | <annevk> | oh I see, poor wording on my part |
| 10:20 | <zcorpan_> | just a nitpick :) |
| 10:21 | <zcorpan_> | maybe i should file a bug at microsoft about foreign lands |
| 10:24 | <zcorpan_> | did Philip` have the results of running the html5lib tests in ie9 somewhere? |
| 10:27 | <zcorpan_> | does ie9 preview2 support <video>? |
| 10:35 | <Philip`> | zcorpan_: http://philip.html5.org/misc/html5lib-runner-ie9.txt |
| 10:35 | <Philip`> | (from the first preview) |
| 10:35 | <zcorpan_> | thanks |
| 10:38 | <annevk> | wow, I thought they said they implemented an HTML5 parser |
| 10:39 | <Hixie> | any interop issues there for which we need updates to the spec? |
| 10:40 | <annevk> | dunno, <title> never has child nodes? |
| 10:40 | <Hixie> | nah, that's widely implemented correctly elsewhere |
| 10:40 | <Philip`> | annevk: I don't think they ever said that |
| 10:41 | <annevk> | your sarcasm sensors are off |
| 10:41 | <zcorpan_> | html5lib tests don't test <foobar/> outside foreign lands |
| 10:41 | Hixie | recalibrates |
| 10:50 | <zcorpan_> | https://connect.microsoft.com/IE/feedback/details/559531/ie9-fails-html5lib-html-parser-tests |
| 10:51 | <othermaciej> | hsivonen's twitter just made me laugh |
| 10:53 | <othermaciej> | I'm not sure I understand the test output |
| 10:53 | <othermaciej> | of the html5lib tests |
| 10:53 | <jgraham> | Using which harness? |
| 10:53 | <othermaciej> | if it doesn't say Failed, does that mean they all passed? |
| 10:53 | <othermaciej> | http://html5.org/parsing-tests/testrunner.htm |
| 10:53 | jgraham | is about 4 days behind on context |
| 10:54 | <othermaciej> | neither Safari 4.0.5 nor Firefox 3.6.3 report any failures |
| 10:54 | <othermaciej> | and I know neither of those parsers is fully HTML5 compliant |
| 10:54 | <zcorpan_> | othermaciej: you need to click on the output to expand the results |
| 10:54 | <othermaciej> | I see |
| 10:54 | <othermaciej> | would be handy if it gave a summary of the pass/fail count somewhere |
| 10:55 | <othermaciej> | oh, are the numbers it reports the failing tests? |
| 10:55 | <zcorpan_> | yes |
| 10:55 | <zcorpan_> | the output sucks |
| 10:55 | <othermaciej> | we fail buckets o |
| 10:55 | <othermaciej> | buckets o' tests then |
| 10:56 | <zcorpan_> | i don't know if http://gsnedders.html5.org/html5lib-tests/runner.html is more up to date |
| 10:56 | <othermaciej> | it seems to run a lot more tests |
| 10:57 | <zcorpan_> | yeah. the one on html5.org is old |
| 10:57 | othermaciej | thinks these should be submitted to the HTML5 test suite |
| 10:57 | <annevk> | the gsnedders one doesn't work on Opera |
| 10:58 | <jgraham> | Ironically |
| 10:58 | <jgraham> | It will be improved |
| 10:58 | <zcorpan_> | hmm wfm |
| 10:58 | <jgraham> | Erm, it won't be improved ironically |
| 10:58 | <annevk> | i mean i can't click on the result lines to see what failed |
| 10:58 | <jgraham> | it will be improved in an entirely irony-free way |
| 11:00 | <jgraham> | So, before I read the logs, has it already been noted that the ES people are discussing the WebGL typed array thing? |
| 11:01 | <jgraham> | So if that doesn't work for websockets use cases for some reason, now would be a good time to say |
| 11:01 | <Hixie> | what's the WebGL typed array thing? |
| 11:01 | <jgraham> | https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html |
| 11:02 | <annevk> | http://lists.w3.org/Archives/Public/public-script-coord/2010AprJun/0008.html scared me about TypedArray |
| 11:02 | <zcorpan_> | i would just want a binary array, which i guess is Uint8Array |
| 11:03 | <jgraham> | annevk: Yeah, that concerns me too |
| 11:04 | <zcorpan_> | javascript already has 16-bit unsigned arrays |
| 11:04 | <zcorpan_> | called strings |
| 11:04 | <othermaciej> | JS has immutable fixed-length 16-bit unsigned arrays |
| 11:05 | <othermaciej> | with a weird syntax to access the elements |
| 11:05 | <othermaciej> | (str.charCodeAt(n) instead of str[n]) |
| 11:05 | <zcorpan_> | str[n] works fine |
| 11:06 | <Hixie> | annevk: wouldn't it just use network byte order regardless of the underlying architecture? |
| 11:06 | <Hixie> | seems like that would solve the problem neatly |
| 11:06 | <zcorpan_> | although it just returns the character, true |
| 11:06 | <Hixie> | anyway, while it may be a bit more complicated than what i was expecting, it seems like it would do the job |
| 11:06 | <Hixie> | dunno if it's the best primitive to have though |
| 11:07 | <Hixie> | i think it'd be neater to have just a straight byte array with a mechanism like C structs to read structured data out of it, but *shrug* |
| 11:07 | <zcorpan_> | one of our carakan devs didn't like having lots of types of arrays |
| 11:08 | <zcorpan_> | but he could see the use case of a binary array |
| 11:08 | jgraham | wonders who that was |
| 11:08 | <zcorpan_> | farre |
| 11:08 | <hsivonen> | is there a way to intercept DOMContentLoaded before normal listeners, do stuff and then dispatch it to normal listeners? |
| 11:10 | <hsivonen> | also, is there a robust way to delay the load event? |
| 11:12 | <othermaciej> | capturing DOMContentLoaded listener on the window |
| 11:12 | <hsivonen> | i wonder if adding an iframe and calling open() onits contentDocument works |
| 11:12 | <othermaciej> | if you set the first one, I believe it is guaranteed to run before any other DOMContenLoaded listener |
| 11:13 | <othermaciej> | do you mean delay the load event from inside DOMContentLoaded? |
| 11:13 | <hsivonen> | othermaciej: thanks. |
| 11:14 | <hsivonen> | othermaciej: no, delaying it first and stopping the delaying from within the fake Domcontentloaded |
| 11:15 | <othermaciej> | what do you mean by fake DOMContentLoaded? |
| 11:16 | <othermaciej> | load can't happen before DOMContentLoaded, so I assume you mean something other than delaying it to the point that DOMContentLoaded fires |
| 11:16 | <othermaciej> | did you want to stop propagation and dispatch it later by hand? |
| 11:16 | <hsivonen> | I was thinking of doing async stuff from my domcontentloaded handler |
| 11:17 | <hsivonen> | so, yes, redispatching it later |
| 11:20 | <gsnedders> | annevk: It should work |
| 11:20 | <gsnedders> | wfm in 10.53 beta for linux |
| 11:21 | annevk | has beta .54 |
| 11:21 | <annevk> | build 6336 |
| 11:21 | <annevk> | hmm |
| 11:23 | <jgraham> | othermaciej: Random comment related to old email: extrapolating from "it's X lines of code for an echo server in Y" to "therefore Y is not complex" is extremely dangerous |
| 11:24 | <jgraham> | e.g. twisted is widely belived to be complex |
| 11:24 | <jgraham> | (to use well) |
| 11:25 | <micheil> | heh, only in node.js, that's actually true that it can be used well in a little amount of code ;P |
| 11:27 | <jgraham> | micheil: It may be, but that's very little to do with how many lines of code an echo server in node.js takes |
| 11:27 | <micheil> | true |
| 11:28 | micheil | has an echo websocket server in node using < 50 lines of code |
| 11:28 | <micheil> | (admittedly I'm using my own module for node to provide websockets :p) |
| 11:28 | <micheil> | it's currently draft75 compliant |
| 11:28 | <micheil> | working on draft76 after I iron out all the small bugs |
| 11:29 | <micheil> | and write tests |
| 12:15 | <Hixie> | man i wish i understood gregw's e-mails |
| 12:16 | <hsivonen> | I wish we had an URL parsing spec already. |
| 12:16 | <othermaciej> | perhaps we need to trick abarth into editing it |
| 12:16 | <annevk> | he offered editing it |
| 12:17 | <othermaciej> | true, I guess we could make it a separate document from the IRIbis draft |
| 12:17 | <Hixie> | let's let him finish his current docs first |
| 12:17 | <Hixie> | i'll eventually just write the url spec is the iri group don't get aroudn to it |
| 12:18 | <othermaciej> | abarth has good test data |
| 12:18 | <hsivonen> | percent escapes in the host name in http: URLs in Gecko don't work |
| 12:18 | <othermaciej> | we converted most of google-url's test suite into a form that is easily runnable in any browser |
| 12:18 | <hsivonen> | but the status bar makes it look like they work |
| 12:19 | <hsivonen> | (as you can see, supposed HTML parser bugs take me to various other areas of Gecko...) |
| 12:22 | <Hixie> | if you set <track>.src and the file starts downloading |
| 12:22 | <Hixie> | and you then dynamically change its .src to something else |
| 12:22 | <Hixie> | should it abort the download? |
| 12:22 | <Hixie> | or should it wait until the download is done before starting the new one? |
| 12:23 | <othermaciej> | it should act the same as any other element that references a resource if you change the relevant attribute |
| 12:23 | <othermaciej> | which would be, abort and start new load |
| 12:23 | <Hixie> | k |
| 12:23 | <othermaciej> | (unless I am missing a subtle reason that it should be different) |
| 12:24 | <Hixie> | no reason other than it being a pain in my neck |
| 12:24 | <Hixie> | but that's what i'm paid for |
| 12:24 | <Hixie> | first, though, i shall sleep |
| 12:24 | <Hixie> | nn |
| 12:41 | <hsivonen> | Is it appropriate to put zero bytes in html5lib tree builder tests? |
| 12:44 | <Philip`> | I believe html5lib always does the input stream processing, so zero bytes would turn into U+FFFD before reaching the tokeniser or tree builder |
| 12:59 | <jgraham> | hsivonen: as in U+0000? |
| 12:59 | <jgraham> | hsivonen: Should be fine I think |
| 12:59 | <jgraham> | hsivonen: (or if not it's a bug) |
| 13:13 | <hsivonen> | jgraham: as in zero byte in the file and the zero byte should decode to U+0000 |
| 13:13 | <hsivonen> | The usability of Grub2 is so fantastically bad it's not even comical |
| 13:14 | <hsivonen> | since Debian/Ubuntu installer is capable of automatically configuring Grub2, why on earth isn't that automation available outside the installation process? |
| 13:16 | <hendry> | hsivonen: code bloat on grub2 is incredible too, hence I use http://syslinux.zytor.com/wiki/index.php/EXTLINUX |
| 13:18 | <hsivonen> | hendry: I think I'm not adventurous enough to use a bootloader other than the one provided by the distro |
| 13:18 | <hsivonen> | but seriously, even Canonical's paid support is unable to give me a recipe for refreshing grub2 on a cloned disk to boot from the disk it was relocated to |
| 13:19 | <hsivonen> | ...after Canonical's paid support has had a couple of attempts at correcting its story |
| 13:20 | <hendry> | hsivonen: Canonical's drives into complexity with upstart and grub2 will just land you in a world of pain. Try Archlinux :-) |
| 13:20 | <hsivonen> | one would think that refreshing the bootloader on a hard drive were something right out of the support cases that are common enough to have scripted responses! |
| 13:21 | <hsivonen> | hendry: I want a non-obscure distro with support available from the vendor |
| 13:21 | <hsivonen> | hendry: as I understand it, the set of non-obscure distros is Ubuntu, Fedora, Debian and openSUSE |
| 13:21 | <hsivonen> | hendry: and of those, only Ubuntu comes with support from the vendor |
| 13:21 | <hendry> | hsivonen: who do you expect to support you when your browser falls over? Ubuntu? |
| 13:22 | <hsivonen> | hendry: browser is different, since I compile the browser myself |
| 13:22 | <hsivonen> | as I understand it, RedHat doesn't sell support for Fedora |
| 13:22 | <hsivonen> | only to RHEL Desktop |
| 13:23 | <hsivonen> | and RHEL desktop is not one of the distros for which end user -oriented packages are made available |
| 13:24 | <hsivonen> | (my cheatsheet for figuring out which distros are non-obscure is looking at the download pages for Skype and Chrome) |
| 13:24 | <hendry> | how does Ubuntu's support work? You call them up? Or do you use that god forsaken Launchpad application? |
| 13:25 | <hsivonen> | hendry: I use a salesforce.com-backed app embedded in Landscape |
| 13:25 | <hsivonen> | It's quite sad, really |
| 13:25 | <hendry> | hsivonen: i really don't see the benefit for developers |
| 13:25 | <hendry> | linux is pretty straightforward imo |
| 13:26 | <hsivonen> | hendry: which "developers"? |
| 13:26 | <hendry> | just took my about 5 years to figure it out mind |
| 13:26 | <hendry> | hsivonen: people who know how to compile code and read a little shell and C :) |
| 13:26 | <hsivonen> | It amazes me that the process of making a bootable backup is so hard |
| 13:26 | <hsivonen> | does everyone else do distupgrades without a bootable backup? |
| 13:27 | <hendry> | hsivonen: er, yup |
| 13:27 | <hendry> | hsivonen: i don't back up binaries |
| 13:27 | <hendry> | hsivonen: most of my stuff is in git and in at least two locations, so I don't backup anything except photos/videos |
| 13:27 | <hsivonen> | hendry: do you back up your package list and do you have a way to reinstall based on a list? |
| 13:28 | <hendry> | hsivonen: i used to, but i don't bother nowadays. it takes me 10 minutes on a new install to get all the stuff I need. |
| 13:28 | <hendry> | dpkg set selections has never really worked for me either. somehow i've managed to screw things up when doing it that way. |
| 13:29 | <hsivonen> | I wonder how much money one needs to be able to do the "I have money but no time" thing with Linux |
| 13:29 | <hendry> | hsivonen: enough to hire a good admin? :) |
| 13:29 | <hsivonen> | I paid the highest single-seat price for support, but it's obvious that it can't buy a lot of work |
| 13:29 | <hendry> | hsivonen: companies like bytemark.co.uk or bitfolk offer really valuable support to me |
| 13:30 | <hsivonen> | hendry: bytemark is servers only, right? |
| 13:30 | <hendry> | hsivonen: yes |
| 13:31 | <hendry> | hsivonen: they are fairly inexpensive compared to hiring someone |
| 13:32 | <hsivonen> | Canonical's support business model seems to be badly thought-out compared to RedHat |
| 13:32 | <hsivonen> | the pricing is roughly the same |
| 13:32 | <hsivonen> | but in the RedHat case, the customer pays before knowing (s)he needs support |
| 13:33 | <hsivonen> | so RedHat can pocket the money when the customer doesn't ask anything |
| 13:33 | <hsivonen> | in the Canonical case, the customer only buys support when (s)he has at least one question to ask |
| 13:33 | <hsivonen> | so Canonical never gets to pocket the money without having a support incident to respond to |
| 13:35 | <hsivonen> | hendry: btw, backups aren't only about upgrades. if my boot disk breaks, I want to have a fully configured and operational system available within half an hour or so preferably sooner |
| 13:36 | <hendry> | hsivonen: PAYG is bad for business. Subscription is the only model that works IMO. |
| 13:37 | <hendry> | hsivonen: if my disk breaks, i get a new server via linode, bytemark and start pushing my configs |
| 13:37 | <hendry> | hsivonen: i guess it will take me a whole day to get back working. I could do it faster if I had more practice. |
| 13:37 | <hsivonen> | hendry: you don't run dev tools locally? |
| 13:38 | <hendry> | hsivonen: oh you are talking about a workstation? |
| 13:38 | <hendry> | hsivonen: same deal I guess |
| 13:38 | <hsivonen> | hendry: yes, I'm talking about the computer I run Eclipse on |
| 13:39 | <smaug___> | volkmar: does Bug 556743 require some other patch to build? |
| 13:39 | <smaug___> | er, wrong channel |
| 13:39 | <hendry> | hsivonen: in my workstation I have a huge disk I rsync to when I can remember to. if my main disk failed I guess I could get up and running on it, in an hour. |
| 13:41 | <hendry> | if i haven't rsynced for a long time, dist-upgrade and git pulls will get me back being productive I hope |
| 13:41 | <hsivonen> | hendry: do you mean booting from that disk or reinstalling the system and then rsyncing bits back? |
| 13:42 | <hendry> | if my main disk failed, I would just boot from the "huge disk". maybe we should go private btw? |
| 16:17 | <jgraham> | annevk: BTW re: test infrastructure, I am having a bash at something simple for discussion |
| 16:17 | <jgraham> | Dunno if it is very good or not |
| 16:18 | gsnedders | started playing around with stuff for it a while ago too |
| 16:18 | <gsnedders> | I learnt a lot of things not to do from that, and nothing much useful :) |
| 16:25 | <TabAtkins> | gsnedders: I'm working on it! |
| 16:25 | <gsnedders> | TabAtkins: Quicker! |
| 16:26 | <AryehGregor> | Knowing what not to do is useful. |
| 16:26 | <gsnedders> | Yeah, I realized I was typing to quickly just as I hit return :) |
| 16:26 | <gsnedders> | I meant nothing useful in terms of anything usable |
| 16:26 | <TabAtkins> | So, update: turns out the hard part (exposing browser-internal routines to public javascript) has (1) an easy solution, and (2) someone else already working on it. |
| 16:26 | <TabAtkins> | The rest of the infrastructure is just writing a webapp. |
| 16:26 | <gsnedders> | TabAtkins: What browser-internal things? |
| 16:27 | <TabAtkins> | Like the ability to grab a pixel region from the page. |
| 16:27 | <gsnedders> | Oh, I only care about the JS test acse |
| 16:27 | <gsnedders> | Not the taking a screenshot case :) |
| 16:27 | <TabAtkins> | We want to be able to do reftests. |
| 16:27 | <gsnedders> | Yeah, we want to |
| 16:27 | <TabAtkins> | They're pretty important for the CSSWG tests, frex. |
| 16:27 | <gsnedders> | But we don't nessisarily need identical code for visual tests and JS tests |
| 16:27 | <TabAtkins> | As in, we-can't-do-complete-testsuits-of-a-lot-of-specs-without-them. |
| 16:28 | <jgraham> | So, erm, what is the solution, who is working on it, and how robust is it? |
| 16:28 | <gsnedders> | Like, it's no problem to use one thing for visual tests and another for JS tests IMO |
| 16:28 | <TabAtkins> | jgraham: The solution is to write an NPAPI extension that exposes it, the person working on it is Jeff Carollo here at Google, and I dunno how robust it is yet. |
| 16:28 | <AryehGregor> | That won't work for IE, will it? |
| 16:28 | <jgraham> | Now I am scared |
| 16:28 | <TabAtkins> | AryehGregor: IE does NPAPI, I think? |
| 16:28 | <gsnedders> | No, it doesn't |
| 16:29 | <jgraham> | I mean I see that *could* work (not for IE) |
| 16:29 | <jgraham> | But plugins are a unholy mess |
| 16:29 | <TabAtkins> | Well, I have assurances that they'll expose whatever APIs we end up needing, so shrug. |
| 16:29 | <jgraham> | I would hate to make them a critical part of testing infrastructure |
| 16:29 | <TabAtkins> | jgraham: Sure, but they'll work for now, and then we can hack direct support in later. |
| 16:29 | <TabAtkins> | Faster iteration! |
| 16:30 | <Philip`> | Why does there need to be a standard way to run reftests? Seems easier to have a standard way to write reftests, and browser-specific ways to run them |
| 16:30 | <gsnedders> | Indeed |
| 16:30 | <AryehGregor> | TabAtkins, you write it once in NPAPI, then another time as an IE plugin. |
| 16:30 | <AryehGregor> | IE doesn't have a distinction between plugins and extensions. |
| 16:30 | <Philip`> | (and non-browser-specific ways to view both pages in an iframe for visual inspection) |
| 16:30 | <TabAtkins> | AryehGregor: That's another option, sure. |
| 16:32 | <jgraham> | Philip`: It's important if you want to let people browse to a page, run some tests, and submit to the results |
| 16:32 | <jgraham> | Philip`: That's not really a goal I have but it seems to be one that W3C has |
| 16:32 | <Philip`> | That seems a weird goal |
| 16:32 | <jgraham> | s/to// |
| 16:33 | <Philip`> | unless you want to test lots of obscure mobile browsers |
| 16:33 | <Philip`> | in which case the plugin approach won't help at all |
| 16:33 | <jgraham> | Yeah, the plugins approach rather assumes that desktop is the only interesting class of device |
| 16:33 | <TabAtkins> | Mobiles come later, if at all. Some tests can be run in them, but they're definitely not a target. |
| 16:33 | <Philip`> | The plugins approach also assumes that people who want to run tests are willing to install a gigantic security vulnerability before running them |
| 16:34 | <AryehGregor> | It's not useful for random users to view the tests if they have non-default settings, unless the tests are specifically written to be robust against non-default settings. |
| 16:34 | <TabAtkins> | Philip`: Only to run the types of tests that require it. |
| 16:34 | <Philip`> | which doesn't seem a good idea for random non-developer users |
| 16:34 | <jgraham> | TabAtkins: That seems odd given that mobiles are the new hotness |
| 16:34 | <jgraham> | TabAtkins: and that there are reports of considerable variation between supposedly similar mobile browsers |
| 16:34 | <Philip`> | and non-random developers can just run custom browser reftest harnesses |
| 16:34 | <TabAtkins> | jgraham: Mobiles still intentionally violate all sorts of things. I don't want to think about them yet. |
| 16:35 | <jgraham> | AryehGregor: it is basically impossible to make tests robust against non-default settings |
| 16:35 | <AryehGregor> | Well, yes. |
| 16:35 | <AryehGregor> | That's more or less my point. |
| 16:35 | <TabAtkins> | Philip`: My goal isn't necessarily for the testsuite to be run by non-developers. Some parts of it will be runnable as that, and we'll expose them as such. But some require more power than that, and there's no way around it. |
| 16:36 | <gsnedders> | We're unlikely to use anything more than whatever manifest format you use for the reftests, FWIW. |
| 16:36 | <Philip`> | TabAtkins: What is the problem with the current approach for tests that need access to browser internals, i.e. the browser developers write their own custom code that renders two pages and compares the pixels/rendertree/etc? |
| 16:36 | <jgraham> | TabAtkins: Is there a substantial difficulty with just standardising a manifest format and letting the browser makers sort it out? |
| 16:37 | <jgraham> | s/it/actually taking the screenshots/ |
| 16:37 | <jgraham> | manifest format + test format + events needed for specifying when the screenshot is taken |
| 16:37 | <TabAtkins> | Philip`: The problem is that that's slower. We want to do that, but we can expose what we need faster by ourselves first. Additionally, this gives us the flexibility to experiment with API, rather than just drafting up something from pure theory and hoping we got it right. |
| 16:37 | <gsnedders> | I expect Gecko will want to use something like their current reftest runner |
| 16:38 | <jgraham> | TabAtkins: Who is "we"? |
| 16:38 | <AryehGregor> | TabAtkins, you can always change the authoring format later easily. It's not like this is web content. There will be very few authors. |
| 16:38 | <TabAtkins> | We = me and the other couple of people on the testing project (fantasai, arronei, jcarollo). |
| 16:39 | <jgraham> | AryehGregor: Changing thousands of tests is disappointingly hard |
| 16:39 | <gsnedders> | TabAtkins: where is all the discussion happening anyway? |
| 16:39 | <gsnedders> | jgraham: Unless it can be done programmatically |
| 16:39 | <TabAtkins> | gsnedders: At the moment, in person. |
| 16:39 | gsnedders | slaps TabAtkins |
| 16:39 | <jgraham> | gsnedders: That's a big "unless" |
| 16:40 | <Philip`> | TabAtkins: Don't all browsers already expose reftest-like test runners that you could use with approximately no effort at all? |
| 16:40 | <jgraham> | Philip`: Not quite |
| 16:41 | <TabAtkins> | I don't think so? Chrome already has some internal APIs available to extensions for doing this, which we're exposing. |
| 16:41 | <jgraham> | Philip`: there are big problems if you need to test something that renders later than the load event |
| 16:41 | <jgraham> | for example |
| 16:42 | <jgraham> | so you need a standardised hook to say "take the screenshot now" which the harness can pick up on. WHich might require more core |
| 16:42 | <Philip`> | Ah |
| 16:42 | <jgraham> | (although maybe using js to dispatch a custom event is enough) |
| 16:42 | <jgraham> | (it depends...) |
| 16:43 | <jgraham> | TabAtkins: Anyway it seems like Chrome + Opera + Firefox all have ways to take screenshots |
| 16:44 | <TabAtkins> | jgraham: Exposed in a public-facing javascript api? |
| 16:44 | <jgraham> | TabAtkins: No |
| 16:44 | <jgraham> | But that's not necessary |
| 16:44 | <TabAtkins> | Yes it... is? |
| 16:44 | <jgraham> | Why? |
| 16:44 | <AryehGregor> | You can't expose a screenshot-taking API to public JS, that's a horrible security hole. |
| 16:45 | <jgraham> | The Mozilla reftests don't depend on a public-facing javascript API |
| 16:45 | <jgraham> | They use a class on the root element which the reftest harness monitors, plus an event |
| 16:45 | <TabAtkins> | AryehGregor: I know. What I mean is something that can be used outside of extensions or similar. It's okay if it requires a compiler flag or similar. |
| 16:46 | <jgraham> | TabAtkins: Requiring special builds or special command line options seems bad |
| 16:47 | <TabAtkins> | jgraham: I don't understand your objection. |
| 16:47 | <jgraham> | TabAtkins: Which objection? |
| 16:47 | <TabAtkins> | The last one. Either you need a special build, or you have public-facing APIs. |
| 16:48 | <jgraham> | No, you can have a perfectly normal build that runs in a special external-to-the-browser harness |
| 16:48 | <jgraham> | where "external-to-the-browser" might mean "implemented as an extension" |
| 16:49 | <TabAtkins> | So... that's what I said we're doing. |
| 16:49 | <jgraham> | TabAtkins: No, you said you were using NPAPI to run the screenshot code as part of the content |
| 16:49 | <TabAtkins> | I don't understand what value you see in that distinction. |
| 16:49 | <jgraham> | (I guess I really mean "external-to-the-content") |
| 16:52 | <TabAtkins> | At the moment I'm not interested in pursuing multiple harnesses if we can avoid it. However, that section of the project is also the least interesting to me, and the most separate from the rest of the work I'm doing. |
| 16:53 | <TabAtkins> | All that's actually required is that *something* runs some tests *somewhere* that are tracked by me, and reports the results in a particular format. |
| 16:53 | <jgraham> | One relies on installing a plugin which I have to remember to disable when not running tests to prevent a security hole and which has to be loaded as part of the test, which can itself affect the outcome of the test (by pushing the browser down odd codepaths, by delaying the load event, etc.). The other does not |
| 18:00 | <jgraham> | http://hg.hoppipolla.co.uk/hgwebdir.cgi/domharness/ is the sketchy draft of something that could be used as the basis for discussions about a good W3C DOM test harness |
| 18:02 | <jgraham> | TabAtkins: BTW re: htmnl5lib in the stdlib, yes, we are interested, but I don't know how to make it happen |
| 18:03 | <TabAtkins> | jgraham: I'll contact some people, see what's necessary |
| 18:03 | <jgraham> | TabAtkins: Great |
| 18:03 | jgraham | is going now, may or may not manage to coax home internet into functionality |
| 18:13 | <TabAtkins> | What's jgraham's email? |
| 18:15 | <Philip`> | TabAtkins: His IRC name @opera.com |
| 18:15 | <TabAtkins> | danke, Philip`. |
| 19:53 | <AryehGregor> | Even I know that 2 is 二, not 亼. |
| 19:54 | <TabAtkins> | That makes 二 people who know that, then. |
| 20:10 | <AryehGregor> | Is there any other way to make up your own list-style-type, theoretically? I tried something using ::marker, but it seems like that's not supported. |
| 20:10 | <TabAtkins> | AryehGregor: Yeah, use counters. I don't know if all the bits that you'd need are supported, but they are specced at least. |
| 20:10 | <AryehGregor> | Use counters how? |
| 20:10 | <TabAtkins> | Though probably split between Lists and G&Rc. |
| 20:10 | <othermaciej> | TabAtkins: are you going to do anything to try to promote an alternate proposal for atom conversion? I'm inclined to just do a call for consensus on removing it from (the w3c copy of) the spec |
| 20:10 | <AryehGregor> | It doesn't look like those support made-up list counters. |
| 20:11 | <othermaciej> | TabAtkins: since you were the only objector and you haven't followed up in the past N weeks |
| 20:11 | <AryehGregor> | Why doesn't the list spec just allow you to give a string for list-style-type, I wonder? |
| 20:11 | <TabAtkins> | othermaciej: I know, I completely forgot about it. |
| 20:11 | <TabAtkins> | AryehGregor: We had that request a few weeks ago, and agreed that it was a good idea. When I pick up Lists I'll add it. |
| 20:11 | <AryehGregor> | Yay. |
| 20:12 | <TabAtkins> | othermaciej: I'll give you a definite yes/no on whether I'll write something by end of day. |
| 20:35 | <AryehGregor> | Interesting: http://lwn.net/Articles/387950/ |
| 20:41 | <AryehGregor> | "There are probably stronger ease-of-development arguments for making plugins enumeratable, but the example of IE shows that it is not strictly necessary. We recommend that browsers switch to confirm-only testing for fonts and plugins, with an exponential backoff to prevent exhaustive searches by malicious javascript." |
| 20:41 | <Philip`> | "exponential backoff" sounds a lot like "performance regression" |
| 20:41 | <AryehGregor> | Yeah, dunno about that part. |
| 20:42 | <AryehGregor> | I wonder if navigator.plugins could be made non-enumerable, though. |
| 20:42 | <AryehGregor> | It doesn't seem like it would make much difference if you could still get the exact version of all the common plugins, though. |
| 20:42 | <AryehGregor> | They didn't get much less data from IE, which doesn't allow plugin enumeration. |
| 20:43 | <AryehGregor> | Interestingly, the list of installed fonts as returned by Flash or Java was a fairly big source of fingerprintability, especially since the order seemed to vary at random. Someone recently requested some way to get a font list in some spec list, didn't they? |
| 20:43 | <TabAtkins> | Yup. |
| 20:43 | <TabAtkins> | Clearly they were a hacker. |
| 20:44 | <AryehGregor> | The EFF should file bugs about some of this stuff. |
| 20:44 | <othermaciej> | exponential backoff on a synchronous API is not really workable |
| 20:45 | <TabAtkins> | othermaciej: Which atom issue am I dealing with again? |
| 20:45 | <othermaciej> | TabAtkins: ISSUE-86 - see the email threads from last month in the archives |
| 20:45 | <othermaciej> | http://dev.w3.org/html5/status/issue-status.html#ISSUE-086 |
| 20:45 | <TabAtkins> | That's what I thought. I have a Change Proposal already recorded for that. |
| 20:46 | <othermaciej> | I believe you were the only one to object to the proposal to remove Atom |
| 20:46 | <othermaciej> | the Chairs asked if you would back down, and you said you wanted to try to convince more people to buy into your proposal or some variant of it |
| 20:47 | <othermaciej> | so the options are Call for Consensus on removing Atom if you no longer care to object, or probably a survey if you stand firm in your objection, or something else if you can actually build consensus around a different proposal |
| 20:48 | <othermaciej> | last email on this from me: http://lists.w3.org/Archives/Public/public-html/2010Apr/1226.html |
| 20:48 | <othermaciej> | that was, like, a month ago |
| 20:49 | <othermaciej> | brb |
| 20:50 | <Aleoss> | I agree, Atom should be deprecated like XHTML is swiftly becoming and ammendmants to feeds should be forwarded to a RSS 3.0 |
| 20:51 | <AryehGregor> | I've heard conflicting things about Atom and RSS. |
| 20:51 | <AryehGregor> | Is there any practical difference? |
| 20:51 | <Aleoss> | Not really, no. |
| 20:51 | <AryehGregor> | MediaWiki used to advertise both RSS and Atom, but that was stupid, so I switched it to RSS only. But another developer said Atom was more reliable or something and switched it to Atom. |
| 20:52 | AryehGregor | shrugs |
| 20:52 | <othermaciej> | Atom has more well-defined processing but less deployment |
| 20:52 | <Aleoss> | Aryeh: Reliable? No. They're equally reliable. |
| 20:52 | <AryehGregor> | He said he had some problem with an RSS feed being misparsed, or something. |
| 20:52 | <AryehGregor> | Let me look it up. |
| 20:53 | <AryehGregor> | http://www.mediawiki.org/wiki/Special:Code/MediaWiki/61026#c5171 |
| 20:53 | <AryehGregor> | Encoding ambiguity, apparently. |
| 20:55 | <Aleoss> | I disagree to that statement. RSS has been around longer than Atom, more browsers (and their older versions) are more compatible to RSS than Atom. |
| 20:55 | <AryehGregor> | Are we talking real-world browsers or IE5? |
| 20:56 | <Aleoss> | Unless he is talking about MIME types. application/atom+xml VS application/rss+xml. Those 2 MIME types were proposed at the same time and prior to them was application/xml for feeds. |
| 20:56 | <othermaciej> | there are some RSS constructs where clients won't behave the same |
| 20:56 | <Aleoss> | In either case: His statement isn't correct. |
| 20:56 | <othermaciej> | in particular, how escaping of RSS contents that are HTML is handled is somewhat ambiguous |
| 20:56 | <AryehGregor> | Okay, well, he said he's seen problems personally. |
| 20:57 | <AryehGregor> | Do you know of a particular significant feed reader that doesn't support Atom? |
| 21:49 | <aho> | the audio element... why is there no balance/panning? seems sorta odd to me |
| 21:50 | <zcorpan_> | aho: baby steps |
| 21:50 | <aho> | kay :) |
| 21:50 | <aho> | i wondered... that playback rate thing... does that work while looping? |
| 21:50 | <Philip`> | You can emulate panning by telling the user to rotate their head |
| 21:51 | <zcorpan_> | aho: yes |
| 21:52 | <aho> | glitch free? |
| 21:52 | <zcorpan_> | that's an implementation issue |
| 21:52 | <aho> | heh |
| 21:53 | <zcorpan_> | i think currently only chrome supports playbackrate |
| 21:53 | <zcorpan_> | so you could try if it's glitch free in chrome |
| 21:53 | <zcorpan_> | if not, file a bug |
| 21:53 | <aho> | will do |
| 21:53 | <aho> | not today though... has been a really long day for me |
| 21:53 | <aho> | and i already did my fair share of just for fun js hacking 14 hours ago :> |
| 21:54 | <aho> | or 20 |
| 21:54 | <aho> | can't really tell |