| 02:34 | <llrcombs> | hey guys |
| 02:35 | <llrcombs> | we ##javascript -ers have decided that this needs a spec: |
| 02:35 | <llrcombs> | adding data to a <video> live |
| 02:37 | <llrcombs> | for example: downloading a video with WebSocket, live decoding its DRM in JS, and continuously appending the output to a <video> |
| 02:40 | <micheil> | llrcombs: well, theoretically you can pipe videos over websockets. |
| 02:40 | <micheil> | practically you can't though, iirc. |
| 02:40 | <llrcombs> | how's it done in theory? |
| 02:41 | <micheil> | well, the idea of being able to use websockets to send / recv video and audio does work |
| 02:41 | <micheil> | but in current implementations it doesn't. |
| 02:42 | <llrcombs> | I mean, how does one hook up a <video> to a WebSocket in theory? Even if it doesn't work now, I can bug the #webkit guys |
| 02:50 | <Hixie> | the theory is not yet at a point where it can be done |
| 02:51 | <Hixie> | as in, it's still just ideas |
| 02:51 | <Hixie> | but there is work in that area |
| 02:51 | <Hixie> | ongoing |
| 02:51 | <micheil> | thanks for saving me on that one hixie |
| 02:51 | <llrcombs> | ahh, as in, "we have an idea but it's not spec'd out yet", not "we have a spec but it's not implemented yet" |
| 02:57 | <micheil> | well, the websocket spec does support sending video over it. |
| 02:57 | <micheil> | it's the javascript api's that don't support binary data yet |
| 02:58 | <micheil> | like, you could go server-to-server and send binary data, as long as both understand binary data |
| 03:06 | <llrcombs> | oh, and also |
| 03:06 | <llrcombs> | has anything recent created an ability to get the URL that a 300-range status'd page is redirecting to? |
| 03:08 | <llrcombs> | because right now I have to do that server-side with a PHP script calling curl |
| 03:12 | <micheil> | Hixie: do you know much about how CORS will impact on websockets? |
| 03:12 | <micheil> | Hixie: I've just had a question about how WebSockets are XSS safe.. |
| 03:49 | <Hixie> | micheil: dunno, i haven't followed the recent changes to web sockets |
| 03:50 | <micheil> | okay |
| 05:01 | <llrcombs> | question: should an element with position: fixed; height: 100%; width: 100%; left: 0px; top: 0px; z-index: 10000000; take up the entire window? |
| 05:02 | <llrcombs> | because right now, other elements around it are showing up above it |
| 05:03 | <llrcombs> | because its parent node has z-index: 100; |
| 07:32 | <aho> | is that same origin stuff defined for "file://"? |
| 07:32 | <aho> | e.g. right now chrome and firefox don't allow read access to images from file (everything came from there), but opera is perfectly fine with it |
| 07:33 | <aho> | there isn't a port for example |
| 07:42 | <aho> | read the specs, but i'm still not sure :) |
| 08:00 | <abarth> | aho: different browsers use different security policies for file |
| 08:01 | <abarth> | aho: the spec lets them do that |
| 08:01 | <aho> | so... it's unspecified? |
| 08:14 | <abarth> | the spec allows the browsers to do what they do |
| 08:14 | <abarth> | i suspect they'll eventually converge on a security policy for file URLs |
| 08:14 | <abarth> | it just might be a while :) |
| 08:16 | <aho> | as far as i'm concerned, i'd say opera's behavior makes more sense |
| 08:17 | <aho> | a script from the local filesystem should be allowed to read the pixel data from some image which also came from the local filesystem |
| 08:17 | <aho> | <: |
| 08:18 | <abarth> | it's unclear why that should be true |
| 08:18 | <abarth> | consider a network file system |
| 08:18 | <abarth> | like AFS |
| 08:18 | <abarth> | why should an HTML file that I receive as a mail attachment |
| 08:19 | <abarth> | be able to use my Kerberos ticket to access all the AFS drives in the world? |
| 08:20 | <aho> | well, in this specific example... everything was in the same directory |
| 08:20 | <aho> | the origin is totally the same - no matter how you look at it |
| 08:20 | <abarth> | that's getting closer to the mozilla security model |
| 08:20 | <abarth> | which is based on the directory tree |
| 08:20 | <abarth> | but ends up being very complicated |
| 08:20 | <abarth> | because the security original of a document depends on what other document caused it to load |
| 08:20 | <abarth> | and how |
| 08:21 | <abarth> | AFAIK, no one understands the firefox policy, not even the folks who invented it |
| 08:21 | <aho> | heh |
| 10:41 | <mikekelly> | morning internet friends |
| 10:45 | <mikekelly> | Wondering if someone could clarify for me what the current state of HTTP Digest is from a browser perspective |
| 10:45 | <mikekelly> | is there a way to make it interoperable across the most common browsers? |
| 10:46 | <virtuelv> | mikekelly: http://en.wikipedia.org/wiki/Digest_access_authentication#Browser_implementation |
| 10:49 | <virtuelv> | problem with any http auth is that browsers act like the Hotel California |
| 10:49 | <virtuelv> | you can never leave |
| 10:49 | <mikekelly> | ? :) |
| 10:50 | <mikekelly> | oh right, yeah :) |
| 10:50 | <mikekelly> | any effort on browser side to make this workable? |
| 10:51 | <mikekelly> | i.e. the 'look and feel' problem and the logout problem |
| 10:59 | <jgraham> | virtuelv: It's more like the opposite of Hotel California; you can leave any time you like but you can never check out |
| 11:11 | <schalkn> | Question: Why is autoplay still part of the specification for audio and video? |
| 11:12 | <Lachy> | schalkn, because it has some valid use cases. |
| 11:23 | <schalkn> | ok, are you aware of identified use cases for using autoplay? Is it more related to video than audio? |
| 11:29 | <virtuelv> | schalkn: there are valid usecases for autoplay of both |
| 11:31 | <virtuelv> | A useragent should rather prevent web sites and applications from playing audio |
| 11:31 | <virtuelv> | or allow override of the autoplay attribute |
| 11:36 | <schalkn> | virtuelv - Yeah, I read that in the spec. I just curious to know of identified use cases. |
| 11:37 | <schalkn> | I writing a bunch of tests and test pages regarding the various elements of HTML5 and would like to include valid use cases of autoplay |
| 11:37 | <schalkn> | So any pointers will be appreciated |
| 11:52 | <virtuelv> | schalkn: any web page that in the past used embeds to autoplay audio files |
| 11:52 | <virtuelv> | not that I'd say they are particularily good websites, but I'd identify (the original) hampsterdance as being valid |
| 12:01 | <jgraham> | schalkn: When you say "tests" what do you mean? If you are planning on making detailed conformance tests it would be good to contribute them back to the WG |
| 12:25 | <schalkn> | jgraham - It is definitely conformance tests, and I will definitely contribute back |
| 12:27 | <schalkn> | virtuelv - ok, so autoplay is more there for backwards 'compatibility' |
| 12:43 | <mikekelly> | fwiw I wrote some thoughts about cookies vs digest http://restafari.blogspot.com/2010/11/cookies-are-gross.html |
| 12:52 | <virtuelv> | schalkn: I didn't say that |
| 12:52 | <virtuelv> | I said there is what people consider valid usecases |
| 12:52 | <Dashiva> | I consider youtube a valid usecase |
| 13:00 | <schalkn> | Dashiva - In terms of autoplaying video? I personally do not like if a video or audio site autoplays anything. But I guess that if this is user preference driven, then it will be real easy to implement. If a user specified autoplay in their preferences, just add the attribute to the media. |
| 13:04 | <Philip`> | There are e.g. news sites in which some pages have articles with videos at the top, which shouldn't autoplay because normally you'll just want to read the text instead, and some pages which only contain video, which should autoplay because you followed the link to that page because you wanted to watch the video |
| 13:05 | <Philip`> | and only the site knows the distinction between those two groups of pages |
| 13:05 | <Philip`> | so it can't just be a user preference |
| 13:11 | <schalkn> | Philip - Ok, I agree with that. I guess it boils down to resposible use. |
| 13:11 | <Dashiva> | That's what the browser pref is for, lets the user override irresponsible use |
| 13:19 | <schalkn> | Dashiva - Do you know of a user agant that has implemented this preference currently or, is this more related to assitive technologies such as screen readers? |
| 13:20 | <Dashiva> | Presumably it's not a high priority feature until video and audio tags start becoming mainstream |
| 13:27 | <schalkn> | Jip, I reckon at the moment the bigger issue is codecs and getting overyone on board with one open audio format |
| 13:28 | <schalkn> | everyone |
| 13:39 | <schalkn> | Am I reading this right |
| 13:40 | <schalkn> | on getting it must return the last value it was set to, or 1.0 if it hasn't yet been set - Context = playbackRate of audio |
| 13:41 | <schalkn> | So if an audio is playing and the result of audio.playbackRate = 1 it was not set. Therefore the browser did not follow the following: |
| 13:41 | <schalkn> | The "play" function in a user agent's interface must set the playbackRate attribute to the value of the defaultPlaybackRate attribute before invoking the play() method's steps |
| 13:42 | <schalkn> | Does this apply only when using the browsers controls to play and pause the audio or also if the author calls the play method from javascript? |
| 13:42 | <schalkn> | i.e. In the second case, it is the author's responsibility to set the playbackRate before calling play |
| 14:04 | <mikekelly> | jgraham: does digest behave like that because it is spec'd wrong? |