| 01:51 | <mihaip> | Hixie: what happens to the pending state object if I call replaceState or pushState before onload fires? |
| 02:42 | <Hixie> | mihaip: is the spec ambiguous? |
| 02:44 | <mihaip> | Hixie: the spec doesn't say anything about the interaction of replaceState with the pending state object |
| 02:44 | <Hixie> | seems like it would have no effect then |
| 02:44 | <mihaip> | Hixie: so a strict reading would be that pending state object is unaffected by replaceState |
| 02:44 | <Hixie> | a strict reading is the only valid reading :-) |
| 02:45 | <mihaip> | Hixie: so if you call replaceState("foo") before onload, you would still get a popstate event with null state right after onload |
| 02:45 | <Hixie> | per the spec, seems that way |
| 02:45 | <mihaip> | Hixie: but then if you call pushState("bar") and then history.back() you would get a popstate event with with "foo"? |
| 02:46 | <Hixie> | i don't understand the order of operations in your scenario |
| 02:46 | <Hixie> | replaceState('foo'), then onload, then popstate, then pushState('bar') then history.back()? |
| 02:46 | <mihaip> | yes |
| 02:48 | <Hixie> | i guess so |
| 02:48 | <Hixie> | i'd have to look at the spec to tell you for sure |
| 04:56 | <roc> | "Extending the border-collapse property to all elements" NOOOOO RUN RUN RUN DIE |
| 05:00 | <MikeSmith> | heh |
| 06:05 | <Hixie> | can someone with IE (ideally 9 but any version will do) tell me if <body bgcolor=" red"> is a black page or a red page? |
| 06:06 | <Hixie> | (or a lime green page) |
| 06:45 | <paul_irish> | Hixie: ie6, ie8, ie9pp4: lime green. |
| 06:46 | <Hixie> | paul_irish: thanks |
| 06:46 | <paul_irish> | Hixie: how'd you know it'd be lime? |
| 06:47 | <Hixie> | it's the result of running the crazy color algorithm on "xxed" |
| 06:47 | <Hixie> | does it at least go red for bgcolor=red? |
| 06:47 | <Hixie> | no need to test more than one |
| 06:48 | <paul_irish> | yes. |
| 06:48 | <paul_irish> | red |
| 06:49 | <Hixie> | thanks |
| 07:27 | <annevk5> | Firefox sniffs the file extension for video served over HTTP? |
| 07:27 | <annevk5> | oh god |
| 07:28 | <kinetik> | no it doesn't. |
| 07:30 | <annevk2> | I guess Chris was confused then |
| 07:33 | <annevk> | I was actually |
| 07:41 | <annevk> | Hopefully window.matchMedia() is now done |
| 08:00 | <annevk> | does anyone know if all the specs on File / Blob et all are up to date? |
| 08:00 | <annevk> | http://dev.w3.org/2006/webapi/FileAPI/ |
| 08:03 | <annevk> | http://dev.w3.org/2009/dap/file-system/file-writer.html seems more up to date |
| 08:04 | <annevk> | http://dev.w3.org/2009/dap/file-system/file-dir-sys.html likewise |
| 08:04 | <annevk> | also confusing some of this is developed at DAP and some at WebApps |
| 08:29 | <MikeSmith> | protip: upgrading your bind9 software is a great way to fill up your logs with tons of useless messages |
| 08:30 | <hsivonen> | This makes me sad: http://www.w3.org/2001/tag/group/track/issues/67 (that it still isn't considered over) |
| 08:34 | <annevk> | the TAG should get someone with web developer experience |
| 08:34 | <annevk> | and maybe someone with browser QA experience |
| 08:34 | <annevk> | if they want to remain somewhat relevant anyway |
| 11:59 | Ms2ger | loves http://dhtml5.com/ |
| 12:02 | <annevk> | heh |
| 12:02 | <hsivonen> | nice |
| 12:13 | <Ms2ger> | I just hope they'll have snowflakes for Christmas |
| 12:17 | <annevk> | it needs some under construction |
| 12:18 | <Philip`> | Needs more <bgsound> |
| 12:18 | <MikeSmith> | annevk: plh is at home in Cambridge |
| 12:18 | <MikeSmith> | boston |
| 12:19 | <annevk> | kk |
| 12:22 | <hsivonen> | too bad the settlers believed in namespaces. all this confusion about Cambridge now... |
| 12:26 | <Philip`> | It's fine when they used an explicit prefix, like "New" |
| 12:26 | <Philip`> | It's just the default namespace that's a pain |
| 12:26 | <hsivonen> | new:cambridge |
| 12:38 | <virtuelv> | Even old New York was once New Amsterdam |
| 12:46 | <hsivonen> | Well, this is interesting: http://www.businesswire.com/news/home/20100825006629/en (a way of making content providers put pressure on software providers, since it seems they still expect software providers to pay) |
| 13:43 | <Peter`> | http://www.businesswire.com/news/home/20100825006629/en |
| 13:44 | <Peter`> | H264 will remain free for internet video for the rest of the codec's lifetime |
| 13:44 | <Workshiva> | This will be interesting |
| 13:45 | <Peter`> | I concur, wondering what Mozilla's stance on it will be |
| 13:45 | <hsivonen> | free for the server operator to serve the bits over HTTP, that is |
| 13:45 | <hsivonen> | not free for browsers or for encoders |
| 13:45 | <hsivonen> | not free for sites that have video behind paid login |
| 13:47 | <annevk> | are they afraid of something? |
| 13:47 | <annevk> | I wonder why they announced that |
| 13:47 | <Workshiva> | Maybe because they want h264 to become the most popular codec? |
| 13:49 | <Rik`> | Workshiva: will that achieve anything? |
| 13:49 | <daedb> | Isn't it already the most popular? |
| 13:49 | <Workshiva> | Rik`: It will prevent other codecs from becoming popular, which makes them a lesser threat against h264's other areas of use |
| 13:50 | <hsivonen> | Rik`: they could extract money from encoder and decoder vendors while the people who make it popular think it's Not Their Problem |
| 13:50 | hsivonen | looks forward to betanews coverage of this |
| 13:57 | <hsivonen> | ooh. more test cases in html5lib |
| 14:05 | <hsivonen> | I see a troubling number of failing cases that are supposed to be simple |
| 14:08 | <hsivonen> | tests21.dat is in a bogus format... |
| 14:23 | <annevk> | hsivonen, I think jgraham introduced something new |
| 14:26 | <hsivonen> | annevk: the file lacks "| " at the start of the tree data lines |
| 14:26 | <hsivonen> | I'll add what's missing |
| 14:27 | <annevk> | who added that? |
| 14:27 | <hsivonen> | since it's not cool to make a trivial change to the test format when the trivial change would require revising a non-trivial number of test harnesses |
| 14:27 | <annevk> | uhuh |
| 14:28 | <hsivonen> | annevk: it seems to me that jgraham added it |
| 16:08 | <kkaefer> | does anyone have an idea how to find out whether a path is clockwise or counterclockwise? |
| 16:10 | <Philip`> | kkaefer: What kind of input do you have? |
| 16:10 | <kkaefer> | the path is the active path on the canvas |
| 16:10 | <kkaefer> | s/active/current/ |
| 16:12 | <Philip`> | If you had a list of line segments that made a simple polygon then you can do lots of things like summing the turn angles at each vertex |
| 16:12 | <Philip`> | In general a path might not be either clockwise or anticlockwise (e.g. it could be both) |
| 16:14 | <kkaefer> | true |
| 16:14 | <kkaefer> | hm |
| 16:14 | <Philip`> | (Also it could clockwise but wind around twice) |
| 16:14 | <kkaefer> | what I'm trying to do is to draw an inset shadow |
| 16:15 | <kkaefer> | so what I'm doing is to draw the path, add a large rectangle around it, to invert the shape |
| 16:15 | <kkaefer> | clip() and fill() |
| 16:15 | <kkaefer> | which works just fine for simple shapes like circles and rectangles |
| 16:16 | <Philip`> | Yeah, if you want arbitrarily complex paths then that's not going to work |
| 16:19 | <Philip`> | If you have two circles, one clockwise (winding number +1) and one anticlockwise (winding number -1), you can never add a constant amount to the winding number (by drawing a rectangle around the shapes) to make them both 0 (hence not-filled) |
| 16:19 | <Philip`> | It'd be more feasible if we had even/odd fill rules instead of just non-zero-winding-number |
| 16:21 | <kkaefer> | yep |
| 16:44 | <kkaefer> | Philip`: ok, found a way with offscreen canvas in case you're interested |
| 16:46 | <kkaefer> | http://pastie.textmate.org/private/qiurumwij0rwnxj4ku6kw |
| 16:53 | kkaefer | can now render http://i.kkaefer.com/canvas-20100826-185830.png |
| 16:54 | Philip` | sees that being unsubscribed from the hybi list hasn't stopped Shelby posting three consecutive posts as replies to each other in the same thread, in the past day, twice |
| 16:55 | <annevk> | it is quite insane |
| 16:56 | <Philip`> | It'd be amusing if it wasn't wasting so much of everyone else's time |
| 16:59 | <MikeSmith> | H.264 news is interesting |
| 17:00 | <MikeSmith> | but aren't a lot of the patents going to start expiring after 2015 anyway? |
| 17:02 | <MikeSmith> | hmm, wondering if anybody has a 10-20 on Maciej |
| 17:08 | <Ms2ger> | Philip`, are people really still replying to him? |
| 17:09 | <annevk> | he is |
| 17:19 | <User> | So as I understand, it is possible specify a font file in CSS, but it can't be use with Canvas.strokeText and Canvas.font |
| 17:19 | <Philip`> | That should be possible |
| 17:19 | <Philip`> | (Using it with canvas, I mean) |
| 17:21 | <User> | I saw scripts that convert the glyphs into JS files and then redraw them in Canvas, and something like ctx.font="url(myfontfile.otf)" triggers an error |
| 17:22 | <Philip`> | ctx.font has to be a font face name, not a URL |
| 17:23 | <Philip`> | so you have to use @font-face to load the URL first |
| 17:23 | <User> | and canvas would use it ? |
| 17:23 | <annevk> | XHR test suite is public at last |
| 17:23 | <annevk> | http://tc.labs.opera.com/apis/XMLHttpRequest/ |
| 17:24 | <User> | ah ok, I think I got it |
| 17:25 | <Philip`> | User: It should work like http://philip.html5.org/tests/canvas/suite/tests/2d.text.draw.fontface.html |
| 17:26 | <Philip`> | using @font-face and then ctx.font = "TheFamilyNameYouDefined" |
| 17:26 | <Philip`> | (though you need to be careful to make sure the browser has finished loading the font first) |
| 17:31 | <User> | I understand how it should work now... but no luck yet. Always the same error when the script runs. And the font file is on local directory, so loading time shouldn't be a problem now. |
| 17:35 | <User> | The font works appears well in a paragraph with the font-family attribute, but not on the canvas with ctx.font |
| 17:42 | <User> | It works with font-family set on canvas, so I consider it a bug. There should be an attribute ctx.fontFamily to set the font family at the level of the context |
| 17:43 | <User> | actually it works only if the size is specified |
| 17:43 | <User> | so it works now... sort of |
| 18:24 | <AryehGregor> | This looks very interesting: http://tcpcrypt.org/tcpcrypt.pdf |
| 18:36 | <MikeSmith> | can anybody suggest a Node framework that you've tried out and can recommend? |
| 18:36 | <MikeSmith> | I mean, e.g., express or geddy or .../ |
| 18:36 | <micheil> | umm.. |
| 18:37 | <micheil> | I've looked at each, Express is nice, Connect is more config, geddy was okay, Fab looks nice, but it confused me a be |
| 18:37 | <micheil> | *bit |
| 18:37 | <micheil> | I'd probably go for Express. |
| 18:37 | <micheil> | MikeSmith: you should really ask in #node.js |
| 18:38 | <MikeSmith> | micheil: OK |
| 18:38 | <MikeSmith> | thanks |
| 18:38 | <MikeSmith> | fwiw, I have been trying out express a bit |
| 18:38 | <MikeSmith> | already |
| 18:38 | <micheil> | TJ has a few screencasts up too |
| 18:38 | <MikeSmith> | TJ? |
| 18:39 | <micheil> | http://screenr.com/6y0 |
| 18:39 | <micheil> | the maintainer |
| 18:43 | <MikeSmith> | I'm trying figure out how closely express is bound to haml |
| 18:43 | <MikeSmith> | e.g., can I just use HTML source instead |
| 18:44 | <micheil> | express isn't bound to HAML, iirc. |
| 18:44 | <MikeSmith> | OK |
| 18:45 | <micheil> | http://expressjs.com/guide.html#View-Rendering |
| 18:45 | MikeSmith | reads |
| 18:46 | <MikeSmith> | ah good |
| 18:47 | <MikeSmith> | so I see mention of Jade there, and now I'm just looking at Jade for the first time |
| 18:48 | <MikeSmith> | and I see this: http://jade-lang.com/ |
| 18:48 | <MikeSmith> | and my reaction is, why/ |
| 18:48 | <MikeSmith> | *why? |
| 18:49 | <micheil> | because it's better then haml? |
| 18:49 | <MikeSmith> | heh |
| 18:49 | <MikeSmith> | well, that's pretty easy to do |
| 18:50 | <MikeSmith> | I meant, why not just write it HTML to begin with? |
| 18:50 | <micheil> | MikeSmith: good luck with writing a tool like jade then :P |
| 18:50 | <micheil> | because you don't want to close tags and whatever else |
| 18:50 | <micheil> | and you want to have access to JS functions in your html |
| 18:50 | <micheil> | like, for loops, etc |
| 18:53 | <MikeSmith> | I think EJS looks more like what I'd personally prefer |
| 18:53 | <MikeSmith> | I do understand why people prefer haml and the haml-like approach, though |
| 18:53 | <MikeSmith> | I don't belittle it |
| 18:53 | <MikeSmith> | I don't mean to belittle it |
| 18:54 | <micheil> | MikeSmith: personally I'm use Jade in a client project, as they were already using haml, but haml had heaps of errors in the browser |
| 18:54 | <MikeSmith> | I see |
| 18:54 | <MikeSmith> | it does seem like a more error-prone approach |
| 18:55 | <MikeSmith> | more processing just to produce the actual HTML, more possible points of failure |
| 18:55 | <micheil> | true, but it's simpler for some reason |
| 19:04 | <jgornick> | MikeSmith: I agree with you |
| 19:04 | <jgornick> | Give me a compelling reason why I need to use something like that to produce the same markup I can already easily write. |
| 19:05 | <jgornick> | "something" is like Haml, Jade, Sass, etc... |
| 19:07 | <Philip`> | jgornick: Because you want to make it much harder to debug, by breaking the direct mapping between source code and output |
| 19:07 | <micheil> | jgornick: it's just quicker |
| 19:07 | <micheil> | harder to debug, yes |
| 19:07 | <micheil> | but it's still quicker to write |
| 19:08 | <jgornick> | micheil: If you are a pro at writing HTML and CSS, then it should be no quicker. |
| 19:08 | <micheil> | it actually is |
| 19:08 | <jgornick> | micheil: If you aren't a pro, then you should continue to learn/use HTML and CSS. |
| 19:08 | <micheil> | especially for something like SASS |
| 19:08 | <micheil> | which is for CSS |
| 19:08 | <micheil> | no {} or ; |
| 19:09 | <micheil> | nested selectors, meaning you don't repeat the nesting |
| 19:09 | <jgornick> | micheil: So, now I have to learn new syntaxes for something that is already easy? |
| 19:09 | <micheil> | jgornick: you don't have to, it's purely optional, some just find it easier to use new syntaxes |
| 19:10 | <jgornick> | micheil: Here's the thing, if everyone in your group/project is using it, then great. If not, no go. |
| 19:10 | <MikeSmith> | http://github.com/cramforce/node-asyncEJS#readme is interesting |
| 19:10 | <MikeSmith> | e.g., <h1><%? setTimeout(function () { res.print("Async Header"); res.finish(); }, 2000) %></h1> |
| 19:10 | <micheil> | jgornick: exactly. |
| 19:11 | <micheil> | in said project of mine, we were already using haml-js, but it had a heap of errors, and the author suggested we move to jade, so we did |
| 19:12 | <jgornick> | micheil: For me, in terms of SASS, CSS is not meant to be compiled, it's not a scripting language and once Eric Meyer (the real Eric Meyer) starts presenting it and using it, I'll maybe consider using it. |
| 19:12 | <micheil> | jgornick: I couldn't care who's using it, if it makes my job a tiny bit easier, I'm all for it. |
| 19:12 | <micheil> | which, overall, it does. |
| 19:14 | <micheil> | jgornick: just sorta for my background on it: http://brandedcode.com/journal/2009/05/20/why-not-just-compile-your-css.html |
| 19:15 | <micheil> | anyway, I'm off. |
| 19:15 | <micheil> | night chaps' |
| 19:15 | <micheil> | s/chaps/folks |
| 19:16 | <jgornick> | Night micheil |
| 19:16 | <jgornick> | Good talks |
| 19:16 | <micheil> | no worries |
| 19:42 | <Lachy> | h.264 is now permanently royalty free for internet streaming sites. http://arstechnica.com/media/news/2010/08/mpeg-la-counters-google-webm-with-permanent-royalty-moratorium.ars |
| 19:45 | <AryehGregor> | But browsers would still have to pay royalties? |
| 19:46 | <Philip`> | Yes |
| 19:46 | <AryehGregor> | Then that doesn't really change anything, does it? |
| 19:46 | <Philip`> | (At least that's what hsivonen said) |
| 19:46 | <Lachy> | yeah, it's only for web sites |
| 19:46 | <AryehGregor> | Most websites weren't really expecting to pay anything anyway. |
| 19:46 | <crash\> | AryehGregor: only eyewashing |
| 19:46 | <AryehGregor> | What? |
| 19:46 | <cheeser> | software patents-- |
| 19:47 | <Lachy> | previously, they had announced that it would be royalty free until 2015, at which point they would review the issue again. |
| 19:47 | <cheeser> | only a fool would take them up on that offer. |
| 19:47 | <AryehGregor> | Um. |
| 19:48 | <AryehGregor> | Anyone who did take them up on that offer was just proven completely correct, weren't they? |
| 19:48 | <cheeser> | "use it for free until you're absolutely dependent on it, then we'll put you over a barrel." |
| 19:48 | <AryehGregor> | Hard to call them foolish. |
| 19:48 | <Philip`> | Sounds like the only real difference is that people can no longer use the argument "you can use H.264 on your site for free now, but there's a bit of uncertainty five years from now, and you can avoid that uncertainty by using [some other codec]" |
| 19:48 | <MikeSmith> | so this timely news story is about something that will not make any difference at all to anybody until after 2015 |
| 19:48 | <Lachy> | so it would mean that sites like vimeo and dailymotion who stream h.264 content, and who AFAIK, have no reason to pay the royalties themselves, won't have to pay up in the future. |
| 19:49 | <AryehGregor> | I think it's probably more correct to say that people who were worried about the 2015 thing turned out to be paranoid, rather than the unworried people being foolish. |
| 19:49 | <AryehGregor> | By 2015 it should be pretty easy to switch to WebM, anyway. I mean, Flash is supporting it, so even if you can't use HTML5 for all users, you can use WebM in Flash rather than H.264 in Flash. |
| 19:50 | <cheeser> | unless you're on an apple device |
| 19:50 | <AryehGregor> | So the threat of the 2015 royalties became kind of empty with the WebM launch. Which I guess is why they dropped it. |
| 19:50 | <Lachy> | well, it means that the previous arguments I've read about not supporting h.264 using codecs available on the platform based on the future threat of royalties for websites are now defeated. |
| 19:51 | <AryehGregor> | I guess. |
| 19:51 | cheeser | cancels his questions and goes to rtfa |
| 19:51 | <AryehGregor> | It's pretty brief. |
| 19:51 | <AryehGregor> | We said everything substantive in it already. |
| 19:51 | <cheeser> | right. "free to view" but not "free to produce" |
| 19:52 | <Lachy> | but it was inevitable that this would be the result because such royalties were not in the MPEGLA's best interest anyway |
| 19:52 | <AryehGregor> | They would be if it had no credible competition. |
| 19:52 | <AryehGregor> | Of course, it would only impose them on sites that could pay. |
| 19:53 | <Lachy> | cheeser, yeah, content producers are still technically subject to the licence issue whereby owning the software that produces h.264 doesn't give you the right to produce it for commercial purposes. |
| 19:53 | <AryehGregor> | Now we just need Microsoft to fully jump on the WebM bandwagon. I can't see Apple remaining sole holdout for long. |
| 19:53 | <cheeser> | one shouldn't have to pay to use standards like that. |
| 19:53 | <cheeser> | and they certainly shouldn't be codified into open standards such as html |
| 19:54 | <cheeser> | but then i think all software patents should be stripped. |
| 19:54 | <Lachy> | we had that discussion with some Microsoft and Apple reps who were in Norway for the CSS WG meeting, and it still seems as though they're not going to do it. |
| 19:54 | <AryehGregor> | No one was suggesting that H.264 be required by HTML5. That would contradict the W3C's position on RF patents, for one thing. |
| 19:54 | <AryehGregor> | Blargh. |
| 19:55 | <Lachy> | but that was just informal discussions at the pub, so nothing they said was official in any way |
| 19:55 | <AryehGregor> | But you don't really know what they're going to do, because their lawyers will say nothing until the last second. |
| 19:55 | <AryehGregor> | I mean, you were talking to developers, right? They aren't the ones making the decision. |
| 19:56 | AryehGregor | wonders why Google can't work out some type of indemnification agreement with MS and Apple . . . surely that doesn't increase their risk much given how much WebM they ship anyway? |
| 19:56 | AryehGregor | also wonders why the patent license doesn't cover reimplementations or modified versions. Whatever happened to being against field-of-use restrictions? |
| 19:56 | <Rik`> | Lachy: we also need hardware decoding |
| 20:26 | <Lachy> | Rik`, yes, but hopefully that will come soon enough, given that there are many hardware vendors in the list of webm supporters |
| 20:27 | <Lachy> | but do you reckon having webm decoding in hardware will increase the chance of Microsoft or Apple supporting it? |
| 20:29 | <AryehGregor> | I don't see why, for the desktop. |
| 20:29 | <AryehGregor> | I can see why it would encourage support for mobile devices. |
| 20:41 | <Rik`> | Lachy: Safari and IE have hardware decoding for H264, there's no chance they gonna switch to webm without it |
| 20:43 | <AryehGregor> | It's not a matter of switching, it's a matter of supporting. |
| 20:44 | <AryehGregor> | Authors can decide which format to use based on availability of hardware encoding, among other factors. |
| 20:44 | <AryehGregor> | Decoding. |
| 20:44 | <AryehGregor> | Whatever. |
| 20:45 | <AryehGregor> | On typical desktops, WebM should decode fast enough in software for most uses, at least for now. |
| 20:53 | <Lachy> | AryehGregor, unfortunately, software decoding of 720p and 1080p webm is not very performant |
| 20:54 | <AryehGregor> | Yet? :) |
| 20:54 | <Rik`> | AryehGregor: that's not how Apple sees it. Either it's good enough to ship or they don't ship |
| 20:54 | <AryehGregor> | Oh well. Clearly it will take a few years. |
| 20:54 | <AryehGregor> | Rik`, so would they refuse to render GIFs because PNG provides superior compression? |
| 20:54 | <AryehGregor> | Kind of stupid example, because obviously you have to support GIF. |
| 20:54 | <Rik`> | compression is not a matter of end user |
| 20:55 | <AryehGregor> | But I'm really quite sure this is largely a legal issue, not a technical issue. |
| 20:55 | <AryehGregor> | I mean, Steve Jobs Himself has pretty much said so. |
| 20:57 | <Lachy> | Rik`, it seems likely that hardware with WebM decoding could start appearing in computers since AMD and nVidia are in the supporter list. So Apple could potentially include the necessary hardware in future Macs, as could PC vendors |
| 20:58 | <Rik`> | Lachy: yeah and I hope so |
| 20:58 | <Rik`> | but until there's something concrete, they won't |
| 20:58 | <AryehGregor> | I really don't think hardware support is a blocker for Safari WebM support. |
| 20:58 | <othermaciej> | I have heard that WebM's design is not friendly to hardware decoding |
| 20:59 | <AryehGregor> | Shall we try to badger a statement beyond "No comment" from some friendly Safari dev? :) |
| 20:59 | <AryehGregor> | Ah, speak of the devil! |
| 20:59 | <Lachy> | after that, it's really just the legal risk of proceeding with it. But I'm reasonably confident that the WebM supporters would have a wide range of defensive patents to fend off any challenges from the MPEGLA. |
| 20:59 | <othermaciej> | that being said, I'm sure QuickTime ships with some codecs that decode purely in software |
| 20:59 | <Lachy> | so the real risk is just patent trolls |
| 20:59 | <AryehGregor> | othermaciej, if you can comment, do you think that Safari for the desktop would support WebM out of the box if there were any legal issues? |
| 20:59 | <AryehGregor> | I mean, if there were no legal issues? |
| 21:00 | <AryehGregor> | (I guess the question is really about QuickTime.) |
| 21:04 | <othermaciej> | I think our other big issue would be that if something is going to become the de facto standard for Web video, we need it to be viable on mobile devices |
| 21:07 | <AryehGregor> | But you could support it without endorsing it as the de facto standard for web video. I mean, QuickTime supports tons of random formats, right? |
| 21:08 | <eric_carlson> | Safari on the desktop supports it now if you have the WebM QuickTime components installed. |
| 21:12 | <Rik`> | eric_carlson: is there any webm quicktime component? |
| 21:13 | <eric_carlson> | Rik`: yes, in TOT Perian |
| 21:14 | <Rik`> | oh great! we just need to wait for a release |
| 21:16 | <Rik`> | AryehGregor: I don't think iOS supports any non hardware decoded codec |
| 21:16 | <AryehGregor> | Probably not. |
| 21:48 | AryehGregor | realizes that there's no point in compiling Firefox from source if he just wants to test if something works in a nightly, hmm |
| 23:08 | <annevk> | http://daringfireball.net/linked/2010/08/26/h264 -- euh gruber fail :/ |
| 23:09 | <othermaciej> | isn't what he says accurate? |
| 23:09 | <annevk> | it's still bait and switch |
| 23:09 | <othermaciej> | there are presumably other issues with the AVC license, but it seems the worry that they will start charging for free internet video is not one of them |
| 23:09 | <annevk> | for the majority of stuff you still have to pay |
| 23:09 | <othermaciej> | that was the concern that people labeled "bait & switch" if I recall correctly |
| 23:09 | <Workshiva> | There's no switch, though |
| 23:10 | <Workshiva> | You get exactly what they offer from day one |
| 23:11 | <annevk> | if enough people get lured by the bigger bait, the switch is everyone being trapped by MPEG LA |
| 23:11 | <annevk> | othermaciej, not pointing out the other issues at all is just bad |
| 23:12 | <annevk> | othermaciej, he makes it seem as if H264 is problem free |
| 23:12 | <othermaciej> | my interpretation was, "this one potential problem with h.264 has now been addressed", rather than "h.264 has no problems", but I am more knowledgable about the issue than the average reader |
| 23:14 | <annevk> | I didn't really see this as a problem at all |
| 23:14 | <annevk> | it's dwarfed by the other problems imo |
| 23:18 | <othermaciej> | some people did cite it as a problem |
| 23:19 | <annevk> | sure, I'm not saying it was not a problem; it's just not the main issue by a long shot |
| 23:24 | <othermaciej> | for example roc cited it as a major issue here: http://weblogs.mozillazine.org/roc/archives/2010/01/video_freedom_a.html |
| 23:24 | <annevk> | Hixie, with http://tc.labs.opera.com/apis/EventSource/ maybe we can move server-sent events to PR soonish |
| 23:25 | <annevk> | Hixie, though .url/.URL still seems an issue with WebKit |
| 23:25 | <annevk> | Hixie, and Opera has not quite released something public yet (though should happen soonish) |
| 23:26 | <roc> | I think it was a major issue that has now gone away |
| 23:26 | <roc> | there are other major issues |
| 23:26 | <roc> | it is not important for us to agree on this |
| 23:28 | <roc> | it is important for us to agree that Gruber is a weasel |
