| 00:00 | <webben> | Lachy, I thought CSS was abstaining from defining how UAs should render form widgets |
| 00:01 | <Lachy> | http://www.w3.org/TR/css3-ui/ |
| 00:02 | <Lachy> | and also see Web Controls 1.0 |
| 00:02 | <webben> | Is there anything to indicate that Safari is likely to implement those? |
| 00:03 | <webben> | (I single out Safari for being the greatest stickler for native-looking widgets) |
| 00:04 | <Lachy> | no idea |
| 00:06 | <Dashiva> | Safari looks like the OS extension IE is ;) |
| 00:07 | <webben> | because if not ... people are likely to continue to use divs and spans |
| 00:07 | <webben> | especially as those work in IE6-7 |
| 00:07 | <Hixie> | safari does a lot of css3-ui already |
| 00:08 | <webben> | really? I'll have to try that out. (not that i particularly like styling widgets to look non-native, but oh well) |
| 00:16 | <Lachy> | http://www.quirksmode.org/blog/archives/2007/04/html_5.html (see comments 7 and 8) |
| 00:18 | Lachy | needs to blog about why xhtml2 is not the future |
| 00:59 | <deltab> | Lachy: it's the flying-car future |
| 08:37 | <annevk> | We could have a state= attribute on certain elements like <xbl:div state> |
| 08:37 | <annevk> | for scripts |
| 08:38 | <hsivonen> | would "private" conflict with ECMA reserved words? |
| 08:39 | <annevk> | iirc, yes |
| 08:40 | <annevk> | I'm not entirely convinced it's need though given XBL2 |
| 08:42 | <hsivonen> | http://www.w3.org/2007/uwa/ |
| 08:42 | <hsivonen> | how (in)applicable is Web Apps 1.0 when it comes to home monitoring and control, home entertainment, office |
| 08:42 | <hsivonen> | equipment, mobile and automotive |
| 08:42 | <hsivonen> | ? |
| 08:43 | <annevk> | I think that group is about putting device specific APIs into a generic framwork or something |
| 08:43 | annevk | isn't sure how that helps anyone |
| 08:57 | <hsivonen> | made a lot of progress: http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fsimon.html5.org%2Ftemp%2Fw3c-home-in-html5.html |
| 09:26 | <Hixie> | hsivonen: what are we looking for, progress wise? |
| 09:27 | <hsivonen> | Hixie: compared to the time when zcorpan pasted that URL here, there are a lot less incorrect error messages |
| 09:27 | <Hixie> | ah cool! |
| 09:27 | <hsivonen> | Hixie: I updated the schema layer |
| 09:42 | <MikeSmith> | hsivonen, annevk - the UWA WG is basically the Device Independece WG, renamed |
| 09:42 | <MikeSmith> | as far as what part of it might be applicable ... |
| 09:43 | <MikeSmith> | http://www.w3.org/2006/10/uwa-charter.html#dci |
| 09:43 | <MikeSmith> | http://www.w3.org/2006/10/uwa-charter.html#device-coordination |
| 09:44 | <annevk> | I didn't care much for their specs either |
| 09:47 | <MikeSmith> | annevk - some criticize them as being overengineered |
| 09:47 | <annevk> | yeah, though that goes for most of the W3C :) |
| 09:48 | <hsivonen> | http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fsimon.html5.org%2Ftemp%2Fw3c-home-in-html5.html |
| 09:48 | <hsivonen> | yay |
| 09:50 | <annevk> | the "conforming |
| 09:50 | <annevk> | message should be clearer |
| 09:51 | <MikeSmith> | annevk - perhaps so (about W3C). and perhaps more people are learning that or have learned it -- the hard way, by not seeing their specs get implemented more widely |
| 09:51 | <hsivonen> | annevk: intentional weasel words at this point :-) |
| 09:51 | <hsivonen> | annevk: or, rather, intentional in the parentheses |
| 09:52 | <hsivonen> | annevk: what would you suggest before the parentheses? |
| 09:53 | <Hixie> | i love the "valid html5" icon he made |
| 09:53 | <Hixie> | that's awesome |
| 09:53 | <annevk> | "Congratulations, your document is conforming HTML5" |
| 09:53 | <annevk> | or something |
| 09:53 | <annevk> | with some !!11! following it... |
| 09:57 | <annevk> | hsivonen, http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fannevankesteren.nl%2F I don't get the "bad value for attribute href" messages... |
| 09:57 | <annevk> | hsivonen, is that because my href has http:// at the start and @ somewhere in it? |
| 10:01 | <hsivonen> | annevk: the line numbers are weird. do you mix Unix and Windows line breaks? |
| 10:01 | <annevk> | maybe, dunno |
| 10:02 | <annevk> | I'm including some standalone files that may or may not have UNIX line endings... |
| 10:02 | <hsivonen> | anyway, TextWrangler and my parser have a different notion of line numbers |
| 10:03 | <hsivonen> | but yeah, chances are that @ is the problem |
| 10:03 | <annevk> | (use it as a testcase) |
| 10:03 | <annevk> | per HTML5 line endings shouldn't matter |
| 10:04 | <hsivonen> | either @ isn't allowed unescaped in HTTP IRIs or the IRI library has a bug in it |
| 10:05 | <hsivonen> | annevk: my parser should decide the nature of a line break on a line-by-line basis, but TextWrangler sniffs the top and assumes the same kind of line breaks throughout the file |
| 10:08 | <annevk> | time to update HTTP IRIs then :) |
| 10:08 | <hsivonen> | annevk: did you already figure out if it is a library bug or an RFC bug? |
| 10:09 | <annevk> | oh no |
| 10:10 | <hsivonen> | annevk: can't be just @. you have more than two instances of such IRIs |
| 10:11 | <annevk> | ipchar seems to allow a literal @ |
| 10:11 | <annevk> | what are the IRIs that trigger it? |
| 10:12 | <hsivonen> | annevk: I don't know, because the line numbers are all weird |
| 10:12 | <annevk> | the line numbers from the validator are correct? |
| 10:13 | <annevk> | ah, it's "irc://irc.w3.org:80/html-wg"; |
| 10:13 | <hsivonen> | annevk: hopefully. :-) |
| 10:13 | <hsivonen> | now, *that's* weird |
| 10:13 | <annevk> | and "irc://irc.freenode.net/whatwg"; |
| 10:14 | <hsivonen> | the library should apply generic IRI processing to irc: IRIs |
| 10:14 | <hsivonen> | and obviously those should be fine as far as the generic processing goes |
| 10:14 | <hsivonen> | irc on port 80? |
| 10:14 | <annevk> | yeah |
| 10:15 | <hsivonen> | firewall thing? |
| 10:15 | <Hixie> | and people tell _me_ off for misusing port 80. pah. |
| 10:15 | <annevk> | to work around certain firewalls that block on port rather than functionality |
| 10:16 | <hsivonen> | annevk: added to my todo list |
| 10:16 | <hsivonen> | annevk: thanks |
| 10:18 | <annevk> | it also complains about accesskeys and my doctype which apparently triggers quirks in an unused browser |
| 10:18 | hsivonen | expects a bug report email when the first person hits the transparent content model of <video> inside <figure> |
| 10:18 | <hsivonen> | annevk: are accesskeys in HTML5 already? |
| 10:19 | <Hixie> | hsivonen: yeah that's a bug |
| 10:19 | <Hixie> | in the spec |
| 10:19 | <annevk> | I suppose they aren't |
| 10:19 | <Hixie> | need to rework how <figure> works to allow <ol>s, though, so i'll fix it later |
| 10:19 | <annevk> | and <svg:svg> |
| 10:19 | <Hixie> | accesskeys aren't in because nobody has yet explained how to fix them |
| 10:20 | <hsivonen> | Hixie: <ol>s? |
| 10:20 | <Hixie> | and <ul>s, and <pre>, and whatever else people have argued should be figurable |
| 10:20 | <Hixie> | assuming we want to do that |
| 10:20 | <hsivonen> | oh |
| 10:22 | <annevk> | would <figure> <legend/> <object> <p>test </p> <p> test </p> </object> </figure> be ok? |
| 10:22 | <Hixie> | who are you asking? |
| 10:23 | <hsivonen> | annevk: IIRC, yes, provided that you put a required attribute on <object> |
| 10:23 | <annevk> | k |
| 10:24 | <hsivonen> | annevk: also, I haven't updated the significant inline stuff to deal with legend |
| 10:26 | <MikeSmith> | Hixie - what's broken about accesskey? |
| 10:28 | <Hixie> | what's not broken |
| 10:28 | <Hixie> | it has never been implemented in a usable way |
| 10:28 | <Hixie> | it isn't device independent |
| 10:28 | <Hixie> | it isn't i18n-compatible |
| 10:28 | <Hixie> | it isn't well specified |
| 10:29 | <annevk> | chaals claims Opera now has a somewhat useful impl |
| 10:29 | <Hixie> | shipped? |
| 10:29 | <Hixie> | does he mean the modal toggle? |
| 10:29 | <annevk> | yeah, I believe we expose the access keys of a page in a sidebar the user can invoke in some way |
| 10:29 | <annevk> | maybe |
| 10:29 | <Hixie> | steps to reproduce? |
| 10:30 | <annevk> | maybe later, haven't played with it myself |
| 10:32 | <Hixie> | well in opera 9.00 it isn't usable |
| 10:34 | <annevk> | ah, Shift+Esc |
| 10:34 | <annevk> | try that on my homepage for instance |
| 10:35 | <MikeSmith> | Hixie - I think it's implemented is some mobile browsers, including Openwave's browser, and very widely used in mobile-specific sites |
| 10:36 | <Hixie> | oh it's used |
| 10:36 | <Hixie> | but all uses suffer from the problems i described |
| 10:36 | <MikeSmith> | yeah, true |
| 10:36 | <Hixie> | it's not too bad in walled-garden device-specific scenarios |
| 10:36 | <Hixie> | but of course that's hardly what we care for here |
| 10:36 | <Hixie> | annevk: again, not usable |
| 10:37 | <Hixie> | anyway |
| 10:37 | <Hixie> | bed time |
| 10:42 | <annevk> | g'night |
| 10:53 | <MikeSmith> | unfortunate fact about accesskey as far as mobile users go is that because it is something that's so widely used in mobile sites, if a content provider wants to move his site from being a walled garden/WAP site to being a Web site, lack of accesskey support is basically a regression in application behavior as far as they are concerned |
| 10:53 | <MikeSmith> | or as far as users of their site will be |
| 10:54 | <MikeSmith> | that's true for inputmode too (which most non-WAP browsers don't support) |
| 10:57 | <MikeSmith> | at least here in Japan, sites use accesskey a lot, and users expect it on sites |
| 10:58 | <MikeSmith> | Konqueror has accesskey support |
| 10:59 | <MikeSmith> | if you press and release Ctrl, it shows tooltip text over each link, with letter of corresponding access key |
| 11:01 | <MikeSmith> | I think if a site doesn't provide accesskey info in the markup, Konq actually generates accesskeys for the page |
| 11:02 | <hasather> | MikeSmith: yea, that seems to be the case |
| 11:03 | <hasather> | wow, that's cool |
| 11:09 | <MikeSmith> | Konqueror has a lot nice features |
| 16:00 | <annevk> | zcorpan, <map> no longer has name= |
| 18:26 | <Philip`> | Since someone mentioned setTimeout: Mozilla passes the timeout handlers a ""secret" final argument that indicates timeout lateness in milliseconds". Is that already known, and is it at all relevant/interesting to anything, like whether it contradicts the spec and should be removed, or whether it should be adopted by the spec, or whether it's fine if nothing changes? |
| 18:34 | <othermaciej> | that's pretty weird |
| 18:39 | <deltab> | it's not mentioned on MDC |
| 18:44 | <Philip`> | http://lxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#6818 is the only place I've seen it mentioned |
| 18:46 | <gavin_> | I'm sure you'll be interested to know that that "secret argument" was in the original revision of nsGlobalWindow, 1.1 <kipp⊙nc> 1998-07-15 18:16 |
| 18:47 | <gavin_> | good luck on finding the reason why it was added! :) |
| 18:47 | <othermaciej> | does anything actually use it? |
| 18:48 | <othermaciej> | seems like checking the current time will almost always be better than a lateness value |
| 18:48 | <gavin_> | per rule #432, someone surely must :) |
| 18:49 | <gavin_> | it's relatively well hidden, though, so maybe we could remove it |
| 18:50 | <gavin_> | I'm not sure it's very useful |
| 18:52 | <deltab> | oh, it is mentioned on MDC, on a talk page: http://developer.mozilla.org/en/docs/Talk:DOM:window.setTimeout |
| 18:53 | <gavin_> | https://bugzilla.mozilla.org/show_bug.cgi?id=10637 has some background info |
| 18:54 | <gavin_> | "It was very useful to *us* at Netscape in performance testing of animation |
| 18:54 | <gavin_> | using intervals, since a script could detect when the CPU became saturated, i.e. |
| 18:54 | <gavin_> | the timeout lateness was increasing monotonically with each timeout." |
| 18:55 | <Dashiva> | A feature nobody knows about that was last used in NS4? |
| 18:56 | <deltab> | and that complicates bindings to non-JS languages |
| 19:24 | <Philip`> | According to bug 263945 it is "an underdocumented feature", which seems like an understatement since the only documentation is the source code and the comments on two bug reports |
| 21:32 | <hsivonen> | http://wiki.whatwg.org/wiki/Video_type_parameters in case anyone cares to continue |
| 21:33 | <Hixie> | cool, thanks |
| 21:34 | <annevk> | ouch |
| 21:34 | <annevk> | looks amazingly complicated |
| 21:35 | <Hixie> | welcome to video |
| 21:35 | <annevk> | when I was welcomed there was <video>, three methods and a couple of .ogg files :) |
| 21:35 | <Hixie> | hehe |
| 21:37 | <hsivonen> | frankly, I think the codec RFC is way too hard for authors. if the codecs parameters is supposed to work, we need sniffer tools that take a file and print out the appropriate MIME type with the codecs parameter |
| 21:38 | <hsivonen> | annevk: and I'm only covering sane and contemporary container/codec combos... |
| 21:38 | <annevk> | hopefully we just have <video src=blah> for the majority of cases |
| 21:39 | <annevk> | maybe the wiki page should document the signature of the files as well? |
| 21:39 | <hsivonen> | annevk: feel free to edit. I'm never fully grokked how MP4-derived magic numbers are supposed to work |
| 21:40 | <Hixie> | i'm not a fan of the rfc either |
| 21:40 | <Hixie> | but do we have something better? |
| 21:41 | <annevk> | RFC42815 |
| 21:41 | <Hixie> | ? |
| 21:41 | <hsivonen> | Hixie: nothing better that all the relevant vendors would agree to, no |
| 21:41 | <annevk> | Hixie, last digit |
| 21:41 | <Hixie> | what do you have that's better which vendors wouldn't agree to? |
| 21:41 | <Hixie> | annevk: ? |
| 21:41 | <annevk> | Hixie, oh, and it's a joke |
| 21:42 | <hsivonen> | Hixie: mandated Ogg :-) |
| 21:42 | <annevk> | and RFC4281 is the current RFC |
| 21:42 | <Hixie> | annevk: oh i see |
| 21:42 | <Hixie> | annevk: well even for that, we'd have to have something better to put _in_ that spec |
| 21:42 | <annevk> | fair enough |
| 21:42 | <Hixie> | hsivonen: no i mean for codec description. even if we mandate codec support, we can't disallow other codecs. |
| 21:42 | <Hixie> | hsivonen: so ogg doesn't solve this problem. |
| 21:43 | <annevk> | and we want authors to be able to provide multiple versions? |
| 21:43 | <hsivonen> | Hixie: I know. but having one true codec would. but not gonna happen |
| 21:43 | <Hixie> | christ, people in the csswg again trying to open new issues in things that aren't problems. |
| 21:44 | <Hixie> | hsivonen: one true codec would not ever be a solution. there's no one codec that solves all problems. e.g. a codec that's good for screencaps isn't going to be good for slow moving video. |
| 21:44 | <Hixie> | if there's a solution that really is better than 4281, i'm open to it |
| 21:45 | <annevk> | so the answer to my question is yes? |
| 21:45 | <Hixie> | yes |
| 21:45 | <othermaciej> | hsivonen: now that I know more about it, it does sound way too hard |
| 21:45 | <Hixie> | we'll be adding a media="" attribute to <source> anyway |
| 21:45 | <Hixie> | which takes a media query |
| 21:45 | <hsivonen> | Hixie: well, killing all the ISO profiles and using plain FourCCs in as codec identifiers would make things easier. but not gonna happen, either |
| 21:46 | <hsivonen> | s/in as/as/ |
| 21:46 | <Hixie> | hsivonen: why wouldn't it happen? (i have no idea what FourCC is) |
| 21:46 | <annevk> | Hixie, based on the beforeprint discussion? |
| 21:46 | <othermaciej> | hsivonen: the codecs need to have comprehensible names |
| 21:46 | <Hixie> | annevk: ? no |
| 21:46 | <othermaciej> | FourCC is a four-character code |
| 21:46 | <annevk> | Hixie, a use case for that came up there |
| 21:46 | <Hixie> | annevk: onbeforeprint will be added in due course. |
| 21:46 | <hsivonen> | Hixie: because ISO has gone profile-crazy. too late to undo it, I think |
| 21:46 | <Hixie> | hsivonen: ah |
| 21:46 | <Hixie> | hsivonen: well if you have any solutions that actually would work, let me know :-) |
| 21:47 | <hsivonen> | Hixie: a FourCC is a four-character identifier that you put in a container to identify the type of a data stream |
| 21:47 | <annevk> | actually, if media="" is added to source you might want to add start end, etc. to <source> as well |
| 21:47 | <annevk> | so for non interactive media you can start at a specific location |
| 21:47 | <Hixie> | annevk: we're not trying to encourage different media being seent, if they have different timelines that's bad |
| 21:47 | <hsivonen> | Hixie: so FourCC is kind of like an intra-file magic or HFS type code |
| 21:48 | <annevk> | or show a specific frame, so to say (which is the use case that came up) |
| 21:48 | <Hixie> | annevk: oh you're misunderstanding. this wouldn't be for screen vs print. it would be for highres vs lowres, or b&w vs color, etc |
| 21:48 | <Hixie> | hsivonen: ah |
| 21:48 | <annevk> | Hixie, k |
| 21:49 | annevk | goes to read the RFC |
| 21:49 | <hsivonen> | If I had the power to fix MPEG-4, I'd have two video codecs: Visual Simple Profile without any levels or subprofiles and H.264 without any levels or subprofiles |
| 21:50 | <Hixie> | hsivonen: so would you also introduce a new version every year as hardware improved? |
| 21:51 | <hsivonen> | Hixie: At least I'd give the new version a different marketing name and FourCC instead of defining it as an Advanced Extended High 10:2:2 profile level 5.2 of something pre-existing |
| 21:52 | <Hixie> | fair enough |
| 21:52 | <Hixie> | so we'd have H.264, H.265, H.266, etc? |
| 21:52 | <hsivonen> | Hixie: for example |
| 21:52 | <Hixie> | makes sense |
| 21:52 | <Hixie> | oh well |
| 21:52 | <Hixie> | sadly we are not the ISO |
| 21:54 | <gsnedders> | MPEG-5 anyone? :P |
| 21:54 | <Hixie> | that's one that i will definitely NOT be ever doing |
| 21:55 | gsnedders | has absolutely no clue about the technical details of codecs |
| 21:56 | <annevk> | at some point bandwidth will be less of an issue and all the linked files can simply be inspected... |
| 21:57 | <Hixie> | i doubt that point will come any time soon |
| 21:57 | <Hixie> | at least not in the next two or three decades |
| 21:59 | <annevk> | isn't the required data not in the first few KiBs? |
| 22:00 | <Hixie> | now scale that up by a billion and imagine what it would do to a site like youtube. |
| 22:01 | <Philip`> | Would latency still be an issue, even if the bandwidth is insignificant? |
| 22:01 | <Hixie> | that too |
| 22:02 | <hsivonen> | what annevk said is more likely to work, though, than requiring authors to write codec identifiers |
| 22:02 | <Philip`> | (unless you had a server-side script that quickly inspected all the files and then told the browser what they all were) |
| 22:03 | <hsivonen> | I wouldn't dismiss magic-based sniffing and HTTP request closing as crazy when type parameters aren't available |
| 22:03 | <hsivonen> | YouTube has staff to figure out RFCs |
| 22:03 | <Hixie> | i don't think this will be used much on sites that don't have staff. |
| 22:03 | <Hixie> | if you don't have staff, you'll likely just use one file. |
| 22:04 | <hsivonen> | Hixie: that's true |
| 22:04 | <hsivonen> | though I don't have staff and I've provided dual videos: Theora and H.264 |
| 22:05 | <Hixie> | that's an easy one |
| 22:05 | <Hixie> | don't even need codec="" for that |
| 22:05 | <hsivonen> | right |
| 22:05 | <hsivonen> | actually, you do |
| 22:05 | <Hixie> | why? just stick ogg first |
| 22:05 | <hsivonen> | what if Ogg contains Dirac and the UA supports Theora and H.264? |
| 22:06 | <Hixie> | nobody supports dirac. it's not even done yet. |
| 22:06 | <hsivonen> | or, rather, how's the UA going to know that the Ogg file contains Theora, not Theora |
| 22:06 | <Hixie> | and why would you put dirac in an ogg container? |
| 22:06 | <annevk> | because authors are silly? |
| 22:06 | <hsivonen> | Hixie: I thought the plan was to put Dirac in Ogg |
| 22:06 | <Hixie> | oh. |
| 22:07 | <Hixie> | well then you use the codec value |
| 22:07 | <Philip`> | http://wiki.xiph.org/index.php/OggDirac |
| 22:07 | <ericcarlson> | I don't think this will really be such a big issue for authors |
| 22:07 | <hsivonen> | Hixie: does that mean that you are going to define default codecs for containers? |
| 22:07 | <annevk> | can't you have other things inside Ogg as well? |
| 22:07 | <Hixie> | i'm open to better schemes, but requiring the browser to sniff the data stream is simply not a workable solution. |
| 22:07 | <Hixie> | hsivonen: i'll probably put your wiki page in the spec in due course (or refer to it), but i'd rather just have a better solution. |
| 22:08 | <hsivonen> | ericcarlson: I think it will be. How do I even figure out what AVC level QuickTime made when I encode? |
| 22:09 | <ericcarlson> | People compressing media for the web export to a "profile" so they |
| 22:09 | <ericcarlson> | know a class of user/devide will be able receive and decode it |
| 22:09 | <annevk> | another problem with those codec= stuff is that authors will just copy and paste it and change the src= value and sometimes it will work and sometimes it won't (though arguably this is a minor issue) |
| 22:09 | <ericcarlson> | When exporting you choose the profile, and that defines the parameters passed to the encoder |
| 22:09 | <hsivonen> | ericcarlson: OK, if I check Baseline in QuickTime, how do I figure out what to put in the AVC level "xx" placeholder in Dave Singer's email? |
| 22:10 | <Hixie> | for the people arguing that the current type="" codec= RFC4281 solution is bad: i agree. giving more reasons why it's not an optimal solution is not required. What's required is a more optimal solution. |
| 22:10 | <ericcarlson> | and it defines the characteristics of the file that comes out the other end (bitrate, B-frames or not, size, etc) |
| 22:11 | <hsivonen> | Hixie: I'm not arguing why it is bad. I'm trying to discover useful data that authors will need when they use it. |
| 22:11 | <Hixie> | i was mostly talking to anne :-) |
| 22:11 | Hixie | would like to know the answer to your question too |
| 22:11 | <hsivonen> | ericcarlson: How do I map QuickTime export dialog values to the RFC indentifiers? |
| 22:15 | <ericcarlson> | hsivonen: which dialog values? |
| 22:15 | <hsivonen> | Movie to MPEG-4, Options... |
| 22:16 | <Hixie> | ericcarlson: if he checks Baseline in QuickTime, how can he figure out what to put in the AVC level "xx" placeholder in Dave Singer's email? |
| 22:16 | <hsivonen> | dialog titled MPEG-4 Export Settings |
| 22:17 | <hsivonen> | ericcarlson: there's no setting for AVC level |
| 22:17 | <ericcarlson> | That information has to come out of the encoded file, so someone (me ;-) will have to write a utility |
| 22:17 | <hsivonen> | ericcarlson: ok :-) |
| 22:17 | <Hixie> | ew |
| 22:18 | <hsivonen> | presumably Movie to iPod will lower the AVC level to a magic value (still without telling me) |
| 22:19 | <ericcarlson> | Yes, but the level is chosen for you based on the "dial-able" parameters. |
| 22:20 | <ericcarlson> | hsivonen: Yes, any preset that doesn't allow any parameter tweaking will be fixed. |
| 22:23 | <Hixie> | i'm about to check in a big set of media/video/audio changes, if anyone wants to give it a look-see while i go grab some food to see if there are any mistakes, i'll fix them before checking in |
| 22:23 | <Hixie> | page will be genned in about 60 seconds |
| 22:24 | <annevk> | some of my reported bugs haven't yet been fixed |
| 22:24 | <annevk> | no apparent visual bugs though |
| 22:29 | <Hixie> | oh? |
| 22:29 | <annevk> | HTMLSourceElement member names in the IDL |
| 22:29 | <annevk> | haven't checked others |
| 22:29 | <Hixie> | ooh, good catch |
| 22:30 | <annevk> | attribute float currentLoop -> unsigned long currentLoop |
| 22:30 | <Hixie> | cool |
| 22:30 | <Hixie> | any others? |
| 22:31 | <annevk> | not right away |
| 22:31 | <Hixie> | hm, i forgot to define seekable |
| 22:31 | <ericcarlson> | I don't see anything obvious |
| 22:32 | <annevk> | in that case, you also forgot to define some events such as volumechange |
| 22:32 | <ericcarlson> | Well, "position" still doesn't have the right name. |
| 22:32 | <Hixie> | yeah name changes and events are next |
| 22:32 | <ericcarlson> | OK |
| 22:32 | annevk | wonders what's wrong with position |
| 22:33 | <Hixie> | apple prefers currentTime, and nobody has argued anything else |
| 22:33 | <annevk> | currentTime is hard to type |
| 22:33 | annevk | misspelled it while typing it in, even! |
| 22:33 | <Hixie> | true, i often type it as currenTTime |
| 22:34 | <annevk> | I forgot the first t |
| 22:34 | <Hixie> | ericcarlson: what were the arguments for currentTime and against position, again? |
| 22:35 | <ericcarlson> | It is a temporal property, and "position" doesn't really have meaning in the time domain. |
| 22:35 | <othermaciej> | Hixie: "position" is more vague and sounds like it would be spacial, not temporal |
| 22:35 | <Hixie> | ah yes, there you go |
| 22:36 | <annevk> | I suppose "location" has the same issues? |
| 22:36 | <annevk> | maybe more |
| 22:36 | <othermaciej> | location sounds like it should be a URL |
| 22:36 | <Hixie> | even worse, yeah |
| 22:36 | <Hixie> | btw did we say that seeking to outside the current loop boundaries should clamp? |
| 22:37 | <ericcarlson> | I think it should |
| 22:37 | <ericcarlson> | For whatever that is worth. |
| 22:37 | <annevk> | and how about position -> time, currentLoop -> loop |
| 22:38 | <Hixie> | that might work |
| 22:38 | <ericcarlson> | "loop" sounds like a boolean |
| 22:40 | <ericcarlson> | The video element still fills with black |
| 22:41 | <Hixie> | i haven't done any of the changes from our lunch |
| 22:41 | <othermaciej> | time might be doable though it is a little more vague |
| 22:41 | <annevk> | what should it be? transparent black? |
| 22:41 | <Hixie> | annevk: should just use css background |
| 22:41 | <annevk> | makes sense |
| 22:42 | <Hixie> | though i think we should have video { background: black } in the UA stylesheet |
| 22:42 | <Hixie> | personally |
| 22:42 | <Hixie> | but that might just be me |
| 22:43 | <ericcarlson> | sounds good for a page with a black background :-) |
| 22:45 | <annevk> | I still think .position is a good pick as everybody will understand what it means and it's way easier to remember and type than .currentTime |
| 22:45 | <Philip`> | Is it possible for the video content to be (semi-)transparent, so you'd need that background colour behind the video rather than just in the areas that don't contain the video? |
| 22:45 | <Hixie> | jesus, just this update to use the new states rather than the old state system is a 2000 line patch |
| 22:46 | <Hixie> | Philip`: if you count animated gifs as video, i guess |
| 22:46 | <othermaciej> | Philip`: there are such things as codecs with alpha |
| 22:46 | <annevk> | Philip`, it's possible with Flash |
| 22:46 | <annevk> | prolly also with FLV |
| 22:47 | <annevk> | Hixie, I suppose it's less than 2000 for /source? |
| 22:47 | <Hixie> | no that was /source :-/ |
| 22:47 | <Philip`> | Okay - I just saw the currently-online version talks about "Areas of the element's playback area that do not contain the video should be filled with pure black", which doesn't seem to cover that case, though I don't know if that's been changed already |
| 22:48 | <Hixie> | it's going to change |
| 22:48 | <Hixie> | but later |
| 22:48 | <Hixie> | :-) |
| 22:48 | <othermaciej> | compositing onto the (possibly transparent) background seems like the right thing for alpha codecs |
| 22:49 | <Hixie> | yeah |
| 22:49 | <annevk> | HTMLSourceElement is still not changed fwiw |
| 22:49 | <Hixie> | haven't regenned yet |
| 22:49 | <annevk> | (I say this because currentLoop is) |
| 22:49 | <Hixie> | oh |
| 22:49 | <Hixie> | wait, what? |
| 22:49 | Hixie | looks again |
| 22:49 | <Hixie> | oh, there was more broken than i thought |
| 22:49 | <Hixie> | oops |
| 22:50 | <Hixie> | oh heh |
| 22:50 | <Hixie> | i fixed it the wrong way -_- |
| 22:50 | <KevinMarks> | I've said for a while that Apple needs to invent a marketing name for h264 |
| 22:50 | <KevinMarks> | they're good at that |
| 22:50 | <othermaciej> | iCodec |
| 22:50 | <othermaciej> | (or Final Codec Pro?) |
| 22:51 | <KevinMarks> | Pixlet Pro? |
| 22:51 | <annevk> | iVideo |
| 22:51 | <KevinMarks> | AVC/H264 is such a non-Apple name |
| 22:51 | <SimonW> | hi all... I'm putting together a "what the heck is HTML 5" talk for a local geek event here in Oxford... is there anywhere online that explains the implications of the Apple <canvas> patent e-mail? |
| 22:51 | <KevinMarks> | especially as the original QT codec from 1990 was called AVC |
| 22:51 | <SimonW> | or is it safe to just ignore that bit? |
| 22:52 | <annevk> | Some people explained it to me mean that when <canvas> goes to the W3C Apple will play nicely |
| 22:52 | <annevk> | But I'm no lawyer |
| 22:52 | <Hixie> | SimonW: i'd ignore it and then if you get a question about it just say that now the work is under the patent policy at w3c, there's no problem. |
| 22:53 | <SimonW> | cool, shall do |
| 22:53 | <Philip`> | http://tech.groups.yahoo.com/group/canvas-developers/message/371 has a comment |
| 23:20 | <Hixie> | right that's checked in |
| 23:20 | <annevk> | Hixie, I suppose you want a feature that turns that commit log into a <ul> or something? |
| 23:21 | <Hixie> | hah no |
| 23:21 | <Hixie> | i hope i never check in so much at once again |
| 23:22 | <Hixie> | oh wow it feels so much better to not have such a huge checkin pending |
| 23:35 | <annevk> | it should prolly be defined when an element is in a document |
| 23:35 | <annevk> | for <source> |
| 23:36 | <annevk> | another thing that seems to be lacking is requirements on what happens when a media element is inserted or removed |
| 23:36 | <Hixie> | it's there |
| 23:36 | <annevk> | <source> causes implicit loading, but <video src> doesn't seem to do so |
| 23:36 | <Hixie> | yes it does |
| 23:36 | <Hixie> | it's there somewhere |
| 23:37 | <Hixie> | i wrote it! i swear! |
| 23:37 | <Hixie> | :-) |
| 23:37 | <Hixie> | "in a document" is a problem i don't want to look at too closely yet |
| 23:37 | <Hixie> | "If a media element whose networkState has the value EMPTY is inserted into a document, user agents must implicitly invoke the load() method on the media element as soon as all other scripts have finished executing. Any exceptions raised must be ignored." |
| 23:38 | <annevk> | i see |
| 23:38 | <annevk> | cheers |
| 23:53 | <ianloic> | hey |
| 23:53 | <ianloic> | if we want to expose functionality in our user agent that doesn't match any existing APIs what should we do? |
| 23:53 | <ianloic> | right now we're planning on just exposing a global object |
| 23:54 | <Hixie> | depends on the api |
| 23:54 | <ianloic> | I'm trying to work out the Right way to expose events. |
| 23:54 | <Hixie> | whatever you do make sure to prefix the api names with the name of your vendor |
| 23:54 | <Hixie> | what's the api, if i may ask? |
| 23:54 | <ianloic> | well, we're a music player - initially it'll be play/pause/playURL and an interface to get the currently playing track |
| 23:55 | <ianloic> | later it'll be richer integration |
| 23:55 | <ianloic> | (this is in Songbird) |
| 23:55 | <Hixie> | sounds like something for Window, yeah. You probably want window.songbirdPlay(), or window.songbird.play(), etc al |
| 23:55 | <Hixie> | et al, even |
| 23:56 | <ianloic> | the goal is to allow web sites to implement something with the functionality of the iTunes music store, or Pandora against your own library or applications like that |
| 23:56 | <ianloic> | we'd ideally like to produce something that could be adopted by other vendors. I'm a little hesitant to push our product name into the API |
| 23:57 | <Hixie> | (using your vendor name is important to prevent future official apis from clashing with you, and giving you problems) |
| 23:57 | <Hixie> | once you have implementation experience, you would come to a standards organisation and propose it as a standard api |
| 23:57 | <Hixie> | and it would change in incompatible ways, probably |
| 23:58 | <Hixie> | at which point you'd be screwed if you hadn't used vendor prefixes first |
| 23:58 | <ianloic> | true dat |
| 23:59 | <ianloic> | I just resubscribed to the whatwg list since there seems to be a bunch of audio/video work going on and we have some different requirements/interests in that than a normal browsery user agent |
| 23:59 | <Hixie> | your input would be very welcome |
| 23:59 | <ianloic> | Hixie, so where would you attach events? To the window? |