| 00:04 | <ttepasse> | http://24ways.org/2009/incite-a-riot |
| 00:13 | <JonathanNeal> | ttepasse, fight for your right to cite! |
| 00:16 | <ttepasse> | :) |
| 01:43 | <hsivonen> | Does Kaazing have a Web Socket server already? |
| 01:48 | <MikeSmith> | hsivonen: yes |
| 01:49 | <MikeSmith> | not a separate server, but integrated into their gateway product |
| 01:49 | <MikeSmith> | iirc |
| 01:57 | <franksalim> | hsivonen, yes |
| 02:00 | MikeSmith | didn't know franksalim was on this channel |
| 02:01 | <MikeSmith> | hi franksalim |
| 02:01 | <MikeSmith> | have you had time yet to look at SPDY much? |
| 02:01 | <franksalim> | MikeSmith, hello |
| 02:03 | <franksalim> | MikeSmith, not in great detail |
| 02:05 | <MikeSmith> | franksalim: I'm just wondering how overlap there will end up being in practice between use of SPDY protocol and use of Web Sockets protocol |
| 02:06 | <MikeSmith> | wondering whether the Web Sockets client API could also be used with SPDY as the network protocol |
| 02:07 | <franksalim> | the WebSocket api could certainly wrap the SPDY protocol in some way |
| 02:09 | <franksalim> | so far SPDY hasn't been exposed to JavaScript in any way beyond how HTTP has been exposed, AFAIK |
| 02:09 | <franksalim> | XHR and requests for resources (that may be cached) |
| 05:04 | <MikeSmith> | AryehGregor: http://www.alvestrand.no/pipermail/ietf-languages/2009-December/009754.html |
| 05:05 | <MikeSmith> | about the "eml" tag |
| 05:05 | <MikeSmith> | we'll see what response that gets |
| 05:05 | <MikeSmith> | but in the mean time, I reckon we can just add special-case handling for eml in the language-tag code |
| 05:06 | <MikeSmith> | and remove it later if/when "eml" does actually get added to the registry |
| 09:56 | <Hixie> | sorry about sporadic downtime overnight, dreamhost were downing some surgery on my web host config to fix some problems on some of my other domains |
| 11:24 | <annevk2> | "If getContext() is subsequently called with any other string, the WebGLRenderingContext shall be detached from its Canvas object (the canvas attribute will be null). API calls may still be made on the WebGLRenderingContext object and readPixels() may be used to obtain the contents of the drawing buffer. But the contents shall no longer be shown on the page." |
| 11:24 | <annevk2> | hmm |
| 11:25 | <annevk2> | it doesn't say it if can become attached again afterwards |
| 11:25 | <Philip`> | Also doesn't say what happens if you have a reference to a 2D context then get a WebGL context then use the 2D context |
| 11:28 | <Philip`> | Maybe HTML5 ought to define a mechanism for new contexts to be defined that interact with other contexts in various ways (e.g. one context being a vendor-specific extension of another context, or one being exclusive to all other contexts, etc) |
| 11:28 | <annevk2> | or it should say that exclusive contexts are verboten |
| 11:28 | <Philip`> | because otherwise it's quite possible that multiple specs will define contradictory behaviour |
| 11:29 | <annevk2> | yuhhuh |
| 11:30 | <Philip`> | How would it work with non-exclusive contents? |
| 11:30 | <Philip`> | If you draw something with WebGL then draw something else with 2D on the same canvas, what happens? |
| 11:30 | <Philip`> | and then when you call toDataURL, what happens? |
| 11:31 | <annevk2> | it should just draw on top |
| 11:31 | <annevk2> | i'd guess |
| 11:31 | <annevk2> | and share the backing store |
| 11:31 | <Philip`> | HTML5 seems to assume there is a single bitmap that's part of the canvas state, but I think that's incompatible with efficient WebGL implementations |
| 11:31 | <annevk2> | so everything draws on the same bitmap |
| 11:32 | <Philip`> | OpenGL doesn't draw onto bitmaps in system memory, unless you manually copy it back from the video card (which is pretty slow) |
| 11:32 | <annevk2> | you could implement 2d in WebGL |
| 11:34 | <Philip`> | I think that's kind of what's happening with some Direct2D browser experiments, but that's Windows-only and it's apparently really hard if you just have the raw 3D APIs |
| 11:34 | jgraham | seems to recall we had this conversation before :) |
| 11:35 | <Philip`> | jgraham: I don't recall coming to any conclusion before, sadly |
| 11:35 | <jgraham> | No, we didn't |
| 11:35 | <Philip`> | It would be nice to have one at some point |
| 11:35 | <Philip`> | before it gets shipped too much |
| 11:35 | <jgraham> | IIRC we decided it would be nice if everything could happen on the graphics card but probably impractical in the short term |
| 11:36 | <annevk2> | Hixie is always big on cracks between the specs |
| 11:36 | <annevk2> | he should take this on! |
| 11:36 | <Hixie> | file a bug |
| 11:36 | <annevk2> | mkay |
| 11:36 | <Hixie> | i wonder how webgl implementations handle the canvas being animated with a 3d css transform |
| 11:37 | <Hixie> | while a <video> plays on top... |
| 11:37 | <annevk2> | on a phone with hardware accelerated video |
| 11:37 | <annevk2> | ...boom... |
| 11:39 | <annevk2> | bugs |
| 11:39 | <annevk2> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=8476 |
| 11:40 | <jgraham> | In the future people will carry their phone in their pocket and a huge backpack containing a graphics card and a water cooling system |
| 11:41 | Philip` | wonders if jgraham has missed the trend for electronic miniaturisation over the past half a century |
| 11:44 | <jgraham> | Philip`: :) But presumably power consumption and heat generation are still rather large problems even with minature components |
| 11:52 | <Philip`> | jgraham: Things like PSPs and iPhones seem to do decent 3D quite happily, with similar capabilities to full-size consoles from ten years ago |
| 11:53 | <Philip`> | and I assume they must cope with the power and heat requirements adequately |
| 11:53 | <Philip`> | and I don't see any reason for the trend to stop |
| 11:54 | <workmad3> | most high-end phones have mobile versions of reasonable graphics chips nowadays |
| 11:55 | <workmad3> | and I'd say the capabilities are closer to pc graphics from about 5 years ago, but with less available memory |
| 11:56 | <Philip`> | workmad3: So they could run Half Life 2? :-) |
| 11:57 | <workmad3> | Philip`: potentially, if you reduced the graphics quality and map size considerably to fit within the memory available ;) |
| 11:59 | <workmad3> | at least in 3d graphics capabilities... there's a lot more to HL2 than that though :) |
| 12:00 | <Philip`> | I probably shouldn't have said "capabilities" - it seems like they support much more modern features and APIs, but performance is further behind |
| 12:00 | <Philip`> | so you have to use the capabilities more sparingly |
| 12:00 | <workmad3> | Philip`: that's probably about right yeah :) |
| 12:01 | <Philip`> | (I know basically nothing about this area though, so mostly I'm just guessing :-) ) |
| 12:01 | <workmad3> | they don't run quite as fast, and have nowhere near as much memory, but the feature-set of the chips in use is pretty modern and allows for more sophisticated stuff than consoles from 10 years ago did |
| 12:01 | <Philip`> | At least they don't have to bother with HD resolution output |
| 12:01 | <workmad3> | that said, you don't need to render in anywhere near as high resolution or store as much geometry :) |
| 12:02 | <workmad3> | I think phone screens nowadays are 'QHD' (quarter HD) nowadays and clock in at 640x360 pixels :) |
| 12:03 | <workmad3> | but raw graphics power isn't really the problem on phones... it's control and all the other stuff that's needed |
| 12:04 | <Philip`> | That sounds more like ninth HD, unless you cheat and consider lower-than-standard-cheap-laptop-display to be HD :-) |
| 12:05 | <Philip`> | They should call it "middling definition", perhaps |
| 12:05 | <workmad3> | Philip`: a standard HD res is 1280 * 720 |
| 12:06 | <workmad3> | (I think that's the res of 1080p) |
| 12:06 | <Philip`> | 1080p is 1920x1080, hence the "1080" in the name, unless I'm horribly confused |
| 12:06 | <workmad3> | so taking the HD resolutions as those supported by HD tvs, then it is a quarter of that :) |
| 12:07 | <Philip`> | (and 1280x720 is 720p) |
| 12:07 | <workmad3> | hmm... I may be thinking of 720p then |
| 12:07 | <workmad3> | still, it's classed as a HD resolution, so the phone manufacturers went with a quarter of it as 'QHD' :) |
| 12:08 | <peroo> | actually qhd is 960x540, one quarter of 1920x1080 :) |
| 12:09 | <peroo> | 640x360 is nHD apparantly, whatever that means |
| 12:10 | Philip` | guesses it must have been a marketing person who decided an acronym containing the word "high" was appropriate for sub-VGA resolutions :-p |
| 12:10 | <jgraham> | "Not High Definition", perhaps |
| 12:11 | <workmad3> | heh, I'm going by what the phones I worked on that had that resolution called it :) |
| 12:13 | <workmad3> | still, AFAIK, the graphics chips available to phones are capable of the raw power required to do all the effects that modern consoles are capable of, the restricting points are things like the physics engines and other processing that's required to get the data ready for the screen in a game |
| 13:33 | <Hixie> | i wonder how to add features to html5 without pissing off the htmlwg |
| 13:37 | <daedb> | Hixie: I don't think that's possible (unless it's XMLy or includes namespaces), but do it anyway :p |
| 13:38 | <Hixie> | well there are options like making the new features only appear in the whatwg version |
| 13:38 | <annevk2> | Hixie, what feature? |
| 13:38 | <Hixie> | which would piss off the people who get pissed off regardless of what i do, but wouldn't piss off the more sane people |
| 13:39 | <jgraham> | I would be pissed off if we introduced namespaces |
| 13:39 | <Hixie> | annevk2: e.g. a widget to trigger the display of UA UI to allow the user to select a video source |
| 13:39 | <Philip`> | What about the people who think it'll be really confusing if there's two substantially different HTML5 specs? |
| 13:39 | <Hixie> | Philip`: are they likely to cause me more or less trouble than the people who would complain at me adding features as we are trying to get to LC? |
| 13:40 | <annevk2> | Hixie, at what point do we declare HTML5 feature complete? |
| 13:40 | <Hixie> | we declared HTML_5_ feature complete about 2 years ago |
| 13:40 | <Hixie> | well that's not quite accurate |
| 13:41 | <Hixie> | we announced that HTML5 feedback shouldn't ask for new features about 2 years ago, and then announced LC (feature freeze) about 2 months ago |
| 13:41 | <Hixie> | but I'm talking about post-HTML5 |
| 13:41 | <Hixie> | HTML6, or HTMLCurrent, or whatever |
| 13:41 | <annevk2> | ah ok |
| 13:41 | <annevk2> | so are you going to version the differences somehow? |
| 13:42 | <Hixie> | how do you mean |
| 13:42 | <annevk2> | <!--HTML6--> or some such |
| 13:42 | <Hixie> | you mean "are the new features going to appear in the w3c html5 draft"? |
| 13:43 | <annevk2> | just wondering about the WHATWG Last Call draft for the moment |
| 13:43 | <jgraham> | any draft that says HTML5 at the top I would have thought |
| 13:43 | <Hixie> | yeah that's the question, how to do it |
| 13:43 | <Hixie> | we could rename the whatwg draft to just "HTML", i guess |
| 13:43 | jgraham | thinks it would be fine to make a HTML.next draft for unstable stuff |
| 13:43 | <Hixie> | or have a separate view of it somehow |
| 13:44 | <annevk2> | I think we should maintain a HTML5 copy |
| 13:44 | <annevk2> | preferably on the same URL |
| 13:44 | <Hixie> | maybe have specs/web-apps/html5/ include just the html5 stuff, and specs/web-apps/current-work/ for the new stuff |
| 13:44 | <Hixie> | (and specs/web-apps/current-work/complete.html for everything but sql) |
| 13:44 | <annevk2> | current-work/ does suggest latest, so yeah, that seems ok |
| 13:45 | <Hixie> | btw if any of you want your specs merged into complete.html, we can do that |
| 13:45 | <Hixie> | e.g. to get the XHR cross-refs working |
| 13:45 | <annevk2> | people will find it somewhat confusing if we call it "HTML" though I suspect |
| 13:45 | <Hixie> | we could call it HTML6 |
| 13:45 | <Hixie> | or 5.1 |
| 13:45 | <Hixie> | or something |
| 13:45 | <annevk2> | Hixie, hmm yeah, I hope someone fixes anolis |
| 13:46 | <Hixie> | (though i really want to drop this versioning crap) |
| 13:46 | <annevk2> | HTML (formerly HTML5) |
| 13:46 | <annevk2> | for at least half a year or so |
| 13:46 | <annevk2> | and then we drop (formerly HTML5) |
| 13:47 | <Hixie> | or "HTML (including HTML5)", to indicate it's more than HTML5 |
| 13:47 | <annevk2> | yeah, works too |
| 13:47 | <Hixie> | and then drop the paranthetical |
| 13:47 | <gsnedders> | annevk2: patches welcome. |
| 13:48 | <jgraham> | Call it HTML unstable or something |
| 13:48 | <Hixie> | (s/a/e/magic) |
| 13:48 | <gsnedders> | HTML Beta |
| 13:48 | <jcranmer> | HTML 5 rc i |
| 13:48 | <jgraham> | HTML Labs |
| 13:48 | <Hixie> | well the idea is to just have a single name that is always the top of the tree |
| 13:48 | <Hixie> | so "unstable" or "beta" is kinda wrong |
| 13:48 | <gsnedders> | jcranmer: So it's not a rc? |
| 13:48 | <Hixie> | i mean, <p> isn't going anywhere |
| 13:48 | <jcranmer> | gsnedders: it's an imaginary one |
| 13:49 | <Hixie> | i wish othermaciej was here, i'm curious as to his opinion on this |
| 13:49 | <jcranmer> | more complex than the real HTMLs |
| 13:49 | <jgraham> | Hixie: Well you always have an unstable and periodically make numbered stable releases, Debian style |
| 13:49 | <jgraham> | (or call it HTML Mainline which sounds cooler, like a VU song) |
| 13:49 | <Hixie> | that's what i want to move away from |
| 13:49 | <annevk2> | I'd rather be forever in release-state |
| 13:49 | <Hixie> | yeah |
| 13:50 | <Hixie> | bbiab, gotta get ready. |
| 13:50 | <jgraham> | Well so I would I but good luck getting the rest of the world to agree |
| 13:50 | <annevk2> | but until we convince the W3C it's prolly safer to have markers for the new stuff |
| 13:52 | <annevk2> | no need to convince the whole world |
| 13:53 | <annevk2> | just the patent lawyers |
| 13:53 | <annevk2> | which is prolly harder |
| 14:19 | <Hixie> | not really any need to convince those either so long as the w3c is publishing snapshots |
| 14:19 | <Hixie> | which i doubt they plan to stop doing |
| 14:21 | <annevk2> | legal effect of the patent policy only applies to W3C Recommendations |
| 14:21 | <annevk2> | I believe |
| 14:26 | <Hixie> | right, so so long as they keep publishing everything the whatwg does, everything is covered |
| 14:26 | <Hixie> | doesn't really matter when the publication happens, since the policy doesn't really kick in until REC anyway, as I understand it |
| 14:26 | <annevk2> | the issue I'm thinking about is that W3C Recommendation status is incompatible with forever-trunk |
| 14:27 | <Hixie> | i'm saying that what we do is forever-trunk at the whatwg, and continue working with the w3c to publish RECs every now and then |
| 14:27 | <Hixie> | as we've basically been doing |
| 14:27 | <Hixie> | the only problem is that the htmlwg is kinda stopping progress on html because of it trying to go to LC |
| 14:28 | <Philip`> | If the patent policy only kicks in at REC, I guess that means everyone is free to sue each other until 2022? |
| 14:28 | <annevk2> | that works though that also means you need to keep the REC markers in the document (or trunk markers) |
| 14:28 | <annevk2> | if you want to get rid of those too (I like!) then the convincing thingie above applies |
| 14:29 | <annevk2> | Philip`, pretty much |
| 14:29 | <annevk2> | Philip`, but I'm not a lawyer |
| 14:29 | <Hixie> | REC markers? |
| 14:31 | <annevk2> | <!--REC-ends--> |
| 14:31 | <annevk2> | or <!--HTML6--> or whatever |
| 14:31 | <jgraham> | That sounds... bad |
| 14:32 | <Hixie> | so long as one source document is generating more than one published document, i don't see how we could stop having some kind of markers |
| 14:33 | <jgraham> | It seems nightmarish to generate multiple versions of the same spec from the same source file |
| 14:34 | <Hixie> | i take it you haven't read http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F recently |
| 14:34 | <annevk2> | Hixie, the difference is that this is a version marker, but maybe that's not much of a difference |
| 14:34 | <MattCampbell> | What version of Python does html5lib require? |
| 14:34 | <Hixie> | annevk2: i don't see how it's any different than html5 vs complete.html, or the whatwg microdata vocab spec vs w3c's three microdata vocab specs |
| 14:34 | <jgraham> | Hixie: This is quite different |
| 14:34 | <annevk2> | Hixie, and hopefully we do not let it scale to IE8 proportions |
| 14:35 | <jgraham> | I would have thought |
| 14:35 | <Hixie> | jgraham: how so? |
| 14:35 | <jgraham> | MattCampbell: 2.4 I guess |
| 14:35 | <Hixie> | annevk2: well these are just supersets of each other right, i mean, it's not like we're changing anything |
| 14:35 | <jgraham> | Hixie: Because I would expect changes from new versions to be much more invasive than changes that just involve splitting along broad feature lines |
| 14:36 | <MattCampbell> | darn, guess I'll have to compile Python from source to use html5lib on RHEL5 (which has Python 2.4) |
| 14:36 | <Hixie> | jgraham: i would expect editorial changes to just be made to all versions |
| 14:36 | <jgraham> | MattCampbell: (it might work under 2.3 but no promises) |
| 14:36 | <annevk2> | Hixie, sure, but it could get tricky nonetheless |
| 14:36 | <Hixie> | annevk2: well if it is too tricky we can always give up and do something else :-) |
| 14:37 | <annevk2> | Hixie, e.g. further overloading of existing methods, etc. |
| 14:37 | <gsnedders> | Hixie: Web DOM Core? |
| 14:37 | <annevk2> | diving and hiking |
| 14:38 | <jgraham> | Hixie: Yes but say you make a change that adds new steps to an existing algorithm, makes a few changes to conformance criteria and adds a few paragraphs of new material |
| 14:38 | <jgraham> | Then you end up with a bunch of ifdefs all over the place to try and seperate out the HTML6 stuff from the HTML5 stuff |
| 14:38 | <Hixie> | jgraham: we have a bunch of ifdefs already to do complete.html |
| 14:39 | <Hixie> | jgraham: it's not that big a problem |
| 14:39 | <jgraham> | Hixie: On such a fine-grained level? It seems like it should be a problem :) |
| 14:40 | <Hixie> | search for "END complete" in the source file |
| 14:41 | <annevk2> | Hixie, anyway, I don't have a better solution other than changing the way the W3C REC-track works and what you have works much better than what I do for XMLHttpRequest I think |
| 14:41 | <annevk2> | (which is trying to keep two documents in sync) |
| 14:41 | <Hixie> | on the long term i definitely think we should change the way the w3c REC track works, but that needs far more effort than i am willing to put out |
| 15:55 | <pesla\work> | sigh, firefox always crashes on the html5 specs -.- |
| 15:56 | <Hixie> | pesla\work: use http://whatwg.org/html5 |
| 15:56 | <Hixie> | pesla\work: that works in firefox |
| 15:56 | <annevk2> | pesla\work, wrong channel to complain |
| 15:56 | <pesla\work> | Hixie: sweet :) |
| 15:57 | <Hixie> | pesla\work: if you need the one-page version, try http://www.whatwg.org/specs/web-apps/current-work/?slow-browser |
| 16:00 | <pesla\work> | annevk2: Man, I just needed someone to listen to my grief! ;) |
| 16:00 | <pesla\work> | Hixie: the /html5 method works perfectly :) |
| 16:05 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmlcollection-0 |
| 16:05 | <Philip`> | "nthnthnth(&*@%WN@%HM)%25" |
| 16:06 | <Philip`> | Hixie: I'm not sure that's valid IDL |
| 16:06 | <Hixie> | yeah, trying to fix that. somehow my script thought i'd fixed it (which i had in the source) and so was refusing to regen the files |
| 16:06 | <Hixie> | ironically, it was there to test that the new webidl check in the pipeline was working |
| 16:06 | <Hixie> | (i've integrated dom's service into my update script) |
| 16:07 | <Philip`> | Ah |
| 16:09 | <annevk2> | pesla\work, just trying to find you a long term solution :p |
| 18:14 | <Hixie> | ok well i tried doing what we were talking about earlier |
| 18:14 | <Hixie> | we'll see how it goes |
| 18:22 | <hober> | Hixie: it seems like whatwg.org/html5 should redirect to the HTML5 draft |
| 18:22 | <hober> | maybe we could mint a whatwg.og/html redirect to current-work |
| 18:23 | <Hixie> | added /html |
| 18:23 | <Hixie> | i think people would find the full html spec more useful than the html5 spec |
| 19:05 | <jwalden> | annevk2: actually, I was thinking old-school, Sinatra; never even heard of MGS before :-) |
| 21:18 | <smaug> | "Your message to whatwg awaits moderator approval" |
| 21:18 | <smaug> | um |
| 21:19 | <smaug> | who is the moderator? |
| 21:34 | <Philip`> | smaug: There is no moderator |
| 21:34 | <Philip`> | smaug: so your message will never be approved |
| 21:34 | <Philip`> | smaug: You have to be subscribed before posting |
| 21:36 | <smaug> | Philip`: I'm subscribed |
| 21:36 | <smaug> | Philip`: the problem is that the email has apparently too many people CC'ed |
| 21:36 | <smaug> | (not that many, really) |
| 21:37 | <Philip`> | smaug: Oh, okay |
| 21:37 | <Philip`> | smaug: CC less :-) |
| 21:39 | <smaug> | Philip`: actually someone else CC'ed already so many people that couldn't really add new ones :) |