Re: [whatwg] Video feedback
On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote: On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote: On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters sim...@opera.com wrote: On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: For commercial video providers, the tracks in a live stream change all the time; this is not limited to audio and video tracks but would include text tracks as well. OK, all this indicates to me that we probably want a metadatachanged event to indicate there has been a change and that JS may need to check some of its assumptions. We already have durationchange. Duration is metadata. If we want to support changes to width/height, and the script is interested in when that happens, maybe there should be a dimensionchange event (but what's the use case for changing width/height mid-stream?). Does the spec support changes to text tracks mid-stream? It's not about what the spec supports, but what real-world streams provide. I don't think it makes sense to put an event on every single type of metadata that can change. Most of the time, when you have a stream change, many variables will change together, so a single event is a lot less events to raise. It's an event that signifies that the media framework has reset the video/audio decoding pipeline and loaded a whole bunch of new stuff. You should imagine it as a concatenation of different media resources. And yes, they can have different track constitution and different audio sampling rate (which the audio API will care about) etc etc. In addition, it is possible for a stream to lose or gain an audio track. In this case the dimensions won't change but a script may want to react to the change in audioTracks. The TrackList object has an onchanged event, which I assumed would fire when any of the information in the TrackList changes (e.g. tracks added or removed). But actually the spec doesn't state when this event fires (as far as I could tell - unless it is implied by some general definition of events called onchanged). Should there be some clarification here ? I agree with Silvia, a more generic metadata changed event makes more sense. Yes, and it should support the case in which text tracks are added/removed too. Also, as Eric (C) pointed out, one of the things which can change is which of several available versions of the content is being rendered (for adaptive bitrate cases). This doesn't necessarily change any of the metadata currently exposed on the video element, but nevertheless it's information that the application may need. It would be nice to expose some kind of identifier for the currently rendered stream and have an event when this changes. I think that a stream-format-supplied identifier would be sufficient. ...Mark eric
Re: [whatwg] Hashing Passwords Client-side
On 06/17/2011 08:34 PM, Aryeh Gregor wrote: On Thu, Jun 16, 2011 at 5:39 PM, Daniel Chengdch...@chromium.org wrote: A variation of this idea has been proposed in the past but was largely seen as undesirable--see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In general, I feel like the same objections are still true of this proposal. This proposal is considerably better formulated than that one was. But yes, in the end, the only real benefit is that the user can confirm that their original plaintext password can only be retrieved by brute-forcing the hash, which protects them only against reuse of the password on different sites. So on consideration, it will probably lead more to a false sense of security than an actual increase in security, yes. It no longer seems like a good idea to me. FWIW I disagree. The same argument could be used against client-side form validation since some authors might stop doing proper server-side validation. But, as in that case, there are definite end user benefits — I consider limiting the scope of attacks to just a single site even in the face of password reuse to be a substantial win — and the authors who are most likely to get the server-side wrong are the same ones who are already storing passwords in plain text.
Re: [whatwg] Video feedback
On Mon, Jun 20, 2011 at 6:29 PM, Mark Watson wats...@netflix.com wrote: On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote: On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote: On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters sim...@opera.com wrote: On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: For commercial video providers, the tracks in a live stream change all the time; this is not limited to audio and video tracks but would include text tracks as well. OK, all this indicates to me that we probably want a metadatachanged event to indicate there has been a change and that JS may need to check some of its assumptions. We already have durationchange. Duration is metadata. If we want to support changes to width/height, and the script is interested in when that happens, maybe there should be a dimensionchange event (but what's the use case for changing width/height mid-stream?). Does the spec support changes to text tracks mid-stream? It's not about what the spec supports, but what real-world streams provide. I don't think it makes sense to put an event on every single type of metadata that can change. Most of the time, when you have a stream change, many variables will change together, so a single event is a lot less events to raise. It's an event that signifies that the media framework has reset the video/audio decoding pipeline and loaded a whole bunch of new stuff. You should imagine it as a concatenation of different media resources. And yes, they can have different track constitution and different audio sampling rate (which the audio API will care about) etc etc. In addition, it is possible for a stream to lose or gain an audio track. In this case the dimensions won't change but a script may want to react to the change in audioTracks. The TrackList object has an onchanged event, which I assumed would fire when any of the information in the TrackList changes (e.g. tracks added or removed). But actually the spec doesn't state when this event fires (as far as I could tell - unless it is implied by some general definition of events called onchanged). Should there be some clarification here ? I understood that to relate to a change of cues only, since it is on the tracklist. I.e. it's an aggregate event from the oncuechange event of a cue inside the track. I didn't think it would relate to a change of existence of that track. Note that the even is attached to the TrackList, not the TrackList[], so it cannot be raised when a track is added or removed, only when something inside the TrackList changes. I agree with Silvia, a more generic metadata changed event makes more sense. Yes, and it should support the case in which text tracks are added/removed too. Yes, it needs to be an event on the MediaElement. Also, as Eric (C) pointed out, one of the things which can change is which of several available versions of the content is being rendered (for adaptive bitrate cases). This doesn't necessarily change any of the metadata currently exposed on the video element, but nevertheless it's information that the application may need. It would be nice to expose some kind of identifier for the currently rendered stream and have an event when this changes. I think that a stream-format-supplied identifier would be sufficient. I don't know about the adaptive streaming situation. I think that is more about statistics/metrics rather than about change of resource. All the alternatives in an adaptive streaming resource should provide the same number of tracks and the same video dimensions, just at different bitrate/quality, no? Different video dimensions should be provided through the source element and @media attribute, but within an adaptive stream, the alternatives should be consistent because the target device won't change. I guess this is a discussion for another thread... :-) Cheers, Silvia.
Re: [whatwg] Video feedback
On Jun 20, 2011, at 10:42 AM, Silvia Pfeiffer wrote: On Mon, Jun 20, 2011 at 6:29 PM, Mark Watson wats...@netflix.commailto:wats...@netflix.com wrote: On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote: On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote: On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters sim...@opera.commailto:sim...@opera.com wrote: On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer silviapfeiff...@gmail.commailto:silviapfeiff...@gmail.com wrote: For commercial video providers, the tracks in a live stream change all the time; this is not limited to audio and video tracks but would include text tracks as well. OK, all this indicates to me that we probably want a metadatachanged event to indicate there has been a change and that JS may need to check some of its assumptions. We already have durationchange. Duration is metadata. If we want to support changes to width/height, and the script is interested in when that happens, maybe there should be a dimensionchange event (but what's the use case for changing width/height mid-stream?). Does the spec support changes to text tracks mid-stream? It's not about what the spec supports, but what real-world streams provide. I don't think it makes sense to put an event on every single type of metadata that can change. Most of the time, when you have a stream change, many variables will change together, so a single event is a lot less events to raise. It's an event that signifies that the media framework has reset the video/audio decoding pipeline and loaded a whole bunch of new stuff. You should imagine it as a concatenation of different media resources. And yes, they can have different track constitution and different audio sampling rate (which the audio API will care about) etc etc. In addition, it is possible for a stream to lose or gain an audio track. In this case the dimensions won't change but a script may want to react to the change in audioTracks. The TrackList object has an onchanged event, which I assumed would fire when any of the information in the TrackList changes (e.g. tracks added or removed). But actually the spec doesn't state when this event fires (as far as I could tell - unless it is implied by some general definition of events called onchanged). Should there be some clarification here ? I understood that to relate to a change of cues only, since it is on the tracklist. I.e. it's an aggregate event from the oncuechange event of a cue inside the track. I didn't think it would relate to a change of existence of that track. Note that the even is attached to the TrackList, not the TrackList[], so it cannot be raised when a track is added or removed, only when something inside the TrackList changes. Are we talking about the same thing ? There is no TrackList array and TrackList is only used for audio/video, not text, so I don't understand the comment about cues. I'm talking about http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#tracklist which is the base class for MultipleTrackList and ExclusiveTrackList used to represent all the audio and video tracks (respectively). One instance of the object represents all the tracks, so I would assume that a change in the number of tracks is a change to this object. I agree with Silvia, a more generic metadata changed event makes more sense. Yes, and it should support the case in which text tracks are added/removed too. Yes, it needs to be an event on the MediaElement. Also, as Eric (C) pointed out, one of the things which can change is which of seve ral available versions of the content is being rendered (for adaptive bitrate cases). This doesn't necessarily change any of the metadata currently exposed on the video element, but nevertheless it's information that the application may need. It would be nice to expose some kind of identifier for the currently rendered stream and have an event when this changes. I think that a stream-format-supplied identifier would be sufficient. I don't know about the adaptive streaming situation. I think that is more about statistics/metrics rather than about change of resource. All the alternatives in an adaptive streaming resource should provide the same number of tracks and the same video dimensions, just at different bitrate/quality, no? I think of the different adaptive versions on a per-track basis (i.e. the alternatives are *within* each track), not a bunch of alternatives each of which contains several tracks. Both are possible, of course. It's certainly possible (indeed common) for different bitrate video encodings to have different resolutions - there are video encoding reasons to do this. Of course the aspect ratio should not change and nor should the dimensions on the screen (both would be a little peculiar for the user). Now, the videoWidth and videoHeight attributes of HTMLVideoElement are not the same as the resolution (for a start, they are in CSS pixels, which
Re: [whatwg] Video feedback
On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote: The TrackList object has an onchanged event, which I assumed would fire when any of the information in the TrackList changes (e.g. tracks added or removed). But actually the spec doesn't state when this event fires (as far as I could tell - unless it is implied by some general definition of events called onchanged). Should there be some clarification here ? I understood that to relate to a change of cues only, since it is on the tracklist. I.e. it's an aggregate event from the oncuechange event of a cue inside the track. I didn't think it would relate to a change of existence of that track. Note that the even is attached to the TrackList, not the TrackList[], so it cannot be raised when a track is added or removed, only when something inside the TrackList changes. Are we talking about the same thing ? There is no TrackList array and TrackList is only used for audio/video, not text, so I don't understand the comment about cues. I'm talking about http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#tracklist which is the base class for MultipleTrackList and ExclusiveTrackList used to represent all the audio and video tracks (respectively). One instance of the object represents all the tracks, so I would assume that a change in the number of tracks is a change to this object. Ah yes, you're right: I got confused. It says Whenever the selected track is changed, the user agent must queue a task to fire a simple event named change at the MultipleTrackList object. This means it fires when the selectedIndex is changed, i.e. the user chooses a different track for rendering. I still don't think it relates to changes in the composition of tracks of a resource. That should be something different and should probably be on the MediaElement and not on the track list to also cover changes in text tracks. Also, as Eric (C) pointed out, one of the things which can change is which of several available versions of the content is being rendered (for adaptive bitrate cases). This doesn't necessarily change any of the metadata currently exposed on the video element, but nevertheless it's information that the application may need. It would be nice to expose some kind of identifier for the currently rendered stream and have an event when this changes. I think that a stream-format-supplied identifier would be sufficient. I don't know about the adaptive streaming situation. I think that is more about statistics/metrics rather than about change of resource. All the alternatives in an adaptive streaming resource should provide the same number of tracks and the same video dimensions, just at different bitrate/quality, no? I think of the different adaptive versions on a per-track basis (i.e. the alternatives are *within* each track), not a bunch of alternatives each of which contains several tracks. Both are possible, of course. It's certainly possible (indeed common) for different bitrate video encodings to have different resolutions - there are video encoding reasons to do this. Of course the aspect ratio should not change and nor should the dimensions on the screen (both would be a little peculiar for the user). Now, the videoWidth and videoHeight attributes of HTMLVideoElement are not the same as the resolution (for a start, they are in CSS pixels, which are square), but I think it quite likely that if the resolution of the video changes than the videoWidth and videoHeight might change. I'd be interested to hear how existing implementations relate resolution to videoWidth and videoHeight. Well, if videoWidth and videoHeight change and no dimensions on the video are provided through CSS, then surely the video will change size and the display will shrink. That would be a terrible user experience. For that reason I would suggest that such a change not be made in alternative adaptive streams. Different video dimensions should be provided through the source element and @media attribute, but within an adaptive stream, the alternatives should be consistent because the target device won't change. I guess this is a discussion for another thread... :-) Possibly ;-) The device knows much better than the page author what capabilities it has and so what resolutions are suitable for the device. So it is better to provide all the alternatives as a single resource and have the device work out which subset it can support. Or at least, the list should be provided all at the same level - there is no rationale for a hierarchy of alternatives. The way in which HTML deals with different devices and their different capabilities is through media queries. As a author you provide your content with different versions of media-dependent style sheets and content, so that when you view the page with a different device, the capabilities of the device select the right style sheet and
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin per-erik.bro...@ericsson.com wrote: The Cache-Control request header used with EventSource is not in the list of simple request headers and a preflight request is not really an option here in my opinion. Agreed. I can add that to CORS. I already added Last-Event-ID for that reason, but somehow missed Cache-Control. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com wrote: On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin per-erik.bro...@ericsson.com wrote: The Cache-Control request header used with EventSource is not in the list of simple request headers and a preflight request is not really an option here in my opinion. Agreed. I can add that to CORS. I already added Last-Event-ID for that reason, but somehow missed Cache-Control. Wait, we don't have to add any headers to the CORS spec just because implementations of various specs needs to send those without doing preflight. The list of simple headers only affects which headers the *page* can immediately set without a preflight being required, for example through features like XMLHttpRequest.setRequestHeader. Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com wrote: Agreed. I can add that to CORS. I already added Last-Event-ID for that reason, but somehow missed Cache-Control. Wait, we don't have to add any headers to the CORS spec just because implementations of various specs needs to send those without doing preflight. The list of simple headers only affects which headers the *page* can immediately set without a preflight being required, for example through features like XMLHttpRequest.setRequestHeader. Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. We could add Host as authors cannot set that anyway. But what you say makes sense. I will remove Last-Event-ID and add a note about how that list works. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, Jun 20, 2011 at 3:57 AM, Anne van Kesteren ann...@opera.com wrote: On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com wrote: Agreed. I can add that to CORS. I already added Last-Event-ID for that reason, but somehow missed Cache-Control. Wait, we don't have to add any headers to the CORS spec just because implementations of various specs needs to send those without doing preflight. The list of simple headers only affects which headers the *page* can immediately set without a preflight being required, for example through features like XMLHttpRequest.setRequestHeader. Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. We could add Host as authors cannot set that anyway. But what you say makes sense. I will remove Last-Event-ID and add a note about how that list works. One thing to keep in mind though is that in the case of XHR, the Content-Type header is often in direct control of the page, even through means other than setRequestHeader. For example by creating a Blob with a specific content type using the .slice method. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking jo...@sicking.cc wrote: One thing to keep in mind though is that in the case of XHR, the Content-Type header is often in direct control of the page, even through means other than setRequestHeader. For example by creating a Blob with a specific content type using the .slice method. Maybe Blob and File when not packaged in FormData should force a preflight then? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, Jun 20, 2011 at 4:06 AM, Anne van Kesteren ann...@opera.com wrote: On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking jo...@sicking.cc wrote: One thing to keep in mind though is that in the case of XHR, the Content-Type header is often in direct control of the page, even through means other than setRequestHeader. For example by creating a Blob with a specific content type using the .slice method. Maybe Blob and File when not packaged in FormData should force a preflight then? I don't see a reason to do that other than when the Content-Type has a value other than the ones listed in the simple headers description. All that I'm saying is that for XHR, there are at least two APIs which allows the page to set headers, .setRequestHeader and .send. Though possibly a safer way to think about it is that the Content-Type header should always be inspected to see if a preflight is needed, no matter if the header is set by the page or by the implementation. I think I like the latter approach more since it seems safer. / Jonas
[whatwg] Readiness of script-created documents
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) complete seems like the most useful and consistent value which would seem like a good reason to require that. / Jonas
Re: [whatwg] CORS requests for image and video elements
On Sat, 21 May 2011 04:48:15 +0200, Jonas Sicking jo...@sicking.cc wrote: When we designed CORS we very intentionally did not want to allow allow * rules for resources that are loaded with user credentials (most significantly cookies). The reason was that we did not want people to repeat the mistakes that happened when flash's cross-site loading technology was deployed. Many sites added a allow * rule to all their resources, thus accidentally leaking all user data to any site that the user visited. That is not actually true as that would require a second header, Access-Control-Allow-Credentials. I think we should stop banning *. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Video feedback
On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote: On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote: The TrackList object has an onchanged event, which I assumed would fire when any of the information in the TrackList changes (e.g. tracks added or removed). But actually the spec doesn't state when this event fires (as far as I could tell - unless it is implied by some general definition of events called onchanged). Should there be some clarification here ? I understood that to relate to a change of cues only, since it is on the tracklist. I.e. it's an aggregate event from the oncuechange event of a cue inside the track. I didn't think it would relate to a change of existence of that track. Note that the even is attached to the TrackList, not the TrackList[], so it cannot be raised when a track is added or removed, only when something inside the TrackList changes. Are we talking about the same thing ? There is no TrackList array and TrackList is only used for audio/video, not text, so I don't understand the comment about cues. I'm talking about http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#tracklist which is the base class for MultipleTrackList and ExclusiveTrackList used to represent all the audio and video tracks (respectively). One instance of the object represents all the tracks, so I would assume that a change in the number of tracks is a change to this object. Ah yes, you're right: I got confused. It says Whenever the selected track is changed, the user agent must queue a task to fire a simple event named change at the MultipleTrackList object. This means it fires when the selectedIndex is changed, i.e. the user chooses a different track for rendering. I still don't think it relates to changes in the composition of tracks of a resource. That should be something different and should probably be on the MediaElement and not on the track list to also cover changes in text tracks. Fair enough. Also, as Eric (C) pointed out, one of the things which can change is which of several available versions of the content is being rendered (for adaptive bitrate cases). This doesn't necessarily change any of the metadata currently exposed on the video element, but nevertheless it's information that the application may need. It would be nice to expose some kind of identifier for the currently rendered stream and have an event when this changes. I think that a stream-format-supplied identifier would be sufficient. I don't know about the adaptive streaming situation. I think that is more about statistics/metrics rather than about change of resource. All the alternatives in an adaptive streaming resource should provide the same number of tracks and the same video dimensions, just at different bitrate/quality, no? I think of the different adaptive versions on a per-track basis (i.e. the alternatives are *within* each track), not a bunch of alternatives each of which contains several tracks. Both are possible, of course. It's certainly possible (indeed common) for different bitrate video encodings to have different resolutions - there are video encoding reasons to do this. Of course the aspect ratio should not change and nor should the dimensions on the screen (both would be a little peculiar for the user). Now, the videoWidth and videoHeight attributes of HTMLVideoElement are not the same as the resolution (for a start, they are in CSS pixels, which are square), but I think it quite likely that if the resolution of the video changes than the videoWidth and videoHeight might change. I'd be interested to hear how existing implementations relate resolution to videoWidth and videoHeight. Well, if videoWidth and videoHeight change and no dimensions on the video are provided through CSS, then surely the video will change size and the display will shrink. That would be a terrible user experience. For that reason I would suggest that such a change not be made in alternative adaptive streams. That seems backwards to me! I would say For that reason I would suggest that dimensions are provided through CSS or through the width and height attributes. Alternatively, we change the specification of the video element to accommodate this aspect of adaptive streaming (for example, the videoWidth and videoHeight could be defined to be based on the highest resolution bitrate being considered.) There are good video encoding reasons for different bitrates to be encoded at different resolutions which are far more important than any reasons not to do either of the above. Different video dimensions should be provided through the source element and @media attribute, but within an adaptive stream, the alternatives should be consistent because the target device won't change. I guess this is a discussion for another thread... :-) Possibly ;-) The device knows much
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On 2011-06-20 12:53, Jonas Sicking wrote: Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. Only custom request headers are matched against the list of simple headers and Host is not a custom header set by the EventSource implementation, hence there is no need to add it to the list. In XHR Level 2 the custom request headers are the author request headers. An option would be to always match the list of simple headers against author request headers only. //Per-Erik
Re: [whatwg] Video feedback
On Tue, Jun 21, 2011 at 12:07 AM, Mark Watson wats...@netflix.com wrote: On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote: On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote: The TrackList object has an onchanged event, which I assumed would fire when any of the information in the TrackList changes (e.g. tracks added or removed). But actually the spec doesn't state when this event fires (as far as I could tell - unless it is implied by some general definition of events called onchanged). Should there be some clarification here ? I understood that to relate to a change of cues only, since it is on the tracklist. I.e. it's an aggregate event from the oncuechange event of a cue inside the track. I didn't think it would relate to a change of existence of that track. Note that the even is attached to the TrackList, not the TrackList[], so it cannot be raised when a track is added or removed, only when something inside the TrackList changes. Are we talking about the same thing ? There is no TrackList array and TrackList is only used for audio/video, not text, so I don't understand the comment about cues. I'm talking about http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#tracklist which is the base class for MultipleTrackList and ExclusiveTrackList used to represent all the audio and video tracks (respectively). One instance of the object represents all the tracks, so I would assume that a change in the number of tracks is a change to this object. Ah yes, you're right: I got confused. It says Whenever the selected track is changed, the user agent must queue a task to fire a simple event named change at the MultipleTrackList object. This means it fires when the selectedIndex is changed, i.e. the user chooses a different track for rendering. I still don't think it relates to changes in the composition of tracks of a resource. That should be something different and should probably be on the MediaElement and not on the track list to also cover changes in text tracks. Fair enough. Also, as Eric (C) pointed out, one of the things which can change is which of several available versions of the content is being rendered (for adaptive bitrate cases). This doesn't necessarily change any of the metadata currently exposed on the video element, but nevertheless it's information that the application may need. It would be nice to expose some kind of identifier for the currently rendered stream and have an event when this changes. I think that a stream-format-supplied identifier would be sufficient. I don't know about the adaptive streaming situation. I think that is more about statistics/metrics rather than about change of resource. All the alternatives in an adaptive streaming resource should provide the same number of tracks and the same video dimensions, just at different bitrate/quality, no? I think of the different adaptive versions on a per-track basis (i.e. the alternatives are *within* each track), not a bunch of alternatives each of which contains several tracks. Both are possible, of course. It's certainly possible (indeed common) for different bitrate video encodings to have different resolutions - there are video encoding reasons to do this. Of course the aspect ratio should not change and nor should the dimensions on the screen (both would be a little peculiar for the user). Now, the videoWidth and videoHeight attributes of HTMLVideoElement are not the same as the resolution (for a start, they are in CSS pixels, which are square), but I think it quite likely that if the resolution of the video changes than the videoWidth and videoHeight might change. I'd be interested to hear how existing implementations relate resolution to videoWidth and videoHeight. Well, if videoWidth and videoHeight change and no dimensions on the video are provided through CSS, then surely the video will change size and the display will shrink. That would be a terrible user experience. For that reason I would suggest that such a change not be made in alternative adaptive streams. That seems backwards to me! I would say For that reason I would suggest that dimensions are provided through CSS or through the width and height attributes. Alternatively, we change the specification of the video element to accommodate this aspect of adaptive streaming (for example, the videoWidth and videoHeight could be defined to be based on the highest resolution bitrate being considered.) There are good video encoding reasons for different bitrates to be encoded at different resolutions which are far more important than any reasons not to do either of the above. Different video dimensions should be provided through the source element and @media attribute, but within an adaptive stream, the alternatives should be consistent because the target device won't change. I guess this is a
Re: [whatwg] Video feedback
On Jun 20, 2011, at 5:28 PM, Silvia Pfeiffer wrote: On Tue, Jun 21, 2011 at 12:07 AM, Mark Watson wats...@netflix.com wrote: On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote: On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote: The TrackList object has an onchanged event, which I assumed would fire when any of the information in the TrackList changes (e.g. tracks added or removed). But actually the spec doesn't state when this event fires (as far as I could tell - unless it is implied by some general definition of events called onchanged). Should there be some clarification here ? I understood that to relate to a change of cues only, since it is on the tracklist. I.e. it's an aggregate event from the oncuechange event of a cue inside the track. I didn't think it would relate to a change of existence of that track. Note that the even is attached to the TrackList, not the TrackList[], so it cannot be raised when a track is added or removed, only when something inside the TrackList changes. Are we talking about the same thing ? There is no TrackList array and TrackList is only used for audio/video, not text, so I don't understand the comment about cues. I'm talking about http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#tracklist which is the base class for MultipleTrackList and ExclusiveTrackList used to represent all the audio and video tracks (respectively). One instance of the object represents all the tracks, so I would assume that a change in the number of tracks is a change to this object. Ah yes, you're right: I got confused. It says Whenever the selected track is changed, the user agent must queue a task to fire a simple event named change at the MultipleTrackList object. This means it fires when the selectedIndex is changed, i.e. the user chooses a different track for rendering. I still don't think it relates to changes in the composition of tracks of a resource. That should be something different and should probably be on the MediaElement and not on the track list to also cover changes in text tracks. Fair enough. Also, as Eric (C) pointed out, one of the things which can change is which of several available versions of the content is being rendered (for adaptive bitrate cases). This doesn't necessarily change any of the metadata currently exposed on the video element, but nevertheless it's information that the application may need. It would be nice to expose some kind of identifier for the currently rendered stream and have an event when this changes. I think that a stream-format-supplied identifier would be sufficient. I don't know about the adaptive streaming situation. I think that is more about statistics/metrics rather than about change of resource. All the alternatives in an adaptive streaming resource should provide the same number of tracks and the same video dimensions, just at different bitrate/quality, no? I think of the different adaptive versions on a per-track basis (i.e. the alternatives are *within* each track), not a bunch of alternatives each of which contains several tracks. Both are possible, of course. It's certainly possible (indeed common) for different bitrate video encodings to have different resolutions - there are video encoding reasons to do this. Of course the aspect ratio should not change and nor should the dimensions on the screen (both would be a little peculiar for the user). Now, the videoWidth and videoHeight attributes of HTMLVideoElement are not the same as the resolution (for a start, they are in CSS pixels, which are square), but I think it quite likely that if the resolution of the video changes than the videoWidth and videoHeight might change. I'd be interested to hear how existing implementations relate resolution to videoWidth and videoHeight. Well, if videoWidth and videoHeight change and no dimensions on the video are provided through CSS, then surely the video will change size and the display will shrink. That would be a terrible user experience. For that reason I would suggest that such a change not be made in alternative adaptive streams. That seems backwards to me! I would say For that reason I would suggest that dimensions are provided through CSS or through the width and height attributes. Alternatively, we change the specification of the video element to accommodate this aspect of adaptive streaming (for example, the videoWidth and videoHeight could be defined to be based on the highest resolution bitrate being considered.) There are good video encoding reasons for different bitrates to be encoded at different resolutions which are far more important than any reasons not to do either of the above. Different video dimensions should be provided through the source element and @media attribute, but within an adaptive stream, the alternatives
Re: [whatwg] Hashing Passwords Client-side
James Graham jgra...@opera.com schrieb am Mon, 20 Jun 2011 10:40:20 +0200: […] and the authors who are most likely to get the server-side wrong are the same ones who are already storing passwords in plain text. What reasoning is behind the assertion that those authors will use the provided client-side hashing facilities correctly, then? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, Jun 20, 2011 at 7:13 AM, Per-Erik Brodin per-erik.bro...@ericsson.com wrote: On 2011-06-20 12:53, Jonas Sicking wrote: Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. Only custom request headers are matched against the list of simple headers and Host is not a custom header set by the EventSource implementation, hence there is no need to add it to the list. In XHR Level 2 the custom request headers are the author request headers. An option would be to always match the list of simple headers against author request headers only. It seems like you are saying exactly what I was saying? Am I missing something? / Jonas
Re: [whatwg] CORS requests for image and video elements
On Mon, Jun 20, 2011 at 6:39 AM, Anne van Kesteren ann...@opera.com wrote: On Sat, 21 May 2011 04:48:15 +0200, Jonas Sicking jo...@sicking.cc wrote: When we designed CORS we very intentionally did not want to allow allow * rules for resources that are loaded with user credentials (most significantly cookies). The reason was that we did not want people to repeat the mistakes that happened when flash's cross-site loading technology was deployed. Many sites added a allow * rule to all their resources, thus accidentally leaking all user data to any site that the user visited. That is not actually true as that would require a second header, Access-Control-Allow-Credentials. I think we should stop banning *. It's still very easy to add those two static headers and thus expose your whole site to attack (most servers allow adding headers on a per-subtree basis). I also don't see a reason to allow it as so far I haven't heard of anyone having problems due to the lack of ability to use *-rules in combination with cookies. So I'm strongly against allowing this. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Sun, 19 Jun 2011, Per-Erik Brodin wrote: On 2011-06-17 21:57, Ian Hickson wrote: On Wed, 1 Jun 2011, ilya goberman wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. Done. Great news! The same-origin check in step 4 under When the EventSource() constructor is invoked .. is still present. Oops. Fixed. According to the CORS specification, a request is not to be terminated even when the resource sharing check fails. However, when using CORS with EventSource I think it may be justified since the response is typically not returned right away. Not sure what you mean here. Could you elaborate? The Cache-Control request header used with EventSource is not in the list of simple request headers and a preflight request is not really an option here in my opinion. Not sure what you mean by simple request headers. The Cache-Control header isn't a custom header, so it doesn't affect whether you use a preflight or not. I've clarified the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Handling of collapsed whitespace in contenteditable
On Mon, Jun 20, 2011 at 5:09 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Does anyone have any suggestions on how best to handle this? It seems like no matter what we do, the best advice to authors would be to set white-space: pre-wrap on the editable region and the resulting editable content. So given that, I wish we could make this happen by default and avoid all the complexity. Failing that, I'll have to work out the least damaging way to use nbsp's here, but it's never going to behave right in some cases. I should add, by the way, that the latter seems very hard to get right without delving further into CSS details than I'd prefer. I can't think of any reliable and not-extremely-complicated way to test from JavaScript whether a space needs to be non-breaking or not in cases like bfoo[]/bbar, for instance. Indeed, in that case WebKit produces nbsp; instead of a regular space.
[whatwg] Handling of collapsed whitespace in contenteditable
If the user has the cursor positioned at the beginning or end of a
line, or immediately before or after a space, and hits space,
inserting a space at the current location would result in no visible
effect. Thus browsers will typically insert an nbsp in at least some
of these conditions, and/or convert surrounding spaces to nbsp's.
This causes all sorts of problems:
* An nbsp at the end of a line makes the last word longer, so when you
hit space, the last word on the line might jump to the next line.
Then when you type a letter, the nbsp gets converted to a regular
space and the word jumps back to the previous line. (I observed this
in Opera. IE and Gecko seem to have some special-case to avoid this;
WebKit avoids it with a more general hack that I'll note later.)
* An nbsp that winds up immediately before a word will cause the word
to be indented if it happens to start a line. Gecko seems to be very
careful to avoid this case, but all other engines do it sometimes.
* A long run of spaces of which some are spaces and some are nbsp's
can result in nbsp's at the beginning of a line. Thus if you type
three spaces in between two words for whatever reason, in some cases
the second word can be indented. This is probably not what users
want.
The behavior we really want here is to output regular spaces, and use
white-space: pre-wrap. This matches the word processors I tested
(Word 2007 and a moderately old OO.org): spaces don't collapse, and a
line break can never occur before a space, but it can always occur
after a run of spaces, and words followed by spaces don't get pushed
to the next line. (This is how pre-wrap behaves in IE and WebKit, at
least. In Gecko and Opera a long sequence of spaces will push the
preceding word to the next line, but I'd say that's a bug.)
If anyone here thinks it's practical to just set [contenteditable] {
white-space: pre-wrap } in UA stylesheets and output spaces all the
time, please say so. (I know the selector isn't quite right.) I
assume it's not, because it will make existing contenteditable areas
containing hand-authored content look wrong. If we did this, of
course, authors would have to set white-space: pre-wrap on the
resulting non-editable content as well, but at least then it would
work exactly as we want. If they don't set it, it won't look quite
the same as when the user edited it, but probably it wouldn't look
drastically worse.
It seems WebKit already does something kind of like this: in
contenteditable areas, line breaks are allowed at nbsp, they just
don't collapse. Thus user-created whitespace is partly nbsp's, and
breaks but doesn't collapse. Pre-existing author-added whitespace
doesn't contain nbsp and so collapses. And when you convert it to
non-editable content, it still doesn't collapse but breaking might be
different. This seems like a kind of evil hack, though.
Does anyone have any suggestions on how best to handle this? It seems
like no matter what we do, the best advice to authors would be to set
white-space: pre-wrap on the editable region and the resulting
editable content. So given that, I wish we could make this happen by
default and avoid all the complexity. Failing that, I'll have to work
out the least damaging way to use nbsp's here, but it's never going to
behave right in some cases.
Re: [whatwg] Hashing Passwords Client-side
On Mon, Jun 20, 2011 at 11:15 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: James Graham jgra...@opera.com schrieb am Mon, 20 Jun 2011 10:40:20 +0200: […] and the authors who are most likely to get the server-side wrong are the same ones who are already storing passwords in plain text. What reasoning is behind the assertion that those authors will use the provided client-side hashing facilities correctly, then? The fact that you can get minimally adequate functionality by just writing input type=password hash. ~TJ
Re: [whatwg] Handling of collapsed whitespace in contenteditable
There's a very good reason why existing browser engines have to resort to nbsp; hacks. It's the only practical way to make sure that foo__bar (s/_/ /) entered into an editable element would appear the intended way when the innerHTML of the editable area is submitted to a server and later displayed in another documents. For this reason, I think we should make the sad choice of specifying the latter behavior. Cheers, Ehsan
Re: [whatwg] Handling of collapsed whitespace in contenteditable
Aryeh Gregor writes: The behavior we really want here is to output regular spaces, and use white-space: pre-wrap. Does anyone have any suggestions on how best to handle this? It seems like no matter what we do, the best advice to authors would be to set white-space: pre-wrap on the editable region and the resulting editable content. Can you detect when an author has set white-space: pre-wrap, and specify that browsers have the sane behaviour in that case? You'd still have to specify the awkward, fragile behaviour for when it isn't set, but it at least means that going forwards authors could opt in to the sane behaviour. And any author who complains about the nbsp;-s not being quite as they wanted could be pointed at the pre-wrap alternative. Smylers -- http://twitter.com/Smylers2
Re: [whatwg] Handling of collapsed whitespace in contenteditable
On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgari eh...@mozilla.com wrote: There's a very good reason why existing browser engines have to resort to nbsp; hacks. It's the only practical way to make sure that foo__bar (s/_/ /) entered into an editable element would appear the intended way when the innerHTML of the editable area is submitted to a server and later displayed in another documents. Is that really such a problem? At worst, there will be annoying mismatches between the same content when it's editable and not editable. Usually these won't really mess up the document, but if the author notices and compares in a debugger, they'll easily be able to figure out that the different white-space value is what's causing the problem, and be able to fix it. WebKit already handles nbsp; differently in contenteditable and not -- have they received any complaints from authors about it? Granted, that discrepancy isn't as drastic as white-space: normal vs. pre-wrap. I'd have thought the bigger problem would be making hand-authored HTML contenteditable. pre-wrap would seriously mangle it if it uses any indentation, and there might be lots of that out on the web. On Mon, Jun 20, 2011 at 5:47 PM, Smylers smyl...@stripey.com wrote: Can you detect when an author has set white-space: pre-wrap, and specify that browsers have the sane behaviour in that case? That's effectively how it already works, except in IE. If the current element has white-space pre or pre-wrap, everyone but IE will just insert regular spaces. (IE only does this for pre, not other elements with non-default white-space values.) But in that case, the behavior would be entirely undiscoverable, so no one would use it. If pre-wrap were the default, the discrepancy in display between editable and non-editable would quickly lead savvy authors to figure out that they need pre-wrap on their content too.
Re: [whatwg] Handling of collapsed whitespace in contenteditable
On Mon, Jun 20, 2011 at 3:00 PM, Aryeh Gregor simetrical+...@gmail.comwrote: Is that really such a problem? At worst, there will be annoying mismatches between the same content when it's editable and not editable. Usually these won't really mess up the document, but if the author notices and compares in a debugger, they'll easily be able to figure out that the different white-space value is what's causing the problem, and be able to fix it. Problem is that not all user agents, in particular, mail clients support white-space: pre-wrap. - Ryosuke
Re: [whatwg] Handling of collapsed whitespace in contenteditable
On 11-06-20 6:00 PM, Aryeh Gregor wrote: On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgarieh...@mozilla.com wrote: There's a very good reason why existing browser engines have to resort to nbsp; hacks. It's the only practical way to make sure that foo__bar (s/_/ /) entered into an editable element would appear the intended way when the innerHTML of the editable area is submitted to a server and later displayed in another documents. Is that really such a problem? At worst, there will be annoying mismatches between the same content when it's editable and not editable. Usually these won't really mess up the document, but if the author notices and compares in a debugger, they'll easily be able to figure out that the different white-space value is what's causing the problem, and be able to fix it. I think so, yes. There are lots of people who use the space key to format the output to match what they want it to look like, and using preformatted whitespace means that what they would get is not what they would see on the screen. WebKit already handlesnbsp; differently in contenteditable and not -- have they received any complaints from authors about it? Granted, that discrepancy isn't as drastic as white-space: normal vs. pre-wrap. I'm not talking about handling non-breaking spaces differently in editable sections (I do believe that's a problem, but it's not relevant to my point). I'm talking about using ASCII space characters and relying on preformatted whitespace to format stuff correctly in editable areas. Since preformatted whitespace is not the default, the generated HTML fragment would render completely differently in non-editable mode. I'd have thought the bigger problem would be making hand-authored HTML contenteditable. pre-wrap would seriously mangle it if it uses any indentation, and there might be lots of that out on the web. That is also a valid concern. On Mon, Jun 20, 2011 at 5:47 PM, Smylerssmyl...@stripey.com wrote: Can you detect when an author has set white-space: pre-wrap, and specify that browsers have the sane behaviour in that case? That's effectively how it already works, except in IE. True, but I agree with Smylers in that we need to specify that behavior. Cheers, Ehsan
Re: [whatwg] Hashing Passwords Client-side
On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote: FWIW I disagree. The same argument could be used against client-side form validation since some authors might stop doing proper server-side validation. I agree, HTML5 forms provide a minor net security loss. However, the loss is fairly small and is easily outweighed by the non-security advantages. Here we have a proposal that only has security benefits, so if it's a net security loss by even a small margin, or even if it's only a small security gain, it's not worth it.
Re: [whatwg] Handling of collapsed whitespace in contenteditable
It is certainly the case that some large subset of users use spaces to align content, not to mention really care about things like two spaces after periods, etc. One way or another, contentEditable needs to support this. If we were starting with a clean slate, the editing behavior we want is likely whitespace:pre-wrap + some logic about what to do when you put extra spaces at the end of a line*. We should make sure the pre-wrap editing works as well as possible (e.g. doesn't do any of these NBSP shenanigans), but we have to support non-pre-wrap even if it's not the default. So, one way or another, we need to spec this behavior. The only way we could make pre-wrap the default is if we made it more backwards-compatible (assuming proper browser support for the CSS). A couple things we'd need to do: 1. Getting innerHTML would need to be special-cased for contentEditable nodes to wrap it in a span with whitespace:pre-wrap or to propagate the whitespace down appropriately. 2. Copy would need to do the same. Copy is a whole can of worms that we'll need to discuss anyways. As it is, WebKit will already do the copy propagating styles if you're contentEditable node is whitespace:pre-wrap. I'm not sure if there are other things we'd need to do, but I expect (1) to be pretty controversial and I can't think of alternatives at the moment that would provide sufficient backwards-compatibility. * Most word-processors stop showing the spaces at the end of a line. They insert the spaces but don't actually move the cursor or scroll until a non-space character is inserted. This behavior is insane to me, but again, it's what some non-trivial subset of users expect. Ojan On Mon, Jun 20, 2011 at 3:13 PM, Ehsan Akhgari eh...@mozilla.com wrote: On 11-06-20 6:00 PM, Aryeh Gregor wrote: On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgarieh...@mozilla.com wrote: There's a very good reason why existing browser engines have to resort to nbsp; hacks. It's the only practical way to make sure that foo__bar (s/_/ /) entered into an editable element would appear the intended way when the innerHTML of the editable area is submitted to a server and later displayed in another documents. Is that really such a problem? At worst, there will be annoying mismatches between the same content when it's editable and not editable. Usually these won't really mess up the document, but if the author notices and compares in a debugger, they'll easily be able to figure out that the different white-space value is what's causing the problem, and be able to fix it. I think so, yes. There are lots of people who use the space key to format the output to match what they want it to look like, and using preformatted whitespace means that what they would get is not what they would see on the screen. WebKit already handlesnbsp; differently in contenteditable and not -- have they received any complaints from authors about it? Granted, that discrepancy isn't as drastic as white-space: normal vs. pre-wrap. I'm not talking about handling non-breaking spaces differently in editable sections (I do believe that's a problem, but it's not relevant to my point). I'm talking about using ASCII space characters and relying on preformatted whitespace to format stuff correctly in editable areas. Since preformatted whitespace is not the default, the generated HTML fragment would render completely differently in non-editable mode. I'd have thought the bigger problem would be making hand-authored HTML contenteditable. pre-wrap would seriously mangle it if it uses any indentation, and there might be lots of that out on the web. That is also a valid concern. On Mon, Jun 20, 2011 at 5:47 PM, Smylerssmyl...@stripey.com wrote: Can you detect when an author has set white-space: pre-wrap, and specify that browsers have the sane behaviour in that case? That's effectively how it already works, except in IE. True, but I agree with Smylers in that we need to specify that behavior. Cheers, Ehsan
Re: [whatwg] getSelection().modify() in vertical writing modes
15.06.2011, в 16:13, Ryosuke Niwa написал(а): Now, in horizontal writing modes, 'left' and 'right' are used to move caret in visual order (in the sense of bidirectional text) and 'forward' and 'backward' are used to move in logical order. However, swapping the meaning of 'character' and 'line' for 'forward' and 'backward' is quite confusing as they used to walk DOM in logical order, and didn't depend on how characters are presented. I think that redefining left and right to mean something different would be much more confusing in the long run. Just like we didn't redefine left and right for RTL, I don't see why we need to do that for vertical text. - WBR, Alexey Proskuryakov
Re: [whatwg] getSelection().modify() in vertical writing modes
On Mon, Jun 20, 2011 at 5:33 PM, Alexey Proskuryakov a...@webkit.org wrote: 15.06.2011, в 16:13, Ryosuke Niwa написал(а): Now, in horizontal writing modes, 'left' and 'right' are used to move caret in visual order (in the sense of bidirectional text) and 'forward' and 'backward' are used to move in logical order. However, swapping the meaning of 'character' and 'line' for 'forward' and 'backward' is quite confusing as they used to walk DOM in logical order, and didn't depend on how characters are presented. I think that redefining left and right to mean something different would be much more confusing in the long run. Just like we didn't redefine left and right for RTL, I don't see why we need to do that for vertical text. I don't think we can make this decision based on comparisons to RTL. If we wanted this API to make sense, we'd disallow using left and right in vertical writing mode and require up and down instead. The downside is that web developers who use this will now need to consider vertical writing mode, which I expect very few developers will. I think we should try to make left and right do the what web developers would expect them to do in non-vertical writing mode. Specifically, they should select a single character if you pass character as the granularity and a single line if you pass line as the granularity. That way developers don't need to specially handle vertical writing mode for logic like select the next character and do something with it. Realistically, we need to operate in a world where developers won't know to handle vertical text specially. Ojan
Re: [whatwg] getSelection().modify() in vertical writing modes
In WebVTT we used start and end instead of left and right. Might that help? Silvia. On Tue, Jun 21, 2011 at 11:00 AM, Ojan Vafai o...@chromium.org wrote: On Mon, Jun 20, 2011 at 5:33 PM, Alexey Proskuryakov a...@webkit.org wrote: 15.06.2011, в 16:13, Ryosuke Niwa написал(а): Now, in horizontal writing modes, 'left' and 'right' are used to move caret in visual order (in the sense of bidirectional text) and 'forward' and 'backward' are used to move in logical order. However, swapping the meaning of 'character' and 'line' for 'forward' and 'backward' is quite confusing as they used to walk DOM in logical order, and didn't depend on how characters are presented. I think that redefining left and right to mean something different would be much more confusing in the long run. Just like we didn't redefine left and right for RTL, I don't see why we need to do that for vertical text. I don't think we can make this decision based on comparisons to RTL. If we wanted this API to make sense, we'd disallow using left and right in vertical writing mode and require up and down instead. The downside is that web developers who use this will now need to consider vertical writing mode, which I expect very few developers will. I think we should try to make left and right do the what web developers would expect them to do in non-vertical writing mode. Specifically, they should select a single character if you pass character as the granularity and a single line if you pass line as the granularity. That way developers don't need to specially handle vertical writing mode for logic like select the next character and do something with it. Realistically, we need to operate in a world where developers won't know to handle vertical text specially. Ojan
Re: [whatwg] getSelection().modify() in vertical writing modes
On Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: In WebVTT we used start and end instead of left and right. Might that help? Isn't 'start' and 'end' more analogous to 'forward' and 'backward'? They're logical movement, right? - Ryosuke
[whatwg] HTTP adaptive streaming of video (was Re: Video feedback)
Moving this to a different subject, since it's all about adaptive streaming now. On Tue, Jun 21, 2011 at 1:43 AM, Mark Watson wats...@netflix.com wrote: On Jun 20, 2011, at 5:28 PM, Silvia Pfeiffer wrote: On Tue, Jun 21, 2011 at 12:07 AM, Mark Watson wats...@netflix.com wrote: On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote: On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote: Also, as Eric (C) pointed out, one of the things which can change is which of several available versions of the content is being rendered (for adaptive bitrate cases). This doesn't necessarily change any of the metadata currently exposed on the video element, but nevertheless it's information that the application may need. It would be nice to expose some kind of identifier for the currently rendered stream and have an event when this changes. I think that a stream-format-supplied identifier would be sufficient. I don't know about the adaptive streaming situation. I think that is more about statistics/metrics rather than about change of resource. All the alternatives in an adaptive streaming resource should provide the same number of tracks and the same video dimensions, just at different bitrate/quality, no? I think of the different adaptive versions on a per-track basis (i.e. the alternatives are *within* each track), not a bunch of alternatives each of which contains several tracks. Both are possible, of course. It's certainly possible (indeed common) for different bitrate video encodings to have different resolutions - there are video encoding reasons to do this. Of course the aspect ratio should not change and nor should the dimensions on the screen (both would be a little peculiar for the user). Now, the videoWidth and videoHeight attributes of HTMLVideoElement are not the same as the resolution (for a start, they are in CSS pixels, which are square), but I think it quite likely that if the resolution of the video changes than the videoWidth and videoHeight might change. I'd be interested to hear how existing implementations relate resolution to videoWidth and videoHeight. Well, if videoWidth and videoHeight change and no dimensions on the video are provided through CSS, then surely the video will change size and the display will shrink. That would be a terrible user experience. For that reason I would suggest that such a change not be made in alternative adaptive streams. That seems backwards to me! I would say For that reason I would suggest that dimensions are provided through CSS or through the width and height attributes. Alternatively, we change the specification of the video element to accommodate this aspect of adaptive streaming (for example, the videoWidth and videoHeight could be defined to be based on the highest resolution bitrate being considered.) There are good video encoding reasons for different bitrates to be encoded at different resolutions which are far more important than any reasons not to do either of the above. Different video dimensions should be provided through the source element and @media attribute, but within an adaptive stream, the alternatives should be consistent because the target device won't change. I guess this is a discussion for another thread... :-) Possibly ;-) The device knows much better than the page author what capabilities it has and so what resolutions are suitable for the device. So it is better to provide all the alternatives as a single resource and have the device work out which subset it can support. Or at least, the list should be provided all at the same level - there is no rationale for a hierarchy of alternatives. The way in which HTML deals with different devices and their different capabilities is through media queries. As a author you provide your content with different versions of media-dependent style sheets and content, so that when you view the page with a different device, the capabilities of the device select the right style sheet and content for display on that device. Opera has an example on how to use this here: http://dev.opera.com/articles/view/everything-you-need-to-know-about-html5-video-and-audio/ (search for Media Query). I believe that this mechanism should also work for adaptive streaming, such that you provide multiple alternative media resources through the source element, each of which has a @media attribute that says what device capabilities that particular resource is adequate for. Except that the media resource provides alternative bitrate files for that case. I do not see a need to move this functionality into the adaptive streaming file. Nice to get started on this discussion about adaptive streaming. ;-) Indeed. So, what I said above is that there is no rationale for a hierarchy. What I mean is that if I have ten encodings of a video, I should just list those ten in a flat list somewhere, annotated
Re: [whatwg] getSelection().modify() in vertical writing modes
On Tue, Jun 21, 2011 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: In WebVTT we used start and end instead of left and right. Might that help? Isn't 'start' and 'end' more analogous to 'forward' and 'backward'? They're logical movement, right? start and end are positions, not movement. You start at the start and you stop and the end. forward and backward are your movements. Silvia.
Re: [whatwg] getSelection().modify() in vertical writing modes
I'm not sure how that relates to this discussion then. - Ryosuke On Mon, Jun 20, 2011 at 6:35 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: On Tue, Jun 21, 2011 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: In WebVTT we used start and end instead of left and right. Might that help? Isn't 'start' and 'end' more analogous to 'forward' and 'backward'? They're logical movement, right? start and end are positions, not movement. You start at the start and you stop and the end. forward and backward are your movements. Silvia.
Re: [whatwg] getSelection().modify() in vertical writing modes
I'm sorry, I probably misunderstood. I saw the discussion about left and right and vertical writing mode. forward and backward seem appropriate then, I guess. Disregard me. :-) Silvia. On Tue, Jun 21, 2011 at 11:37 AM, Ryosuke Niwa rn...@webkit.org wrote: I'm not sure how that relates to this discussion then. - Ryosuke On Mon, Jun 20, 2011 at 6:35 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Jun 21, 2011 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: In WebVTT we used start and end instead of left and right. Might that help? Isn't 'start' and 'end' more analogous to 'forward' and 'backward'? They're logical movement, right? start and end are positions, not movement. You start at the start and you stop and the end. forward and backward are your movements. Silvia.
