| 00:06 | <Hixie> | oh Lachy's post reminds me that i need to follow up with the canvas issue |
| 00:15 | <Lachy> | Hixie, what did you think of my suggestions for making that canvas example accessible? Were they reasonable given the contstraints, or is Joshue right about it being ridiculous? |
| 00:16 | <Hixie> | i don't understand why you would use canvas for that use case at all |
| 00:17 | <Hixie> | (...and it already has an accessible version anyway) |
| 00:17 | <Hixie> | though that one seems to be missing the descriptions |
| 00:19 | <Philip`> | Lachy: Animated image maps sound ridiculuous to me |
| 00:20 | <Hixie> | man, changing table taint is gonna be such a pain |
| 00:20 | <Philip`> | If you're going to all the trouble of maintaining a kind of scene graph DOM, you might as well just use SVG and then you won't have all the weirdness and restrictiveness of image map shapes |
| 00:22 | <Hixie> | that won't get you accessibility though |
| 00:22 | <Hixie> | (though for some reason, svg gets a free pass) |
| 00:23 | <Philip`> | s/ridiculuous/ridiculous/ |
| 00:27 | <Lachy> | Hixie, I know that specific page probably shouldn't use canvas, but there are lots of other interactive uses of canvas |
| 00:30 | <Lachy> | Philip`, I don't see why animated image maps would be ridiculous. If you wanted to support keyboard navigation while still providing the same visual layout, how would you do it without throwing out the canvas entirely? |
| 00:31 | <Hixie> | you can't do it properly right now without using either svg or crazy image map stuff |
| 00:32 | <Hixie> | i don't know how to make it possible though |
| 00:34 | <Philip`> | The image map keyboard navigation order will be completely unrelated to the spatial positions of the areas, so it's not a good way to provide keyboard navigation of the graphical display |
| 00:35 | <Hixie> | keyboard navigation is the one aspect of making canvas accessible that i might be able to figure out |
| 00:35 | <Lachy> | if you know the positions of the areas on the screen, it's conceivable that you could calculate a reasonable tab order and either set tabindex or do the complicated thing of reording the area elements in the DOM |
| 00:35 | <Philip`> | Anything that gives a linear keyboard navigation order will be operating over a separate view of the data from the non-linear graphical view, so it seems unhelpfully complex to try to mix both the views together instead of just providing two independent views |
| 00:36 | <Hixie> | e.g. by providing a hook for the canvas to say how it is willing to handle focus movement while the canvas is focused |
| 00:36 | <Philip`> | (where one view might be <canvas> and the other view might be a <table> or <ul> or something) |
| 00:37 | <Lachy> | Philip`, providing 2 separate views doesn't solve the problem that Steve raised, which is that the original should be accessible, instead of having to maintain two completely different views |
| 00:38 | <Lachy> | although, in this case, as I mentioned in my email, the table view is probably useful for more than just accessibility reasons |
| 00:39 | <Lachy> | what if we took the concept of the image map and provided an API to declare a specific region of the canvas as being an active region which can respond to events? |
| 00:40 | <Lachy> | and which can recieve focus |
| 00:41 | <Philip`> | canvas.clearEventHandlers(); ctx.addEventHandlerOnClickInsideCurrentPath(function (evt) { ... }) |
| 00:41 | <Lachy> | Then a backwards compatibility layer could possibly be provided by script libraries that generate equivalent image maps in the DOM |
| 00:44 | <Lachy> | Philip`, I was thinking something like: region = context.createActiveRegion(...); region.addEventListener(...); |
| 00:47 | <Hixie> | that might be even better than doing it manually |
| 00:48 | <Philip`> | It'll be fun the first time someone creates a hundred active regions per frame, and forgets to delete them all before starting the next frame |
| 00:48 | <Hixie> | yeah that's the main reason i prefer the manual approach |
| 00:48 | <Hixie> | anyway, hopefully the wai will advise us as to the best approach |
| 00:49 | <Lachy> | Philip`, it might be better to just move the regions around, rather than delete and create new |
| 00:49 | <aboodman> | does anyone know of a demo anywhere of app cache that works in firefox 3.5? |
| 00:49 | <aboodman> | the web fails me |
| 00:51 | <aboodman> | uh, n/m, found something |
| 00:51 | <Lachy> | do we have a list of known uses canvas, like Yahoo Pipes, Bespin, and this Web Tools directory, from which we can analyse the use cases? |
| 00:51 | <Lachy> | Would be useful to have things like that listed in a wiki |
| 00:52 | <Philip`> | Use cases for a declarative canvas interaction API, I guess? |
| 00:53 | <Lachy> | good, looks like we do have some http://esw.w3.org/topic/HTML/AddedElementCanvas#head-c43887ef27c016a20e53d16718ab16a398b6899d |
| 00:53 | <roc> | what is the difference between "declarative canvas interaction API" and "SVG"? |
| 00:53 | <Lachy> | Philip`, yeah. Any non-interactive canvas probably wouldn't need much beyond traditional fallback content, just like a regular image |
| 00:54 | <Philip`> | roc: Canvas is cooler than SVG |
| 00:55 | <Philip`> | It would be sensible to see how many of the use cases could be better handled with SVG, but I guess if the original developers chose canvas (despite it requiring lots of manual code to process input) then they must have had reasons |
| 00:56 | <roc> | performance tends to be one reason |
| 00:57 | <roc> | but it seems plausible that maintaing some set of parallel structures is likely to hurt performance |
| 00:57 | <Lachy> | roc, it's better to pave the cowpaths and let them keep using canvas in more accessible ways, than to try and get everyone to use SVG instead |
| 00:58 | <roc> | I don't agree |
| 00:58 | <roc> | building a bunch of new canvas APIs and then discovering it's approximately as crappy as SVG would have been would be a terrible outcome |
| 00:59 | <Lachy> | no-one is suggesting building a set of APIs that are as crappy as SVG |
| 01:00 | <roc> | sure, no-one starts out with that intention |
| 01:00 | <roc> | anyway |
| 01:01 | <Lachy> | I'm not sure what you're trying to say now |
| 01:01 | <Hixie> | i'm sure the SVG WG didn't plan to make something "as crappy as SVG" as roc put it |
| 01:01 | <Lachy> | you started out questioning why we needed to develop declerative canvas APIs instead of just using SVG, but then said SVG is crappy. So I'm confused |
| 01:01 | <Hixie> | so why would your idea not end up being "as crappy as SVG"? |
| 01:01 | <roc> | I'm saying that adding some kind of parallel, accessible view of the canvas content may well destroy the reasons that people like to use canvas in teh first place |
| 01:02 | <Lachy> | roc, the new APIs suggested in here wouldn't be a parallel accessible view. |
| 01:02 | <Lachy> | the backwards compatible image map approach I suggested could be considered that way though |
| 01:03 | <roc> | you're talking about declaring "active regions" |
| 01:03 | <roc> | how is that not a parallel, accessible view? |
| 01:04 | <Lachy> | because it wouldn't just serve accessibility reasons. Imagine being able to declare an active region, and then just listen for clicks there, instead of having to calculate where on the canvas the click occurred |
| 01:04 | <Philip`> | It's still a parallel view which is accessible |
| 01:05 | <roc> | the cases where canvas wins most over SVG are where the information is dense |
| 01:05 | <roc> | like graphs, or an RTS where every pixel is custom rendered |
| 01:06 | <roc> | in those cases, you'll have zillions of active regions |
| 01:06 | <roc> | if you only have a few active regions, then you probably only have a few shapes, and you can use SVG |
| 01:06 | <Philip`> | http://philip.html5.org/demos/canvas/spritepick/example.html |
| 01:07 | <roc> | pretty cool |
| 01:07 | <Lachy> | roc, what other possible way is there that could solve the problem? |
| 01:07 | <roc> | I don't know |
| 01:07 | <Philip`> | That probably counts as dense information |
| 01:07 | <roc> | not all problems have solutions |
| 01:07 | <Lachy> | then how could we improve on the solution the idea to solve some of its own problems? |
| 01:07 | <Philip`> | What is the problem anyway? |
| 01:07 | <roc> | another problem with the active region approach is that it's bolted-on accessibility |
| 01:08 | <roc> | authors just won't use it |
| 01:08 | <Lachy> | the problem is making canvas accessible to people other than sighted people with a mouse |
| 01:08 | <roc> | or they'll use it wrong |
| 01:08 | <roc> | especially if there's a measurable performance hit |
| 01:09 | <Hixie> | Lachy: as i said, the other solution is to provide a hook for script so that when the canvas is focused, if the user tabs or directionally navigates the focus, the canvas can say "ok keep the focus in the canvas, i can handle that one" |
| 01:09 | <Philip`> | roc: They might use it if it's the easiest way to support interactivity (i.e. clicking on regions), and a side-effect is that it can be exposed in a more accessible way |
| 01:09 | <Lachy> | there doesn't really seem to be a way for it to not be bolt on accessibility. But, as I said before, it could be leveraged for more than just accessibility purposes |
| 01:09 | <Philip`> | roc: It's kind of a pain to put onclick on the canvas and then have to manually work out which object was clicked on, so an API that makes that easier might get used by people who don't care about accessibility |
| 01:10 | <Lachy> | Hixie, that sounds far more complicated than letting the browser itself help out |
| 01:10 | <roc> | Philip`: maybe, except for the problem I noted about having large numbers of regions |
| 01:10 | <Hixie> | Lachy: maybe, i haven't compared the resulting code |
| 01:11 | <roc> | If the canvas contents are changing, then you have to maintain the set of regions and their geometry |
| 01:11 | <roc> | seems to me that's probably actually harder than writing your own picker code |
| 01:11 | <roc> | maintaining cached stuff persistently is almost always harder than just recomputing something whenever you need it |
| 01:12 | <Philip`> | I'm assuming you could just destroy and recreate all the regions every frame, at the same time as you're recreating all the rendered paths |
| 01:12 | <roc> | if you're doing that, then the actual code that walks the regions to do picking is relatively easy |
| 01:12 | <Philip`> | (Hooray for garbage collectors) |
| 01:13 | <roc> | maybe if you did beginRegion(...); draw draw draw; endRegion(...) |
| 01:17 | <Lachy> | interesting idea. So the region would include any pixel that was drawn on |
| 01:19 | <roc> | yeah |
| 01:20 | <Philip`> | What does "drawn on" mean? |
| 01:21 | <roc> | whatever we want it to mean |
| 01:21 | <roc> | that would be more convenient than writing your own custom picking code, so I can believe that people might actually use it |
| 01:21 | <roc> | and it might perform OK, since the browser can compute bounding boxes for you |
| 01:21 | <Philip`> | I can imagine it would relatively common to e.g. draw a shadowed box, and want to respond to the mouse being over the box and not its shadow |
| 01:21 | <roc> | and probably already does for invalidation etc |
| 01:22 | <Philip`> | but also to draw an image with transparency, and want to respond to the mouse being over non-zero-alpha bits |
| 01:24 | <jwalden> | man, wikipedia is being amazingly aggressive with their video support |
| 01:35 | <ezyang> | It's... it's... taint mode changes! (Runs away and screams) |
| 01:36 | <ezyang> | Pretty large changeset too. That makes me very unhappy |
| 01:36 | <Hixie> | sorry! |
| 01:37 | <Hixie> | it shouldn't actually be that hard to code |
| 01:37 | <Hixie> | most of the changes were in the examples |
| 01:37 | <Hixie> | assuming your tokeniser already groups characters, you don't need the new insertion mode |
| 01:45 | <Hixie> | http://www.lebgeeks.com/forums/viewtopic.php?id=5446&action=new |
| 01:54 | <Lachy> | where do people get the idea that HTML5 is officially released? |
| 01:55 | <Hixie> | it is officially released |
| 01:55 | <Hixie> | it's been officially released since about 2004 |
| 01:55 | <Lachy> | it seems more like that the forum post meant finalised, not just a public draft |
| 01:56 | <Hixie> | what does "finalised" mean |
| 01:56 | <Hixie> | you mean like xhtml2? :-) |
| 01:56 | <Lachy> | no, I mean like being finished and published as a Rec |
| 01:57 | <Lachy> | but if that's not what the post meant, then it's not clear why he would use langauge like "Officially Released" in that context |
| 01:58 | <Lachy> | unless he thinks this is the first time it's been public |
| 01:59 | <Hixie> | by the time html5 is a REC, nobody will care |
| 01:59 | <Hixie> | we'll be all working on HTML6 or even HTML7 (assuming we don't go with what I would like to do, which is just make HTML a living document with no meaningless versioning) |
| 02:01 | <Lachy> | so you would just keep it like it is on the whatwg copy with section specific status markers forever? |
| 02:03 | <Hixie> | sure |
| 02:06 | <Lachy> | we could effectively do that if we just treat the Recs as stable snapshots, and keep going with the same spec instead of starting fresh each time (which wouldn't be a good idea, anyway) |
| 02:07 | <Hixie> | that would require a change to the w3c process though |
| 02:08 | <Hixie> | you can't do LC->CR->PR->REC if you're just doing RECs as snapshots |
| 02:09 | <Lachy> | not really, since each time you begin work on the next version, you just fork the spec into, e.g. an HTML5 or HTML6 branch, which then continues along the Rec track while the trunk keeps going |
| 02:10 | <Lachy> | just like how software branches quite happily go through alphas->betas->release candidates->final |
| 02:13 | <Hixie> | oh hell, i'm not maintaining two branches of html5 |
| 02:13 | <Hixie> | it's bad enough for code |
| 02:13 | <Hixie> | i'm not maintaining a 15 year branch |
| 02:14 | <Lachy> | how else do you intend us to start on HTML5 within the current w3c process then? |
| 02:14 | <Lachy> | *HTML6 |
| 02:17 | <Hixie> | we can't, with the current process |
| 02:17 | <Hixie> | but i think the problem is the process |
| 02:17 | <Lachy> | but with your model, it seems difficult for any specific section to ever be marked stable and stay that way for very long |
| 02:18 | <Hixie> | yup |
| 02:18 | <Hixie> | that's the point |
| 02:18 | <Hixie> | there is no stability here |
| 02:18 | <Hixie> | it's an ever-evolving platform |
| 02:18 | <Hixie> | the specs should reflect that |
| 02:19 | <Lachy> | but by publishing a stable snapshot, it allows implementers to clearly distinguish the stable sections from the new unstable sections |
| 02:20 | <Lachy> | so e.g. if video becomes widely implemented with its current feature set, and then you want to go add some new APIs after that, the new unstable stuff would be mixed in with the previously stable stuff |
| 02:21 | <Hixie> | i disagree with your use of the word "clearly" |
| 02:22 | <Hixie> | if we're trying to make it easier to recognise new features, then we should work on that specifically |
| 02:22 | <Hixie> | having said that, i don't know how to do that, especially when the new features integrate deeply with e.g. navigation |
| 02:25 | <Lachy> | I suppose I can understand why maintaining forks won't work too well. It doesn't really work too well for XHR and XHR2, like Anne is doing |
| 02:27 | <Hixie> | it doesn't ever work well |
| 02:27 | <Hixie> | it only vaguely works for software projects when they have very short lifetimes (weeks at most) and few checkins (just patches for crashes and stop-ship bugs) |
| 02:28 | <Hixie> | anything that has to either track another branch, or have bugs fixed in two or more branches, or merge back into another branch later, is a disaster |
| 02:35 | <sebmarkbage> | There is never going to be anything like stable sections. I'm currently implementing drag & drop APIs with backward compatibility. They're largely implemented but there are lots of little quirks that live through major releases. I think it'll remain like that for quite a while. |
| 02:37 | <Lachy> | sebmarkbage, in which browser? |
| 02:39 | <sebmarkbage> | I'm implementing JS legacy compatibilty for MooTools and while doing that, working on patches for WebKit. |
| 02:39 | <othermaciej> | software is never perfect or frozen, yet we still ship it every once in a while |
| 02:39 | <othermaciej> | not sure if this is a plausible model for specs |
| 02:43 | <sebmarkbage> | That's the essence of HTML 5 IMHO. If you could do perfect frozen models, it'd be called XHTML 2. But the internet is a moving organism of legacy code. That somehow works. |
| 03:46 | <ezyang> | Hmm, new table handling algo doesn't seem too hard to implement |
| 03:47 | <ezyang> | Go go PHP |
| 04:35 | <ezyang> | Wtf. None of our tests started failing with the new taint mode |
| 04:35 | <ezyang> | That's not acceptable! |
| 04:48 | <ezyang> | What do the vertical lines in the "handling parser errors" section mean? |
| 05:01 | <ezyang> | Landed! |
| 05:03 | <ezyang> | Someone should doublecheck my test cases |
| 05:20 | <roc> | Tom Lord is frustrating me |
| 05:22 | <othermaciej> | would www-font be at all useful in any case if not for Tom Lord? |
| 05:23 | <othermaciej> | roc: btw, I'm pretty sure I told Hixie that canPlayType would cause the exact mistake you made to be extremely common |
| 05:23 | <othermaciej> | I wonder if it's too deployed to change now :-( |
| 05:23 | <roc> | I told him too |
| 05:23 | <othermaciej> | at the very least, it should not have been named to sound like it returns a boolean |
| 05:23 | <roc> | I make that mistake about every time I use it |
| 05:23 | <othermaciej> | something like playabilityForType() |
| 05:23 | <othermaciej> | or to make the "no" case return false |
| 05:23 | <othermaciej> | or split into mightPlayType() and canDefinitelyPlayType() |
| 05:23 | <roc> | yeah |
| 05:24 | <roc> | having the "no" case return false would screw with non-JS bindings |
| 05:24 | <roc> | Would www-font be useful? Maybe. |
| 05:24 | <roc> | at least it would be less painfully unuseful. |
| 05:25 | <othermaciej> | roc: I didn't even know your code was buggy from memory, it was only when I tested that I found it was always saying "YES" |
| 05:25 | <othermaciej> | (wanted to confirm that our canPlayType bug was properly fixed) |
| 05:25 | <roc> | hehe |
| 05:25 | <othermaciej> | so basically, if you and I can't understand how the API works, despite commenting on it in detail in the past, it is clearly broken |
| 05:25 | <roc> | yes, that was my snarky point |
| 05:26 | <roc> | I also implemented it |
| 05:27 | <Hixie> | i thought i'd fixed the things you mentioned, didn't realise i'd failed to address this particular point. i agree that we should fix this. |
| 05:28 | <roc> | returning the empty string would work |
| 05:28 | <roc> | we could probably ram that into a Firefox update |
| 05:29 | <othermaciej> | empty string would work for JS, yes |
| 05:29 | <othermaciej> | in other languages, it would be harder to make it accidentally do a boolean check |
| 05:29 | <roc> | yeah |
| 05:29 | <othermaciej> | wait, I'm not sure as to Java |
| 05:30 | <othermaciej> | if (!str) is probably a null check in Java |
| 05:30 | <roc> | it's not |
| 05:30 | <othermaciej> | oh good |
| 05:30 | roc | likes Java and doesn't care how unfashionable that makes him |
| 05:31 | <othermaciej> | it's not quite too late to get "" in the next Safari update if it's decided, like, today or tomorrow |
| 05:31 | <othermaciej> | (not that it's shipping tomorrow but I won't be able to sneak it in after that) |
| 05:31 | <Hixie> | spec updated to say "" instead of "no". |
| 05:33 | <Hixie> | roc: re www-font... given that microsoft have (as i understand it) said they won't do TTF, is there anything to discuss? |
| 05:33 | <Hixie> | i've only been skimming the discussion |
| 05:34 | <roc> | Hixie: thanks re. canPlayType |
| 05:34 | <othermaciej> | Hixie: thanks - I'll try to sneak it in |
| 05:35 | <roc> | Hixie: There is potential value in jfkthame's ZOT proposal, or something like it, independent of what MS does |
| 05:36 | <roc> | IMHO |
| 05:37 | <othermaciej> | roc: link? |
| 05:38 | <roc> | I wish Gmail would find public archived versions of messages |
| 05:38 | <Hixie> | ZOT? |
| 05:39 | <roc> | hehe ... www-font traffic: Jan-March: 1, April-June: 54, July-September: 415 |
| 05:40 | <Hixie> | that's not a good trend |
| 05:40 | <roc> | considering we're 10 days into July |
| 05:41 | <roc> | http://lists.w3.org/Archives/Public/www-font/2009JulSep/0018.html |
| 05:44 | <doublec> | are "probably" and "maybe" the only return values possible from canPlayType? |
| 05:45 | <doublec> | oh, and empty string, missed that |
| 05:45 | <Hixie> | right |
| 05:54 | <MikeSmith> | yey - just scored a print copy of chrome japanese comic |
| 05:59 | <roc> | pah |
| 05:59 | <roc> | othermaciej got his patch in first |
| 05:59 | <roc> | but I claim it's only because they have fewer tests to update that use canPlayType |
| 06:00 | <Hixie> | hah |
| 06:02 | <othermaciej> | actually, what happened is that olliej (who didn't even see this conversation) saw on twitter that the spec changed and immediately coded a patch |
| 06:02 | <othermaciej> | I was gonna do it to morrow |
| 06:03 | <doublec> | hopefully it doesn't break any existing canPlayType usage |
| 06:03 | <roc> | doublec: it probably will |
| 06:03 | <roc> | however |
| 06:03 | <roc> | this seems to be a situation where most people using the API are probably using it incorrectly already |
| 06:04 | <doublec> | Not from what I've seen |
| 06:04 | <doublec> | But they check for "probably" and "maybe" explicitly and fail on anything else |
| 06:04 | <doublec> | it seems |
| 06:04 | <roc> | that's OK |
| 06:04 | <doublec> | yep |
| 06:04 | <roc> | if you test on multiple browsers you probably get the "no" case OK |
| 06:04 | <roc> | if you don't, you lose |
| 06:06 | <roc> | hmm, I'm up at the beach and there's a storm warning advising everyone to stock up on food for 2-3 days |
| 06:06 | <roc> | if I'm offline for a while, that'll be why |
| 06:11 | <Hixie> | good to know |
| 07:25 | <JPKe> | 3 |
| 07:40 | <hsivonen> | so, I think I should implement HTML5-compliant document.write timing behavior |
| 07:41 | <hsivonen> | basically prevent it from timeouts and such |
| 07:41 | <hsivonen> | is it correct that insertion point is |
| 07:41 | <hsivonen> | 1) Not defined when document.write runs synchronously and is not breaking on </script> |
| 07:42 | <hsivonen> | 2) Defined when document.write breaks on </script> |
| 07:42 | <hsivonen> | 3) Defined when normal tokenization executes inline script on </script> |
| 07:43 | <hsivonen> | 4) Defined when an external non-defer script's load completes and it is run. |
| 07:43 | <hsivonen> | 5) (Not yet but per sicking's email will be) when the network stream has ended, there are only defer scripts left and a defer scripts is executed |
| 07:44 | <hsivonen> | 6) Not defined at any other time |
| 07:44 | <hsivonen> | Correct? |
| 08:09 | hsivonen | struggles with the UI of the spec |
| 08:13 | <hsivonen> | hmm. diveintomark.org seems broken |
| 08:39 | <hsivonen> | what's the deal with SVG scripts setting the parser pause flag to true before running? |
| 08:44 | <hsivonen> | #dfnReturnLink-n for any value of n broken for everyone or just for me? |
| 08:57 | <hsivonen> | Hixie: is there a maximum for script nesting level that follows from everything else? |
| 09:05 | <hsivonen> | Hixie: it seems that Gecko doesn't execute a script if the script is in a noscript or noembed container in the tree at the time that execution is attempted |
| 09:07 | <hsivonen> | s/execution/running/ to use HTML5 terms |
| 09:08 | <hsivonen> | s/noscript/noframes/ |
| 09:34 | <hsivonen> | Hixie: does this if block comply with HTML5? http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptLoader.cpp#550 |
| 09:38 | <hsivonen> | Hixie: have you looked at the Gecko script blocker concept? does HTML5 deal with it somehow? |
| 09:39 | <hsivonen> | Hixie: as far as I can tell, HTML5 executes inline non-async scripts immediately, but Gecko may spin the event loop if there's a script blocker in effect |
| 09:44 | <hsivonen> | Hixie: the script nesting level concept was removed from Gecko a while ago |
| 09:45 | <hsivonen> | Hixie: while it was in Gecko, did it inspire the current spec text? |
| 09:56 | <hsivonen> | Hixie: so, if a script's parent has been moved to a different document and the script does document.write(), does it blow away the other document? |
| 10:05 | <hsivonen> | It seems that if I want to avoid seriously refactoring Gecko's script execution code |
| 10:05 | <hsivonen> | (and I want to avoid it) |
| 10:06 | <hsivonen> | I need to make scripts not only know their document but their originating parser |
| 10:06 | <hsivonen> | well, I suppose having a weak ref to the parser from parser-inserted script nodes isn't too serious bloat... |
| 10:08 | <hsivonen> | cause if I don't make them know their originating parser and scripts are moved between documents that both have active parsers, bad stuff could happen, I think |
| 11:22 | <Lachy> | http://arstechnica.com/web/news/2009/07/apple-proposes-http-streaming-feature-as-a-protocol-standard.ars |
| 11:24 | <hsivonen> | the basic idea would work also for Ogg, right? since you can concatenate Ogg pieces rather freely |
| 11:25 | <hsivonen> | I'm sure the Apple rep dealing with this at the IETF will have a fun time with all the RTSP proponents |
| 11:25 | <kinetik> | depends what the unpublished patent(s) related to that draft are |
| 11:25 | <kinetik> | http://datatracker.ietf.org/ipr/1142/ |
| 11:27 | <hsivonen> | "In the event that these patents issue, Apple |
| 11:27 | <hsivonen> | agrees, upon written request from a party, to negotiate with that party a |
| 11:27 | <hsivonen> | non-sublicenseable license to the Essential Claims under reasonable and |
| 11:27 | <hsivonen> | non-discriminatory terms and conditions, solely to the extent necessary to |
| 11:28 | <hsivonen> | implement required portions of the Informational Internet Draft," |
| 11:28 | <hsivonen> | non-sublicensable RAND... |
| 11:28 | <hsivonen> | way to go IETF |
| 11:36 | Philip` | keeps getting RTSP and RTMP mixed up |
| 11:38 | hsivonen | wonders if the BBC is still using Real's formats for something |
| 11:38 | <hsivonen> | looks like it |
| 11:38 | <Philip`> | They still provide radio streams using Real |
| 11:39 | <Philip`> | (but default to Flash) |
| 11:39 | <hsivonen> | I guess Flash has hurt Real pretty seriously |
| 11:40 | <Philip`> | Looks like they also provide WMA of radio streams |
| 11:41 | <jgraham> | Yeah the BBC tries pretty hard to cover all its bases and is pretty reluctant to remove old stuff |
| 11:41 | hsivonen | hasn't used RealPlayer in ages |
| 11:42 | <Philip`> | (get_iplayer says "flashaac1,flashaac2,realaudio,wma" for radio streams; "flashaac1,flashaudio,iphone,realaudio" for old radio programmes) |
| 11:44 | <Philip`> | ("flashnormal" for live TV streams; "flashhd1,flashhigh3,flashlow1,flashlow2,flashnormal,flashvhigh2,iphone,n95_wifi,subtitles" for old TV programmes (at least ones available in HD)) |
| 11:46 | Philip` | likes their HD content - 1280x720 H.264 looks pretty good, and it's only 1.4GB per hour |
| 11:48 | <Philip`> | (Also, no adverts and I don't even have to pay the TV Licensing fee) |
| 11:51 | <Lachy> | there could well be prior art on it anyway, since play lists have been around for years and the idea of splitting videos up and playing them sequentially isn't new |
| 11:54 | <Lachy> | though it sucks that Apple decided to include the equivalent of the broadcast flag :-( |
| 11:54 | <hsivonen> | oh there's even that kind of thing lurking in there :-( |
| 11:55 | <Lachy> | yeah, it was mentioned in the ars technica article |
| 11:55 | <Lachy> | Apparently it's just a flag that indicates whether clients are allowed to cache it or not |
| 11:56 | <Lachy> | so of course it's a completely inneffective form of DRM, but it could well be subject to anti-circumvention clauses like the broadcast flag was |
| 12:03 | <hsivonen> | is async an HTML5 invention or an IE thing? |
| 12:03 | <hsivonen> | on scripts |
| 12:07 | <Lachy> | I think it's an HTML5 invention |
| 12:10 | <hsivonen> | Lachy: OK. thanks |
| 12:12 | <Lachy> | hsivonen, does IE even support it? |
| 12:13 | <hsivonen> | Lachy: I don't see it on MSDN |
| 12:13 | <Lachy> | nor do I |
| 12:14 | <hsivonen> | If authors start using the async attribute ahead of browsers, the feature will be pretty much poisoned... |
| 12:14 | <Lachy> | is there any evidence that they are? |
| 12:14 | <Lachy> | I've not seen much written about it at all |
| 12:16 | <hsivonen> | Lachy: there seems to be existence proof that it has been used in the wild once |
| 12:16 | <hsivonen> | Lachy: view source on http://samaxes-demos.appspot.com/samaxesjs/toc-jquery.html |
| 12:16 | <Lachy> | it probably wouldn't hurt too much though, as long as authors don't use it and then stupidly rely on the script executing synchronously |
| 12:17 | <hsivonen> | "as long as", yeah... |
| 12:17 | <Lachy> | yeah, I don't have much faith in authors not doing stupid things either |
| 12:18 | <Lachy> | for many cases, they'd be better off using defer instead, since the difference between waiting for the script to be available and the page to finish downloading would be negligable in most cases |
| 12:19 | <Lachy> | and at least defer is supported by IE |
| 12:23 | <Rik|work> | and firefox now ? |
| 12:24 | <Lachy> | I haven't heard about it being supported in firefox, but possibly |
| 12:25 | <Rik|work> | http://hacks.mozilla.org/2009/06/defer/ |
| 12:26 | <Lachy> | I'm quite surprised that such a useful feature has taken so long to be deployed in other browsers |
| 12:27 | <Lachy> | especially given that people have used increasingly complex methods of achieving effectively the same result |
| 14:12 | <Lachy> | I was going to see if I could have a go at doing some video codec comparisons between theora, dirac and h.264, but with a slightly improved methodology over what was used here http://people.xiph.org/~greg/video/ytcompare/comparison.html |
| 14:12 | <Lachy> | unfortunately, I can't obtain ffmpeg right now |
| 14:13 | <Philip`> | Are you intending to compare the quality of the codec format, or the quality of ffmpeg's implementation of them? |
| 14:14 | <Lachy> | one problem with that previous methodology was that the source video he created used a lossy codec, and so artifacts from that were passed through to the the resultant h.264 and theora versions |
| 14:15 | <Philip`> | That's how codecs get used in practice |
| 14:15 | <Lachy> | Philip`, from what I've read, ffmpeg seems to have the latest version of schroedinger in it for encoding dirac, and it also allows me to encode the Big Buck Bunny images into a lossless source video |
| 14:16 | <hsivonen> | Lachy: I'd expect quality 100 MJPEG not to invalidate the methodology |
| 14:16 | <Philip`> | People don't upload lossless videos to YouTube - they just copy the MPEG-2 that their camera recorded or the XviD that they generated on their computer or whatever |
| 14:16 | <hsivonen> | Lachy: also, non-computer-generated video will have been through DCT anyway |
| 14:16 | <Lachy> | it's better to eliminate unnecessary losses in quality before the final encodes |
| 14:16 | <hsivonen> | either as MJPEG or as DV |
| 14:17 | <hsivonen> | Lachy: the interesting thing is to test with the kind of crappy source material that gets uploaded to YouTube |
| 14:17 | <hsivonen> | Philip`: whose camera records MPEG-2? |
| 14:17 | <Philip`> | As someone mentioned on the list, any comparison should look at varying kinds of source material, e.g. clean CG animations and camera-phone videos and cartoons and TV recordings etc |
| 14:18 | hsivonen | thought cameras were DV, MJPEG and H.264 |
| 14:18 | <Philip`> | since some codecs might be good at some and rubbish at others |
| 14:18 | <Philip`> | hsivonen: No idea, I just made it up |
| 14:18 | <hsivonen> | oh, and many camera phones are MPEG-4 SP |
| 14:20 | <Lachy> | no, the interesting thing is to elimiate as many variables as possible and ensure you're only testing the quality of the encoders |
| 14:21 | <Philip`> | Lachy: In that case, maybe you should use a pure black image as the source video, to fully eliminate the variability in the input |
| 14:21 | <Lachy> | also, I'm not enitrely sure that quality 100 MJPEG is lossless, and he also had another lossy step before that when he resampled the images to 480x270 using ImageMagick |
| 14:22 | <hsivonen> | Lachy: I think the right thing to test is substantial random sample of raw YouTube material with YouTube's current H.264 encode and Thusnelda with constant settings for the whole sample per Thusnelda config |
| 14:22 | <hsivonen> | Lachy: because in practice YT doesn't hand tune |
| 14:22 | <hsivonen> | Lachy: because in practice, it's a comptetition against H.264 as practiced by YT--not ideal H.264 encode |
| 14:23 | <hsivonen> | Lachy: and because real world has crappy source video |
| 14:23 | <hsivonen> | Lachy: as long as you don't crop after 100 MJPEG, MJPEG should be fine |
| 14:23 | <Lachy> | so, that doesn't mean it's not useful to have true comparison that only tests the codecs in a way that is unaffected by other external factors |
| 14:24 | <hsivonen> | (since the JPEG blocks will align with the video codec blocks anyway) |
| 14:24 | <hsivonen> | (and video codecs most likely do something sufficiently DCT-like anyway) |
| 14:24 | <hsivonen> | Lachy: depends on what you are trying to prove |
| 14:25 | <Philip`> | Video compression is all about tradeoffs, and if you only use one source video then you're only seeing one data point and have no idea what tradeoffs were made that harm other equally-important inputs |
| 14:25 | <Lachy> | anyway, my plan was to encode the PNGs into a lossless huffyuv encoded video (since that's supported by ffmpeg) and then use that as the source for comparing dirac and theora, and possibly h.264 |
| 14:25 | <jgraham> | Lachy: I think it is well known that H.264 is better in an ideal world |
| 14:25 | <jgraham> | The question is is it substantially better under real wworld conditions |
| 14:25 | <hsivonen> | Lachy: what kind of camera are you getting your video from? |
| 14:26 | <Philip`> | Lachy: RGB to YUV is kind of lossy, I think |
| 14:26 | <Lachy> | hsivonen, I'm using the Big Buck Bunny images that were used in the previous test |
| 14:27 | <jgraham> | Lachy: I still don't understand what you're trying to show |
| 14:27 | <Lachy> | Philip`, if you know of another lossless codec that is supported by an available tool, which will then allow me to reencode as dirac and theora, let me know |
| 14:28 | <Lachy> | jgraham, I'm trying to test the quality differences primarily between dirac and theora |
| 14:28 | <jgraham> | The absolute quality difference? |
| 14:29 | <Lachy> | what do you mean by the absolute quality difference? |
| 14:29 | <jgraham> | Well I don't really mean "absolute" |
| 14:29 | <jgraham> | I mean you seem to want perfect input |
| 14:30 | <Philip`> | Lachy: I think my point is that "lossless" is kind of meaningless, since almost any processing of video loses at least a little bit of data (even if it's just converting colour formats), though I'm not sure it's a particularly interesting or relevant point |
| 14:30 | <jgraham> | And then will presumably fix something (bitrate? encoding time?) for output |
| 14:30 | <Lachy> | yes, so that the only thing being tested is the codec quality, and so that any artifacts in the video are purely as a result of the final encode, rather than any previous step |
| 14:31 | <Lachy> | jgraham, yes, I will eliminate as many variables as physically possible |
| 14:31 | <jgraham> | OK but that seems irrelevent to video on the web |
| 14:31 | <jgraham> | I suspect it will show you that dirac is no good at small file sizes compared with theora and H.264 is better than both |
| 14:32 | <jgraham> | At large file sizes Dirac will be good |
| 14:32 | <Philip`> | From what I've heard, Dirac is currently aimed mainly at very-high-bitrate applications, so it wouldn't be very interesting to compare at low YouTube-style bitrates |
| 14:32 | <jgraham> | What Philip` said |
| 14:33 | <takkaria> | has anyone watched hi-def stuff on youtube? :) |
| 14:34 | <Philip`> | takkaria: I've tried, but Flash uses up all my CPU juice and it goes all jittery :-( |
| 14:34 | <Philip`> | (mplayer is perfectly happy with fullscreen 720p, though) |
| 14:35 | <takkaria> | I've uploaded a couple of hi-def videos to youtube, so it seems like Dirac might be suitable for that |
| 14:35 | <jgraham> | (As Philip` or someone said the right test for video-on-the-web is to take multiple types of real world (i.e. lossy) input, reencode it to H.264/Theora/Dirac in a way that takes roughly the same time as youtube and produces roughly the same file sizes as youtube, and compare the resulting output) |
| 14:37 | Philip` | sees http://lwn.net/Articles/326830/ saying "If you are archiving video, building a unencumbered-bluray, or squeezing production grade 1080 HD video into 270mbit SD channels, Dirac is what you want. If you are webcasting with under a couple of megabits per second, Theora is what you want" |
| 14:38 | <Philip`> | though I'm not sure how much that's justified by data, or where the balancing point would be |
| 14:38 | <Lachy> | testing with lossy input makes it harder to compare the result, since so many of the artifacts in the output will be a direct result of the input, rather than the re-encoding process |
| 14:40 | <Philip`> | A hard-to-compare result sounds better than a result that's meaningless to anyone who wants to use the codecs in practice |
| 14:40 | <jgraham> | Lachy: Since the real world input is ally lossily encoded trying to remove that from the tests makes the tests less relevent |
| 14:40 | <Lachy> | if you take a look at the input avi file used in http://people.xiph.org/~greg/video/ytcompare/comparison.html it's incredibly lossy, which isn't useful |
| 14:40 | <Lachy> | well, I disagree with both of you |
| 14:41 | <jgraham> | Lachy: It depends what you are looking at. But if you are interested in video on the web you need to look at the type of source material that people actually use for video on the web |
| 14:42 | <jgraham> | Losslessly encoded sources are only one (rather rare) type of source material |
| 14:43 | <Lachy> | so, I'm only interested in the quality of the final encodes, since the results of encoding a lossless input to multiple encodings should show the same relative differences in output quality, as would a lossy input, but make it much clearer to judge the result |
| 14:44 | <jgraham> | That seems like a huge and, I think, provably false, assumption |
| 14:44 | <Philip`> | Are you assuming the quality of the output is directly proportional to the quality of the input? |
| 14:45 | <jgraham> | (e.g. if the lossly initial encoding is compresses in blocks then a lossy subsequent encoding that works with the same block size will look better than one that uses a totally different compression scheme, or has the blocks offset or something) |
| 14:45 | <jgraham> | s/l// |
| 14:46 | <jgraham> | (even if the other encoding scheme is "better" given ideal input) |
| 14:47 | <Lachy> | right, so if my input video used a lossy codec which unfairly favoured one of the output codecs due to block sizes or whatever, then the test would be biased. |
| 14:47 | <Philip`> | It seems like saying that if you have e.g. a lossless PDF document full of text and compress it as PNG and JPEG then PNG will do pretty well, and asserting that if you print out the PDF and take a photograph so you've got a lossy version then PNG will be relatively just as effective as before |
| 14:48 | <Lachy> | Philip`, yeah, that['s true |
| 14:48 | <jgraham> | Lachy: Which is why the interesting test is to look at the actual inputs that people use. |
| 14:50 | <Lachy> | that may also be interesting, but that doesn't mean what I want to do isn't |
| 14:51 | <jgraham> | Right, it's just not interesting for the video-on-the-web problem (except the tiny fraction of the problem that involves losslessly encoded input) |
| 14:52 | <Philip`> | (Actually the tinier fraction that involves losslessly encoded input with the same kind of colour range and detail and motion as the one you're testing with) |
| 14:53 | Philip` | has noticed that iPlayer programmes with bright primary red/blue backgrounds tend to look terrible and blocky around the edges of the foreground, and wonders if that's an artifact of H.264 or something else |
| 14:58 | <jgraham> | takkaria: You got an email address you prefer? |
| 14:59 | <Philip`> | http://etill.net/projects/dirac_theora_evaluation/ |
| 15:08 | <takkaria> | jgraham: andiāto |
| 15:10 | <hsivonen> | interesting that Vorbis is missing in the BBC action even though it works today and BBC is interested in RF codecs |
| 15:10 | <hsivonen> | enough to put money into Dirac |
| 15:12 | <Philip`> | As far as I'm aware, it doesn't work in the sense that you could serve it over the web and most people would be able to listen to it without installing any new software |
| 15:12 | <hsivonen> | Philip`: that doesn't mention Thusnelda, which suggest the test may have used a stale encoder |
| 15:13 | <Philip`> | hsivonen: That seems quite likely (and apparently the tests were performed "Q2-2008") |
| 15:25 | <takkaria> | jgraham: any particular reason? |
| 15:29 | <jgraham> | takkaria: I used your @opera email address instead |
| 15:30 | <jgraham> | If you didn't get an email, I got it wrong :) |
| 16:15 | <remysharp> | hi, I'm having some trouble understanding the effectAllowed and dropEffect attribs in drag and drop - can anyone give me a helping hand for a min? |
| 16:23 | <remysharp> | okay - is dropEffect effect supposed to be on the dragged element or on the element we're dropping on to? |
| 16:23 | <remysharp> | it looks like (in the browser) that I'm supposed to use effectAllowed on the dragged element |
| 16:23 | <remysharp> | but I don't understand the language used on the attributes then.... - |
| 16:24 | remysharp | confused :-\ |
| 17:16 | <gsnedders> | ezyang: Habari will probably use it soon |
| 17:27 | <ezyang> | Nice! Once I fix the DOM issues, HTML Purifier 5.0 will also use html5lib |
| 17:33 | <sypasche> | Hixie: ping |
| 23:26 | <Dashiva> | I can understand people who want to write a strict syntax (subset), but is there really anything stricter about using <br/> than <br>? If anything, it leaves you open to <br/> vs <br /> |
| 23:27 | <Dashiva> | Could've saved a lot of trouble if people had talked about strict HTML rather than saddling it on XHTML |
| 23:29 | <hober> | indeed |
| 23:55 | <tantek> | Dashiva - back in the day, many of us *did* talk about strict valid semantic HTML. |
| 23:56 | <tantek> | but HTML by then had already earned too much of a "presentational" reputation, even among web designers, especially among programmers. |
| 23:57 | <tantek> | XHTML 1.0 was an opportunity to present valid semantic HTML anew, and for the most part, it worked/works quite well. |
| 23:58 | <tantek> | eventually a lot of us started referring to good use of XHTML/HTML by the shorthand (X)HTML, which was sufficient to include those that really wanted to just use HTML4 really well. |