| 00:00 | <othermaciej> | now I have to read the backlog of old <video> feedback and read the spec more closely |
| 00:00 | <othermaciej> | fun, fun |
| 00:01 | <othermaciej> | not sure if I should start any additional threads just yet, or let people digest the proposal first |
| 00:02 | <othermaciej> | but I did want to comment on some specific points, like "why <audio>" and the issue of codecs |
| 00:02 | <Hixie> | i recommend reading the spec rather than the entire 200+ threads of feedback |
| 00:02 | <Hixie> | or at least first :-) |
| 00:03 | <othermaciej> | I skimmed it already |
| 00:04 | <zcorpan_> | from the list, reading hixie's replies should be sufficient i think |
| 00:04 | <othermaciej> | I mainly ready hixie's and howcome's messages |
| 00:04 | <Hixie> | heh |
| 00:04 | <Hixie> | my replies reply to all the other mails, so yeah, they should cover the salient points |
| 00:07 | <Hixie> | othermaciej: how would you like feedback on these proposals? (most of the suggested features are either already in the draft, or have been left out for specific reasons, or have been left out for simplicity's sake but are on the v2 list) |
| 00:08 | <othermaciej> | Hixie: well, I don't know what "v2" is |
| 00:08 | bewest | witholds snarky comments |
| 00:09 | <Hixie> | v2 features are the set of features that would be considered once v1 (the current <video> spec) is more widely implemented |
| 00:09 | <othermaciej> | Hixie: is "v2" post-HTML5, or "I'll get to this later"? |
| 00:09 | <Hixie> | depends on the rate of adoption. <canvas> for example is already on v2. |
| 00:09 | <Hixie> | (canvas has a bunch of features in the spec that weren't in the original spec) |
| 00:09 | <othermaciej> | cause we want to implement about this feature-set and then some, and would not find staging what is in the spec helpful |
| 00:10 | <othermaciej> | yeah, we haven't implemented most of the v2 things |
| 00:10 | <othermaciej> | I'm sure we will have feedback on it when we attempt that |
| 00:10 | <Dashiva> | Do you mark sections as v2, or is it just a vague label? |
| 00:10 | <Hixie> | thing is i fear that if we spec too much in one go, we'll lose the other browsers to lack of interoperability when they balk at the feature set and each do their own small parts |
| 00:11 | <othermaciej> | well, let's see what they actually say |
| 00:11 | <Hixie> | Dashiva: (for video, there's a list in the spec source (as a comment) listing the features to consider for v2) |
| 00:11 | <bewest> | it's also hard to respond to authors who aren't yet using it |
| 00:11 | <othermaciej> | many of these features are there to make it at least as good as the QuickTime plugin or Flash video for various uses |
| 00:11 | <Hixie> | Dashiva: (but in general we're looking -- zcorpan_ and Charl are implementing this -- at making the spec describe how well things are being implemented) |
| 00:11 | <Hixie> | othermaciej: sure |
| 00:12 | <othermaciej> | anyway, we can implement more stuff than is in the spec, but then we would have to keep our own spec for that |
| 00:12 | <Hixie> | yeah |
| 00:12 | <Hixie> | i'm just scared of adding too much at once and seeing the whole thing be ignored by other vendors |
| 00:13 | <othermaciej> | well, we can ask the relevant people from Mozilla and Opera if a subset would be necessary and if so how to express it |
| 00:13 | <othermaciej> | (and Microsoft when/if this makes it to the HTML WG) |
| 00:14 | <othermaciej> | timed media is a complex area, unfortunately |
| 00:14 | Hixie | changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!' |
| 00:14 | <Hixie> | yeah |
| 00:14 | <othermaciej> | but we do have a lot of experts in the area |
| 00:14 | <Dashiva> | We get to keep our patents now? |
| 00:14 | <othermaciej> | and if you want to speak to some of them in person that can probably be arranged too |
| 00:14 | <Hixie> | othermaciej: so does google ;-) (the current spec is based a lot on feedback from our various video groups) |
| 00:15 | <Dashiva> | Has anyone expressed concern with the openness of the video yet? |
| 00:17 | <othermaciej> | Hixie: well, I don't know of Google having anything comparable to QuickTime or Final Cut Pro or iMovie or iTunes, although of course YouTube and Google Video are very popular and important services to consider |
| 00:18 | <Hixie> | well, youtube video player, google video player, and google video ads player are all media players :-) |
| 00:18 | <Hixie> | but yes, google is more on the content side than the UA side |
| 00:18 | <Hixie> | both are important of course |
| 00:19 | <othermaciej> | I'm not saying it's required, but if you want to ever discuss in person, I can arrange it |
| 00:19 | <othermaciej> | that is all |
| 00:19 | <othermaciej> | up to you whether you avail yourself of the offer |
| 00:19 | <Hixie> | cool |
| 00:20 | <othermaciej> | we met a lot in person to hammer out the spec as-is, and many times it was more effective than email |
| 00:20 | <Hixie> | sure |
| 00:20 | Hixie | needs to work out how the proposal and the current spec differ before knowing whether he has anything to ask |
| 00:21 | <othermaciej> | I need to do that as well |
| 00:35 | <othermaciej> | it probably would have been more helpful to you if we'd posted it as suggested changes, but it would have taken a long time to rewrite it and it took way too long as it is |
| 00:35 | <Hixie> | no worries |
| 00:36 | <Hixie> | let me know if i miss anything when i reply, though |
| 00:37 | <othermaciej> | it's also probably not the highest quality in terms of formally correct spec language |
| 00:38 | <Hixie> | actually getting sample specs is no problem, the bigger problem is getting sample specs that try to cater for every little detail (i.e. sample specs that are actually proper specs), because then integrating the proposals with the "real" spec is a lot more work |
| 00:38 | <zcorpan_> | autoplay: "If the attribute is present, the user agent must begin playing the element as soon as it estimates that playback will not be interrupted to rebuffer.", that's something i didn't think about, just invoking play() ASAP would possibly result in the video being interrupted (unless play() also waits in the same way) |
| 00:38 | <Hixie> | so i'm actually happier when it's not formally correct language :-) |
| 00:38 | <Hixie> | zcorpan_: play() works the same way, see the spec |
| 00:38 | <Hixie> | zcorpan_: if there's not enough data, the UA will just switch to AUTO_PAUSED and wait |
| 00:38 | <zcorpan_> | ok |
| 00:39 | <othermaciej> | in our proposal, play() works when the element is playable at all, not when it estimates it will be able to play all the way through |
| 00:39 | <Hixie> | (or at least, it's allowed to) |
| 00:39 | <othermaciej> | (PLAYABLE vs. PLAYTHROUGHOK state) |
| 00:39 | <Hixie> | yeah maybe we could have a playForce() or something |
| 00:39 | <othermaciej> | I think that is how you expect a play button to work, so play() should in fact do that |
| 00:40 | <Hixie> | that's the best argument i've heard for autoplay="" so far |
| 00:40 | <othermaciej> | the one that only plays when you can get to the end would be the more obscure case, but you could just listen to the relevant event and call play() |
| 00:41 | <Hixie> | yeah |
| 00:43 | <Hixie> | i'm confused about how the startTime/endTime and other interface things are supposed to interact with the equivalents in css |
| 00:43 | <zcorpan_> | "The height attribute on the element does not include the size of the controller, it is the size of the video element only." does this imply that the ui is above or below the element? what about width=""? |
| 00:43 | <othermaciej> | I don't think we wrote that up well enough but the intent is that the API is linked to presentational attributes which interact with CSS in the usual presentational attribute way |
| 00:44 | <othermaciej> | zcorpan_: same is intended to apply for width, the idea is just that it excludes the area of the controls |
| 00:44 | <othermaciej> | so you can size your video without worrying about how each UA might do the UI for controls |
| 00:44 | <Hixie> | othermaciej: so you can end up in situations where play() doesn't play because CSS is overriding it? |
| 00:44 | <Hixie> | that seems confusing |
| 00:44 | <othermaciej> | Hixie: adding play-state to CSS was a last-minute thing which I am not sure makes sense |
| 00:45 | <Hixie> | ah ok |
| 00:45 | <othermaciej> | I dunno if the whole design for how these things interacts works just yet, as I said, it was kind of a work in progress |
| 00:45 | <othermaciej> | apologies for things being somewhat sloppy |
| 00:45 | <Hixie> | no worries |
| 00:45 | <Hixie> | are currentRate and playRate both supposed to be mutable? |
| 00:47 | <othermaciej> | I think so, although it is a bit confused and I am not sure both are necessary |
| 00:47 | <othermaciej> | you can set currentRate to 2.0 and the video plays at double speed |
| 00:49 | <othermaciej> | but if playRate is still 1.0, then when you hit play() you play at normal speed |
| 00:49 | <othermaciej> | (i.e. currentRate goes back to 1.0) |
| 00:49 | <Hixie> | sounds like something you'd want to implement on top of a simpler API... we don't want the API to be too biased towards a particular UI |
| 00:49 | <zcorpan_> | internet radio. an obvious use-case for <audio>. never thought about that before |
| 00:50 | <Hixie> | (same reason current spec doesn't have mute as well as volume) |
| 00:50 | <Hixie> | zcorpan_: would you do internet radio by going to a web site in your browser? |
| 00:50 | <Hixie> | seems like you'd be better off doing that using a media player. |
| 00:50 | <othermaciej> | if you don't have mute as well as volume, you have to remember the old volume |
| 00:50 | <Hixie> | othermaciej: depends on the mute UI |
| 00:50 | <zcorpan_> | Hixie: yes, i know lots of sites that offer internet radio in a popup via some plugin |
| 00:50 | <Hixie> | zcorpan_: freaky |
| 00:50 | <Hixie> | but interesting |
| 00:51 | <othermaciej> | well, at least some mute UIs leave volume control around while muted |
| 00:51 | <Hixie> | yup |
| 00:51 | <Hixie> | you can implement those on top of a simple volume attribute |
| 00:52 | <othermaciej> | you can, although that makes it hard for multiple controllers dealing with the element (one UI and one maybe something else) from working together without making special arrangements to handle mute |
| 00:53 | <othermaciej> | this is also the reason we added events for all the possible kinds of state changes |
| 00:53 | <Hixie> | yeah the spec could do with more events, that i agree with |
| 00:53 | <Hixie> | onended and onvolumechange are things that we should add in v1, imho, i just haven't gotten around to it |
| 00:59 | <othermaciej> | hey KevinMarks |
| 00:59 | <KevinMarks> | hello |
| 01:04 | othermaciej | is reading rfc4281 now, it's not exactly pretty syntax |
| 01:04 | <Hixie> | yeah really |
| 01:04 | <othermaciej> | but at least it's unambiguous |
| 01:05 | <Hixie> | just sent a reply to your mail covering the main points |
| 01:05 | <Hixie> | at least, the main ones i saw |
| 01:06 | <KevinMarks> | dang, now I need ot reply to both of you... |
| 01:06 | <othermaciej> | that was quick |
| 01:06 | <Hixie> | i was basically idling waiting for your mail this afternoon :-) |
| 01:07 | <othermaciej> | sorry it took so long, approval can be a long process |
| 01:07 | <Hixie> | oh don't worry |
| 01:07 | <Hixie> | i did a bunch of administrivia stuff i've been waiting to have time to do |
| 01:10 | <Hixie> | hey hyatt |
| 01:10 | <dhyatt> | hi |
| 01:12 | <dhyatt> | "The "mute" feature is IMHO better left at the UI level, with the API |
| 01:12 | <dhyatt> | only having a single volume attribute. This is because there are |
| 01:12 | <dhyatt> | multiple ways to implement muting, and it seems better to not bias the |
| 01:12 | <dhyatt> | API towards a particular method." |
| 01:12 | <dhyatt> | i disagree |
| 01:12 | <dhyatt> | :) |
| 01:12 | <dhyatt> | here are some reasons: |
| 01:12 | <dhyatt> | (1) you may want to style controls or video differently when muted |
| 01:13 | <dhyatt> | (this is a distinct state from just having the volume turned all the way down) |
| 01:13 | <dhyatt> | (2) your volume control should not suddenly jump to 0 just because you are muted |
| 01:13 | <dhyatt> | (and forcing a volume control to have to account for muting and "lie" about its volume position seems suboptimal) |
| 01:17 | <zcorpan_> | agreed, fwiw |
| 01:17 | <Hixie> | i agree in the cases where your mute control actually does want to act independent of the volume |
| 01:17 | <othermaciej> | having a mute API also does not preclude having a mute-as-volume-0 UI |
| 01:17 | <Hixie> | but consider the case where your ui doesn't have a separate mute button |
| 01:17 | <othermaciej> | or a UI with no separate mute button |
| 01:17 | <Hixie> | and someone mutes it somehow (e.g. through the ua ui when fullscreen) |
| 01:18 | <Hixie> | you can no longer unmute, and the volume control has no effect |
| 01:18 | <Hixie> | but yeah, that seems weak |
| 01:18 | <othermaciej> | you could make a volume slider that always unmutes when you move it as well as changing volume |
| 01:18 | <dhyattDinner> | well having mute doesn't preclude someone from doinig muting using volume |
| 01:18 | <dhyattDinner> | but muting simplifies things |
| 01:18 | <Hixie> | yeah i think you guys have convinced me |
| 01:18 | <dhyattDinner> | if it's a separate state imo |
| 01:19 | <dhyattDinner> | ok going to stop leaving my cooking unattended |
| 01:19 | <dhyattDinner> | so i don't catch my kitchen on fire :) |
| 01:20 | <Hixie> | hehe |
| 01:24 | <zcorpan_> | http://www.sitepoint.com/forums/showthread.php?t=467068#post3327983 |
| 01:27 | <Hixie> | ok added video.muted to the spec |
| 01:28 | <Hixie> | should we just have 'volumechange', or should we have both 'volumechange' and 'mutechange'? |
| 01:28 | <Hixie> | (and why?) |
| 01:30 | <zcorpan_> | you could listen for mutechange and update the ui, otherwise you'd have to listen for volumechange and then check the muted state. dunno if that should warrant an event though |
| 01:32 | <Hixie> | maybe volumechange is better cos then you won't have people getting themselves into situations where their mute ui is the opposite of the actual state |
| 01:34 | <othermaciej> | Hixie: did you look at the open issues list btw? it has a lot more proposed features that we did not spec yet |
| 01:34 | <othermaciej> | Hixie: also curious to hear your thoughts about using CSS |
| 01:35 | <Hixie> | i looked at the open issues list but wasn't sure what to make of it (didn't look as closely as the spec proposal) |
| 01:35 | <Hixie> | not sure css makes sense for things you'd affect from the api |
| 01:35 | <Hixie> | not sure really |
| 01:36 | <Hixie> | hyatt had a good example of what you'd want css for the other day |
| 01:36 | <Hixie> | i forget what it was |
| 01:36 | <Lachy_> | it's easier to listen for one "volumechange" event and check the state of 2 variables, than to listen for 2 different events |
| 01:37 | <othermaciej> | stepping out for dinner, will be back |
| 01:41 | <Hixie> | any opera people here? |
| 01:45 | <Hixie> | i wonder if for CSS we can argue that the playback UI of a <video> counts as its "scrolling ui" and therefore doesn't contribute towards its height/width |
| 01:46 | <Lachy_> | Hixie, what do you mean by "scrolling ui"? |
| 01:47 | <Hixie> | scrollbars are considered exempt from the height/width |
| 01:47 | <Hixie> | they're like a type of padding |
| 01:47 | <Lachy_> | ok |
| 01:49 | <Lachy_> | so if I set this: video { height: 300px; width: 400px; } and then the UA adds 50px of UI to the bottom, then the video remains unaffected by that |
| 01:49 | <Hixie> | yeah i'm wondering if we can get away with saying that |
| 01:49 | <Lachy_> | how does window.open() deal with the chrome issue? Is width and height for that the viewport size or the window size? |
| 01:50 | <Hixie> | well mozilla seem to be against having a lot of these things in v1 |
| 01:50 | <Hixie> | sigh |
| 01:51 | <Hixie> | looks like i might have to make two versions of the spec |
| 01:51 | <Hixie> | window.open() doesn't really deal with it well. |
| 01:51 | <Lachy_> | which things in v1 are they objecting to? |
| 01:51 | <Hixie> | <doublec>|I'd hope the first spec would just provide playing of videos, fast forward and rewind. Not farme by frame, declarative looping, etc |
| 01:52 | <Hixie> | (chris double is apparently the one who'd likely end up implementing this) |
| 01:52 | <Hixie> | roc said similar things |
| 01:52 | <Lachy_> | oh, so they want to remove all the APIs that actually make it useful? |
| 01:53 | <Hixie> | no |
| 01:53 | <Hixie> | they want, like i do, for the spec to grow at a steady race |
| 01:53 | <Hixie> | instead of throwing the kitchen sink in at v1 |
| 01:53 | <Hixie> | and then hoping that all the browsers implement everything interoperably on their first try :-) |
| 01:53 | <Hixie> | problem is i presume that a lot of this will be far easier for safari to implement than for anyone else |
| 01:53 | <Lachy_> | yeah, I realise that, but there still needs to be something useful in v1 |
| 01:54 | <Lachy_> | what advantage does safari have over the others? |
| 01:54 | <Hixie> | you don't think the current feature set is useful? |
| 01:54 | <Hixie> | apple own quicktime. |
| 01:55 | <Hixie> | anyway, dinner. bbl. |
| 01:55 | <Lachy_> | no, I think it is useful as it is. If you took out some of the stuff, leaving just play, pause, stop, fast forward and rewind, that's not particularly useful |
| 01:58 | <om_food> | Hixie: is that really true in all cases? I don't think a CSS-sized <textarea> changes size when scrollbars appear |
| 02:16 | <othermaciej> | well, we never asked Mozilla to wait when they wanted to implement certain features faster than we did |
| 02:19 | <Lachy_> | hmm. I wonder if CSS could handle the size of the chrome vs. size of content using some pseudo elements. e.g. video::chrome { height: x; } video { ... } |
| 02:20 | <zcorpan_> | i thought that, if you don't like the native ui, or want consistent ui across browsers, you'd script your own ui |
| 02:21 | <zcorpan_> | (you could still fallback to native ui without JS) |
| 02:21 | <zcorpan_> | so i don't see why there's a need to have any control over the native ui |
| 02:22 | <othermaciej> | the native UI could be different in each browser |
| 02:22 | <othermaciej> | it might be on the bottom, it might be on top, it might be on the side |
| 02:22 | <Lachy_> | yeah, that's the problem |
| 02:22 | <othermaciej> | or even stranger possibilities |
| 02:23 | <zcorpan_> | i don't see why it's a problem. if you modify it, it's not really native anymore. if you don't like it, fine, you can create your own. :) |
| 02:24 | <Lachy_> | yeah, true. |
| 02:25 | <othermaciej> | I do think you need the ability to set size of the video independent of the controls |
| 02:25 | <othermaciej> | (if any) |
| 02:25 | <othermaciej> | it would be nicer if CSS worked for that |
| 02:25 | <zcorpan_> | agree |
| 02:26 | <Lachy_> | yeah, I agree with that |
| 02:41 | <sayrer> | othermaciej: I think video features should be grouped into conformance classes. level1 for playback stuff, level2 for editing. |
| 02:45 | <othermaciej> | sayrer: I don't think anyone has yet proposed a feature set that would be sufficient for editing |
| 02:45 | <sayrer> | othermaciej: there are plenty proposed that are not needed for playback stuff |
| 02:46 | <othermaciej> | well, it depends on how fancy you want your playback to be |
| 02:46 | <othermaciej> | if you want full-featured playback of DVD content, say, then you need more than just basic controls |
| 02:47 | <sayrer> | "Start and end time are useful in case you want to package a bunch of small bits of video in one file and just play different segments" |
| 02:47 | <othermaciej> | yeah, that's if you have multiple bits of video in your site |
| 02:47 | <othermaciej> | can put them all in one file to save http round trips |
| 02:47 | <othermaciej> | similar to the way content authors pack up multiple images in one file |
| 02:47 | <sayrer> | yes, I know the trick |
| 02:48 | <sayrer> | it sounds like it wouldn't work as well for a linear format |
| 02:48 | <sayrer> | er, a time-based one |
| 02:48 | <sayrer> | since one will play after the next anyway |
| 02:49 | <sayrer> | "Or consider looping audio, or a single audio file with multiple sound effects." |
| 02:49 | <sayrer> | this is all squarepushing stuff |
| 02:50 | <othermaciej> | I gotta go |
| 02:50 | <othermaciej> | will be online later tonight |
| 02:50 | <othermaciej> | ciao |
| 02:52 | <karlUshi> | othermaciej: do you know Alexey Proskuryakov |
| 02:52 | <karlUshi> | oops just missed him ;) |
| 02:53 | <othermaciej> | karlUshi: yes |
| 02:53 | <karlUshi> | is he an employee of Apple? |
| 02:53 | <othermaciej> | later |
| 02:53 | <othermaciej> | not yet |
| 02:54 | <karlUshi> | ok thanks |
| 02:54 | <othermaciej> | ttyl |
| 03:40 | <sayrer> | it would be nice to get through a week without patent fud emails |
| 03:41 | <sayrer> | "it's not completely clear that there are no hamburgers on the moon" |
| 03:41 | <sayrer> | come on, prove a negative! |
| 03:43 | <Lachy_> | sayrer: which email are you talking about? |
| 03:44 | <sayrer> | Codecs (was Re: Apple Proposal for Timed Media Elements) |
| 03:46 | <sayrer> | maybe we can start a whatwg-legal-discuss list for people who want to talk about that stuff |
| 03:56 | <billmason> | DanC made this comment in html-wg today: |
| 03:56 | <billmason> | 14:49:35 [DanC] |
| 03:56 | <billmason> | i.e. WHATWG brainstorms and designs, and then the HTML WG plays "defense", makes tests, worries a little about laywers, etc. |
| 03:57 | <billmason> | Maybe that would be applicable here. |
| 03:57 | <sayrer> | I don't care. I don't want to read about patents every week. so yeah, send it to the w3c |
| 04:19 | <dhyatt> | patents are relevant to the discussion though (in some cases) |
| 04:21 | <sayrer> | send it to whatwg-legal |
| 04:54 | <Lachy_> | sayrer: I wasn't expecting you to actually set up whatwg-legal :-) |
| 05:41 | othermaciej | returns |
| 05:41 | <othermaciej> | karlUshi: Alexey is a WebKit open source contributor |
| 05:41 | <othermaciej> | his feedback on the topic of WebKit is likely to be accurate |
| 05:43 | <karlUshi> | thanks |
| 05:44 | <karlUshi> | He's applied to the HTML WG, I wanted to be sure he's not part of Apple, to help him to choose the right path for the application. |
| 05:44 | <karlUshi> | s/He's/He/ |
| 05:45 | <othermaciej> | he is taking the correct path |
| 05:45 | <othermaciej> | I pointed WebKit contributors to the correct instructions for both employees and non-employees of a Member |
| 06:04 | <Hixie> | othermaciej: re earlier, i'm definitely not saying apple should slow down development, just that we might not need all the features you guys want :-) but i think i'll end up specifying a lot tomorrow anyway |
| 06:06 | <othermaciej> | Hixie: how are we going to track issues? there are a lot of differences between the two specs, now that I read yours more closely, and I'm not as comfortable as you in using my mail client as an issue tracker |
| 06:07 | <othermaciej> | even a wiki page would be better |
| 06:07 | <othermaciej> | Hixie: if you think any features are unneeded, you should point that out, and we can provide justification, but that seems like a "should we have this at all" question, not a "v1 vs v2" question |
| 06:08 | <othermaciej> | Hixie: fwiw I think all the features are quite reasonably implementable with any good media framework, probably Ogg included, though I have not studied its API |
| 06:08 | <Hixie> | yeah like i said tomorrow i'm just gonna move the spec to v2 and add everything |
| 06:10 | <Hixie> | then we can work from there |
| 06:11 | <Hixie> | oh btw othermaciej i was thinking |
| 06:11 | <Hixie> | the problem with multiple levels of <video> fallback is that you don't know which one to use |
| 06:11 | <Hixie> | what would be better is something like: |
| 06:12 | <othermaciej> | ok, should I wait until you do that and then try to review for remaining differences, to determine which are on purpose? |
| 06:12 | <Hixie> | <video> <param src="a.ogg" codec="ogg"> <param src="a.mpg" codec="mpeg 4 baseline"> </video> |
| 06:12 | <Hixie> | othermaciej: sure, i'll try to list the differences i noticed too (though i might miss some of course) |
| 06:12 | <sayrer> | are there tags that work that way now? |
| 06:13 | <Hixie> | not really. it's a big source of troubles for <object>/<embed>, you always have to work out which one to talk to |
| 06:14 | <sayrer> | perhaps we should standardize things that are known to work. just my two cents. |
| 06:14 | <Hixie> | well that would exclude the multiple element fallback |
| 06:14 | <Hixie> | :-) |
| 06:14 | <othermaciej> | Hixie: interesting idea |
| 06:14 | <othermaciej> | Hixie: that would certainly be easier from an API pespective |
| 06:14 | <sayrer> | yeah, fallback has been tried many time afaik |
| 06:15 | <sayrer> | I guess another failed attempt won't matter much |
| 06:18 | <othermaciej> | Hixie: that would make it practical to add more attributes on the param to express other things like data rate, or to somehow tie into CSS media queries |
| 06:18 | <othermaciej> | w/o messing up the <video> and <audio> tags themselves |
| 06:18 | <Hixie> | yeah |
| 06:18 | <Hixie> | i kinda like it |
| 06:19 | <dhyatt> | one argument for <audio> as its ow nt ag btw |
| 06:19 | <dhyatt> | is that having a different tag allows for different default intrinsic sizes |
| 06:19 | <dhyatt> | the UA can make better decisions without having to download a resource |
| 06:19 | <dhyatt> | to figure out what is going on |
| 06:19 | <othermaciej> | I like the MIME type w/ codec extension better than an add-hoc codec syntax though, because even though it is fugly it is already well-specified and will be extended for new codecs |
| 06:20 | <Hixie> | mime types for codecs are really not well specified as far as i know |
| 06:22 | <sayrer> | also it implies that implementors will follow the MIME registration rules |
| 06:22 | <sayrer> | but at least major browser vendors don't do that |
| 06:23 | <sayrer> | at least two |
| 06:23 | <sayrer> | so it seems kind of silly to go on pretending |
| 06:24 | dhyatt | is having an identity crisis |
| 06:24 | <karlUshi> | is there a way to associate different video elements together? |
| 06:24 | <karlUshi> | I'm thinking about synchronized starting |
| 06:25 | <karlUshi> | when for example two cameras on a same event and you want both of them synchronized |
| 06:25 | <karlUshi> | or if you want to make a side by side comparison. |
| 06:26 | <karlUshi> | http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html#Timing-ParSyntax |
| 06:27 | <karlUshi> | par |
| 06:27 | <karlUshi> | A par container, short for "parallel", defines a simple time grouping in which multiple elements can play back at the same time. |
| 06:28 | <Hixie> | othermaciej: do you have reference for the parameters for mime types and stuff? |
| 06:28 | <othermaciej> | Hixie: http://www.ietf.org/rfc/rfc4281 |
| 06:28 | <othermaciej> | Hixie: it's linked from http://webkit.org/specs/HTML_Timed_Media_Elements.html |
| 06:29 | <othermaciej> | note that you need to specify the container format, not just the codec (technically the container format is not a codec, but the main mime type already says what it is) |
| 06:30 | <Hixie> | yeah |
| 06:31 | <Hixie> | (thanks for the reference) |
| 06:31 | <othermaciej> | that was one of the exciting things I learned from Apple's media folks |
| 06:32 | <othermaciej> | other things I can't unread include a description of smpte-drop-30, followed by realization that it's not such a good idea to use it to specify times |
| 06:32 | <sayrer> | looks like that only applies to 3gpp formats? |
| 06:33 | <othermaciej> | sayrer: "This parameter MAY be specified for use with additional MIME media types." |
| 06:33 | <sayrer> | of course it may |
| 06:34 | <sayrer> | it may even be specified with different syntax rules |
| 06:34 | <sayrer> | since each MIME type determines its own parameters |
| 06:35 | <othermaciej> | sayrer: 3GPP is based on the MP4 container format |
| 06:37 | <Hixie> | jesus, this rfc 4281 thing is complicated |
| 06:37 | <Hixie> | but ok |
| 06:38 | <othermaciej> | 3GPP is basically MPEG-4 limited to a reasonable subset of codecs |
| 06:39 | <Hixie> | hi don't get the codecs*= thing |
| 06:39 | <Hixie> | er |
| 06:39 | <Hixie> | s/hi// |
| 06:39 | <Hixie> | that is, s/hi/i/ |
| 06:39 | <othermaciej> | I can talk to Dave Singer about improving this if need be, or for clarification |
| 06:39 | <othermaciej> | I don't get the * either |
| 06:40 | <Hixie> | where do we get these magic values from |
| 06:40 | <othermaciej> | ah, it's some lame MIME legalism |
| 06:40 | <sayrer> | I have actually unpacked 3gpp video from my nokia before. still don't see why we would standardize it. |
| 06:40 | <othermaciej> | apparently it defers to the MP4 Registration Authority |
| 06:41 | <Hixie> | well if you guys are happy with it |
| 06:41 | <othermaciej> | for the ISO Base Media File Format (which is the MPEG-4 container format, extra-fancy name) |
| 06:41 | <Hixie> | i just have to refer to it |
| 06:41 | <Hixie> | so it's no skin off my back |
| 06:41 | <othermaciej> | actually no one here loves it, but it's kind of a standard |
| 06:41 | <Hixie> | are we ok with just reusing <param> with different attributes or do we want some other element? |
| 06:41 | <othermaciej> | I will have to inquire about it some more |
| 06:42 | <sayrer> | Hixie, is there an example of "v2" stuff in the spec now? |
| 06:43 | <othermaciej> | Hixie: I think either is fine, the use is somewhat analogous, though in other ways different |
| 06:44 | <othermaciej> | or more accurately I would say "no strong opinion" |
| 06:45 | <dhyatt> | what is the allure of theora over mpeg? |
| 06:45 | <othermaciej> | it is claimed to be patent-safe |
| 06:46 | <othermaciej> | the company that developed it donated all the patents they had on it themselves as royalty-free for use with it |
| 06:46 | <dhyatt> | and mpeg isn't? isn't mpeg used by tons of companies? |
| 06:46 | <sayrer> | well, it is royalty free right now |
| 06:46 | <sayrer> | and mpeg requires royalties |
| 06:46 | <othermaciej> | mpeg has patents that cost money to license |
| 06:46 | <dhyatt> | ah |
| 06:47 | <Hixie> | sayrer: not now |
| 06:47 | <dhyatt> | so if opera or mozilla implemented support for mpeg natively they would have to pay somebody? |
| 06:47 | <Hixie> | sayrer: tomorrow :-) |
| 06:47 | <Hixie> | yeah |
| 06:47 | <sayrer> | Hixie: ok |
| 06:47 | <sayrer> | dyatt: mpeg money goes to Fraunhoffer (sp?) and some others now |
| 06:48 | <othermaciej> | H.264 actually has open source implementations |
| 06:48 | <dhyatt> | that ponied up the money already or something? |
| 06:48 | <othermaciej> | but it's unclear what the legal status is there |
| 06:48 | <dhyatt> | ok i get it now |
| 06:48 | <sayrer> | but open source isn't the interesting part, it's disribution that makes it tough |
| 06:48 | <Hixie> | dhyatt: and if debian wants to ship it, they can't, because their users are supposed to be allowed to redistribute, but they wouldn't be allowed to in a licensed regime |
| 06:48 | <dhyatt> | seems bad to have to pay money just to support <video> |
| 06:49 | <Hixie> | yeah |
| 06:49 | <Hixie> | that's why people want to support theora instead |
| 06:49 | <Hixie> | it's a tough one |
| 06:49 | <dhyatt> | ok i get it |
| 06:49 | <othermaciej> | the patent situation with video is a tough one |
| 06:49 | <Hixie> | of course for a company like apple or google, who has already paid MPEG-LA for the right to use MPEG4, it's actually safer to use MPEG |
| 06:49 | <dhyatt> | right |
| 06:49 | <dhyatt> | since theora is kind of an unknown |
| 06:49 | <Hixie> | yeah |
| 06:49 | <othermaciej> | thus the lack of consensus |
| 06:50 | <dhyatt> | how greedy is mpeg |
| 06:50 | <sayrer> | do Apple and Google have to pay Forgent? |
| 06:50 | <Hixie> | dhyatt: no idea |
| 06:50 | <othermaciej> | I think they have a sliding scale |
| 06:50 | <dhyatt> | i wonder if they would be moved by the desire for this to be the video standard on the web |
| 06:50 | <dhyatt> | i guess not |
| 06:50 | <othermaciej> | sayrer: you sure talk about patents a lot for someone who doesn't want to hear about them |
| 06:51 | <sayrer> | I don't mind talking about them. I don't like sending them to WG lists. |
| 06:52 | <sayrer> | it's part of reality, but you don't want to open up a technical mailing list to all of reality |
| 06:52 | <sayrer> | you will never get anything done |
| 06:52 | <othermaciej> | so you don't want patent discussion on the mailing list, but on IRC it's ok? |
| 06:52 | <sayrer> | I don't want technical proposals to start with a discussion of patents |
| 06:53 | <othermaciej> | well, video is a special case |
| 06:53 | <sayrer> | it comes down to it in the end, as we have seen over in the w3c |
| 06:53 | <Hixie> | so according to http://www.mpegla.com/avc/AVC_TermsSummary.pdf it seems that random joe with a mildly popular web site would have to pay $2500 per year to code his videos using MPEG4 |
| 06:53 | <Hixie> | but i could be misreading it |
| 06:54 | <sayrer> | and here we have Microsoft paying Alcatel-Lucent 1.2 Billion for two submarine patents on mp3 just last week |
| 06:54 | <sayrer> | 1.52 billion, sorry |
| 06:54 | <sayrer> | http://animators.digitalmedianet.com/articles/viewarticle.jsp?id=114856 |
| 06:54 | <Hixie> | mp3 = MPEG 1 Layer 3 |
| 06:55 | <othermaciej> | Hixie: see Internet Broadcast |
| 06:55 | <sayrer> | this all sucks so badly. :/ |
| 06:55 | <Hixie> | it looks like browser vendors would also have to pay about $0.20 per seat |
| 06:56 | <Hixie> | but never more than $4.25 million a year |
| 06:56 | <Hixie> | this doesn't seem to handle free software distribution |
| 06:56 | <Hixie> | where each person is a distributor |
| 06:56 | <othermaciej> | 0-100,000 unitls are free |
| 06:57 | <Hixie> | yeah but debian has more than 100,000 downloads |
| 06:57 | <Hixie> | although this summary says "sold" |
| 06:57 | <othermaciej> | I don't know how much MPEG-LA can be convinced to change things, or how they would think of this applying to free software |
| 06:57 | <sayrer> | hmm, is this even gpl/lgpl compatible? |
| 06:57 | <Hixie> | gpl doesn't mention patents |
| 06:57 | <othermaciej> | Apple has contacts there, I can ask for more research/clarification |
| 06:57 | <Hixie> | (it's not mpl compatible though as far as i can tell) |
| 06:58 | <sayrer> | Hixie: both mention patents |
| 06:58 | <Hixie> | gpl doesn't. |
| 06:58 | <Hixie> | that's why they're doing gpl3. |
| 06:58 | <Hixie> | iirc |
| 06:58 | <Hixie> | could be wrong |
| 06:59 | <sayrer> | section 7 has something about it |
| 06:59 | <sayrer> | I don't claim to understand it |
| 06:59 | <Hixie> | ah |
| 06:59 | <Hixie> | anyway |
| 06:59 | <Hixie> | bbl |
| 07:21 | <hsivonen> | dhyatt: MPEG-LA is so greedy that Apple was unable to negotiate a blanket license for MPEG-4 on behalf of its users even after making a big deal about it publicly |
| 07:21 | <dhyatt> | hsivonen: :( |
| 07:24 | <hsivonen> | I believe that the way the open source implementations work is that the implementors are in Sweden and Hungary and then Google pays MPEG-LA and does not distribute the software further so by using it privately they don't invoke the patent clause of the GPL. (but IANAL) |
| 07:25 | <sayrer> | hsivonen: but that would suck for browser distributions, in your NAL analysis, right? |
| 07:26 | <hsivonen> | sayrer: it would suck big time. moreover, it would be incompatible with the Mozilla and WebKit licensing scheme in the U.S. |
| 07:27 | <sayrer> | that's what I thought from reading the FSF stuff, but I don't understand software licensing very well |
| 07:27 | <othermaciej> | including the source in the same binary would, linking to a binary (under whatever terms) wouldn't violate the LGPL afaict |
| 07:28 | <othermaciej> | (insert usual IANAL disclaimer) |
| 07:28 | <othermaciej> | hi annevk! |
| 07:28 | <hsivonen> | othermaciej: yeah. MPEG-4 is already supported through the quicktime plug-in |
| 07:31 | <sayrer> | yeah, but then it gets tricky if the entire device is closed source |
| 07:42 | <othermaciej> | wow, my blog post about Apple joining the HTML WG seems to be getting more news attention than the W3C's original press release about it |
| 07:43 | <sayrer> | it is cool that you are inviting more people in |
| 07:46 | annevk | reads the Apple <video> proposal |
| 07:54 | annevk | wonders why there's need for a Video() constructor |
| 07:55 | <othermaciej> | I'm not sure there is, but you could use it for preloading like Image() |
| 07:55 | <othermaciej> | (didn't notice that crept in there) |
| 07:58 | <Lachy> | ha! "fair, reasonable, non-discriminatory access..." on the MPEG LA home page :-) They seem to be totally unfair, and discriminate against everyone who can't afford their unreasonable licence fees! |
| 08:06 | <hsivonen> | Lachy: RAND usually is neither reasonable nor non-discriminatory |
| 08:07 | <hsivonen> | Lachy: I think the fee for the algorithm is not their most unreasonable demand. the demand for money when you copy the bits produced by the algorithm is |
| 08:07 | <othermaciej> | sadly the A/V standards world has very different cultural norms for patents than the web standards world |
| 08:07 | <hsivonen> | Lachy: so basically they want money if you have deep pockets and you want to run cp on bytes they think they own |
| 08:08 | <Lachy> | does that mean someone technically isn't allowed to publish an MPEG4 encoded video on the web without paying? |
| 08:08 | <othermaciej> | http://www.mpegla.com/avc/AVC_TermsSummary.pdf |
| 08:09 | <hsivonen> | Lachy: if the someone is wealthy enough to go over the threshold that makes MPEG-LA care, then the someone has risk |
| 08:09 | Lachy | reads |
| 08:10 | <hsivonen> | Lachy: it is up to lawyers to assess is the risk is reality-based and whether paying the hush money is cheaper that defending in court in case MPEG-LA believes they have a case to enforce |
| 08:15 | <Lachy> | hmm. If I read that correctly (though I didn't understand most of it) I'd have to pay to publish a video longer than 12 minutes |
| 08:18 | <annevk> | The CSS proposal looks the least interesting |
| 08:18 | <sayrer> | MPEG-LA |
| 08:19 | <sayrer> | What's Not To Like? |
| 08:19 | <othermaciej> | we tried to put the presentational aspects in CSS, particularly things that could apply to other elements like <img> showing an animated GIF or <marquee> |
| 08:22 | <hsivonen> | FWIW, last time I checked, the managers of the AAC patent pool were much more reasonable about decoder licenses than the managers of the AVC patent pool. but that probably does not help enough |
| 08:24 | <hsivonen> | besides, it is claimed that Vorbis in technically on par with AAC |
| 08:24 | <hsivonen> | too bad Theora is technically on par with H.264 |
| 08:26 | <othermaciej> | you mean "isn't" in the last bit I assume |
| 08:26 | <annevk> | hmm, I'm mentioned on http://womengeeks.com/ |
| 08:26 | <othermaciej> | heh |
| 08:26 | <othermaciej> | annevk: I get that sort of thing myself at times, though not as much as you I bet |
| 08:26 | <hsivonen> | othermaciej: do. yes, I meant "isn't" |
| 08:27 | <hsivonen> | othermaciej: why do you get it? |
| 08:27 | <othermaciej> | "Maciej" is not a common name anywhere but in Poland, so people don't know what it is, and sometimes assume it is "Macie J" or something like that |
| 08:27 | <hsivonen> | oh |
| 08:28 | <annevk> | It's amazing how many people still believe in content negotiation |
| 08:28 | <annevk> | Especially considering that it doesn't actually work most of the time |
| 08:28 | <hsivonen> | Maciej is like Matthew, right? |
| 08:28 | <othermaciej> | well, sort of |
| 08:29 | <othermaciej> | there is also the name "Mateusz" |
| 08:29 | <Lachy> | othermaciej, you're a male? Wow, I guessed wrongly too :-) |
| 08:29 | <othermaciej> | Lachy: you're kidding, right? |
| 08:29 | <Lachy> | no, I had no idea |
| 08:30 | <othermaciej> | heh |
| 08:30 | <Lachy> | don't feel bad, I assumed the same with hsivonen and annevk initially too! |
| 08:30 | <krijnh> | Now we know what W3C FTF's are for ;) |
| 08:30 | <hsivonen> | there are enough famous Frenchmen with my first name, even though in general English-speakers tend to think that Finnish men whose name ends with an 'i' are women |
| 08:30 | <hsivonen> | Lachy: whoa! |
| 08:31 | <othermaciej> | I never would have thought Henri would be a woman's name |
| 08:32 | <annevk> | lol |
| 08:32 | <Lachy> | Henry normally ends with a 'y' where I come from, so I assumed Henri was the female alternative |
| 08:33 | <othermaciej> | anyway "Maciej" is kind of an old slavic name, though claimed cognate with Czech Matej and supposedly analogous to Matthew, but I think that is a retroactive decision |
| 08:33 | <othermaciej> | "Mateusz" is more clearly derived from the same root as Matthew but often translated as "Mathias" |
| 08:34 | <annevk> | i see an obvious usecase for <name sex=male|female> |
| 08:34 | <hsivonen> | Lachy: in Finland 'Henry' has an sv-FI connotation |
| 08:35 | <Lachy> | what's sv-FI? |
| 08:35 | <hsivonen> | Lachy: Swedish spoken in Finland |
| 08:35 | <Lachy> | ok |
| 08:40 | <othermaciej> | I know a lot of Finnish men whose names end in "i" but also a bunch of French Henris |
| 09:18 | <krijnh> | Regarding the irc logs |
| 09:19 | <krijnh> | People can now flag important lines by double clicking |
| 09:19 | <krijnh> | And unflag by double clicking again |
| 09:23 | <Lachy> | where's whatbot gone? krijnh are you using a different name for your bot? |
| 09:23 | <krijnh> | Lachy: I don't know, I think Charl dropped it |
| 09:24 | <krijnh> | Lachy: I'm not using a bot |
| 09:24 | <annevk> | he is the bot |
| 09:24 | <krijnh> | *bleep* |
| 09:24 | <Lachy> | I thought you were since the logs are on your site |
| 09:24 | <Charl> | Lachy: whatbot is dead :) R.I.P. :) |
| 09:25 | <krijnh> | Lachy: My client is just logging files which I parse again |
| 09:25 | <Lachy> | oh, ok. |
| 09:26 | <krijnh> | I still have to fix whatbots archive though |
| 09:27 | <annevk> | yeah |
| 09:27 | <annevk> | it should redirect too |
| 09:28 | <Lachy> | yeah, it's easier to remember and type whatbot.charlvn.za.net, then remember how to spell krijnh's domain name |
| 09:28 | <krijnh> | :( |
| 09:28 | <Lachy> | I can't even figure out how to pronounce it |
| 09:29 | <krijnh> | Yeah, I had that problem in the USA as well |
| 09:29 | <annevk> | why can't krijnh get a subdomain on whatwg.org ? |
| 09:29 | <krijnh> | Just say 'John' :) |
| 09:29 | <annevk> | irclogs.whatwg.org |
| 09:29 | <krijnh> | And let that redirect to me |
| 09:29 | <krijnh> | Or something |
| 09:29 | <annevk> | or you just get access to it... |
| 09:29 | <Lachy> | what the? Is that really close to what it sounds like, or is that just an alternative you use? |
| 09:29 | <annevk> | that's fairly trivial with dreamhost |
| 09:29 | <krijnh> | annevk: I can't run my irc client on that server I guess :] |
| 09:29 | <krijnh> | krijnhoetmer.nl is in my LAN |
| 09:29 | <annevk> | Lachy, lol |
| 09:30 | <krijnh> | Lachy: what do you think? ;) |
| 09:30 | <Lachy> | hey, don't laugh. well, I was surprised when I found out Hakon was pronounce howcome! |
| 09:30 | <annevk> | krijnh, I'm not talking about a server, just about a domain |
| 09:30 | <krijnh> | Lachy: me too |
| 09:30 | <krijnh> | annevk: Ah, k |
| 09:31 | <annevk> | Lachy, it's not really howcome though |
| 09:31 | <Lachy> | I know, I read that. But I couldn't find anything that described the accurate pronunciation |
| 09:31 | <krijnh> | Lachy: my name sounds like a combination of 'crane' and 'crying' btw |
| 09:31 | <annevk> | hoh-con maybe |
| 09:32 | icaaq | sounds like I suck (aka isac) |
| 09:32 | <annevk> | :p |
| 09:33 | <Lachy> | oh, I thought icaaq was like ick-ark or something. |
| 09:34 | <Lachy> | so you pronounce 'c' like 's' for some strange reason |
| 09:34 | <krijnh> | Like in ice :) |
| 09:34 | <krijnh> | Strange |
| 09:34 | <othermaciej> | jeez, don't any web standards people have normal names? |
| 09:34 | <krijnh> | Molly, Chris, Dean |
| 09:34 | <annevk> | Ian |
| 09:35 | <Lachy> | othermaciej, Ian, Matthew, and several others! |
| 09:35 | <icaaq> | it started when i got my first icq and I just added two a's icaaq |
| 09:35 | <krijnh> | What has Ian to do with standards? :| |
| 09:36 | <icaaq> | Lachy: Yes and q like k |
| 09:36 | <Lachy> | krijnh, maybe Ian Hickson |
| 09:36 | <krijnh> | ;) |
| 09:43 | <krijnh> | Okay, enough irc logs stuff for today |
| 09:43 | <krijnh> | Work |
| 09:46 | <krijnh> | annevk: btw, change your copyright line to 2003-2007 |
| 09:48 | <annevk> | done |
| 09:48 | <krijnh> | :) |
| 09:49 | <annevk> | remind me in 2008 please |
| 09:49 | <krijnh> | date('Y') |
| 09:49 | <Lachy> | annevk, you could just remove it, then you won't need to up date it |
| 09:49 | <krijnh> | Or that |
| 09:49 | Lachy | thinks copyright notices are silly |
| 10:19 | <Dashiva> | copyright then-now |
| 10:31 | <KevinMarks> | evening |
| 10:32 | <annevk> | morning |
| 10:32 | <Lachy> | good e-day :-) |
| 10:40 | virtuelv | looks at Apple's video fallback proposal |
| 11:08 | <Lachy> | in Apple's <video> proposal, does anyone else think availabledurationchange event seems like a progress event? |
| 11:09 | <Lachy> | it seems a bit redundant to me |
| 11:10 | <annevk> | it's different from a progress event |
| 11:10 | <annevk> | Content-Length is not equal to the duration... |
| 11:10 | <Lachy> | yeah, true |
| 11:11 | <annevk> | it'd be good to have usecases instead of a spec |
| 11:11 | <virtuelv> | Lachy: looks more like something for cuemarks, but I might be wrong |
| 11:11 | <Lachy> | ok |
| 11:19 | <annevk> | <keygen> should prolly be added to HTML5... |
| 11:20 | <annevk> | but I think I already said that once on the list... |
| 11:20 | <virtuelv> | annevk: the old Netscape thing noone ever used? |
| 11:21 | <annevk> | sites rely on it |
| 11:21 | <annevk> | (it's also in Mozilla) |
| 11:21 | <annevk> | for IE they use some ActiveX control |
| 11:22 | <Lachy> | annevk, have you found any documentation that describes exactly what it does and how to use it? There seems to be very little information about it, which is why it hasn't been added |
| 11:23 | <Lachy> | it isn't supported by IE either, so browsers really don't need to support it to be compatible with the web |
| 11:24 | <annevk> | Lachy, ever heard of sniffing? |
| 11:24 | <annevk> | Lachy, Skandiabanken relies on it for instance |
| 11:24 | <Lachy> | what is that site? |
| 11:24 | <Lachy> | a bank? |
| 11:25 | <annevk> | I think so. (This information was passed to me.) |
| 11:25 | <Lachy> | there's still the problem of figuring out exactly what it does, how it works and how to use it |
| 11:28 | <annevk> | yup |
| 11:28 | <annevk> | but that should be doable |
| 11:29 | <Lachy> | aren't https and TLS better solutions for whatever its usecases are? |
| 11:32 | <annevk> | i don't think so |
| 11:32 | <Lachy> | then what does it do? I thought it was to provide some sort of encryption and security |
| 11:33 | <annevk> | it generates a key I believe... |
| 11:33 | <Lachy> | for what purpose? |
| 11:33 | <Lachy> | what good is a key if it doesn't fit into any locks? |
| 11:33 | <annevk> | as I said, I'm not up in the details of what exactly it does |
| 11:33 | <annevk> | i just know it's needed |
| 11:33 | <Lachy> | for one site? I don't think so |
| 11:35 | <annevk> | i would assume more sites use it |
| 11:35 | <annevk> | it's not that we added it just for them... |
| 11:35 | <Lachy> | does Opera support it? |
| 11:36 | <annevk> | yes, Opera and Firefox and maybe Safari |
| 11:36 | <Lachy> | oh, then whoever implemented it there should be able to provide some description of what it does and how it works |
| 11:37 | <annevk> | when you submit a form that contains it it starts an async process that generates a key |
| 11:37 | <annevk> | in firefox it's just that and in Opera you can encrypt this key using a master password |
| 11:38 | <Lachy> | I have a general idea of what happens on the client side before form submission. It's just that I do not understand what use it is to the server or the client afterwards |
| 11:38 | <annevk> | http://webdesign.about.com/od/htmltags/p/bltags_keygen.htm |
| 11:39 | <annevk> | so Safari supports it as well |
| 11:42 | <Lachy> | so presumably, servers are supposed to be able to encrypt data using that public key and send it back to the browser |
| 11:43 | <annevk> | in WebKit it subclasses the <select> element |
| 11:45 | <MikeSmith> | annevk - <keygen> and browser support for it sounds potentially very useful to me |
| 11:45 | <MikeSmith> | is it meant for client-side signing of data/documents? |
| 11:46 | <annevk> | the usecase isn't entirely clear to me |
| 11:46 | <MikeSmith> | well, the lack of a standard mechanism for digital signing in browsers is on thing that causes browser lock-in in some places |
| 11:46 | <annevk> | i just know it's supported in some form of interop between Safari / Firefox / Opera |
| 11:46 | <MikeSmith> | in Korea, for example |
| 11:46 | <MikeSmith> | annevk - OK |
| 11:48 | <MikeSmith> | anway, Korean banks and government sites use digital signing quite a lot, but they rely on an ActiveX control for doing it |
| 11:48 | <MikeSmith> | without any fallback or alternative mechanism for other browsers |
| 11:48 | <annevk> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-November/thread.html#5092 |
| 11:48 | <annevk> | MikeSmith, I see, I guess that might indeed be the usecase for <keygen> ... |
| 11:49 | <MikeSmith> | annevk - maybe |
| 11:50 | <MikeSmith> | I just glanced at the old Netscape docs you cited and it's not really clear from those what the use case is meant to me |
| 11:50 | <MikeSmith> | to be |
| 11:50 | <Lachy> | if that's its usecase, and it actually works like that, then it could be useful. But there's not much point discussing it till we find out exactly how it's supposed to work. |
| 11:51 | <Lachy> | =MIICQTCCASkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5weCgMUZ+IugwXGeOr1xspUaqrTTEjPurmS37XEBn1BFEMQ4TvmY20BsVwo674QoVfpx0ko2JVS33VBBkEDGCo551ZZiWfGQWVeiePU0kggUdw9QeVC+hB5vZZqOc+ie+UjwpzekoyPWOk2mmQXBaEHRpz0cG9rPsz/e33bIyRbZNZ0Y089HzWlqWnDZYB/P+kg43SsdZzeXhm1O6ejUH6ZN3ot/wAgBxRIgVoI8njGjUE6sTUeBAHdsxLRk5zI4MGj5Q2dWh+eViZX9HTag6AEQ9hw1xi4kji180H9m8EVi/zBsyY9IHfXq+KE6hZTpv2U2EHsYRzfsIYoOQrf9HAgMBAAEWAQAwDQYJKoZIhvcNAQEEBQADggEBAC8iywKI6Q |
| 11:51 | <Lachy> | HcgtHAmJnQS9kqbOUqrl+fHclQkiS1BxMhKk6HSN9D0Sz6Wjk9GGm26gU9m5+nToJc4i6169FOl+CWQMjaaBpxjhnUS90iWORS4G2xVZP5At5V2gC3I+jDKrpA7m+pI6i/tRYlDREWI97k9aGBErE+WdcJ4SjCV9lQLxRMr98h+jeZwzsnga51RzhKYKlr+bcuUEc0BIy5zc/MWi7CC8ghbZTCjnwut+1fv4s5DJdvLm51jjWpXE7y1waQmjJG+P83b3u5Rar0WMdjVhZAaNyeYZS2qyxSrSx6nQQ+KM/qPxtmWex8k24Kibelo5b0e42mRK82lk0s3MQ= |
| 11:51 | <Lachy> | =MIICQTCCASkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5weCgMUZ+IugwXGeOr1xspUaqrTTEjPurmS37XEBn1BFEMQ4TvmY20BsVwo674QoVfpx0ko2JVS33VBBkEDGCo551ZZiWfGQWVeiePU0kggUdw9QeVC+hB5vZZqOc+ie+UjwpzekoyPWOk2mmQXBaEHRpz0cG9rPsz/e33bIyRbZNZ0Y089HzWlqWnDZYB/P+kg43SsdZzeXhm1O6ejUH6ZN3ot/wAgBxRIgVoI8njGjUE6sTUeBAHdsxLRk5zI4MGj5Q2dWh+eViZX9HTag6AEQ9hw1xi4kji180H9m8EVi/zBsyY9IHfXq+KE6hZTpv2U2EHsYRzfsIYoOQrf9HAgMBAAEWAQAwDQYJKoZIhvcNAQEEBQADggEBAC8iywKI6Q |
| 11:51 | <Lachy> | HcgtHAmJnQS9kqbOUqrl+fHclQkiS1BxMhKk6HSN9D0Sz6Wjk9GGm26gU9m5+nToJc4i6169FOl+CWQMjaaBpxjhnUS90iWORS4G2xVZP5At5V2gC3I+jDKrpA7m+pI6i/tRYlDREWI97k9aGBErE+WdcJ4SjCV9lQLxRMr98h+jeZwzsnga51RzhKYKlr+bcuUEc0BIy5zc/MWi7CC8ghbZTCjnwut+1fv4s5DJdvLm51jjWpXE7y1waQmjJG+P83b3u5Rar0WMdjVhZAaNyeYZS2qyxSrSx6nQQ+KM/qPxtmWex8k24Kibelo5b0e42mRK82lk0s3MQ= |
| 11:51 | <Lachy> | http://www.blooberry.com/indexdot/html/tagpages/k/keygen.htm |
| 11:51 | <Lachy> | aargh!, sorry, my clipboard was full of other stuff I didn't realise :-( |
| 11:52 | <Lachy> | anyway, that crap I pasted was the output of the keygen element |
| 11:54 | <annevk> | Safari only supports keytype and challenge |
| 11:54 | <annevk> | (and only RSA) |
| 11:56 | <MikeSmith> | annevk - maybe Hallvord and write up a description of what it's actually being used for in practice (whatever the Skandiabanken is using it for) and send it to the list |
| 11:57 | <MikeSmith> | s/Hallvord and/Hallvord can/ |
| 12:01 | <Lachy> | this page http://wp.netscape.com/eng/security/downloadcert.html seems to describe the certificates used for it |
| 12:24 | <annevk> | fancy |
| 12:24 | <annevk> | the BBC guys weigh in |
| 12:26 | <virtuelv> | nice |
| 12:26 | <hasather> | Just noticed that Sweden's largest auction site allows arbitrary HTML in the object description :S Just alerted my own cookie |
| 12:26 | <annevk> | heh |
| 12:33 | <Lachy> | oh, nice! I wonder if BBC are considering releasing their content in DRM-free Dirac in the future? |
| 12:34 | <Lachy> | last I read, they were considering implementing DRM and moving to proprietary formats |
| 12:34 | <annevk> | if browsers all support their open format... |
| 12:34 | <Lachy> | that would be awesome! |
| 12:34 | <Lachy> | here it is http://defectivebydesign.org/blog/939 |
| 12:35 | <hsivonen> | has Dirac been vetted for patent avoidance in the UK or also in the US? |
| 12:36 | <Lachy> | Thomas' email said "So this time next year, there is a good chance that Dirac will be an international, royalty-free SMPTE standard." |
| 12:37 | <hsivonen> | hmm. I wonder how the SMPTE deals with having just approved Microsoft's stuff that is subject to an MPEG-LA portfolio |
| 12:37 | <hsivonen> | that is, how they deal with standardizing something else without upsetting MS too much |
| 12:39 | <annevk> | I hope that other "year" it takes is a realistic estimate |
| 12:44 | <annevk> | Lachy, someone just raised that question |
| 12:45 | <hasather> | sent them a mail, I hope they fix it soon |
| 12:54 | <Lachy> | does Dirac need to be embedded in a container format like Ogg to be used? |
| 12:55 | <annevk> | prolly |
| 12:56 | <annevk> | http://dirac.sourceforge.net/ |
| 12:58 | <Lachy> | http://wiki.xiph.org/index.php/OggDirac |
| 12:58 | <Lachy> | If Direc is better than Theora, than the spec should change to require it |
| 12:58 | <annevk> | Dirac isn't finished |
| 12:59 | <annevk> | see my remark about "year" above |
| 12:59 | <Lachy> | yeah, I realise that |
| 12:59 | <hsivonen> | I wonder if the Dirac folks are able and willing to adopt the MPL 1.1 / GPL 2.0 / LGPL 2.1 tri-license... |
| 12:59 | <hsivonen> | Debian... |
| 13:00 | <Lachy> | Maybe the spec could recommend both and then let the market decide which is better |
| 13:01 | <annevk> | if it's done in a year it prolly make sense to use it |
| 13:01 | <Lachy> | I thoght the MPL was the tri-licence |
| 13:02 | <annevk> | no |
| 13:02 | <annevk> | Gecko is tri-licensed |
| 13:02 | <Lachy> | I'm reading the the MPL FAQ |
| 13:02 | <hsivonen> | Lachy: their FAQ implies that they are using the tri-license after all. (I haven't checked their source headers) |
| 13:02 | <hsivonen> | their being Dirac |
| 13:04 | <annevk> | "We intend to pack the Dirac elementary stream into MXF, which has lots of useful features. That doesn't preclude it packing into Ogg (or Matroska, or anything else) as well, and it's probably a good idea to have a variety of packing formats. For this the elementary stream needs to be very well defined." |
| 13:04 | <Lachy> | ok, I get it now. MPL is one of the 3 licences, which places additional restrictions that are incompatible with GPL. The tri-license says you have the right to use the code under the terms of either licence |
| 13:09 | <Lachy> | I wonder if Dirac could be implemented on Rockbox or iPodLinux. I read somewhere that Theora can't be due to memory and/or processing contstraints |
| 13:12 | <virtuelv> | Lachy: is it that bad? Rockbox has support for MPEG on players without video decoder circuitry (on the ipod nano, for instance) |
| 13:12 | <hsivonen> | Lachy: the technical problem with avoiding the base techniques of the MPEG family is that the hardware DSP chips accelerate the operations needed for MPEG |
| 13:14 | <Lachy> | so are you saying that since Dirac won't have the hardware support like MPEG, then it's unlikely? |
| 13:15 | <hsivonen> | Lachy: I am saying that existing MPEG-oriented hardware probably won't be particularly useful for accelerating Theora or Dirac |
| 13:16 | <Lachy> | ok |
| 13:16 | <hsivonen> | (but then, some DSP chips really suck. on Nokia 770, MPEG-4 ASP decoding works better on the CPU than on the DSP) |
| 14:15 | <annevk> | lol |
| 14:15 | <annevk> | someone is blaming a Firefox developer for solely using IE and not considering Firefox |
| 14:18 | <Lachy> | hehe |
| 14:24 | <annevk> | and now he forwards my offlist comment to the list |
| 14:24 | <annevk> | oh well |
| 14:24 | <annevk> | i suppose i can also just ignore him |
| 14:25 | annevk | reads bits of http://www.w3.org/TR/NOTE-HTMLplusTIME |
| 14:29 | <hasather> | plus, he top-posts |
| 14:31 | <MikeSmith> | dude seems to be set on trying to tick off as many people as possible |
| 14:32 | <MikeSmith> | Isn't that the same guy that took a discussion with Hallvord off into the weeds a couple days ago? |
| 14:32 | <annevk> | think so |
| 14:33 | <hasather> | it is |
| 14:33 | <Lachy> | is this the first time he's posted to the list? |
| 14:33 | <Lachy> | is he just a troll? |
| 14:33 | <annevk> | he tries to make points i suppose |
| 15:30 | <tylerr> | Morning all. |
| 15:30 | <zcorpan_> | sigh. the trick didn't work. we still get spammers to the forum :( |
| 15:31 | <hasather> | zcorpan_: they aren't bots then |
| 15:31 | <tylerr> | XHTML2 fanboys. |
| 15:31 | tylerr | winks. |
| 15:31 | <zcorpan_> | could be |
| 15:31 | <tylerr> | Just out to cause inconvenience. |
| 15:49 | <ROBOd> | zcorpan_: it takes more time to fight spam, than to approve each user |
| 15:49 | <ROBOd> | zcorpan_: it's also easier to appoint more moderators/admins which can do this "job" |
| 15:58 | <zcorpan_> | ROBOd: perhaps... but sometimes it's hard to tell whether a user is a spammer or not |
| 15:59 | <ROBOd> | zcorpan_: not really. spammers almost *always* fill their profile with wrong data |
| 15:59 | <zcorpan_> | the last two didn't have anything in particular in their profile |
| 15:59 | <zcorpan_> | like most users |
| 15:59 | <ROBOd> | and you can also "smell" spammers based on their email address. e.g. i don't approve accounts @mail.ru |
| 15:59 | <zcorpan_> | @mail.ru is already banned |
| 15:59 | <zcorpan_> | but yeah |
| 16:00 | <ROBOd> | and based on the names they pick... |
| 16:01 | <ROBOd> | but yes, i understand it's harder for you to tell spammers apart from normal users |
| 16:02 | <ROBOd> | in my case, on the forum i was referring to, it's for a national informatics contest. so, accounts with english names are marked as spam from the start :) |
| 16:03 | <zcorpan_> | ROBOd could be a spammer ;) |
| 16:03 | <ROBOd> | hehe |
| 16:03 | <ROBOd> | right |
| 16:04 | <tylerr> | Any one of us could be. |
| 16:04 | tylerr | shifts his eyes around. |
| 16:16 | <annevk> | more XForms pushing on public-html |
| 16:16 | <annevk> | by citing a guy famous for promoting XForms |
| 16:19 | <zcorpan_> | i thought the good stuff from xhtml2 and xforms were already in html5 and wf2 |
| 16:19 | <annevk> | xhtml2 certainly |
| 16:19 | <annevk> | xforms prolly as much as possible |
| 16:29 | annevk | e-mailed a simple reply |
| 16:51 | <gsnedders> | if createElement(tagName) creates an element in the HTML namespace, isn't it the same as createElementNS("http://www.w3.org/1999/xhtml";, tagName)? |
| 16:52 | <annevk> | yes |
| 16:52 | <annevk> | that battle hasn't finished yet though |
| 16:53 | <gsnedders> | didn't Opera have some pre-release version with namespaces in HTML? What caused the issues with that? |
| 16:53 | <gsnedders> | Did it allow namespaces from within the document, or what? |
| 16:54 | <annevk> | we had special HTML parsing that caused problems |
| 16:54 | <annevk> | this is different |
| 16:54 | <annevk> | in Opera createElement(tagName) maps to createElementNS(document.documentElement.namespaceURI, tagName) btw... (well, it also caters for documentElement being undefined) |
| 16:56 | <gsnedders> | ah, thanks annevk |
| 16:57 | <annevk> | the upside is that it caters for broken SVG documents and the downside is that it might break scripts that are copy and pasted between standalone and compound documents |
| 16:58 | <annevk> | then again, those scripts should prolly use the namespaced method anyway |
| 17:07 | annevk | wonders what the fuss about whatwg-legal is about |
| 17:07 | <ROBOd> | hmm... is that even near to be something "official"? |
| 17:08 | <annevk> | of course not |
| 17:08 | <ROBOd> | i don't like that ... |
| 17:08 | annevk | thought it was joke |
| 17:08 | <ROBOd> | me too |
| 17:09 | <gavin_> | it's hosted on Microsoft's servers |
| 17:09 | <ROBOd> | it's like i'd start right now a newsgroup "microsoft-legal" on google groups :) |
| 17:09 | <annevk> | it's created by a guy from MoCo |
| 17:09 | <gavin_> | they need to review their patent portfolio before the group can be activated |
| 17:10 | <gavin_> | annevk: I'm well aware! |
| 17:10 | <annevk> | thought so :) |
| 17:10 | <annevk> | but MS only needs to review the HTML charter |
| 17:10 | <ROBOd> | does the WHATWG *allow* the usage of the WHATWG name? when it's not officially approved |
| 17:10 | <annevk> | it covers everything the HTML5 spec covers iirc |
| 17:11 | <gavin_> | What I said above about patents was a joke. |
| 17:11 | <MikeSmith> | annevk - are you planning maybe to follow up with Hallvord about <keygen> use cases? |
| 17:11 | <annevk> | ROBOd, WHATWG isn't an organization |
| 17:11 | <annevk> | MikeSmith, I followed up with Yngve actually |
| 17:11 | <MikeSmith> | annevk - ah, you're brave |
| 17:12 | <ROBOd> | annevk: so, then .. I can create whatwg-robod mailing list? :) |
| 17:12 | <annevk> | I didn't get much out of him but I believe the idea is that the browser creates a private key and submits the public key to the server |
| 17:12 | <annevk> | and each time you then submit a <keygen> thing again that key is e-mailed to the server |
| 17:12 | <annevk> | or something in that direction |
| 17:13 | <annevk> | ROBOd, there's already a whatwg⊙mo list if I'm not mistaken |
| 17:13 | <annevk> | (that just copies all the e-mails somewhere else) |
| 17:14 | <sayrer> | you're all jealous of my splinter group! |
| 17:14 | <ROBOd> | sayrer: lol |
| 17:15 | <zcorpan_> | sayrer: you could opt to not read the threads you're not interested in, you know ;) |
| 17:15 | <ROBOd> | sayrer: it's only a splinter... after all :P |
| 17:16 | <ROBOd> | and yes... we all keep up with all the emails |
| 17:16 | <ROBOd> | only Hixie can .... |
| 17:16 | <ROBOd> | *we CANNOT all keep up |
| 17:16 | <annevk> | http://twitter.com/tommorris/statuses/9288361 |
| 17:16 | <MikeSmith> | annevk - so knowing the use case, you will maybe write a <keygen> proposal to the list? |
| 17:17 | <MikeSmith> | or at least ask if anybody else on the list has interest in it being spec'ed? |
| 17:17 | <ROBOd> | and as such, what zcorpan_ suggests is the norm for me: i do not read what i'm not interested of |
| 17:18 | <annevk> | MikeSmith, I believe Ian is already planning on adding it in due course |
| 17:18 | <zcorpan_> | whining about things only adds even more noise to the list |
| 17:18 | <ROBOd> | exactly |
| 17:21 | <annevk> | http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_frm/thread/45ccb1fa7847fea1/39f7e00f8481e524 |
| 17:43 | <hasather> | annevk: Ironically for Jukka, his name is in the Acks :D |
| 17:43 | <billmason> | lol |
| 17:45 | <annevk> | btw, I just pasted this one into #html-wg: http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_frm/thread/68cc062324b71173/50049eff53cbb5f2 (never say never) |
| 17:46 | <hasather> | annevk: hehe |
| 17:47 | <hasather> | I think most of us thought that at the time |
| 17:59 | annevk | moves to some other place |
| 17:59 | <annevk> | bbl |
| 18:35 | <zcorpan_> | hmm, http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/008870.html has surely existed before |
| 18:37 | <zcorpan_> | oh, it's on http://lists.whatwg.org/ now. ok. |
| 18:43 | <annevk> | heh, the <di> joke continues |
| 18:46 | <Hixie> | did he just resend his e-mail? or is my client confused or something. |
| 18:46 | <gavin_> | my client is also confused |
| 18:46 | <gavin_> | so perhaps he did |
| 18:47 | <billmason> | I think he resent it when w3 had a mail outage earlier. |
| 18:49 | <Hixie> | ah |
| 19:27 | <othermaciej> | hi everyone |
| 19:27 | <hasather> | hi |
| 19:28 | <tylerr> | Hi othermaciej. |
| 19:28 | <tylerr> | How's the day going? |
| 19:28 | <othermaciej> | hi tylerr |
| 19:28 | <othermaciej> | going ok |
| 19:29 | <tylerr> | Good good. :) |
| 19:30 | <othermaciej> | looking forward to leading the day's flames |
| 19:30 | <sayrer> | at least you aren't leading a rogue splinter group |
| 19:31 | <tylerr> | Hah! I'm too busy fixing other people's work today to even feel the warmth of the flames. ;) |
| 19:39 | <tylerr> | Mmm, company-wide connection hiccups are fun. :( |
| 19:47 | <billmason> | It's funny how #html-wg is so entertaining to me even though the argument is so far over my head, it's probably looped back under my feet. |
| 20:01 | <Hixie> | right. |
| 20:01 | <Hixie> | so. |
| 20:01 | <Hixie> | <audio> |
| 20:02 | Hixie | tries to extract out an abstract spec from the <video> section |
| 20:02 | <tylerr> | Where should we start on that? |
| 20:02 | <Hixie> | i'm starting from the current spec and apple's proposal |
| 20:03 | <tylerr> | billmason: I'm completely new to all this too, so we can learn together. :) |
| 20:32 | <Dashiva> | Hixie: Your little green guys are getting impatient ;) |
| 20:58 | <Hixie> | Dashiva: i played all my games |
| 21:20 | <Hixie> | looks like hsivonen is going through old threads he's been stockpiling like me :-) |
| 21:23 | <hsivonen> | Hixie: just the one now that I have something to say about bibliographies |
| 21:24 | <Hixie> | hehe |
| 21:26 | <hsivonen> | I need to flush my stockpiled paper scribblings at some point, though |
| 21:27 | <hsivonen> | (stuff that I've written in the margins of the spec prints) |
| 22:04 | <zcorpan_> | http://forums.whatwg.org/profile.php?mode=viewprofile&u=52 i would impossibly be able to tell that was a spammer |
| 22:06 | <hasather> | zcorpan_: I'd say spammer |
| 22:07 | <zcorpan_> | although he did seem to spam manually |
| 22:07 | <zcorpan_> | oh sure, but having admin approval to activate accounts wouldn't help here |
| 22:08 | <Hixie> | not a very good spammer if he is |
| 22:08 | <Hixie> | he didn't do any <a> links to sites anywhere as far as i can tell |
| 22:08 | <Hixie> | hey hyatt |
| 22:08 | <hasather> | zcorpan_: ah, I see what you mean |
| 22:09 | <hyatt> | Hixie: howdy |
| 22:11 | Hixie | splits <video> into <video> and an HTMLMediaElement abstract concept |
| 22:12 | <Dashiva> | Indeed |
| 22:12 | <Hixie> | christ that ended up being nearly a 40000 line diff |
| 22:12 | <Hixie> | oh i think bert must have updated his script |
| 22:16 | <hyatt> | Hixie: did you spec <marquee> in html5? |
| 22:16 | <Hixie> | no |
| 22:17 | <Hixie> | (nobody asked for it) |
| 22:17 | <Hixie> | (and i didn't think about adding it) |
| 22:18 | <hyatt> | given that everyone implements it |
| 22:18 | kingryan | is tempted to ask for it, just because :D |
| 22:18 | <hyatt> | i think it should be in the spec |
| 22:18 | <Hixie> | oh it'll be in the rendering section for sure |
| 22:19 | <Hixie> | i haven't even started that |
| 22:19 | <Hixie> | i thought you meant in the language (i.e. allowed) |
| 22:25 | zcorpan_ | should also go away and write his own spec on forms, then ask for it to be merged with WF2 |
| 22:32 | <tylerr> | Quick question. I'm organizing all the tags into element types. Using the working draft as my source, is the order of the grouping significant in any way? |
| 22:33 | <Lachy_> | tylerr: what do you mean? |
| 22:33 | <tylerr> | As an example, <aside> is both a sectioning and block-level element. |
| 22:34 | <tylerr> | I'm trying to determine how to group elements that are a part of multiple types. |
| 22:35 | <zcorpan_> | they are grouped in the spec, e.g. "Lists", "Phrase elements", etc. |
| 22:35 | <Lachy_> | well, in that example, all sectioning elements are inherently block level anyway |
| 22:35 | <zcorpan_> | except <body> |
| 22:35 | <tylerr> | Ah right. |
| 22:36 | <Lachy_> | that seems like a sensible grouping method |
| 22:36 | <tylerr> | I'm getting the elements grouped up so that I can start drafting up my articles. |
| 22:36 | <Lachy_> | though, it depends on your needs. I assume this has something to do with that series of articles you're planning? |
| 22:36 | <Lachy_> | ok. |
| 22:37 | <tylerr> | I'm just stripping all the excess out for the moment and trying to get a very basic organized group established. |
| 22:38 | <Hixie> | i wouldn't worry about putting them into mutually exclusive gorups |
| 22:38 | <Hixie> | groups |
| 22:38 | <Hixie> | i'd look at it more from a general feature perspective, e.g. tutorials about sections, tutorials about overall structure (<body> would be in both), etc |
| 22:39 | <tylerr> | That's what will be the end product I hope Hixie for my articles. |
| 22:39 | <Hixie> | cool |
| 22:39 | <tylerr> | If you're familiar with "Web Standards Solutions" or "HTML Mastery", I'll be following their structure. |
| 22:39 | <tylerr> | Just in smaller more digestible chunks. :) |
| 22:41 | <tylerr> | So you would suggest then articles on things like, "Root", "Metadata", "Sections", "Prose", etc. as per the spec? |
| 22:42 | <tylerr> | I think that's the best way to approach it. |
| 22:42 | <Hixie> | dunno |
| 22:42 | <Hixie> | i'm not a tutorial author |
| 22:42 | <Hixie> | i have no idea what authors want |
| 22:42 | <Hixie> | or need |
| 22:42 | <tylerr> | :) |
| 22:42 | <Lachy_> | you might want to try structuring it around the use cases |
| 22:42 | <bewest> | cookbook style? |
| 22:43 | <Lachy_> | yeah, I guess |
| 22:43 | <Lachy_> | e.g. Talk about how to create a graph with <canvas>, or make a drop down toolbar menu with <menu>, etc. |
| 22:44 | <tylerr> | Sure. Perhaps as a use case at the end of the explaination and such? |
| 22:44 | <tylerr> | Like, introduce the <canvas> element, talk about its uses and properties, then give the use case. |
| 22:44 | <tylerr> | Those could be two separate entries though I suppose. |
| 22:44 | <Lachy_> | talking about it's uses means to give the use cases, doesn't it? |
| 22:45 | <tylerr> | Well, describe the element briefly, then dive into the use case rather. :) |
| 22:45 | <Lachy_> | I'd start with describing the use case, introduce the elements that can be used to solve it, and then demonstrate how |
| 22:46 | <zcorpan_> | yeah |
| 22:46 | <tylerr> | Cool, good concept. |
| 22:46 | <tylerr> | "Problem -> Solution -> Implementation" |
| 22:46 | <Lachy_> | yes, exactly! |
| 22:46 | <Hixie> | hmmm |
| 22:46 | Hixie | ponders about reusing <param> |
| 22:47 | <Lachy_> | Hixie, I think that was a good idea |
| 22:47 | <tylerr> | Heh, after enough of these, I'd have the makings of a book. :p |
| 22:48 | <tylerr> | Now the question is, whom is the audience? Experienced HTML authors wanting to migrate to HTML5, or fresh off the cutting block newbies, or both? :) |
| 22:49 | <tylerr> | And then there is the issue of styling the implementations and enhancing them with behaviors. |
| 22:49 | <Hixie> | sweet, IE doesn't drop <param> elements inside <video> tags |
| 22:49 | <Hixie> | and it even keeps the attributes |
| 22:49 | <Hixie> | score! |
| 22:49 | <tylerr> | So many things to cover... |
| 22:49 | tylerr | grins |
| 22:49 | <bewest> | that reminds me to check how button works in html5 |
| 22:51 | <bewest> | oooo - would <button> be in forms? (I'm specifically curious as to whether or not the spec takes a stance on IE's behaviour of re-assigning the node contents to the value attribute) |
| 22:51 | <Hixie> | that's bogus. bug in ie. |
| 22:51 | <Hixie> | and yes it's in wf2 |
| 22:51 | <Lachy_> | tylerr: I am writing a book like that on HTML5, maybe I'll rip off some of your articles ;-) |
| 22:51 | <tylerr> | Haha! |
| 22:52 | <tylerr> | What's the context? For beginners? |
| 22:52 | <bewest> | yeah, that is my pet peeve |
| 22:52 | <bewest> | I hate that behaviour |
| 22:52 | <Lachy_> | It should cover from beginner to advanced authors |
| 22:53 | <tylerr> | Ah lovely. |
| 22:53 | <tylerr> | Perhaps if this turns into a book for me, we'll suggest eachothers' work's in the intros. ;) |
| 22:54 | <tylerr> | Too many apostrophes. :) |
| 23:01 | <tylerr> | So here's an idea. Take each of the sections and have a use case that is comprised of steps, or levels of enhancement. |
| 23:06 | <tylerr> | As an example, start with a <p>, give it enhancements with <em>/<strong>/etc. move on to breaking up quotes with <blockquote>, so on and so forth. All the while introducing each of these elements. |
| 23:07 | <Lachy_> | yeah, but aren't you only writing about the new features in HTML5, not those that have been in HTML forever? |
| 23:08 | <Hixie> | probably makes sense to treat them the same, if you're targetting newbies |
| 23:09 | <tylerr> | It all depends on whom I'm targeting. |
| 23:09 | <tylerr> | Which I haven't decided upon yet. :) |
| 23:09 | <zcorpan_> | people reading the whatwg blog probably already know about html4, i'd think |
| 23:10 | <zcorpan_> | as a start, i'd focus on new features that are implemented in some browser |
| 23:10 | <tylerr> | Sure. Perhaps I'll start with the new items, particularly the ones already implemented, them move on from there. |
| 23:10 | <tylerr> | So <canvas>, then move on from there. ;) |
| 23:12 | <zcorpan_> | now we're talking ;) |
| 23:12 | <tylerr> | Anyway, more tomorrow, as I'm off for the evening. Cheers everyone! |
| 23:12 | <zcorpan_> | bye |
| 23:23 | <Hixie> | so |
| 23:23 | <Hixie> | othermaciej: the <param> thing is great, but it poses an interesting design choice |
| 23:23 | <Hixie> | othermaciej: should we say that the choice of which media resource to use is only made when you call .play() the first time (or after a .stop() call), and that dynamic changes to the document are otherwise ignored? |
| 23:23 | <othermaciej> | Hixie: after talking to Darin, I don't think it should use the <param> element, seems wonky to reuse it with a whole separate set of attributes |
| 23:24 | <Hixie> | well i don't mind what we call the element, <param> has the advantage of not requiring parser changes (legacy UAs would treat a new element as being an inline element, not just an empty one) |
| 23:24 | <Hixie> | (IE notwithstanding) |
| 23:24 | <othermaciej> | Hixie: my thought on how static fallback should work: |
| 23:25 | <othermaciej> | 1) You first do it when you hit the video close tag |
| 23:26 | <Hixie> | hrm, i'm trying to avoid things that depend on parsing the end tag. </script> is the only one that does that right now. |
| 23:26 | <Hixie> | doing that makes a dichtomy between dynamic mutations and parsing |
| 23:26 | <Hixie> | which is annoying to spec (puts knowledge of the element into the parser part of the spec) |
| 23:27 | <Hixie> | but we can do it on the invokation of play(), and say that that gets called automatically onload if autoplay is set |
| 23:28 | <othermaciej> | Hixie: sorry, in meeting, I'll get back to this shortly (less than 30 min) |
| 23:28 | <Hixie> | k |
| 23:28 | <Hixie> | no worries |
| 23:30 | <Lachy_> | Hixie, I don't understand what you mean by "the choice of which media resource to use is only made when you call .play() the first time" |
| 23:31 | <Lachy_> | doesn't the UA need to choose choose the suitable format from those available and downlaod it before play() is invoked? |
| 23:31 | <Hixie> | no, .play() is what starts the download in the current spec |
| 23:31 | <Lachy_> | oh, did that change? |
| 23:31 | <Lachy_> | maybe I just didn't read carefully enough |
| 23:32 | <Hixie> | well the UA can precache before if it wants |
| 23:32 | <Hixie> | but that isn't required |
| 23:33 | <Lachy_> | ok, so that handles YouTybe's case where videos embedded on other sites don't begin downloading till the user requests, but UAs would need to provide an easy way to start downloading in the background before play)( |
| 23:33 | <Lachy_> | play() |
| 23:35 | <Hixie> | hm fair point |
| 23:35 | <Hixie> | although |
| 23:35 | <Hixie> | wouldn't that be just up to the UA |
| 23:35 | <Hixie> | i mean, the author shouldn't have to say "download this, you might need it", surely, having a <video> there is enough to do that |
| 23:35 | <Hixie> | brb |
| 23:36 | <Lachy_> | yes, it would be up to the UA. Isn't that what I said? |
| 23:41 | <Hixie> | oh |
| 23:41 | <Hixie> | i guess i misunderstood "would need to provide an easy way" |
| 23:42 | <Lachy_> | that sentence begun with "but UAs ...", and figuring out the "easy way" is up to their UI designers |
| 23:47 | <Hixie> | i don't understand why there'd be any ui |
| 23:47 | <Hixie> | wouldn't browsers just do it? |
| 23:48 | <Hixie> | though i guess if we do do this we _should_ send events so that the author-driven ui can update too |
| 23:49 | <othermaciej> | Hixie: will have much to say on this once I am out of my meeting, topic is too complex to discuss in background to this meeting |
| 23:50 | <Hixie> | sure |
| 23:50 | Hixie | is playing while he waits :-D |
| 23:53 | <bewest> | Hixie: how many documents do you have that contain a classname containing "vcard" somewhere in the document? |
| 23:53 | <Hixie> | haven't done a classname survey for many months |
| 23:53 | <Hixie> | when i did it it wasn't many |
| 23:53 | <Hixie> | but that was at least 6 months ago now |
| 23:54 | bewest | nods |
| 23:54 | <bewest> | what is the rough range of not many? |
| 23:55 | <Lachy_> | Hixie, it depends. In some cases it makes sense to immediately start downloading and buffering the video, in others it doesn't. |
| 23:56 | <Lachy_> | e.g. when on YouTube, I like to open new videos in background tabs and have them load while I'm watching another, but if I just happen to come across a blog with a video in it, I'd like to decide whether or not I want to download it first |
| 23:56 | <Hixie> | bewest: not in the top 1000 class names. less common than class="srchbox_keywords_div" or class="affiliates_wrapper" or class="ex_hdr_cell" |
| 23:56 | <bewest> | hmmm that's interesting |
| 23:56 | bewest | looks for himself |
| 23:56 | <Hixie> | Lachy_: hm, fair enough. not sure how to tell the difference, but yeah, that would be a ui thing. |
| 23:56 | <zcorpan_> | Lachy_: the one on youtube in a background tab would have autoplay="" |
| 23:57 | <zcorpan_> | the blog with video in it wouldn't |
| 23:57 | <Hixie> | you'd hope |
| 23:57 | <Lachy_> | possibly, but I wouldn't want the video to actually play until I swtich to that tab. I guess that's also up to the UA, since that's Safari's behaviour |
| 23:58 | <Hixie> | does safari even buffer? |
| 23:58 | <bewest> | do authors copy/paste those from somewhere? |
| 23:58 | <Lachy_> | not sure, I only know what othermaciej told me a few days ago |
| 23:59 | <Lachy_> | I haven't tested it out yet |