| 00:07 | <chin1> | you guys got an email i can send to along with public-webapi⊙wo at the same time ? |
| 00:12 | <Hixie> | hmm |
| 00:12 | <Hixie> | how to do the ui thing |
| 00:12 | <Hixie> | hmmmmmmm |
| 00:12 | <Hixie> | we need a way to allow any ui, but to have the ui immediately appear if there's no js-provided ui, but have the ui not appear at all if there is |
| 00:13 | <Hixie> | maybe an event handler? |
| 00:13 | <Hixie> | hmmm |
| 00:14 | <Dashiva> | What happened to the attribute? |
| 00:14 | <Hixie> | the attribute to do what? |
| 00:14 | <Dashiva> | To specify if the ui should appear or not |
| 00:15 | <Hixie> | you don't want a declarative way of doing it, since you'll only want no ui when you have scripted control |
| 00:15 | <Hixie> | so you want the ui to turn _off_ from script |
| 00:15 | <Hixie> | and be on by default otherwise |
| 00:15 | <Hixie> | the problem is you want a way to turn off the default ui without the ui ever actually appearing in the first place |
| 00:16 | <Hixie> | tough one |
| 00:16 | <Dashiva> | Ah, you mean so the ui doesn't hide for JS disabled? |
| 00:16 | <Hixie> | yeah |
| 00:16 | <Dashiva> | <noscript>ui="false"<noscript> :) |
| 00:16 | <Lachy_> | hi |
| 00:17 | <tylerr> | Hi Lachy_. |
| 00:18 | <tylerr> | I could have really used the <dialog> element today. |
| 00:18 | <Hixie> | Dashiva: yeah but you don't want it to just be js-bound (since then we could just have it be on when js is off), you want it bound to the loading of the actual js in question |
| 00:18 | <tylerr> | Had to throw a transcript onto a page for a client. |
| 00:18 | <Lachy_> | Hixie, if script is disabled or unsupported, the UI should show by default (perhaps depending on user prefs). |
| 00:19 | <Dashiva> | Hixie: So basically, a script should be able to ping in (probably on load or domcontentloaded) to say "I'm here, go away ui" |
| 00:19 | <Lachy_> | it's when script is enabled, but no script is provided that's harder |
| 00:19 | <Hixie> | Dashiva: yeah |
| 00:19 | <Hixie> | Dashiva: but it should work without flicker |
| 00:19 | <Hixie> | which is the hard part |
| 00:19 | <othermaciej> | Hixie: how about declare to have UI on, but if script is disabled, UAs MAY show default UI even if not enabled |
| 00:20 | <Dashiva> | What if you said "Default UI should not be shown before domcontentloaded is fired" or somesuch? |
| 00:20 | <Hixie> | Dashiva: then you get flicker the other way around |
| 00:20 | <Hixie> | othermaciej: we could... |
| 00:20 | <othermaciej> | I mean, if we are worried about the special case of not having script, then just trigger off that |
| 00:20 | <othermaciej> | but I don't think it's a terribly important case personally |
| 00:21 | <Lachy_> | so we need a way to know whether or not a UI is provided as soon as the <video> is added to the DOM, and it seems the only way to do that is with an attribute |
| 00:21 | <Dashiva> | Hixie: I wouldn't consider it flicker, it's no different from images taking a while to load even though the page is done |
| 00:21 | <Dashiva> | Flicker would be appearing and disappearing again |
| 00:21 | <Hixie> | othermaciej: it's also in the case where the ui js didn't load for some reason |
| 00:22 | <Hixie> | othermaciej: but yeah, maybe we shouldn't support it at all |
| 00:22 | <Hixie> | Dashiva: ok, bouncing, whatever you want to call it :-) |
| 00:22 | <Dashiva> | If you make it fade in, it might even look cool |
| 00:22 | <Dashiva> | "cool" |
| 00:22 | <Hixie> | heh |
| 00:23 | <Hixie> | Lachy_: it's not the only way |
| 00:23 | <Hixie> | Lachy_: we could synchronously fire an event handler |
| 00:23 | <Hixie> | <video ondecidewhethertohaveui="return false"> |
| 00:23 | <Hixie> | which fires when the element is inserted |
| 00:23 | <Hixie> | or rather, onshowui="" |
| 00:24 | <Lachy_> | that still requires an event attribute |
| 00:24 | <Hixie> | which you can cancel |
| 00:24 | <Hixie> | right, an attribute of some kind, certainly |
| 00:24 | <Hixie> | i thought you meant a boolean one, sorry |
| 00:25 | <Lachy_> | you could also listen for DOMNodeInserted (or whatever it's called) on the document, and when a video element is inserted, turn the UI off |
| 00:25 | <Hixie> | yeah, e.g. |
| 00:25 | <Hixie> | i'm sort of liking this onshowui="false" solution |
| 00:26 | <Hixie> | it looks declarative, solves the no-js situation, and allows advanced decision making without flicker or bouncing |
| 00:26 | <Lachy_> | I just don't see the benefit in controlling it via an event handler attribute as opposed to a boolean |
| 00:26 | <Hixie> | the boolean isn't linked to the execution of JS, and can't call to check to see whether you really need UI (e.g. check to see if thte relevant .js file loaded at all) |
| 00:27 | <Lachy_> | ok |
| 00:27 | <Lachy_> | but wouldn't it have to be onshowui="return false;" ? |
| 00:28 | <Hixie> | as opposed to? |
| 00:28 | <Lachy_> | to what you said above |
| 00:28 | <Lachy_> | onshowui="false" would be a JS error |
| 00:28 | <Lachy_> | wouldn't it? |
| 00:28 | <Hixie> | return is implied on the last statement in JS bodies |
| 00:28 | <Hixie> | and the semicolon is optional at end of lines in JS |
| 00:28 | <Hixie> | so "return false;" and "false" are exactly equivalent in event handlers |
| 00:28 | <Hixie> | aiui |
| 00:29 | <Lachy_> | yeah, the return is implied, but it doesn't return the last statment |
| 00:29 | <Lachy_> | it returns null |
| 00:29 | <Hixie> | really? i thought it returned the last expression. |
| 00:29 | <Hixie> | ok, then onshowui="return false" |
| 00:29 | Lachy_ | goes to make a test case... |
| 00:30 | <Dashiva> | It will "return" the last value if you use javascript: in the address bar, a common annoyance :) |
| 00:31 | <Lachy_> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Ca%20href%3D%22http%3A//www.google.com/%22%20onclick%3D%22false%22%3EImplicit%20Return%3C/a%3E%0A%3Ca%20href%3D%22http%3A//www.google.com/%22%20onclick%3D%22return%20false%22%3EExplicit%20Return%3C/a%3E |
| 00:31 | <othermaciej> | making showui an event is kinda hokey |
| 00:31 | <Hixie> | Lachy_: indeed |
| 00:31 | <Lachy_> | maybe make it oninit, and have a DOM Attribute: video.ui = false; |
| 00:31 | <Hixie> | othermaciej: yeah maybe we don't solve this case, just seems kinda crappy not to though |
| 00:32 | <othermaciej> | Hixie: the "don't have script on" case? |
| 00:32 | <Lachy_> | browsers can always allow users to turn on UI from the context menu |
| 00:32 | <othermaciej> | I think my proposal of ui=on to call for UI, plus permission or mandate to turn it on if script is off or unsupported, is sufficient |
| 00:32 | <Hixie> | othermaciej: or the "script isn't working for some reason" case |
| 00:33 | <othermaciej> | "script isn't working for some reason" is likely to break much more than your video controls |
| 00:33 | <Hixie> | othermaciej: yeah, i'm just seeing if we can go beyond sufficient. i agree your proposal is the fallback position. |
| 00:33 | <othermaciej> | if you depend on script to any significant extent |
| 00:33 | <Hixie> | yep |
| 00:33 | <Lachy_> | onshowui="return false;" doessn't even handle the case where the rest of the script didn't load |
| 00:33 | <othermaciej> | I don't think individual scripts failing to load is something we can turn into a good experience |
| 00:33 | <Hixie> | Lachy_: indeed |
| 00:34 | <Hixie> | the other thing is do we want to default to a native ui being enabled or not? there are good arguments both ways |
| 00:34 | <Philip`> | (Lachy_: JS returns undefined if you fall off the end of a function without a return, rather than null) |
| 00:34 | <Hixie> | typically the same arguments, namely "we want that to be the default because it's the more common case and would make life easier" |
| 00:35 | <Lachy_> | Philip`: ok |
| 00:37 | <othermaciej> | I think asking to turn something on is slightly more tasteful than asking to turn it off, but it doesn't seem like a huge deal |
| 00:37 | <Dashiva> | Is it acceptable to delegate to UAs to decide on their own to override and enable UI when scripting is disabled? |
| 00:37 | <othermaciej> | if it's just ui=on, that's 5 chars to get default controls |
| 00:37 | <othermaciej> | in the script case you need extra script content for the controls you are adding |
| 00:37 | <Hixie> | i'm curious how many people are going to bother to use ua-provided ui |
| 00:38 | <Dashiva> | I see three user groups: Big sites with branding, small sites with cool web 2.0 custom UIs, and other sites which just want video |
| 00:38 | <Dashiva> | The latter group might be tiny |
| 00:38 | <Hixie> | the other thing is, would we want ui="" to default to on or off for <audio>? |
| 00:39 | <Hixie> | othermaciej: (actually it'd be just three extra characters: <video src='...'> vs <video ui src='...'>) |
| 00:39 | <Hixie> | (i'd want <audio> and <video> to have the same default) |
| 00:39 | <Dashiva> | I say default on for both video and audio. Hidden sound I can't turn off is a bad idea |
| 00:39 | <othermaciej> | I imagine a blogger randomly embedding a video would be happy with default controls |
| 00:40 | <othermaciej> | but they might be embedding from a hosting site which wants you to use their controls |
| 00:40 | <othermaciej> | Hixie: good point |
| 00:40 | <othermaciej> | anyway, I think negatives are a bit harder to understand, since lack of it is then conceptually a double negative |
| 00:40 | <Hixie> | yeah |
| 00:40 | <othermaciej> | if (!video.noui) |
| 00:41 | <Hixie> | so that implies default-off |
| 00:43 | <othermaciej> | yes, although other considerations could override, but it seems a toss-up otherwise |
| 00:44 | <Lachy_> | I'm happy with either default, it makes little difference to me |
| 00:45 | <Dashiva> | If default is off, we can equalize "author forgot to specify UI" with "UI script failed to load" |
| 00:47 | <Lachy_> | but should we call the attribute ui=""? Should we expect the average author to understand what UI means? |
| 00:48 | <Hixie> | what would you call it? |
| 00:48 | <Hixie> | ui is compellingly short |
| 00:48 | <Lachy_> | maybe controls="on" |
| 00:49 | <Hixie> | this will be a boolean attribute |
| 00:49 | <Lachy_> | I know it's short, but UI is a technical term |
| 00:49 | <Hixie> | <video controls> |
| 00:49 | <othermaciej> | controls="" would be maybe a bit more clear |
| 00:49 | <othermaciej> | but a tiny bit longer to type |
| 00:49 | <Lachy_> | IIRC, the windows media player plugin uses <param name="controls"> |
| 00:50 | <Hixie> | ok controls it is. |
| 00:51 | <Hixie> | autoplay="". |
| 00:51 | <Hixie> | hmm. |
| 00:51 | <Hixie> | to do autoplay='' i guess we need to have the new states first |
| 00:52 | <othermaciej> | yes, probably |
| 01:05 | <Hixie> | this state thing is an interesting problem. |
| 01:05 | <Hixie> | there are two sets of state that are relevant that i can see |
| 01:05 | <Hixie> | the state from the user/ui perspective, and the state from the ua perspective |
| 01:07 | <Hixie> | from the user's perspective, you have playing, not playing because i told it not to play, not playing but it could soon play, and not playing and it won't play |
| 01:07 | <Hixie> | these correspond to the current states PLAYING, PAUSED, AUTO-PAUSED, and STOPPED |
| 01:07 | <Hixie> | from the ua's perspective, whether you're playing or not is almost incidental |
| 01:08 | <othermaciej> | our states are designed from the script-driven control perspective |
| 01:08 | <Dashiva> | What about moving in the data at other rates than 1.0? |
| 01:08 | <Dashiva> | Is rewinding PLAYING? |
| 01:08 | <Hixie> | and you have the states in the apple proposal: no idea what's going on, we tried and it failed, we're loading, we're loading and can render something, we're loading and can play something, we're loading and can play something and it's likely that we won't catch up to our cache, and we're done loading. |
| 01:09 | <othermaciej> | each state change is supposed to be tied to some UI change you would make |
| 01:09 | <Hixie> | which are the apple states respectively |
| 01:09 | <othermaciej> | (although playing or not is also relevant to script-driven UI, but we have one bit for that) |
| 01:10 | <Dashiva> | I'm almost tempted to suggest a <stream> element for non-finite video |
| 01:10 | <Hixie> | the two sets of states really are parallel but not really overlapping, it's kind of weird, i wouldn't have thought we could come up with two so close yet not overlapping sets of state |
| 01:10 | <othermaciej> | well, we just have a "paused" boolean for playing vs. paused |
| 01:11 | <Dashiva> | And .currentRate for the velocity, wasn't it? |
| 01:11 | <Hixie> | othermaciej: yeah but you can be paused even when the ui should be showing "playing" as the state, simply because you're buffering |
| 01:11 | <othermaciej> | STOPPED is not a distinct state (unless it is the same as UNINITIALIZED) and AUTO-PAUSED is not directly reflected though it can be inferred |
| 01:11 | <othermaciej> | yes, we don't consider auto-paused as paused |
| 01:11 | <Hixie> | STOPPED is the same as UNINITIALIZED (but easier to spell) |
| 01:11 | <othermaciej> | EMPTY might be a good name for that |
| 01:11 | <Hixie> | also same as ERROR |
| 01:11 | <Hixie> | yeah |
| 01:12 | Hixie | changes STOPPED to EMPTY in the spec |
| 01:12 | <othermaciej> | we also don't have a "buffering" boolean |
| 01:12 | <Hixie> | yeah "buffering" is basically states 2 through 5 of your state machine |
| 01:12 | <othermaciej> | since it is assumed that what you care about is currently available time chunks and when they change |
| 01:12 | <Hixie> | well the spec also has buffered |
| 01:12 | <Hixie> | which lists the time chunks |
| 01:13 | <othermaciej> | yes, that's more informative than our availableDuration boolean |
| 01:13 | <othermaciej> | both are kind of weird if you have an implementation that might discard some buffers |
| 01:13 | <Hixie> | yeah |
| 01:13 | <Hixie> | we need an event for when they change |
| 01:13 | <othermaciej> | because then you just want to pretend it's all available |
| 01:13 | <Hixie> | 'buffering' or 'bufferchange' or something |
| 01:13 | <othermaciej> | er, availableDuration float, not boolean |
| 01:14 | <othermaciej> | we just overloaded durationchange to apply to both duration and availableDuration, but that's kinda lame |
| 01:14 | <Hixie> | yeah not dealing with duration changes right now, that's for tomorrow or later or something :-) |
| 01:14 | <Hixie> | mostly i'm trying to work out what to do with these states |
| 01:15 | <Hixie> | i like the simple four-state system we have now, but it needs to handle the stuff you guys have done too |
| 01:15 | <Dashiva> | should watch out so there aren't any dead states in the final proposal, like the first few readyStates for xmlhttprequest |
| 01:16 | <othermaciej> | well, the extra booleans you have sort of imply extra states |
| 01:17 | <othermaciej> | like I said, we tried to tie the state changes to times when a script-driven controller would want to take an action to update the UI |
| 01:18 | <othermaciej> | I think with your states, it's impossible to tell whether to enable the play/pause button, since there's no way to determine current playability at all |
| 01:19 | <ericcarlson> | There really are two different states to track: loading and playback |
| 01:19 | <othermaciej> | and if you want to show some kind of spinner over the video area before there is even an initial frame to show, you can't do that |
| 01:20 | <Dashiva> | ericcarlson: But some combinations are mutually exclusive, so by combining them you can remove the impossible ones |
| 01:20 | <othermaciej> | Dashiva: but by combining them you end up with a crazy number of states |
| 01:20 | <Hixie> | othermaciej: that's true, yeah |
| 01:21 | <Dashiva> | That's also true |
| 01:22 | <othermaciej> | PLAYTHROUGHOK is mainly useful for a script-driven decision to auto-play |
| 01:22 | <Hixie> | yep |
| 01:23 | <Dashiva> | Although, auto-paused suggests the UA will also auto-resume, probably at that same state, no? |
| 01:23 | <Hixie> | hmm |
| 01:23 | <othermaciej> | yes, we would treat auto-paused as not paused w/ assumption that UA will auto-resume |
| 01:23 | <Hixie> | othermaciej: would you be ok with having both, playState and readyState ? |
| 01:23 | <othermaciej> | since there's no real UI action to take at that time |
| 01:24 | <othermaciej> | Hixie: I would, but I'd like to be convinced that playState can't be collapsed to a boolean |
| 01:24 | <Hixie> | othermaciej: well, it's 2 bits of information. does the ua want to play, and does the user want to play. so i guess it's two booleans. |
| 01:24 | <Hixie> | othermaciej: i'd be ok with two booleans i guess |
| 01:24 | <Dashiva> | What's the difference between PAUSED and STOPPED? As I understand playback, pause = stop at current offset, stop = stop at beginning of clip |
| 01:25 | <Hixie> | Dashiva: STOPPED is now EMPTY |
| 01:25 | <Hixie> | which is basically the same as UNINITIALISED in the apple proposal |
| 01:25 | <othermaciej> | Hixie: not sure what you mean by "does the UA want to play" |
| 01:25 | <othermaciej> | it's really more like "is time currently advancing", isn't it? |
| 01:26 | <Dashiva> | But for playState, does whether it's stopped or paused really matter? In either case it's not playing. |
| 01:26 | <Hixie> | othermaciej: e.g. when the user agent is seeking, it can't play, even though the user thinks it isn't paused |
| 01:26 | <othermaciej> | (I assume in what you call auto-pause, the user still wants to play, but time is not advancing) |
| 01:26 | <Hixie> | othermaciej: right |
| 01:26 | <othermaciej> | so we'd represent that as a currentRate of 0 I think |
| 01:26 | <othermaciej> | but paused would be false |
| 01:26 | <Hixie> | hm |
| 01:26 | Dashiva | likes that |
| 01:26 | <Hixie> | i was hoping we could collapse currentRate and playbackRate to one mutable attribute |
| 01:27 | <Dashiva> | I'm thinking (not as actual names) preferredRate and actualRate |
| 01:28 | <Dashiva> | But are there more states to currentRate than either playbackRate and 0? |
| 01:29 | Hixie | would like to relegate rate controls purely to the situation of playing back at different rates, rather than have authors have to deal with it even in simple uis |
| 01:30 | <Dashiva> | I'm not typing straight, better head to bed. Good luck with the wrangling. |
| 01:30 | <Hixie> | othermaciej: btw there seems to be a state missing between UNINITIALZED and UNDERSTANDABLE if you're using the states as a way to report current status |
| 01:30 | <Hixie> | namely the state where you're initialised, but haven't yet gotten a response |
| 01:30 | <Hixie> | "OPEN", for lack of a better term |
| 01:32 | <othermaciej> | Hixie: or LOADING maybe |
| 01:32 | <othermaciej> | Hixie: I think you are right |
| 01:33 | <Hixie> | another idea for PLAYABLE vs PLAYTHROUGHOK, not that i like it, much is to have downloadRate, and have people compare that to playbackRate to see if it's safe yet |
| 01:33 | <Hixie> | no i guess that doesn't work |
| 01:33 | <Hixie> | nevermind |
| 01:33 | <Hixie> | othermaciej: yeah |
| 01:34 | <othermaciej> | if you buffer on demand, downloadRate could be changing all the time |
| 01:34 | <Hixie> | yup |
| 01:34 | <Hixie> | yeah i think that idea sucks |
| 01:34 | <Hixie> | you know, we could split out your states into multiple booleans too |
| 01:35 | <Hixie> | and just have a farm of booleans, each with its own event |
| 01:35 | <Hixie> | not that i like that idea either |
| 01:35 | <Hixie> | i'm just thinking out loud here |
| 01:36 | <othermaciej> | yes, there could be a bool farm, but I think the state machine diagram is enlightening and would be harder to draw for bools |
| 01:36 | <othermaciej> | there would be many invalid combinations |
| 01:37 | <Hixie> | i'm not convinced the current state machine is really right |
| 01:37 | <Hixie> | e.g. you could seek and go from playable to playthroughok |
| 01:38 | <othermaciej> | that's true |
| 01:38 | <Hixie> | and you can get to the empty state from anywhere assuming we keep the method to do close the current video stream |
| 01:38 | <Hixie> | at which point it's pretty messy anyway |
| 01:38 | <Hixie> | not that i think all bools is better |
| 01:39 | <othermaciej> | yeah, I'm not sure a method to close down is all that useful |
| 01:39 | <othermaciej> | but that would be logically consistent, to return to EMPTY |
| 01:40 | <Hixie> | yeah that's why i added stop() back when i added it, mostly for symmetry. I agree it's not overly useful. |
| 01:40 | <Hixie> | we can drop it, i'm not tied to it or anything |
| 01:40 | <othermaciej> | you could seek from presentable to playable too |
| 01:40 | <Hixie> | yeah |
| 01:41 | <Hixie> | why can you seek to understandable? is that equivalent to seeking to a part of the stream you don't have any data for? |
| 01:41 | <othermaciej> | yes |
| 01:41 | <othermaciej> | so you don't have a frame to show for that position |
| 01:41 | <othermaciej> | though in that case you most likely want to just keep showing the last frame played |
| 01:41 | <Hixie> | so you can seek from there to all the other states too |
| 01:42 | <othermaciej> | yeah |
| 01:42 | <Hixie> | basically seek can take you from any of the four inner states to any of the other four inner states |
| 01:42 | <Hixie> | yeah the current spec says to keep showing hte last frame |
| 01:42 | <Hixie> | i'm not sure we want to expose whether or not we have the current playback position's frame's data necessarily |
| 01:42 | <othermaciej> | all seek arcs should be bidirectional |
| 01:43 | <Hixie> | it makes sense at the start to go from never having had a frame to having the first frame |
| 01:43 | <Hixie> | but i don't know that we should expose more than that |
| 01:43 | <othermaciej> | I dunno either |
| 01:43 | othermaciej | wonders if ericcarlson has a more informed opinion |
| 01:44 | <Hixie> | i'm tempted to propose having the following states: EMPTY ERROR LOADING BUFFERING LOADED, and having two booleans: canPlay, and canPlayThroughToTheEnd (names obviously not final) |
| 01:45 | <othermaciej> | so what event happens when you become playable or stop being playable? |
| 01:46 | <Hixie> | an event would happen when canPlay changes, same as now when you go from playing to autopaused and back again |
| 01:46 | <othermaciej> | playabilitychanged separate from the states? |
| 01:46 | <Hixie> | and an event would happen when canPlayThrough becomes true |
| 01:46 | <othermaciej> | so basically this partitions the BUFFERING state into 3 possibilities (since one combo of the booleans is impossible) |
| 01:46 | <Hixie> | oncanplaychange and onautoplayready maybe |
| 01:46 | <Hixie> | yeah |
| 01:47 | <Hixie> | and lets ui designers focus on the parts they care about |
| 01:47 | <othermaciej> | also not clear on the diff between LOADING and BUFFERING |
| 01:47 | <Hixie> | oh LOADING would be the new state that isn't in your system, and BUFFERING is the four middle states |
| 01:47 | <othermaciej> | well, all the state changes have an individual event, so that's not too hard to do, except for syncing up to an already operating video |
| 01:47 | <Hixie> | LOADING is "we've begun, but don't have any useful data yet so the attributes like height and width aren't useful yet" |
| 01:48 | <othermaciej> | UNDERSTANDABLE vs. PRESENTABLE distinction seems to be lost in your system |
| 01:48 | <Hixie> | yeah, that's the one that i wasn't sure we should expose |
| 01:48 | <othermaciej> | (both would be BUFFERING with canPlay and canPlayThroughToTheEnd true) |
| 01:48 | <Hixie> | false |
| 01:48 | <Hixie> | but yes |
| 01:48 | <othermaciej> | er, yeah, false |
| 01:48 | <othermaciej> | it is a useful distinction |
| 01:49 | <Hixie> | it's useful for the software doing the actual playback, but what ui distinction would you make? |
| 01:49 | <othermaciej> | at UNDERSTANDABLE, you know width, height, and possibly metadata like title / artist, track list, etc (future extension) |
| 01:49 | <othermaciej> | at PRESENTABLE, you can remove placeholder UI over content area and show the first frame |
| 01:49 | <Hixie> | oh, hm, interesting |
| 01:49 | <ericcarlson> | the first PRESENTABLE state is important as it is the first time you know there is something to display |
| 01:49 | <Hixie> | so yeah you'd want that transition at the first-- |
| 01:49 | <Hixie> | right |
| 01:49 | <Hixie> | what you said |
| 01:51 | <ericcarlson> | [cooking dinner for the kids, having a hard time keeping up on the discussion] |
| 01:51 | <Hixie> | ericcarlson: i'll make sure whatever we come up with you can review carefully at your leisure |
| 01:52 | <Hixie> | so really we want the readyStates to be EMPTY ERROR LOADING [some state meaning that metadata is in but not video or audio data] BUFFERING LOADED |
| 01:52 | <ericcarlson> | thx |
| 01:52 | <Hixie> | i'm at a loss for a good name though |
| 01:53 | <ericcarlson> | LOADING isn't a great name since it is technically "loading" as long as data is being downloaded |
| 01:53 | <othermaciej> | I'm not sure collapsing PRESENTABLE / PLAYABLE / PLAYTHROUGHOK into one state plus two bools is very helpful |
| 01:53 | <othermaciej> | (the bools would have only one valid setting in every other state) |
| 01:54 | <ericcarlson> | I agree, it seems much cleaner to check the state instead of the state and a bool (or two) |
| 01:54 | <Hixie> | well you're already going to have to be checking bools left right and center |
| 01:55 | <othermaciej> | being >= PLAYABLE is a very basic thing for UI, more so than BUFFERING |
| 01:55 | <othermaciej> | since it tells you whether to enable the play button |
| 01:55 | <othermaciej> | or dim it |
| 01:56 | <othermaciej> | hard to imagine a polished JS controller not caring |
| 01:56 | <ericcarlson> | and what does BUFFERING mean when you load on demand? |
| 01:56 | <Hixie> | so you'd want the play/pause button to change state as you're seeking? |
| 01:56 | <Hixie> | i don't think i've ever seen that |
| 01:56 | <Hixie> | but you could do it by just watching canPlay |
| 01:56 | <Hixie> | which is imho easier than watching a state |
| 01:57 | <Hixie> | the other thing is that right now there's no state for when you're actually seeking |
| 01:57 | <Hixie> | i.e. when you're "moving the play head" as it were |
| 01:57 | <ericcarlson> | it is instantaneous if the media is buffered |
| 01:58 | <Hixie> | no it's not |
| 01:58 | <ericcarlson> | no? |
| 01:59 | <Hixie> | one of the pieces of feedback i got from the youtube/google video guys is that they were really annoyed that most video apis assumed seek()s were instantaneous (even when they had all the data), because in practice it isn't instantaneous |
| 01:59 | <Hixie> | it's quick, for sure |
| 01:59 | <Hixie> | but you still have to go and find the last complete frame and then decode all the way to the new frame position before you can play |
| 02:00 | <ericcarlson> | true |
| 02:00 | <Hixie> | i've seen videos where that can take seconds to do |
| 02:00 | <Hixie> | (especially WMA or whatever the windows one is called, for some reason -- sometimes it takes ages to seek) |
| 02:00 | <ericcarlson> | yes, MPEG can be the same |
| 02:01 | <Hixie> | i have to go now |
| 02:01 | <Hixie> | but i'll keep looking at this |
| 02:01 | <Hixie> | ttyal |
| 02:23 | <Lachy_> | does anyone know of a good article or thread discussing why src on every element is a bad idea, that I can link to in my reply to the latest request on public-html? |
| 02:24 | <othermaciej> | I posted something about global attributes in general on whatwg recently |
| 02:24 | <othermaciej> | short version: |
| 02:24 | <othermaciej> | - annoying to implement |
| 02:24 | <othermaciej> | - bad semanticly |
| 02:25 | <othermaciej> | - lack of img-specific API / attributes, presence of non-image API |
| 02:25 | <othermaciej> | - results on active elements like <input type="checkbox"> are bizzare |
| 02:26 | <othermaciej> | - conflates presentational technique of image replacement with semantically meaningful content images |
| 02:26 | <othermaciej> | (for this case) |
| 02:29 | <Lachy_> | I can't find it in the archives, but we should turn that in to a blog entry |
| 02:30 | <othermaciej> | I might have been talking about global href, not global src in this case |
| 02:30 | <othermaciej> | don't remember |
| 02:30 | <Lachy_> | yeah, I saw threads about href |
| 02:31 | <Lachy_> | and Anne has just published one about href on his blog |
| 03:59 | <Lachy_> | http://www.w3.org/QA/2007/03/validation_to_conformance.html is interesting. |
| 04:28 | <mpt> | "Some HTML is OK" -- W3C |
| 04:28 | <mpt> | (gratuitously out-of-context quote, but it was too good to resist) |
| 04:29 | <Lachy_> | :-) |
| 10:58 | <annevk> | Hixie, currentLoop should be unsigned long, not float |
| 11:09 | <Dashiva> | Is the leap from UNDERSTANDABLE to PRESENTABLE really going to be noticable? Wouldn't it basically consist of loading a single first frame, since UNDERSTANDABLE takes care of all the metadata? |
| 11:16 | <annevk> | not just loading the frame but also decoding it |
| 11:18 | <Dashiva> | For something going tens of frames per second, that's not a very long time |
| 11:24 | <annevk> | I wonder if I should rename UNINITIALIZED to EMPTY as well for XMLHttpRequest... |
| 11:27 | <Dashiva> | I wouldn't, since that's a very specific state in xhr |
| 11:27 | <Dashiva> | You have to call open before anything else, so it really is uninitialized |
| 11:28 | <annevk> | it's exactly the same as EMPTY for <video>, actually |
| 11:31 | <annevk> | what makes you think it's different? |
| 11:42 | <Dashiva> | The loading states work on how much data has been loaded and understood, so with detaching of video streams and cached data you might go from EMPTY to e.g. PLAYTHROUGHPOSIBLE in one jump |
| 11:46 | <annevk> | are you sure the intermediate events wouldn't dispatch? |
| 11:47 | <annevk> | anyway, EMPTY is much easier to type than UNINITIALIZED... |
| 11:47 | <annevk> | that you have to invoke load() is just how the API works, load() is always invoked for <video> as well currently |
| 11:54 | <annevk> | http://programming.reddit.com/info/1d855/comments |
| 11:54 | <annevk> | (comments on href= on every element) |
| 11:54 | <annevk> | (not very interesting) |
| 12:05 | <hsivonen> | annevk: if anything, we should congratulate the XHTML propagandists for being very effective at shifting the Overton Window to their favor |
| 12:07 | <hsivonen> | though the WHATWG has clearly shifted the window the other way among key people (the kind who use del.icio.us :-), so it can be expected that the Digg/Reddit masses follow eventually |
| 12:08 | <annevk> | it seems Reddit has more sensible people than Digg |
| 12:08 | <Dashiva> | I really hope it says HTML5 and doesn't become common to write (X)HTML5. I see enough Xes as it is |
| 12:09 | <annevk> | XHTML5 is just the XML serialization of HTML5 |
| 12:09 | <annevk> | HTML5 is both the language and the HTML serialization which may be a bit confusing... |
| 12:09 | <hsivonen> | annevk: yes, Reddit people have more clue than Digg users |
| 13:02 | <karlUshi> | meuh |
| 13:03 | <karlUshi> | [meuh meuh meuuuuh meuuuuuuuuh] |
| 13:04 | <annevk> | karlcow is indeed an appropriate nickname for him |
| 13:27 | <annevk> | Philip`, are you using -o-2d-game to get the pixel values in Opera or so? |
| 13:34 | <Philip`> | Yep, it's the opera-2dgame getPixel |
| 13:35 | <Philip`> | (though it always tries getImageData first, if it exists) |
| 13:36 | <annevk> | k |
| 13:37 | <annevk> | your testcases are quite nice btw |
| 13:38 | <annevk> | for getImageData(), do you take into account that height/width doesn't necessarily reflect the height/width of the canvas? |
| 13:45 | <Philip`> | I don't - in most cases it shouldn't matter because I'm only testing a single pixel at a time and ignoring everything but the first four array elements (so it'll work as long as getImageData doesn't return zero pixel) |
| 13:46 | <Philip`> | In a couple of cases it does matter because I'm comparing the whole image to the expected one, but I expect that's very fragile anyway (since it depends on the antialiasing and whatever) so I should probably stop doing that |
| 13:47 | <Philip`> | *zero pixels |
| 14:13 | <annevk> | Hixie, the <source> IDL interface is wrong |
| 15:22 | <zcorpan> | ponder. perhaps stating that rel=nofollow is used on all links (on the register page) will prevent the manual spam too. |
| 15:23 | <zcorpan> | (on the forum) |
| 15:33 | <Philip`> | Hmm, I used to have a spam problem (averaging several spam posts per day for a month or so) on a forum (several years old, ~1600 members, running IPB), but solved it entirely by adding a "I am a human, not a spam-bot" checkbox on the registration page and have had no problems since then |
| 15:33 | <Philip`> | so I've always assumed that manual spam is uneconomical and not a problem; but maybe I'm just lucky to have avoided being hit by it |
| 15:34 | <annevk> | it's a problem |
| 15:35 | <annevk> | recently some people managed to get passed by well-formedness required + forced preview check |
| 15:35 | <annevk> | (I also require at least one block level element for comments) |
| 15:36 | <hsivonen> | Philip`: apparently, low-skilled English-literate labor is available at a very low cost, so implementing an MTurk-like arrangement for manual spamming seems to be feasible :-( |
| 15:38 | <Lachy> | luckily, for now at least, manual spamming isn't quite as bad a spam bots cause bots are able to send a significant amount more than manual |
| 15:38 | annevk | isn't sure that DOMContentLoaded solves issues |
| 15:38 | annevk | notes http://www.w3.org/2006/webapi/track/issues/36 |
| 15:39 | <Lachy> | DOMContentLoaded is roughly equivalent to <script defer> |
| 15:39 | <annevk> | do all scripts need to be loaded first? |
| 15:39 | <annevk> | how would that work? |
| 15:40 | <Lachy> | all scripts get loaded and executed during parsing anyway |
| 15:40 | <annevk> | ah right |
| 15:40 | <annevk> | but still |
| 15:40 | <annevk> | so maybe the moment document.close() is invoked |
| 15:40 | <annevk> | btw, for XHTML that may not be the case |
| 15:41 | <Lachy> | I wonder if DOMContentLoaded fires immediately after the root element closes, or whether it waits till all content afterwards (like comments are whitespace) are parsed too |
| 15:41 | <Lachy> | s/are/and/ |
| 15:42 | <annevk> | for HTML it has to wait |
| 15:42 | <Lachy> | yeah |
| 15:42 | <Lachy> | for XHTML? |
| 15:42 | <Lachy> | I suppose, since commetns are added to teh DOM, it would have to wait too |
| 15:42 | <annevk> | dunno, the script containing the listener might not even be loaded... |
| 15:42 | <Lachy> | why wouldn't it be loaded? |
| 15:43 | <annevk> | why would parsing XML be delayed by script loading? |
| 15:43 | <Lachy> | hmm. I don't know, I guess since document.write() can't work, scripts can be loaded async |
| 15:44 | <annevk> | in XHTML you also have <svg:script> and <xbl:script> etc. |
| 15:44 | <annevk> | which makes this more painful as at least SVG defines a different processing model iirc |
| 15:45 | <Lachy> | I assume <xbl:script> has a sensible processing model |
| 15:45 | <Lachy> | but I suppose svg is still a potential problem |
| 15:48 | <annevk> | SVG is a problem nonetheless :) |
| 15:53 | <annevk> | http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d03d5ef0-3453-4458-8c13-c1c94c0dff1b |
| 15:58 | <hsivonen> | GUIDs make URIs uncool |
| 15:59 | <annevk> | no shit |
| 15:59 | <Lachy> | hsivonen, yeah. using the milliseconds since 1970-01-01 is much more sensible! :-) |
| 16:00 | <hsivonen> | Lachy: I've wondered about the rationale behind that design decision. :-) |
| 16:01 | <Lachy> | yeah, me too. you'll have to ask Hixie |
| 16:02 | <Lachy> | can someone test if http://lachy.id.au/ is responding? I can't get it to load |
| 16:05 | <hsivonen> | Lachy: works for me |
| 16:05 | <Lachy> | yeah, it's come back up for me now too |
| 16:06 | <Lachy> | thanks |
| 16:14 | <virtuelv> | re http://lachy.id.au/log/2007/03/problems-with-xhtml - hehe |
| 16:15 | <Lachy> | there was a followup post too! http://lists.w3.org/Archives/Public/www-html-editor/2007JanMar/0053.html |
| 16:19 | <h3h> | wow |
| 16:19 | tylerr | needs to delegate some tasks so he has time to work on WHATWG articles. |
| 16:19 | <Lachy> | what kind of tasks? |
| 16:21 | <tylerr> | Page builds, bug fixes, link scanning, etc. |
| 16:21 | <tylerr> | All in a tool that doesn't have S&R. :-( |
| 16:22 | <Lachy> | oh, you mean tasks at your work. I thought you meant getting somewhere here to help you out |
| 16:22 | <tylerr> | Oh hehe, well, that will come in time. :-) |
| 16:22 | <Lachy> | ok boss! |
| 16:22 | <tylerr> | I need to plough through all my *real* work first. |
| 16:23 | <tylerr> | Maybe that should be "real". ;-) |
| 19:00 | <annevk2> | http://blog.outer-court.com/archive/2007-03-29-n69.html |
| 19:02 | <annevk2> | not very interesting though, except that he doesn't really seem to grasp it |
| 19:02 | <annevk2> | "we need better marketing" |
| 19:46 | <gsnedders> | annevk: what was that blog you commented on a couple days ago about HTML5, referencing the about page? ever get a reply? |
| 21:34 | <othermaciej> | I hate arguing with X People |
| 21:44 | <Hixie> | where are you arguing with XPeople? |
| 21:47 | met_ | thinks it probably isn't on http://www.xpeople.org/ |
| 21:48 | <othermaciej> | public-html |
| 21:48 | <othermaciej> | I don't even want to read all the emails about how great hidden metadata is |
| 21:48 | <othermaciej> | especially the long rambling one that is all lowercase except instances of html tag names |
| 21:49 | <Hixie> | heh |
| 21:49 | <Hixie> | afk |
| 21:51 | <gsnedders> | so we can then normalise them in our heads to lowercase? :P |
| 21:51 | <Dashiva> | Has there been a good explanation that visible metadata usually = correct and updated metadata yet? |
| 21:53 | <othermaciej> | there have been explanations |
| 21:53 | <othermaciej> | I don't know if they would count as good |
| 22:01 | <Lachy> | good morning |
| 22:12 | <othermaciej> | hey KevinMarks |
| 22:14 | <othermaciej> | KevinMarks: check out the "Visible Metadata" threads here: http://lists.w3.org/Archives/Public/public-html/2007JanMar/thread.html |
| 22:27 | <KevinMarks> | oh boy |
| 22:28 | <KevinMarks> | I'm in Quinn's talk about embedding magnets in her body right now |
| 22:28 | <othermaciej> | ! |