| 00:11 | <zcorpan_> | http://simon.html5.org/temp/valid-html5.png |
| 00:12 | <Hixie> | hahahahaha |
| 00:12 | <Hixie> | i love it |
| 00:13 | <zcorpan_> | :) |
| 00:15 | <othermaciej> | Hixie: ok, I'm out of my meeting |
| 00:15 | <Hixie> | cool |
| 00:15 | <Hixie> | so |
| 00:15 | <Hixie> | you started saying something before |
| 00:15 | <othermaciej> | Hixie: I don't think downloading starting on play() is right, so maybe we should step back and discuss that |
| 00:15 | <Hixie> | let's work out where to put the urls first |
| 00:16 | <Hixie> | since i'm half way through a patch to the spec to do that |
| 00:16 | <Hixie> | and i'd have to undo my changes to change something else first |
| 00:16 | <othermaciej> | ok |
| 00:16 | <othermaciej> | well, I think that affects when you want the fallback algorithm to apply |
| 00:16 | <Hixie> | yes, i agree |
| 00:17 | <Hixie> | wait, there are two "fallback mechanisms" here |
| 00:17 | <Hixie> | there's the content-negotiation "pick the right video" case, and the "my UA doesn't support <video>" case |
| 00:17 | <othermaciej> | which two do you have in mind? |
| 00:17 | <othermaciej> | ok, agreed |
| 00:18 | <Hixie> | i would argue that for the former you just want a list of URIs and metadata (MIME type with RFC4281, eg) |
| 00:18 | <othermaciej> | yes |
| 00:18 | <Hixie> | and for the second you want arbitrary markup, which is never shown in <video>-supporting UAs |
| 00:18 | <othermaciej> | even if the last chance media source is unsupported? |
| 00:19 | <Hixie> | i think if none of the codecs are supported, the better result is for the UA to display UI to the effect of "codec not supported, download more here" |
| 00:19 | <Hixie> | (maybe automatically doing so) |
| 00:20 | <othermaciej> | it's possible <object> would support codecs that are not natively supported |
| 00:20 | <othermaciej> | I can see arguments either way |
| 00:20 | <othermaciej> | would rather not debate it now |
| 00:20 | <othermaciej> | I think your proposal is fine |
| 00:21 | <othermaciej> | list for content negotiation, alternate content only for non-<video> UAs |
| 00:21 | <Hixie> | so my straw man for how to give the UA the list and alternate content would be <video> (list goes here) (legacy ua content goes here) </video> |
| 00:21 | <Hixie> | with the list being a series of elements with src/type attributes |
| 00:22 | <Hixie> | tentatively <param> since it already works and is a void element (no end tag) in all UAs |
| 00:22 | <othermaciej> | can you also specify src/type on <video> itself? |
| 00:22 | <othermaciej> | if so, what if you specify both that and <param>s? |
| 00:23 | <Hixie> | i would only have one |
| 00:23 | <Hixie> | on the principle of simplicity |
| 00:23 | <Hixie> | though i agree it's weird |
| 00:24 | <othermaciej> | if it weren't for the <param> is already void issue, I would suggest having a new element called <alt> |
| 00:24 | <Hixie> | agreed |
| 00:24 | <othermaciej> | and allow src/type on <video> and have that be the first one considered |
| 00:24 | <zcorpan_> | oh, no, that's too confusing with alt tags, er, i mean alt attributes :P |
| 00:24 | <othermaciej> | so the non-fallback case is still simple |
| 00:24 | <Hixie> | though i dunno what i'd like, namewise |
| 00:25 | <Hixie> | well even with <param> we could do that |
| 00:25 | <Hixie> | but it looks a bit weird |
| 00:25 | <Hixie> | <video src=a type=a> <param src=b type=b> <param src=c type=c> ... </video> |
| 00:26 | <othermaciej> | yeah, that's why I suggested <alt>, cause then it's clear that it is an alternate source |
| 00:27 | <othermaciej> | not sure what would happen in existing UAs if it appeared as an unclosed element |
| 00:27 | <othermaciej> | or you could be lame and require a close tag even though there can't be content |
| 00:28 | <zcorpan_> | it wouldn't mess up existing uas, i think. in ie it would be an empty element, and other browsers would close them at </video> |
| 00:28 | <Hixie> | well it's not really an <alt>, though, right, i mean it's equally important as the first one |
| 00:28 | <Hixie> | it's just the ua will pick the best one, or something |
| 00:29 | <zcorpan_> | <negotiate> |
| 00:29 | <othermaciej> | well, there's an ordering |
| 00:29 | <othermaciej> | so there is in fact a priority order |
| 00:29 | <Hixie> | oh, ok |
| 00:34 | <othermaciej> | or rather, I think the algorithm should pick the first one that it supports |
| 00:35 | <othermaciej> | I suppose another design would have the UI somehow evaluate quality, not just binary yes/no |
| 00:35 | <othermaciej> | but I think that is harder to deal with for both UAs and authors |
| 00:41 | <Hixie> | hang on mtg of my own now |
| 00:41 | <othermaciej> | ok |
| 00:48 | <Hixie> | ok back |
| 00:48 | <Hixie> | i guess we can have src/type on video and on child elements |
| 00:48 | <Hixie> | but it feels a little weird to me |
| 00:48 | <Hixie> | kind of assymetric |
| 00:50 | <othermaciej> | Agreed, but it would be nice not to make the no-fallback case more complex |
| 00:50 | <Hixie> | yeah.. |
| 00:50 | <Hixie> | <video><param src=""></video> |
| 00:50 | <Hixie> | it's not that much more complex i guess |
| 00:51 | <Hixie> | or maybe we can make it be one or the other |
| 00:51 | <Hixie> | if there's a src, ignore children |
| 00:51 | <Hixie> | if there isn't, only use children |
| 00:51 | <Hixie> | and not have a type="" on the <Video> element itself |
| 00:53 | <othermaciej> | it's hard for me to have a strong opinion on these particular details |
| 00:53 | <othermaciej> | I would like both single-source and multi-source cases to be nice syntactically |
| 00:53 | <Hixie> | ok well i'll just go with that last suggestion then |
| 00:53 | <Hixie> | what was the argument against using <param>? |
| 00:54 | <othermaciej> | is using an already-void element really a big advantage here, btw? |
| 00:54 | <othermaciej> | is there any UA where </video> wouldn't close random open unknown elements? |
| 00:54 | <Hixie> | well it's not a huge advantage, it's just neat. It also avoids the need to invent yet another element. |
| 00:54 | <Hixie> | every element we use here is one less name we can use elsewhere when we really need it |
| 00:55 | <othermaciej> | sure, but one element that you use with completely orthogonal sets of attributes in different situations is not much of a simplification |
| 00:55 | <othermaciej> | and makes validators either more complicated or less effective |
| 00:56 | <Hixie> | this is probably a one-line change in a decently architected conformance checker |
| 00:56 | <Hixie> | it only complicates matters if someone tries to document the element itself, as opposed to <object> and <video> |
| 00:56 | <Hixie> | hm |
| 00:56 | <Hixie> | what could we call it if not <param>... |
| 00:56 | <Hixie> | <source>, maybe |
| 00:56 | <othermaciej> | <source> is good |
| 00:56 | <Hixie> | <video> <source src="" type=""> <source src="" type=""> <p>You need Safari 3.</p> </video> |
| 00:58 | <othermaciej> | <source src> is a bit awkward, but better than alternatives I guess |
| 00:58 | <othermaciej> | the other prior art would be <source data> or <source href> and both of those seem worse |
| 00:58 | <Hixie> | yeah |
| 00:59 | <Hixie> | personally i prefer <param src="" type=""> but <source> is fine too. i'm speccing <source> for now, we can see what people say. |
| 00:59 | <zcorpan_> | i'd vote for <param> over <source> |
| 00:59 | <zcorpan_> | fwiw |
| 01:01 | <othermaciej> | it would seem weird to me if <param value name> and <param src type> were the same element but had completely different semantics, behavior, allowed attributes and contexts where they are valid |
| 01:03 | <Hixie> | i'd consider them different elements :-) |
| 01:03 | <Hixie> | just that happen to have the same name :-) |
| 01:04 | <othermaciej> | would the HTMLParamElement interface also include both sets of attributes? |
| 01:05 | <Hixie> | sure |
| 01:05 | <Hixie> | on <source>, should the type="" attribute require a codec="" parameter? |
| 01:05 | <othermaciej> | Some audio/video types may already imply a codec |
| 01:06 | <Hixie> | k |
| 01:06 | <Hixie> | so optional but mentioned |
| 01:07 | <othermaciej> | <param> already has a type attribute BTW |
| 01:07 | <Hixie> | not in HTML5 |
| 01:07 | <Hixie> | but yeah |
| 01:07 | <Hixie> | in HTML4 it did |
| 01:07 | <othermaciej> | I guess no one uses that? |
| 01:08 | <Hixie> | i couldn't work out what it was supposed to do and nobody could tell me |
| 01:08 | <Hixie> | so i dropped it |
| 01:08 | <Hixie> | :-) |
| 01:08 | <Hixie> | much like <meta scheme> |
| 01:08 | <Hixie> | and many others |
| 01:10 | <Lachy_> | hmm. I was expecting you to use <param name="src" value=""> |
| 01:10 | <Lachy_> | embedding flash in IE uses <param name="movie" value="flash.swf"> |
| 01:10 | <Hixie> | the name="src" would be redundant and UAs would end up ignoring it |
| 01:11 | <Lachy_> | so this param is only ever going to be used for specifying alternate sources? |
| 01:11 | <Hixie> | it's <source> right now |
| 01:11 | <Hixie> | but for now, yes |
| 01:11 | <Hixie> | extensibility doesn't work when you only have one value, because people end up ignoring it |
| 01:11 | <Hixie> | look at, e.g., <style>'s type="" attribute |
| 01:13 | <Lachy_> | I thought it might have been useful for extensibility, so that instead of adding new attributes to <video> for every new feature in the future, we could just use <param name value> |
| 01:14 | <othermaciej> | better yet, we could do that for all elements, and deprecate attributes entirely |
| 01:14 | <othermaciej> | </reductio> |
| 01:14 | <Lachy_> | :-) |
| 01:15 | <Lachy_> | I'm not particularly thrilled with <source src>. The name seems a little redundant, and could cause confusion for some about which spelling of source/src to use |
| 01:15 | <Hixie> | that's what xhtml2 has done |
| 01:15 | <Hixie> | (seriously) |
| 01:16 | <Lachy_> | really? I thought XHTMl2 <param> was only for object |
| 01:16 | <Hixie> | well they use <meta> |
| 01:16 | <Lachy_> | oh, they have done that with <meta> thought |
| 01:17 | <Hixie> | but <element><meta name="foo">bar</meta></element> is supposedly exactly equivalent to <element foo="bar"/> in XHTML2 |
| 01:17 | <Lachy_> | where is that specified? ;-) |
| 01:17 | <Hixie> | hah |
| 01:17 | <Hixie> | i asked steven that in person once |
| 01:17 | <Hixie> | he told me it wasn't required |
| 01:18 | <zcorpan_> | it's undefined, like everything else ;) |
| 01:18 | <Hixie> | i never got him to explain why the spec says about that <title> example that the two are equivalent, if they're not as he claimed to me in person |
| 01:18 | <Lachy_> | I never got a response to my questions about the equivalence of <title>/<meta name="title'> |
| 01:18 | <Hixie> | go figure |
| 01:21 | <othermaciej> | Lachy_: maybe if you were more aligned you would understand |
| 01:22 | <Lachy_> | understand what? |
| 01:22 | <othermaciej> | the equivalent of <title>/<meta name="title"> |
| 01:23 | <othermaciej> | I'm kind of being facetious here |
| 01:23 | <Hixie> | i still don't get why we would want to _not_ look at concrete technical issues |
| 01:24 | <Hixie> | but instead pontificate on "interesting" questions |
| 01:26 | <othermaciej> | well apparently if you do that, you get XHTML2 |
| 01:34 | <Hixie> | what should the method that does the conneg without doing the play() be called? open() or load() ? |
| 01:42 | <Dashiva> | Hixie: buffer? preload? Among the two you suggested, I'd take load |
| 01:44 | <Dashiva> | Or do you mean only a basic HEAD to get the parameters, no content download involved? |
| 01:44 | <Hixie> | preload() i guess could work too |
| 01:44 | <Hixie> | though i prefer load(), i think |
| 08:25 | <krijnh> | Whoops |
| 08:59 | <Hixie> | gonna go home |
| 08:59 | <Hixie> | might work some more from home |
| 09:00 | <dhyatt> | seeya |
| 09:11 | Looking | up krijnh user info... |
| 10:39 | <Hixie> | i wonder whether loop() should automatically seek() to the begin point first |
| 10:43 | <met_> | for video or audio? |
| 10:44 | <Hixie> | both |
| 10:44 | <Hixie> | though if you think they should be different, do say |
| 10:45 | <met_> | when compare with e.g. mp3 players, there you can switch on/off repeat during listening and it contiues play without switching |
| 10:45 | <met_> | same tape-recorders |
| 10:45 | <met_> | do not see seek before loop in any system I know |
| 10:46 | <met_> | dvd players the same I think |
| 10:47 | <Hixie> | the problem is if you don't seek() when you call loop(), then it's not clear how to either (a) restart a loop, or (b) do a loop with pre- and post-roll sfx |
| 10:48 | <Hixie> | (a) would require the author to explicitly seek() to start pos when paused before calling loop(), otherwise nothing would happen when you called loop() |
| 10:49 | <Hixie> | i'm gonna get some sleep, think about it when i get up. |
| 10:49 | <Hixie> | ttyl |
| 10:49 | <met_> | gn |
| 13:10 | <Hixie> | anyone know what "apply sort field" does on a selection in iTunes? |
| 13:20 | <billmason> | If you have data in one of the "sort" fields on that selection, you can apply that data to songs that match whatever "same-whatever" you choose. Or something like that. |
| 13:20 | <billmason> | http://blech.vox.com/library/post/sort-fields-in-itunes-71.html is a better explanation |
| 13:21 | Hixie | reads, hoping it explains it |
| 13:22 | <billmason> | It has to be more coherent than my ramblings. :) |
| 13:22 | <billmason> | I don't use it much. The UI doesn't help to discover it. |
| 13:28 | <Hixie> | wow, yeah, that explained it |
| 13:28 | <Hixie> | cool |
| 13:28 | <Hixie> | thanks |
| 13:28 | <Hixie> | glad that it was just added and i hadn't missed it for ages |
| 13:31 | <billmason> | you're welcome |
| 13:43 | <Hixie> | hm |
| 13:43 | <Hixie> | i just realised |
| 13:43 | <Hixie> | that in the html5 spec we haven't defined how <script> actually works in XML |
| 13:43 | <Hixie> | since it's defined to execute when inserted |
| 13:43 | <Hixie> | and the html5 parser is careful not to insert until the script has been appended |
| 13:44 | <Hixie> | but that wouldn't work for an xml parser |
| 14:10 | <othermaciej> | good evening |
| 14:13 | zcorpan_ | is skipping all the Codec emails |
| 14:22 | <Hixie> | so othermaciej, if we say that something happens when you parse the </video> tag in HTML5, that still doesn't solve the XML problem |
| 14:23 | <othermaciej> | Hixie: I don't think we should say that, on further thought |
| 14:24 | karlUshi | wonders if the ordering in iTunes follows the hiragana japanese ordering. |
| 14:25 | <Hixie> | so then the problem is what do we wait for to trigger downloads? the 'load' event on body? |
| 14:45 | <Lachy_> | I don't understand the XML problem regarding the downloading of <video> content |
| 14:48 | <Hixie> | same as the <script> problem |
| 14:51 | <Lachy_> | yeah, I don't understand that one either |
| 14:51 | <Hixie> | so <script> is defined to execute when it's inserted into the document |
| 14:51 | <Lachy_> | why is it a problem? Why can't you just specify that the script executes as soon as the script element is finished |
| 14:51 | sayrer | thanks Hixie for his rude email |
| 14:52 | <othermaciej> | Hixie: anyway, back to </video> |
| 14:52 | <othermaciej> | here's my proposed rules for fallback |
| 14:52 | <othermaciej> | 1) at parse time, you process the <source> elements one at a time, the first successful one becomes the content source |
| 14:53 | <othermaciej> | 2) if you change the contents of <video> in a way that would change which is the first <source> that's successful, redo the fallback algorithm |
| 14:53 | <othermaciej> | (either change which is first, or change what URL it points to) |
| 14:53 | <Hixie> | Lachy_: well, there are two options i see: do it on insertion and have the html parser delay insertion until it's filled the child nodes (the script) -- this doesn't handle xml -- or, have different rules for xml, html, and dynamically created elements |
| 14:54 | <othermaciej> | the specific changes that would trigger #2 include changing type on the first successful <source> or one before it, removing the first successful <source> or one before it, or inserting a <source> before the first successful one |
| 14:54 | <othermaciej> | but you don't have to limit it |
| 14:54 | <othermaciej> | can just say that if the same URL ends up being the final src don't make any changes |
| 14:54 | <Hixie> | othermaciej: i really don't want to have to rerun the algorithm every time you change the DOM. You'd end up firing dozens of HTTP requests only to cancel them. |
| 14:54 | <sayrer> | option 3: don't specify it because it doesn't work |
| 14:54 | <Hixie> | othermaciej: and doing things when the DOM changes is a source of constant bugs |
| 14:54 | <othermaciej> | I don't think you would fire a lot of HTTP requests |
| 14:54 | <othermaciej> | in the common parsing case, exactly one |
| 14:55 | <othermaciej> | or zero if no <source> elements have a good type |
| 14:55 | <Hixie> | othermaciej: i mean in the DOM manipulation case |
| 14:55 | <Hixie> | e.g. if i am moving <source>s about |
| 14:55 | <Hixie> | in a DOM inspector or something |
| 14:55 | <othermaciej> | yes, well, you don't necessarily have to start the load until the particular script in question is done |
| 14:55 | <Hixie> | i'd much rather have an explicit "look at the elements and start the load" step. |
| 14:56 | <Hixie> | we can certainly run that algorithm every time you add a <source> element |
| 14:56 | <othermaciej> | hmm |
| 14:56 | <othermaciej> | usually rendering reacts to DOM changes without the need to make an explicit call |
| 14:56 | <Hixie> | which would work fine for load time |
| 14:56 | <Hixie> | yeah but this isn't just rendering |
| 14:56 | <Hixie> | i mean, it would interrupt active playback and everything |
| 14:56 | <Hixie> | and it's a very rare edge case we're talking about |
| 14:56 | <Hixie> | so it's extra complexity that isn't worth it |
| 14:57 | <Hixie> | sayrer: regarding the e-mails, apologies if it sounded rude, it wasn't meant that way. your reply seems to be missing a verb in the first sentence which is preventing me from understanding what you mean. |
| 14:57 | <othermaciej> | haven't thought that deeply about the dynamic case, but I usually prefer things where the state of the document is reflected in the rendering regardless of how you got there |
| 14:57 | <sayrer> | Hixie: yeah, I skipped "know" |
| 14:57 | <othermaciej> | even though that can be complicated to implement |
| 14:57 | <othermaciej> | you are right that swapping two <source> elements you wouldn't want to interrupt the video |
| 14:57 | <othermaciej> | if it doesn't change which one applies |
| 14:58 | <othermaciej> | but I think more commonly you'd update the src and type of all the <source> elements in order |
| 14:58 | <sayrer> | Hixie: "I hate to be the one to break this to you" is pretty much universally interpreted as condescending and rude |
| 14:58 | <sayrer> | especially when followed by things that everyone knokws |
| 14:59 | <sayrer> | I should have been clearer with the patent point, though |
| 14:59 | <sayrer> | if you have to pay someone, that means someone owns something |
| 15:00 | <sayrer> | which is a pretty good definition of proprietary |
| 15:00 | <othermaciej> | sayrer: ordering everyone to take patent discussion to a separate list you just created is pretty rude |
| 15:00 | <sayrer> | othermaciej: I didn't order anyone. I thought it was pretty obviously a joke. |
| 15:02 | <othermaciej> | sayrer: wasn't obvious to me, since you objected to patent discussion repeatedly |
| 15:02 | <sayrer> | I do object to it |
| 15:02 | <sayrer> | I don't think participating in WHATWG should include getting weird legal email from Apple. Sorry. |
| 15:02 | <othermaciej> | if you don't want to hear about patents you are free to unsubscribe |
| 15:03 | <Hixie> | just ignore the mails you don't care about, sheesh |
| 15:03 | <Hixie> | we have to sort out this codec thing, and that means discussing patents |
| 15:03 | <Hixie> | deal with it |
| 15:03 | <othermaciej> | however, they are sadly a relevant issue to web standards |
| 15:03 | <Hixie> | othermaciej: i think you'd want to update the srcs and then when you're done run the algorithm once. |
| 15:04 | <Hixie> | othermaciej: i don't think you'd want to have the algorithm run as you're updating, with the UA flashing a "no available streams" message for a few milliseconds or something |
| 15:04 | <othermaciej> | Hixie: that's probably so |
| 15:04 | <Hixie> | othermaciej: or have the UA start playing one of the previous set of sources or something |
| 15:04 | <othermaciej> | Hixie: I wish this could be like CSS style resolution |
| 15:04 | <othermaciej> | where you can change multiple styles |
| 15:04 | <othermaciej> | but the style recalc only happens after a delay |
| 15:04 | <othermaciej> | or if you do something that demands the knowledge immediately |
| 15:04 | <othermaciej> | (happens at next async opportunity that is) |
| 15:05 | <Hixie> | i dunno, i think it makes sense to just have it be something you have to invoke. trying to see if i can think of other examples of this though. |
| 15:06 | <Hixie> | one example would be XMLHttpRequest, it doesn't send off the request just because you've updated the headers |
| 15:06 | <Hixie> | there's an explicit commit step |
| 15:06 | <Hixie> | (two of them, even, with that API) |
| 15:06 | <othermaciej> | yes, but explicit sending of a request is what the API is all about, and how network APIs normally work |
| 15:06 | <Hixie> | i dunno, we can make it watch mutations... it just seems painful |
| 15:07 | <othermaciej> | updating the rendering to reflect the markup is how display in browsers normally works |
| 15:07 | <othermaciej> | even if some loads are involved |
| 15:07 | <Hixie> | as a general rule i wouldn't put too much stock in precedent of how html works :-P |
| 15:07 | <othermaciej> | I agree that having to explicitly update sounds easier to implement |
| 15:07 | <othermaciej> | but it also seems unwebby |
| 15:08 | <othermaciej> | anyway my opinion on this point isn't that strong, either way it will be better than <object> |
| 15:09 | <Hixie> | fwiw, for some precedent the other way, <script> doesn't reexecute when you change it. |
| 15:10 | <Hixie> | does changing <param> elements respawn the <object>'s plugin? |
| 15:10 | <othermaciej> | no |
| 15:11 | <othermaciej> | not even changing the data attribute changes the contents, I believe |
| 15:11 | <Hixie> | hm, html5 says to relaunch plugin when data= or type= change, but ignores changes to <param> |
| 15:11 | <Hixie> | might need to look into that at some point then |
| 15:13 | <Hixie> | i'm gonna say changing the <source>s doesn't change the <video>, but we can change that later if we want. no biggie. |
| 15:13 | <othermaciej> | ultimately I think we want something that works in the dynamic case (after all, it's "Web Apps 1.0") but that seems ok for starters |
| 15:14 | <Hixie> | oh well don't get me wrong |
| 15:14 | <Hixie> | there's already a method to manually trigger the algorithm |
| 15:14 | <Hixie> | you just call video.load() and it redoes it all |
| 15:14 | <othermaciej> | oh |
| 15:14 | <othermaciej> | that seems ok |
| 15:14 | <Hixie> | the question is just whether to implicitly call that for anything |
| 15:14 | <Hixie> | the problem is what to call it for during parse time |
| 15:15 | Lachy_ | wonders how these test cases are useful and why they were posted to public-html? http://accessibleinter.net/html/testcases/ |
| 15:15 | <Hixie> | wait for document load event? hook it into the parser? |
| 15:16 | <othermaciej> | I think at parse time loading the first successful one you see is fine |
| 15:16 | <Hixie> | oh, right, we can still do that, yeah |
| 15:16 | <othermaciej> | explicit load() can be required only if you change things after one has succeeded |
| 15:17 | <Hixie> | yeah |
| 15:25 | <billmason> | Lachy_: I don't know either, and because I was asked to. |
| 15:25 | KevinMarks | reads scrollback |
| 15:26 | <Lachy_> | I don't recommend blindly doing everything you are asked to do |
| 15:26 | <KevinMarks> | so alternates for video are now in <source> |
| 15:26 | <Hixie> | yeah |
| 15:26 | <Hixie> | i'm speccing it now |
| 15:26 | <Hixie> | should be done in an hour or so |
| 15:27 | <Lachy_> | billmason: test cases are useful when trying to determine support for some specific feature in browsers and when they have clear pass/fail conditions. |
| 15:28 | <KevinMarks> | dang, what a backlog of comments |
| 15:28 | <Lachy_> | in the case of abbr/acronym, browser support is well known already, and your test cases don't specify any pass/fail conditions |
| 15:30 | <billmason> | You're not telling me anything I don't know, I'm afraid. |
| 15:30 | <KevinMarks> | have you looked at hreflang on source as a possible choice driver? |
| 15:30 | <sayrer> | hehe, it gets better and better |
| 15:31 | <sayrer> | content negotiation ftw |
| 15:31 | <KevinMarks> | QT's content alternatives stuff supports that |
| 15:31 | <Hixie> | KevinMarks: this is purely about getting the right codec, if you want to do language selection, just offer the languages to your users |
| 15:31 | <Hixie> | or use HTTP Accept-Language |
| 15:32 | <sayrer> | oh speaking of QT, is ok to do stuff in the <video> that isn't strictly video? |
| 15:32 | <Hixie> | like what? |
| 15:32 | <sayrer> | like, can I put Flash movie in it? |
| 15:32 | <Hixie> | you mean an FLV file? |
| 15:32 | <sayrer> | or an interactive QT thing? |
| 15:32 | <Hixie> | sure |
| 15:32 | <Hixie> | if your browser supports the FLV codecs |
| 15:32 | <Hixie> | (which truly _are_ proprietary, unlike MPEG4) |
| 15:32 | <sayrer> | no, I mean full on flash movies |
| 15:32 | <KevinMarks> | well, the microformat draft did do that: |
| 15:32 | <KevinMarks> | http://microformats.org/wiki/alternates#Strawman_6_.28lists_.2B_explicit_alternator_.2B_using_existing_HTML_idiom.29 |
| 15:33 | <Hixie> | you mean flash applications? as in swf files? |
| 15:33 | <Hixie> | no |
| 15:33 | <sayrer> | yep |
| 15:33 | <sayrer> | ok, does the spec say that? |
| 15:33 | <Hixie> | not sure what it would say |
| 15:33 | <Hixie> | it won't work, because the UA won't support that codec |
| 15:33 | <sayrer> | does it also rule out the quicktime stuff, and any other weird interactive technologies? |
| 15:33 | <Hixie> | because it's not a codec |
| 15:34 | <sayrer> | well, some mime types imply a codec |
| 15:34 | <Hixie> | if UAs want to work out what it would mean for that to work, i personally wish them luck |
| 15:34 | <Hixie> | i don't see any reason to disallow it |
| 15:34 | <sayrer> | (not trying to be a jerk... this will happen eventually) |
| 15:34 | <Hixie> | actually, the spec does require one thing |
| 15:34 | <Hixie> | it requise that the playback position increase monotonically |
| 15:35 | <Hixie> | requires |
| 15:35 | <sayrer> | ah, that's good |
| 15:35 | <Hixie> | which pretty much throws out all that stuff |
| 15:35 | <sayrer> | not too clear that stuff like DVD menus is out |
| 15:35 | <KevinMarks> | chapters are useful, but they are hard to make now |
| 15:35 | <Hixie> | well anyway |
| 15:36 | <Hixie> | <source> is the current topic at hand |
| 15:36 | <Hixie> | (as far as editing goes) |
| 15:36 | <Hixie> | (feel free to discuss other things amongst yourselves!) |
| 15:36 | <sayrer> | (well that won't work, no one has done it yet) |
| 15:37 | <KevinMarks> | got ot get my train |
| 15:38 | <dhyatt> | sayrer: btw not sure why you're ratholing on patents |
| 15:38 | <dhyatt> | sayrer: maciej raised a technical objection to theora as well |
| 15:38 | <dhyatt> | sayrer: but you just assumed he was talking about patents again when he wasn't |
| 15:38 | <sayrer> | dyhatt: I saw one about hardware playback? |
| 15:38 | <dhyatt> | correct. |
| 15:38 | <Hixie> | oh god, yeah, theora is doomed on hardware-constrained devices |
| 15:38 | <dhyatt> | you can't play video using theora in software on low end devices |
| 15:39 | <Hixie> | without hardware support there's no way |
| 15:39 | <dhyatt> | and even on those where you could sort of do it, the battery drain would be unacceptable |
| 15:39 | <sayrer> | dhyatt: I asked if something about theora prevented hardware playback |
| 15:39 | <Hixie> | yeah really |
| 15:39 | <dhyatt> | you *need* hardware support right now |
| 15:39 | <dhyatt> | this is a really serious issue that people are glossing over |
| 15:39 | <dhyatt> | theora chips aren't going to magically materialize any time soon |
| 15:39 | <Hixie> | sayrer: nothing prevents it, but it's academic if there are no hardware chips (there aren't any) |
| 15:39 | <sayrer> | I asked a direct question about it |
| 15:40 | <sayrer> | I'm not glossing over it |
| 15:40 | <dhyatt> | anway my point was just that maciej is mainly concerned about that |
| 15:40 | <dhyatt> | not about patents |
| 15:40 | <dhyatt> | there are sound technical reasons to object to theora |
| 15:40 | <dhyatt> | ranging from tools for putting video together not supporting it to hardware playback to etc |
| 15:41 | <sayrer> | certainly there are sound reasons to refuse it as the /only/ option |
| 15:41 | <dhyatt> | although maybe the former is not a big deal and i am just ignorant there :) |
| 15:41 | <dhyatt> | my opinion is that we shouldn't even mandate a baseline codec |
| 15:41 | <sayrer> | which some have suggested |
| 15:41 | <dhyatt> | since <img> doesn't do that |
| 15:42 | <dhyatt> | telling mobile devices that can play mpeg in hardware but nothing else that they just can't support the <video> element because they don't do theora is crazy imo |
| 15:42 | <sayrer> | well, they wouldn't be compliant |
| 15:42 | <Hixie> | oh the spec already allows you to not do ogg theora if you can't |
| 15:42 | <dhyatt> | ah ok |
| 15:42 | <Hixie> | it's a should-level requirement only at the moment |
| 15:42 | <dhyatt> | got it |
| 15:42 | <sayrer> | yes, you changed it |
| 15:42 | <Hixie> | (it has never been a must) |
| 15:42 | <sayrer> | the question is whether that's interesting when the spec is four years out |
| 15:44 | <sayrer> | Hixie: there is a comment in there about it not being a must. I assumed you had changed it from some previous state. |
| 15:44 | <Hixie> | nope |
| 15:44 | <sayrer> | there is a comment in there, right? |
| 15:44 | <sayrer> | "this isn't a must because of legal issues" |
| 15:46 | <Hixie> | there's a comment, yes |
| 15:47 | <Hixie> | it's to remind me of why it's a should, should anyone try to convince me to change it to a must :-) |
| 15:47 | <Hixie> | i used to not leave notes to myself, and then i ended up in loops where i'd respond to feedback from one person, go must->should, a year later i'd go should->must, and back and forth year after year |
| 15:47 | <Hixie> | until i realised what was going on |
| 15:48 | <Hixie> | and now i put guards against that in these kinds of situations |
| 15:49 | <tylerr> | Morning everyone. |
| 15:55 | <zcorpan_> | morning tylerr |
| 15:56 | <tylerr> | Hey there zcorpan_, how was the rest of the day yesterday? |
| 15:56 | <zcorpan_> | fine i guess |
| 15:57 | <tylerr> | Good good, any plans for the (rest of the) day? |
| 15:58 | <zcorpan_> | yeah, i'll play duke nukem 3d at "damn i'm good" :D |
| 15:59 | <zcorpan_> | i'm almost through the second episode |
| 16:01 | <zcorpan_> | what about you? |
| 16:03 | <tylerr> | Just got into the office and have to clean up the work of another vendor that our client has building pages. It's rather frustrating seeing a professional vendor produce such garbage pages. |
| 16:59 | <Hixie> | tada! |
| 16:59 | <Hixie> | spec updated for <source> |
| 17:03 | <othermaciej> | woo hoo |
| 17:05 | <othermaciej> | I see you also split out the media element generic stuff from <video> |
| 17:08 | <Hixie> | yeah |
| 17:08 | <Hixie> | gonna collapse <audio> and Audio() |
| 17:08 | <Hixie> | and make them inherit from HTMLAudioElement like in your propasl |
| 17:14 | <othermaciej> | cool |
| 17:16 | <othermaciej> | I guess I will wait til you are done adding stuff to compare the result to our proposal w/ my Apple cohorts and to raise any issues |
| 17:17 | <othermaciej> | and after that I will raise for discussion features we did not even propose a spec for, like metadata access, track info, timed text support, etc |
| 17:17 | <othermaciej> | although I am not sure it is worth raising such things on the whatwg list w/o a spec proposal |
| 17:17 | <othermaciej> | since there don't seem to be a lot of media experts there, either that or they don't want to chime in |
| 17:17 | <othermaciej> | hello KevinMarks |
| 17:18 | <Hixie> | feel free to raise use cases and feature requests |
| 17:18 | <KevinMarks> | hi |
| 17:18 | <KevinMarks> | sorry, I should review it, I have had a hectic couple of days |
| 17:18 | <Hixie> | i'll talk to the various experts i have access to (including apple people if they'll talk to me), look at existing apis, and see what we can come up with |
| 17:18 | <Hixie> | don't review it today |
| 17:19 | <Hixie> | tomorrow it should be in better state |
| 17:19 | <KevinMarks> | OK |
| 17:19 | <Hixie> | i'm slowly merging a bunch of the apple proposals |
| 17:19 | <othermaciej> | did you mean the stuff in the whatwg spec or apple's proposals? |
| 17:19 | <othermaciej> | apple's proposals aren't going to change, so you can read them, but Hixie is changing some stuff as he merges it in |
| 17:19 | <Hixie> | oh sorry i assumed he meant the whatwg spec |
| 17:19 | <KevinMarks> | I read the main apple one |
| 17:20 | <KevinMarks> | but I haven't read the whatwg spec recently, though I did plough through some of ian's mmaoth collations |
| 17:20 | <KevinMarks> | *mammoth |
| 17:20 | <Hixie> | hehe |
| 17:20 | <othermaciej> | one important but minor point is that time should really be floating point (and so probably seconds) instead of integer milliseconds |
| 17:20 | <Hixie> | ew, really? |
| 17:20 | <othermaciej> | I can write an email explaining why if you want |
| 17:20 | <othermaciej> | well, it wasn't an accident that our spec had it that way |
| 17:20 | <Hixie> | i'll change it, but, i'd love to see the reasoning, yes |
| 17:21 | <Hixie> | when i looked at it it seemed like a really bad idea |
| 17:21 | <othermaciej> | 1) milliseconds are not precise enough for audio |
| 17:21 | <Hixie> | precise enough to do what with audio? |
| 17:21 | <KevinMarks> | get the right sample |
| 17:21 | <othermaciej> | 2) using integer milliseconds you start getting roundoff error accumulation |
| 17:21 | <KevinMarks> | really, you want to use fractions like QT does |
| 17:21 | <othermaciej> | audio has very high sample rates |
| 17:22 | <othermaciej> | yeah, rational numbers of some kind would work best |
| 17:22 | <othermaciej> | we are still discussing a proposal for that |
| 17:22 | <othermaciej> | it's hard to come up w/ something sane |
| 17:22 | <Hixie> | floats in general seem like a really bad idea due to the loss in precision as you go higher |
| 17:22 | <KevinMarks> | yes |
| 17:22 | <othermaciej> | well, JS numbers are all floats anyway |
| 17:22 | <Hixie> | (not to mention the general disaster that floats give you) |
| 17:22 | <Hixie> | but ok |
| 17:22 | <KevinMarks> | and video frames are actually 30000/1001 per second in the US |
| 17:23 | <othermaciej> | television video signals, yes |
| 17:23 | <othermaciej> | thus the wonder that is smpte drop frames |
| 17:23 | <Hixie> | to be honest i wasn't seeing seeking to precise frames and audio samples as a feature with demand |
| 17:23 | <Hixie> | all the seeking i've seen happen seems to just be for scrub bars |
| 17:23 | <KevinMarks> | and chapters |
| 17:23 | <othermaciej> | we'd like something that can at least be extended to pro-type applications in the future |
| 17:24 | <KevinMarks> | I need to write up something on chapters |
| 17:24 | <othermaciej> | even if it doesn't handle them in the HTML5 version |
| 17:24 | <KevinMarks> | HTML EDLs? |
| 17:24 | <othermaciej> | we had a vague comment on chapters in our open issues list |
| 17:24 | <Hixie> | lord, i hope y'all don't want to reimplement Final Cut Express in HTML |
| 17:24 | <KevinMarks> | chapters are a common case for podcasts |
| 17:25 | <KevinMarks> | little running order posts with time offsets |
| 17:25 | <othermaciej> | I doubt FCE is coming but a simple video editor web app might not be out of the question |
| 17:25 | <KevinMarks> | maybe that's a microformat rather than an html 5 feature |
| 17:25 | <othermaciej> | or something to review HD video dailies |
| 17:25 | <Hixie> | how high can JS Numbers go before they lose too much precision for accurate seeking? |
| 17:26 | <othermaciej> | they are IEEE floating point doubles, they can go pretty high |
| 17:26 | <Hixie> | k |
| 17:26 | <KevinMarks> | they are 64 bit? |
| 17:26 | <othermaciej> | 52 bit mantissa, 11 bit exponent, 1 bit sign |
| 17:27 | <othermaciej> | not sure if that is sufficient even for streaming applications where you leave the stream running for days |
| 17:27 | <othermaciej> | but there you don't generally support seeking anyway |
| 17:27 | <KevinMarks> | and you have to futz with the samples to stay in sync cos of the 2 clocks problem |
| 17:28 | KevinMarks | is getting fashbacks |
| 17:28 | <othermaciej> | I don't think our proposal is totally ready for the streaming case |
| 17:28 | <KevinMarks> | it's marginal anyway... |
| 17:28 | <othermaciej> | web video chat? |
| 17:28 | <othermaciej> | live broadcasts? |
| 17:29 | <KevinMarks> | hm, maybe |
| 17:29 | <othermaciej> | internet radio? |
| 17:29 | <KevinMarks> | that got killed |
| 17:30 | <KevinMarks> | they have indefinite duration |
| 17:30 | <KevinMarks> | I think you covered that |
| 17:30 | <othermaciej> | if you want 10 digits after the decimal, IEEE double is enough for a 139,461 year long stream |
| 17:30 | <othermaciej> | so probably more than enough |
| 17:31 | <othermaciej> | we did cover indefinite duration |
| 17:31 | <othermaciej> | did not really cover inability to seek or some of the other grungy details |
| 17:34 | <KevinMarks> | Hixie, did I show you my example fo a qt movie with chapters? |
| 17:34 | <Hixie> | no? |
| 17:35 | <othermaciej> | KevinMarks: do you have in mind chapters that exist as metadata in the media file, or external chapters that just link a name to some point in time? |
| 17:35 | <Hixie> | othermaciej: btw did you have a list of names i should add to the acknowledgements of people who wrote your proposal? |
| 17:35 | <othermaciej> | Hixie: I'm not sure they all want to be credited but I'll ask |
| 17:35 | <KevinMarks> | http://epeus.blogspot.com/2007/01/iphones-great-step-back-from-ichat.html |
| 17:35 | <Hixie> | othermaciej: k |
| 17:36 | <Hixie> | othermaciej: (i generally add anyone who says anything that results in the spec changing, whether the change is what they wanted or not, and whether they want to be associated with the spec or not) |
| 17:36 | <Hixie> | right, converted to floats/seconds |
| 17:37 | <KevinMarks> | not in the media file. I think specifying them in the html, so that your soft controller can do the chapterlist thing |
| 17:37 | <KevinMarks> | maybe they're just a <select> |
| 17:39 | <othermaciej> | KevinMarks: but in your example I assume the chapters are in the media file? |
| 17:39 | <KevinMarks> | they aren't in apple's media file |
| 17:40 | <othermaciej> | for chapters purely in html, you don't really need special support |
| 17:40 | <KevinMarks> | I authored them in apple's not-quite xml format, and rendered them into a movie |
| 17:40 | <othermaciej> | unless you somehow want to feed them into native controller UI |
| 17:40 | <othermaciej> | for chapters in the media file, you want a metadata API to get the names, and to seek to chapter by name |
| 17:41 | <KevinMarks> | http://docs.info.apple.com/article.html?path=QuickTime%20Player/7.0/en/c3qt20.html |
| 17:42 | <KevinMarks> | hm, I think that used to have screenchots in |
| 17:47 | <KevinMarks> | here's the timestamp format |
| 17:47 | <KevinMarks> | http://developer.apple.com/documentation/QuickTime/RM/ImportExport/DataExchange/F-Chapter/chapter_6_section_7.html |
| 17:51 | <othermaciej> | we wanted to put a way to use that timestamp format in the API to specify times |
| 17:51 | <othermaciej> | and in the CSS stuff |
| 17:51 | <othermaciej> | didn't have time to spec it out before publishing though |
| 17:52 | <othermaciej> | (not necessarily the brackets, but the genral idea of a clock time with fractional seconds) |
| 17:52 | <Hixie> | yeah maybe we need a helper function like atob() |
| 17:52 | <Hixie> | ctos() (clock to seconds) |
| 17:52 | <othermaciej> | we thought conversion functions back and forth might cut it, yeah |
| 17:52 | <Hixie> | ctos('22h33m21s.02') |
| 17:53 | <Hixie> | though some people have said they need to be able te specify exact frames in video |
| 17:53 | <othermaciej> | I think 22:33:21:0.02 is more legible |
| 17:53 | <Hixie> | for which that wouldn't work |
| 17:53 | <Hixie> | either's fine |
| 17:53 | <othermaciej> | for exact frames you basically need a frame number, since some formats have variable-duration frames |
| 17:53 | <Hixie> | (the h/m/s/. format has the advantage of allowing you to omit seconds) |
| 17:54 | <KevinMarks> | dear god, what is that xml format it exports? |
| 17:54 | <Hixie> | yeah |
| 17:55 | <KevinMarks> | http://homepage.mac.com/kevinmarks/macworld2007.txt is the text version |
| 17:55 | <KevinMarks> | which could map to HTML cleanly IMO |
| 17:55 | <KevinMarks> | http://homepage.mac.com/kevinmarks/macworld2007.xml is a total rats nest |
| 17:57 | <othermaciej> | yeah, with colons you can only omit from the larger unit |
| 17:57 | <KevinMarks> | timeScale="30" s the key |
| 17:57 | <othermaciej> | but that is generally ok |
| 17:57 | <othermaciej> | it is also more likely to be what you want to display to the user |
| 17:57 | <othermaciej> | though I guess Date already has format capabilities |
| 17:58 | <Hixie> | in this locale, at least |
| 17:58 | <Hixie> | in french locale, 7h20m10s is quite common |
| 17:58 | <Hixie> | at least for wallclock |
| 17:58 | <KevinMarks> | is the interval version of Date in javascript? |
| 17:58 | <othermaciej> | JavaScript Dates are absolute times, not time intervals |
| 17:59 | <othermaciej> | I don't think there is a way to represent a time interval, other than a number |
| 18:01 | <KevinMarks> | there is in 8601 iirc |
| 18:01 | hsivonen | tries not be too snide when replying to a message motivated by failure to comprehend Apple's lawyer talk |
| 18:01 | <hsivonen> | seriously, software and Web design people should learn to parse lawyer speak |
| 18:02 | <Hixie> | 8601 isn't a standard |
| 18:02 | <hsivonen> | this working around of patent ghosts where there's no reason to work around is silly |
| 18:02 | <KevinMarks> | http://www.faqs.org/rfcs/rfc3339.html |
| 18:02 | <KevinMarks> | then |
| 18:02 | <Hixie> | it's the result of a brainstorming session |
| 18:02 | <KevinMarks> | though that is only decimal seconds |
| 18:03 | <Hixie> | (i'm being facetious, but seriously, who the hell did 8601, it's ridiculous) |
| 18:03 | <KevinMarks> | yes, it is a bit overbroad |
| 18:04 | <KevinMarks> | rfc3339 is a more sensible subset |
| 18:13 | <Hixie> | ok, behold <audio>. |
| 18:13 | <hasather> | hehe: http://my.opera.com/hallvors/blog/2007/03/23/hp-com-no-clue-noscript |
| 18:14 | <hsivonen> | wow |
| 18:15 | <Hixie> | need to add looping then we can retire Audio() |
| 18:15 | <Hixie> | (with new Audio() creating an HTMLAudioElement instead) |
| 18:18 | <Hixie> | othermaciej? |
| 18:18 | <Hixie> | othermaciej: do you know the use case for loopStartTime/loopEndTime? |
| 18:19 | <Hixie> | i guess if your audio samples are from one file |
| 18:20 | <othermaciej> | Hixie: yeah, if you want multiple samples from one file; we also have the possibility of intro and outro besides the looping section but that might be excessive |
| 18:21 | <othermaciej> | but at least the lead-in can be useful for some background sound-effects |
| 18:21 | <othermaciej> | intro then loop |
| 18:21 | <Hixie> | true |
| 18:21 | <othermaciej> | loopEndTime is mainly for symmetry |
| 18:21 | <Hixie> | so should we have start/end, start/loopStart/end, or start/end/loopStart/loopEnd? |
| 18:22 | <Hixie> | or should we do looping simply by providing a cue point api |
| 18:22 | <Hixie> | and requiring people to do it themeselves? |
| 18:23 | <othermaciej> | programmatic looping is more likely to glitch |
| 18:23 | <Hixie> | audio.addCuePoint(93.3, function () { audio.seek(12.0); }); |
| 18:23 | <Hixie> | yeah |
| 18:23 | <Hixie> | true |
| 18:23 | <othermaciej> | especially if you are discarding buffers, or for audio |
| 18:23 | <othermaciej> | for audio especially even dropping one sample (at a very high sample rate) can audibly glitch |
| 18:23 | <Hixie> | yeah |
| 18:24 | <othermaciej> | CuePoint sounds like a better name than TimeTrigger (which is what we had) |
| 18:24 | <Hixie> | cool, i'll use CuePoint then (i think i have CueMark in the comments right now) |
| 18:24 | <Hixie> | how about semi-declarative cue points, as in audio.addAutoSeekCuePoint(99.3, 12.0) |
| 18:24 | <Hixie> | i guess that wouldn't do finite looping |
| 18:24 | <Hixie> | ok so we need something |
| 18:25 | <Hixie> | start/end/loopStart/loopEnd, i guess |
| 19:07 | <tylerr> | hsivonen: We need a <legal> tag that auto-parses. ;) |
| 19:09 | <hendry> | "Leading the Forefront - with IRC ! ?" lol |
| 19:10 | <tylerr> | :-) |
| 20:05 | <othermaciej> | good morning |
| 20:25 | <zcorpan_> | othermaciej: morning |
| 20:45 | <othermaciej> | hello zcorpan_ |
| 21:08 | <zcorpan_> | Hixie: there are three IDs "video" in the spec |
| 21:09 | <krijnh> | Still? |
| 21:10 | <zcorpan_> | yes |
| 21:17 | <zcorpan_> | "Perhaps not, but this will: applet { display: none !important; }" LOL |
| 21:31 | zcorpan_ | updated html5-elements |
