| 00:44 | <Hixie> | could some opera people comment on whether they're interested in having the spec spec http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028107.html ? |
| 01:51 | <lhnz> | NGEN |
| 05:24 | <hober> | OK. My ISSUE-27 CP is getting pretty close to where I wanted it to be. |
| 05:25 | <hober> | http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-27 |
| 05:25 | <hober> | any and all feedback welcome |
| 06:19 | <othermaciej> | hober: that looks quite thorough |
| 08:20 | <phrearch> | morning |
| 08:42 | <phrearch> | hm, are there any conventions yet how to do pageviews over websockets? |
| 08:43 | <phrearch> | like i do a xhr request now for /frontend/wiki/home/ , but i rather do this over a websocket, so i can keep track of where a user is on the site without much hazzle |
| 09:30 | <hsivonen> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=10970 What happened to the claim that RDFa 1.1 is a superset of Microdata? |
| 09:33 | jgraham | didn't realise that RDFa was non-deterministic (that is: different consumers may produce different graphs) |
| 09:33 | <jgraham> | That seems bad |
| 09:34 | <jgraham> | hsivonen: I assume that the answer is that it's conceptually a superset i.e. any triple that you can produce with microdata you can also produce with RDFa, but it is not necessarily a superset at the markup level |
| 09:34 | <jgraham> | Or did they make the stronger claim at some point? |
| 09:40 | <hsivonen> | jgraham: I don't know if someone meant to make a stronger claim at some point, but I certaintly thought someone made a stronger claim. |
| 09:42 | <othermaciej> | RDFa is not a syntactic superset for trivial reasons (e.g. doesn't support itemscope) |
| 09:42 | <othermaciej> | I don't recall exactly what claims were made though |
| 09:46 | <hsivonen> | I like the title of http://www.adambarth.com/experimental/websocket.pdf |
| 09:46 | <MikeSmith> | heh |
| 09:48 | <MikeSmith> | the graphics are great as well |
| 09:48 | <MikeSmith> | figures |
| 09:49 | <annevk> | Firefox' encoding menu looks even worse than Opera's |
| 09:49 | <annevk> | I'm impressed |
| 09:49 | <othermaciej> | hah, I didn't even look at the graphics before |
| 09:50 | <annevk> | Although admittedly it only goes wrong when you open the "more encodings" subdialog |
| 09:50 | <othermaciej> | I am sad that the paper didn't do much to win people over to the true path of handshake righteousness |
| 09:51 | <hsivonen> | Don't countries have legislation that bans tampering with communications in transit the way transparent proxies do? |
| 09:51 | <othermaciej> | even though it shows a rather awful vulnerability |
| 09:51 | <othermaciej> | hsivonen: you mean, besides the countries running such proxies themselves? |
| 09:51 | <annevk> | So bored with hybi... |
| 09:51 | <hsivonen> | othermaciej: well, those countries could have laws, too |
| 09:51 | <annevk> | Would be nice if they settled on something already... |
| 09:52 | <annevk> | Same with the HTML test suite stuff by the way |
| 09:52 | <hsivonen> | othermaciej: e.g. Finland has a law that authorizes the police to tamper with the DNS records of foreign sites, but they are known to tamper with the DNS record of at least one Finnish site, too. |
| 09:52 | <othermaciej> | I might try my own attempt at hacking the test framework to be more convenient for simple script tests |
| 09:53 | <othermaciej> | hsivonen: some intercepting proxies are national firewalls but some are corporate firewalls, or set up on public wifi networks by the operators of said network |
| 09:53 | <othermaciej> | I doubt the latter two categories are illegal |
| 09:54 | <annevk> | ooh hey |
| 09:54 | <annevk> | did we pass one of the HTML WG deadlines December 1? |
| 09:54 | <othermaciej> | there was one on December 6 |
| 09:54 | <hsivonen> | I *think* my ISP in the late 1990s had a transparent proxy for a while but it resulted in much complaining |
| 09:54 | <othermaciej> | all bugs are supposed to be resolved by editors |
| 09:55 | <annevk> | actually, that's tomorrow |
| 09:55 | <othermaciej> | I think there are a tiny handful of open pre-LC bugs |
| 09:55 | <annevk> | per http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html |
| 09:55 | <hsivonen> | or I know it had a transparent proxy at one point, but I *think* it was found to be a bad idea 10 years ago already |
| 09:55 | <othermaciej> | ah, right, the 8th |
| 09:55 | <othermaciej> | my mistake |
| 09:56 | <jgraham> | othermaciej: You saw I committed the change I made to add generate_tests? |
| 09:57 | <othermaciej> | jgraham: no I didn't, but generate_tests doesn't seem at all like what I want, based on your prior description of it |
| 09:57 | <jgraham> | Oh well |
| 09:57 | <othermaciej> | it is confusingly indirect |
| 09:57 | <jgraham> | I used it and found it worked rather well |
| 09:57 | <hsivonen> | I didn't read the full paper yet, but by skimming it looks like Flash and Java can poison transparent proxies, too |
| 09:58 | <hsivonen> | did I skim it right? |
| 09:58 | <jgraham> | hsivonen: yes |
| 09:58 | <annevk> | http://www.cafepress.co.uk/sk/w3c_shop -- not cashing in on HTML5 |
| 09:58 | hsivonen | wonders if Flash and Java are now also considered to have serious security flaws |
| 09:58 | <othermaciej> | I would really just like a way to write test assertions in a normal straightforward way, and have the results of each one reported, without having to double-nest them all in calls |
| 09:58 | <hsivonen> | (as opposed to transparent proxies having them) |
| 09:59 | <othermaciej> | generate_tests instead adds an obscure way to generate tests+assertions from arrays of stuff |
| 09:59 | <othermaciej> | it seems like almost everyone who has commented finds the test vs. assertion distinction confusing and painful |
| 09:59 | <jgraham> | It's really not that obsucre |
| 10:00 | <jgraham> | Yes, it feels like I am fighting a losing battle there |
| 10:00 | <jgraham> | But nevertheless I think it is a highly useful distinction |
| 10:01 | <othermaciej> | it is a lot less readable than just writing individual assertions |
| 10:01 | <othermaciej> | also the way you write it seems to lose the exception catching on the assert expressions |
| 10:02 | <othermaciej> | (I infer from generate_tests(assert_equals, [[1+1,2], [2+3,5]])) |
| 10:02 | <phrearch> | hm this may be nice for websocket routing. combination of crud and urls |
| 10:02 | <jgraham> | I don't think it is less readable if you want something more than a simple assert_ |
| 10:02 | <jgraham> | Which is a rather common case |
| 10:02 | <jgraham> | Or at least was the case the only time I used it so far |
| 10:02 | <phrearch> | myws.remote('/path/to/my/resource/action',{params}) |
| 10:02 | <othermaciej> | yeah, but just wanting a simple assert is a rather common case too |
| 10:02 | <othermaciej> | which is quite poorly served right now |
| 10:03 | <jgraham> | Right, so having one solution that works for both cases seems strictly better than having a whole bunch of special cases for each assert_ |
| 10:03 | <othermaciej> | compared to other frameworks for browser-based tests that folks have experience with |
| 10:03 | <jgraham> | To be honest the vibe I get is that everyone wants to do what they are used to |
| 10:03 | <othermaciej> | but this does almost nothing to fix my complaint even for the simple assert_equals case |
| 10:04 | <othermaciej> | it can't catch exceptions in those expressions |
| 10:04 | <jgraham> | I'm not saying that my thing is perfect or even good, but you proposed something like the webkit tests and Mozilla folks basically proposed Mochitest |
| 10:04 | <jgraham> | othermaciej: Why can't it catch exceptions? |
| 10:04 | <othermaciej> | mochitests and webkit tests are much more similar to each other than to your thing |
| 10:05 | <othermaciej> | jgraham: what exception handler is in effect when the expression "2 + 3" is being evaluated in your example? |
| 10:05 | <jgraham> | Maybe I have been looking at the wrong Webkit tests then |
| 10:05 | <othermaciej> | what if instead of 2 + 3, that expression was getElementById("foo").tagName (or something else that could throw)? |
| 10:05 | <jgraham> | othermaciej: That's a fair point, but in practice I wouldn't exprect a complex expression there |
| 10:06 | <hsivonen> | jgraham: my learning experience when I was writing my first mochitest was more successful than my experience when first writing an HTML WG test |
| 10:06 | <jgraham> | I would typically expect you to pass a primitive to a function |
| 10:07 | <othermaciej> | how would you use generate_tests to check that DOM calls which may throw have specific expected results? |
| 10:07 | <othermaciej> | I don't see any way to do it |
| 10:07 | <othermaciej> | and that's exactly what my id test is |
| 10:07 | <jgraham> | How would you fix the problem but preserve the property that the code is run in an exception handler? |
| 10:08 | <othermaciej> | I can think of three ways |
| 10:08 | <othermaciej> | (1) make each assert_* macro report its results, no matter how they are grouped in test() calls |
| 10:09 | <jgraham> | I don't see how (1) helps |
| 10:09 | <othermaciej> | (2) make assert_* macros just work at top level without being nested in test(), but take strings to eval, or thunks |
| 10:09 | <othermaciej> | (3) make test_* macros that are variants of assert_* which combine the creation of a test |
| 10:10 | <othermaciej> | (1) helps because I could rewrite my id test to have one test(function() { .... }); wrapping it |
| 10:10 | <othermaciej> | instead of one per assert |
| 10:10 | <othermaciej> | and still get the same output |
| 10:11 | <jgraham> | I am really, really skeptical of systems that require output for each assert. One assert passing is not typically sufficient to indicate that the test passed |
| 10:11 | <jgraham> | Except in trivial cases |
| 10:11 | <othermaciej> | who said anything about "systems that require"? |
| 10:12 | <othermaciej> | it makes it easier for browser engineers running the test to determine exactly which parts are failing |
| 10:12 | <othermaciej> | and which parts are working |
| 10:12 | <othermaciej> | more so than a single pass/fail result |
| 10:13 | <jgraham> | Anyway, what implementation of "thunks" did you have in mind? |
| 10:13 | <othermaciej> | I am assuming here that the goal of the tests is to improve interop, and therefore optimizing the output to be useful for implementors |
| 10:13 | <jgraham> | Yes, I agree with that |
| 10:14 | <jgraham> | And I can see that adding stack traces where the test fails is useful |
| 10:14 | <jgraham> | and adding the asserts that passed for failing tests might give you some indication of what code flow you had |
| 10:14 | <jgraham> | (I am thinking of async tests here) |
| 10:14 | <othermaciej> | by "thunks" I just mean 0-arg functions used to delay expressions (rather than quoting them as strings) |
| 10:15 | <jgraham> | Isn't that roughly what it uses already? |
| 10:15 | <jgraham> | That seems to be the thing that is drawing all the complkaints |
| 10:15 | <othermaciej> | that plus the two separate concepts that you have to layer together by hand each time |
| 10:17 | <jgraham> | (fwiw I *could* make generate_tests exception-safe in the same way. That is I could make it take a function that is evaluated to return the parameter lists, or something) |
| 10:17 | <othermaciej> | I haven't really thought about async tests, but even there I think it is useful to report results for all steps that actually run, even if you don't end up running all the steps |
| 10:17 | <othermaciej> | especially so if the failure is that one of your async steps never runs (e.g. because some event never fires), even though all asserts up to that point passed |
| 10:18 | <gsnedders> | Is it not implicit that all asserts up to the point that it failed at passed? |
| 10:18 | <othermaciej> | see comment above about optimizing output for ease of use by implementors |
| 10:19 | <jgraham> | You can't fail because a step never runs and keep the common pattern where you add an assert_unreached() to indicate that an event that was not supposed to fire did not |
| 10:19 | <othermaciej> | yes, you could stare real hard at the test, figure out the control flow, and surmise where you must have failed, or the test output can tell you that |
| 10:20 | <othermaciej> | how will async tests detect failure by an event never firing? |
| 10:20 | <jgraham> | The test will timeout |
| 10:20 | <othermaciej> | so presumably you know what step was pending at that point |
| 10:20 | <jgraham> | "You"? |
| 10:20 | <othermaciej> | I assume a timeout is a failure |
| 10:20 | <jgraham> | The harness doesn't know |
| 10:20 | <gsnedders> | FWIW, in our case, as I believe jgraham said on the list already, for our automated testing system (or any that does regression tracking, which I think would include MS as well), having tests/asserts that sometimes appear and sometimes don't are actively harmful for tracking stuff |
| 10:21 | <jgraham> | A timeout is a failure |
| 10:21 | <othermaciej> | how is that compatible with steps that are expected to never run and assert_unreached()? |
| 10:21 | <jgraham> | But the test harness doesn't know about the order of things, so it doesn't know what, if anything is pending |
| 10:21 | <jgraham> | It just knows that the test hasn't declared itself finished |
| 10:22 | <jgraham> | Anyway, it is easy to add some information about the asserts that passed to the output of failed tests |
| 10:22 | <othermaciej> | anyway, this only further makes the case that printing partial results as the test runs is useful |
| 10:23 | <jgraham> | It is also easy to add stack information via non-standard apis |
| 10:23 | <othermaciej> | if there is a way to meet Opera's specialized needs (that WebKit and Gecko don't seem to share) without making it harder to write good tests, I'm all for it |
| 10:23 | <jgraham> | I don't think either of these things are fundamental design issues though |
| 10:24 | <othermaciej> | I'm not sure stack information is very important |
| 10:24 | <jgraham> | Well it's hard to tell exactly which assert we are talking about without it |
| 10:25 | <othermaciej> | I must admit I do not really understand the details of Opera's needs, but I'm willing to take your word for it that the test/assert distinction somehow serves it |
| 10:26 | <jgraham> | Our needs are mostly that we get consistent output from files containing multiple tests |
| 10:26 | <gsnedders> | othermaciej: Basically, we need a constant set of tests/asserts/whatever to be reported back to the regression tracking |
| 10:26 | <othermaciej> | but I'm not sure I am willing to write three times as many lines of script per HTML5 test to meet those needs |
| 10:26 | <jgraham> | That is, if they give 10 results one day we need 10 results the next day even if we broke something in the middle |
| 10:26 | <othermaciej> | compared to what I am used to in other script tests frameworks |
| 10:27 | <gsnedders> | FWIW, something like what qUnit does of showing all the asserts that ran works for us, provided we still have the tst output. |
| 10:28 | <jgraham> | Yes, ease of authoring is a concern. But maybe this is best discussed with a patch |
| 10:28 | <othermaciej> | I'll write a sample modification to the test framework (maybe more than one) and show how my test case would look with and without it |
| 10:29 | <MikeSmith> | jgraham: btw, https://bitbucket.org/validator/html-spec |
| 10:30 | <MikeSmith> | mirror of the subversion repo for the spec |
| 10:30 | <MikeSmith> | the mercurial clone is only 31MB |
| 10:31 | <MikeSmith> | I had made another attempt at making a git clone of it, but stopped when it got to 8GB |
| 10:32 | <jgraham> | Yeah, something crazy there |
| 10:32 | <MikeSmith> | disk space limit at github is 300MB anyway |
| 10:32 | <MikeSmith> | jgraham: yeah, I have no idea what would cause it to balloon like that |
| 10:33 | <MikeSmith> | also, I think the subversion python bindings that hgsubversion uses by default leak memory |
| 10:34 | <MikeSmith> | making the hg clone kept causing my server to run out of memory |
| 10:34 | <MikeSmith> | and then kill the process |
| 10:35 | <MikeSmith> | all of the available ways to create DVCS clones of subversion repos seem to have some serious problems when working with a subversion repo for any large project |
| 10:36 | <jgraham> | I choose to blame svn |
| 10:36 | <MikeSmith> | hell yeah |
| 10:36 | <MikeSmith> | as usual |
| 10:37 | <MikeSmith> | I dislike subversion enough I'm tempted to say I hope subversion's death is slow and painful |
| 10:38 | <MikeSmith> | as payback for all the wasted time it has cost |
| 10:38 | <jgraham> | It is dying slowly and painfully. Sadly the pain is for the people still using it and those trying to move away from it |
| 10:39 | <rimantas> | MikeSmith, creating svn clone requires to check out every revision out of subversion |
| 10:39 | <MikeSmith> | rimantas: yah, I figured as much |
| 10:39 | <MikeSmith> | jgraham: I just hope that people have enough sense to quit using it for new projects at least |
| 10:40 | <MikeSmith> | why anyone would voluntarily choose subversion for a new project at this point is beyond me |
| 10:40 | <rimantas> | actually it shows one of the ways how subversion sucks - everything (almost) over the net, and slow |
| 10:40 | <gsnedders> | othermaciej: Would something like having setup/teardown would work? There, IMO, needs to be a way to capture exceptions from each and every part of an, e.g., @id testsuite |
| 10:40 | <MikeSmith> | yeah, we could write a book about all the ways it sucks |
| 10:40 | <MikeSmith> | mutli-volume book |
| 10:41 | <annevk> | hmm, Obama failed with tax, Julian Assange arrested |
| 10:41 | <annevk> | not a great day |
| 10:41 | <MikeSmith> | arrested? |
| 10:41 | <MikeSmith> | where? |
| 10:41 | <annevk> | in London, he turned himself in |
| 10:41 | <MikeSmith> | damn |
| 10:41 | <annevk> | according to twitter anyway |
| 10:42 | <MikeSmith> | yeah |
| 10:42 | <jgraham> | MikeSmith: For some kinds of things git et. al. really suck. I'm thinking huge repositories with many files some large and where partial checkouts are useful |
| 10:42 | <MikeSmith> | well, we still have cvs for that |
| 10:42 | <MikeSmith> | for the other stuff |
| 10:42 | <jgraham> | It is not clear to me that CVS sucks less |
| 10:42 | <jgraham> | I mean, there is some competition |
| 10:43 | <MikeSmith> | heh |
| 10:43 | <MikeSmith> | yeah, svn and cvs and going head-to-head there |
| 10:45 | <MikeSmith> | annevk: anyway, he's let the genie out of the bottle… it'll be hard to imagine things just going back to normal. They are not going to be able to prevent leaks from getting published going forward. I think others can see now that it's possible to get the information out |
| 10:46 | <MikeSmith> | jgraham: the bitbucket repo provides an RSS feed |
| 10:46 | <zcorpan> | partial checkout is nice |
| 10:46 | <MikeSmith> | https://bitbucket.org/validator/html-spec/rss |
| 10:46 | <MikeSmith> | zcorpan: partial checkout? |
| 10:47 | <zcorpan> | MikeSmith: checkout just one folder |
| 10:47 | <MikeSmith> | ah |
| 10:49 | <MikeSmith> | bitbucket can do twitter notifications, so I got them turned on now for the @html5 user |
| 10:50 | <MikeSmith> | e.g., http://twitter.com/#!/html5/status/11940556187897856 |
| 10:50 | <MikeSmith> | if anybody wants, I can get notifications (re)set up for @whatwg from there too |
| 10:51 | <MikeSmith> | but first I need to step away for a bit |
| 11:14 | <zcorpan> | interesting that in the first version of WebSocket (then called TCPConnection), the handshake was client: "Hello\n" server: "Welcome\n" |
| 11:26 | <phrearch> | hm, i got a solution for my ws problem: http://hwios.blogspot.com/2010/12/websocket-routing.html |
| 11:27 | <phrearch> | applying urls on a websocket kinda makes sense |
| 11:31 | <phrearch> | either via ws or via http should just point to some resource. maybe have some simulation of get/post in there as well |
| 11:34 | <zcorpan> | phrearch: in theory you could talk HTTP over a websocket |
| 11:35 | <phrearch> | zcorpan: im not sure if i understand :) |
| 11:36 | <zcorpan> | like ws.send('GET /foo/bar HTTP/1.1\r\n ...') |
| 11:36 | <phrearch> | im using it now just as a messaging medium(json) with html as payload for layout |
| 11:36 | <phrearch> | aha |
| 11:37 | <phrearch> | i guess that would take a custom server implementation? |
| 11:37 | <zcorpan> | i'm not sure if HTTP is more useful than JSON though :) |
| 11:37 | <phrearch> | im pretty happy with json atm, but i havent found a consistent routing mechanism yet |
| 11:38 | <phrearch> | having a router that can decode the url to some function would be nice |
| 11:39 | <phrearch> | django had a websocket implementation, but that one seems to try to fit the websocket in a http request/response |
| 11:39 | <phrearch> | it doesnt seem to make sense to do a http handshake every time |
| 12:25 | <MrWax> | Will the WebSQL API be continued in some kind of way? now W3C doesn't do it? |
| 12:25 | <gsnedders> | No |
| 12:26 | <MrWax> | So WebSQL will definitely something we won't see in our webpages in the future? |
| 12:27 | <gsnedders> | Inded |
| 12:27 | <MrWax> | Actually wondering, why not? I mean, it could be quite handy in the light of the more offline apps |
| 12:27 | <gsnedders> | Because there's a lack of interest from implementors, apart from those who've already implemented it |
| 12:27 | <gsnedders> | And that all of them like it anyway |
| 12:27 | <MrWax> | That's kinda bad |
| 12:27 | <gsnedders> | IndexedDB is the future |
| 12:28 | <MrWax> | ok let me look it up |
| 12:28 | <MrWax> | Actually, for a presentation of HTML5, in the light of a CMS i have completely renewed (non HTML5 techniques, just a year ago) I was trying to convince people in a presentation how HTML5 offline web technologies will come to the rescue in a CMS like this |
| 12:28 | <MrWax> | WebSQL was a part of the story but I have to remove it now |
| 12:31 | <phrearch> | hm, offline storage is going away? |
| 12:31 | <gsnedders> | localStorage will contain to exist, and IndexedDB will come into existance |
| 12:32 | <gsnedders> | *continue |
| 12:32 | <gsnedders> | ergh, I can't spell |
| 12:32 | <MrWax> | no no |
| 12:32 | <MrWax> | ok |
| 12:33 | <phrearch> | hm, as long they dont do that for websockets... |
| 12:33 | <gsnedders> | WebSockets has wide support, and is implemented by almost everyone. It's far from in the situation Web SQL ever was. |
| 12:33 | <MrWax> | gsnedders: so basically, what I could explain is something like: The CMS could have an option to work offline, as in, indexedDB will store the pages and their rights etc in tables, localStorage will store the page contents, App cache will store pictures Icons |
| 12:34 | <phrearch> | ok, glad to hear websockets arent scheduled for removal :) |
| 12:34 | <phrearch> | will read up on the websql thing |
| 12:34 | <zcorpan> | websockets is scheduled for disabling in firefox 4 at least |
| 12:34 | <zcorpan> | https://bugzilla.mozilla.org/show_bug.cgi?id=616733 |
| 12:34 | <gsnedders> | Though that is temporary |
| 12:34 | <zcorpan> | yeah |
| 12:34 | <MrWax> | gsnedders: is that a correct approach simply said? |
| 12:34 | <phrearch> | ow dear |
| 12:35 | <gsnedders> | MrWax: localStorage is just for any key->value pair, really |
| 12:35 | <phrearch> | ah well, as long it can be enabled in about::config |
| 12:35 | <MrWax> | gsnedders: so bulk page text contents of a CMS page - how would they be stored for offline usage? |
| 12:36 | <gsnedders> | phrearch: The issue is that the handshake makes it possible to exploit a number of buggy deployed HTTP proxies |
| 12:36 | <gsnedders> | MrWax: Either as key-value pairs in localStorage, in a table in IndexedDB, or as standard content in the app cache |
| 12:36 | <phrearch> | gsnedders: any radical changes expected there? |
| 12:36 | <gsnedders> | phrearch: At a protocol level, yes. |
| 12:38 | <phrearch> | gsnedders: i guess it wont hurt, as long its keeping a persistant connection like now |
| 12:39 | <MrWax> | gsnedders: I also have made a list of HTML5 (and HTML5 related) APIS .. just main, primary not every exact, but the important ones to present.. is this a list which farely represents the more important APIS? |
| 12:39 | <MrWax> | canvas, video/audio, drag & drop, app cache, geolocation, workers, localstorage, microdata, indexeddb |
| 12:40 | <MrWax> | I know there is a lot more, but this is just a small presentation |
| 12:40 | <phrearch> | well, websockets... |
| 12:40 | <phrearch> | :) |
| 12:40 | <gsnedders> | Well, most of them aren't actually in HTML5 |
| 12:40 | <MrWax> | (and some that are not maintained by WHATWG HTML) |
| 12:40 | <MrWax> | yes |
| 12:40 | <MrWax> | thats why I said related |
| 12:41 | gsnedders | isn't great judge of this off the top of his head |
| 12:41 | <gsnedders> | Because I'm probably forgetting half of what is in the spec |
| 12:41 | <MrWax> | ok :) |
| 12:41 | <MrWax> | anyone else maybe? |
| 12:44 | <zcorpan> | canvas: yes (but 2d context is not in w3c version), video/audio: yes, dnd: yes, app cache: yes, geolocation: no, workers: no, localstorage: no, microdata: only in whatwg version, indexeddb: no |
| 12:45 | <MrWax> | zcorpan: ok, for geolocation i agree, but why no localstorage and workers? |
| 12:45 | <zcorpan> | they're not in the html5 spec |
| 12:45 | <MrWax> | yes, but they are considered related apis right? that most browsers will soon implement |
| 12:45 | <zcorpan> | all web apis are related to html |
| 12:46 | <MrWax> | actually who has developed workers, do you know? |
| 12:46 | <zcorpan> | Hixie |
| 12:46 | <zcorpan> | well he wrote the spec |
| 12:46 | <zcorpan> | proof of concept impl was in Gears |
| 12:47 | <jgraham> | MrWax: http://quotes.burntelectrons.org/4394 should explain everything |
| 12:47 | <MrWax> | but, from how I see it, i could just simply change the subject of the second part of my presentation where I speak about APIs, first speak about those in the html5 spec, and then talk about the "related future web" apis |
| 12:47 | <MrWax> | jgraham: thx |
| 12:51 | <Philip`> | We're still in need of a name, as far as I'm aware |
| 12:52 | <zcorpan> | the name is "HTML5" |
| 12:53 | <MrWax> | Who's Hixie related to? |
| 12:53 | <MrWax> | Mozilla? |
| 12:53 | <zcorpan> | he works for google |
| 12:53 | <MrWax> | oh sorry I see his name now sorry sorry |
| 13:04 | <Philip`> | zcorpan: If that's the name, tell gsnedders to stop telling people that things aren't actually in HTML5 :-) |
| 13:04 | <annevk> | IE does not even render my site that terrible |
| 13:04 | <annevk> | IE8* |
| 13:05 | <jgraham> | I think HTML5 is the marketing name meaning one thing and the technical name meaning another thing. It sounds confusing but it is no more confusing than every other case where a word has multiple meanings |
| 13:05 | <jgraham> | You just need to disabmiguate based on context |