Re: [whatwg] Change request: rules for pixel ratio
On Tue, 2008-06-10 at 10:48 -0700, Ralph Giles wrote: Does this mean the implementation must retrieve the self-described pixel aspect ratio from the stream and supply it as part of the DOM? Yes, the implementation would read the pixel ratio from the video stream. In libtheora this is aspect_numerator/aspect_denominator of the th_info struct (yes, this is pixel ratio, not frame aspect ratio). This would all be handled by some multimedia framework anyway, so most browsers won't have to worry too much about such details. Exposing pixel ratio as readonly float videoPixelRatio in HTMLVideoElement might be a good idea. If the media resource doesn't self-describe its pixel ratio (many formats don't) it should be assumed to be 1.0. I'm not convinced it is necessary as content authors who want to be very explicit will probably set the pixelratio manually. Still, it is trivial to expose and might make life easier for those who want this information for low-level control of the video element size via the DOM. -- Philip Jägenstedt Opera Software
Re: [whatwg] Proposal: target=_tab
Hi Adrian, That is actually a very good point, I missed that. In fact, it means that _tab should not be part of HTML spec because it would possibly make things even worse than they currently are (opening GReader links in new _tabs in old browsers would lead to losing the opened articles) . I still believe that there should be a way to instruct the browser to open a new tab and the before mentioned CSS3 target-new is probably the best way (if not only one) to go. Thanks, Borek - Original Message From: Adrian Sutton [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Tuesday, 10 June, 2008 10:29:54 PM Subject: Re: [whatwg] Proposal: target=_tab From my brief testing, _tab opens a new window so it should be backwards compatible. It's deceptively close but not quite backwards compatible. _tab will cause the link to open in the frame called _tab and if it doesn't exist it creates it, as a new window. So the first link works perfectly and opens a new window but the second link you click will replace the first one since there is now a frame called _tab. Regards, Adrian Sutton. __ Adrian Sutton, CTO US: +1 (650) 292 9659 x717 UK: +44 (20) 8123 0617 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/ __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
Once you have support in CSS, you can use DOM+CSS from JS. No particular support within JS is required. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Borek Bernard Sent: Wednesday, June 11, 2008 10:37 AM To: Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Ian, What do you think about the GReader use case? In my eyes, it makes the _tab scenario quite valid. But, as mentioned by Adrian Sutton, there would be technical problems with older browsers so this proposal has to be scrapped. On the HTML/CSS level, this will be eventually handled by the 'target-new' property (which will be more flexible than target=_tab as well) and I hope it will find its way into JavaScript too, eventually. P.S. Sorry for not maintaining the thread sequence correctly, I couldn't figure out how to do that (that's why I used the forum instead of the mailing list in the first place :) --- Borek
Re: [whatwg] Proposal: target=_tab
In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. In general, it's best to let users decide where the link should open. Absolutely agreed. What is interesting though is that authors can let open new windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this functionality, that may ultimately impede user experience, can really be considered structural, presentational, /and/ behavioral. -- Jens Meiert http://meiert.com/en/
Re: [whatwg] Proposal: target=_tab
Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek - Original Message From: Kristof Zelechovski [EMAIL PROTECTED] To: Borek Bernard [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Wednesday, 11 June, 2008 10:42:41 AM Subject: Re: [whatwg] Proposal: target=_tab Once you have support in CSS, you can use DOM+CSS from JS. No particular support within JS is required. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Borek Bernard Sent: Wednesday, June 11, 2008 10:37 AM To: Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Ian, What do you think about the GReader use case? In my eyes, it makes the _tab scenario quite valid. But, as mentioned by Adrian Sutton, there would be technical problems with older browsers so this proposal has to be scrapped. On the HTML/CSS level, this will be eventually handled by the 'target-new' property (which will be more flexible than target=_tab as well) and I hope it will find its way into JavaScript too, eventually. P.S. Sorry for not maintaining the thread sequence correctly, I couldn't figure out how to do that (that's why I used the forum instead of the mailing list in the first place :) --- Borek __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Proposal: target=_tab
On Wed, 11 Jun 2008, Jens Meiert wrote: In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors should have the ability to suggest that links open in new windows and new tabs. The suggested solution is to introduce a new browsing context keyword _tab. In general, it's best to let users decide where the link should open. Absolutely agreed. What is interesting though is that authors can let open new windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this functionality, that may ultimately impede user experience, can really be considered structural, presentational, /and/ behavioral. I have no idea what you mean or how it affects the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] ImageData feedback
On Tue, 19 Feb 2008, Oliver Hunt wrote:
The first is relatively simple, 3.14.11.1.10 states
If any of the arguments to createImageData() or getImageData() are infinite
or NaN, or if either the sw or sh arguments are zero, the method must instead
raise an INDEX_SIZE_ERR exception.
I feel this should probably be extended to throw on negative sw and sh.
This is intended to support negative arguments, hence the mention of
absolute magnitude in the definition of what the method does. This is
for consistency with the other methods, which work fine with negative
dimensions.
Additionally sw and sh are both floats and can therefore have a fractional
component, so this needs to be handled. I think we should specify the finite
value clamps in device pixels, eg.
If any of the arguments to createImageData() or getImageData() are infinite
or NaN, or if either the sw or sh arguments are less than one when scaled to
the device pixel space, the method must instead raise an INDEX_SIZE_ERR
exception.
I don't think we want to make exception raising be dependent on the
resolution of the backing store, since that's a UA decision. I think it
makes more sense to make the height and width be always at least 1. Right
now UAs are required to do this, though it's not explicitly stated in
terms of rounding. I can add a note if you like.
(I've added createImageData() to the paragraph that talks about device
rounding, by the way. This was an unintentional omission.)
The other issues relate to the data member of ImageData. Currently this
is referred to as an int array, however the DOM does not define such an
array, and certainly doesn't specify any kind of clamping (let alone
clamping to a smaller range than that supported by the type). I think
the behaviour of this array needs to be defined, and givevn that only
Opera currently implements an actual ImageData type i've been looking at
their implementation.
Assuming we have an ImageData object with width, w and height, h then Opera
provides a data member of CanvasPixelArray, with the following behaviour:
* A readonly length property is provided return the value w*h*4
* Assignment to elements [0..w*h*4) (approximately) follows the behaviour
defined in section 3.14.11.1.10 (assignment never throws NaN is stored a zero
which i believe is preferable)
* Assignment to elements outside [0..w*h*4) results in no clamping and does
not alter the length property, this includes non-numeric properties
* Iteration returns only the length property and those properties that have
been added programmatically -- iteration does *not* include [0..w*h*4)
By and large I am fine with this behaviour, although i would prefer that
it were not possible to add arbitrary properties to the data array --
but i can't come up with a real justification for such a restriction :D
I've added a CanvasPixelArray interface and used that. (The setter and
getter are temporarily named XXX5 and XXX6 while we wait for WebIDL to
have a way to hide members from objects.)
On Thu, 21 Feb 2008, Oliver Hunt wrote:
At the moment the spec merely states that
putImageData(getImageData(sx,sy,..),sx,sy) should not result in any
visible change to the canvas, however for those implementations that use
a premultiplied buffer there is a necessary premultiplication stage
during blitting that results in a loss of precision in some
circumstances -- the most obvious being the case of alpha == 0, but many
other cases exist, eg. (254, 254, 254, alpha 255). This loss of
precision has no actual effect on the visible output, but does mean that
in the following case:
imageData = context.getImageData(0,0,...);
imageData.data[0]=254;
imageData.data[1]=254;
imageData.data[2]=254;
imageData.data[3]=1;
context.putImageData(imageData,0,0);
imageData2.data = context.getImageData(0,0,...);
At this point implementations that use premultiplied buffers can't
guarantee imageData.data[0] == imageData2.data[0]
They don't have to. As Philip says:
On Wed, 30 Apr 2008, Philip Taylor wrote:
The spec does not state that getImageData(putImageData(data)) == data,
which is where the problem would occur. It only states that
putImageData(getImageData) == identity function, which is not a
problem for premultiplied implementations (since the conversion from
premultiplied to non-premultiplied is lossless and reversible). So I
don't think the spec needs to change at all (except that it could have
a note mentioning the issue).
(getImageData can convert internal premultiplied (pr,pg,pb,a) into
ImageData's (r,g,b,a):
if (a == 0) {
r = g = b = 0;
} else {
r = (pr * 255) / a;
g = (pg * 255) / a;
b = (pb * 255) / a;
}
(using round-to-zero integer division). putImageData can convert the other
way:
pr = (r*a + 254) / 255;
pg = (g*a + 254) / 255;
pb = (b*a + 254) / 255;
Then put(get()) has no effect on
Re: [whatwg] Proposal: target=_tab
What is interesting though is that authors can let open new windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this functionality, that may ultimately impede user experience, can really be considered structural, presentational, /and/ behavioral. I have no idea what you mean or how it affects the spec. And you don't have to as it was just a side note. HTML 5 won't resolve this anyway. -- Jens Meiert http://meiert.com/en/
Re: [whatwg] Proposal: target=_tab
On Wed, 11 Jun 2008, Jens Meiert wrote: What is interesting though is that authors can let open new windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this functionality, that may ultimately impede user experience, can really be considered structural, presentational, /and/ behavioral. I have no idea what you mean or how it affects the spec. And you don't have to as it was just a side note. HTML 5 won't resolve this anyway. Ah. Ok then. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] imageRenderingQuality property
On Mon, 2 Jun 2008, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). How can an author know which is appropriate? This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty: attribute string imageRenderingQuality; 'auto' (default): The user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. 'optimizeQuality': Emphasize quality over rendering speed. 'optimizeSpeed': Emphasize speed over rendering quality. This seems to be something that is completely inappropriate for SVG or for canvas. The UA should make its own tradeoffs, likely tradeoffs that don't even remotely fit into the categories above (e.g. adapting to scripts that do animations to converge on the best quality possible at 30fps, or optimise for memory usage). On Mon, 2 Jun 2008, Oliver Hunt wrote: Um, could you actually give some kind of reasoning for these? I am not aware of any significant performance issues in Canvas that cannot be almost directly attributed to JavaScript itself rather than the canvas. On Mon, 2 Jun 2008, Vladimir Vukicevic wrote: Sure; bilinear filtering is slower than nearest neighbour sampling, and in many cases the app author would like to be able to decide that tradeoff (or, at least, to be able to say I want this to go as fast as possible, regardless of quality). Some apps might also render to a canvas just once, and would prefer to do it at the highest quality filtering available even if it's more expensive than the default. Why not just have the UA run in a high quality mode the first time it is painted on, but if the script tries to paint again within a certain amount of time, switch to high speed? Trusting the author to do this right seems like a fantastically bad idea. On Mon, 2 Jun 2008, David Hyatt wrote: On Jun 2, 2008, at 4:34 PM, Vladimir Vukicevic wrote: Yeah, I agree -- I thought that there was some plan somewhere to uplift a bunch of these SVG CSS properties into general usage? I know that Gecko uplifted text-rendering, we should figure out what else makes sense to pull up. (If image-rendering were uplifted, it would apply to canvas, for the scaling/transformation of the canvas element itself as opposed to the canvas rendering content.) Right, that would be my expectation as well (that the CSS property could be applied to canvas to control the quality when rendering the canvas buffer itself). That neatly moves the problem away from the canvas API, and thus it wouldn't be my problem necessarily, but I still don't think it'd be a good idea. :-) On Mon, 2 Jun 2008, Oliver Hunt wrote: That's exactly what i would be afraid of people doing. If I have a fast system why should i have to experience low quality rendering? It should be the job of the platform to determine what level of performance or quality can be achieved on a given device. Typically such a property would be considered a hint, and as such would likely be ignored. If honouring this property was _required_ rather than being a hint you would hit the following problems: * Low power devices would have a significant potential for poor performance if a developer found that their desktop performed well so set the requirement to high quality. * High power devices would be forced to use low quality rendering modes when perfectly capable of providing better quality without significant performance penalty. Neither of these apply if the property were just a hint, but now you have to think about what happens to content that uses this property in 18 months time. You've told the UA to use a low quality rendering when it may no longer be necessary, so now the UA has a choice it either always obeys the property meaning lower quality than is necessary so that new content performs well, or it ignores the property in which case new content performs badly. The correct behaviour would be for the UA to work out itself what it can do, which it needs to be able to do anyway, in order to satisfy the auto option. That line of reasoning seems correct to me. On Mon, 2 Jun 2008, Vladimir Vukicevic wrote: If web apps misuse the property, then bugs should be filed on those apps that incorrectly use the property, and the app developer should fix them. That's naive, I'm afraid. In practice, sites are written and abandoned, and don't get fixed. On Tue, 3 Jun 2008, Robert O'Callahan wrote: These hint properties are opt-in for UAs. If you don't like the idea, just treat all values as auto. There's not much point us adding the feature if multiple UAs aren't going to implement it. Also, if it's a hint, then it's untestable, and we
Re: [whatwg] [WF2] |min| and |max| number of selected |option|s
Christoph Päper wrote: Dear WHAT WG When using input type=checkbox or select multiple one somtimes wants to limit the number of selected check boxes or options. Could you provide some examples of some sites that need to apply such limits, and show how people are currently achieving this? Are there sites that use JavaScript to achieve this now, perhaps by listening for click events on the checkboxes, counting how many are checked and then preventing too many being checked. Or are there sites that count how many are checked onsubmit to ensure there aren't too few or too many? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Proposal: target=_tab
You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] Proposal: target=_tab
As mentioned multiple times, that up to the user agent, or browser if you prefer, to control. Users with browsers with tabbed interface want tabs and that it. Leaving such usability in control of a webpage is bad. All browser that support tabs allow the user to choose if they want the browser to open new windows of just tabs. Na , Kristof Zelechovski [EMAIL PROTECTED] escreveu: You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] Proposal: target=_tab
For the record: I do not advocate the original recommendation; I only hypothesized about what can be achieved with CSS instead. I never recommended actually doing it. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joao Eiras Sent: Wednesday, June 11, 2008 9:16 PM To: Kristof Zelechovski; 'Borek Bernard'; 'Ian Hickson'; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab As mentioned multiple times, that up to the user agent, or browser if you prefer, to control. Users with browsers with tabbed interface want tabs and that it. Leaving such usability in control of a webpage is bad. All browser that support tabs allow the user to choose if they want the browser to open new windows of just tabs. Na , Kristof Zelechovski [EMAIL PROTECTED] escreveu: You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek
Re: [whatwg] [canvas] imageRenderingQuality property
On Wed, Jun 11, 2008 at 10:34 PM, Ian Hickson [EMAIL PROTECTED] wrote: Why not just have the UA run in a high quality mode the first time it is painted on, but if the script tries to paint again within a certain amount of time, switch to high speed? This makes sense. However, there is still a potential use case for speed vs quality hints: when the author wants to treat some content on the page as visually more important than other content. For example, you might have a gallery page with a bunch of unimportant bling around the actual image/canvas you care about. I'm unsure whether that's realistic enough to justify supporting hints. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Some media element details
On Fri, 16 May 2008, Antti Koivisto wrote:
[It would be nice to have a read-only attribute (called playing for
example) that would be true when the element is actively playing.
Knowing if the playback is progressing is necessary for implementing
basic playback UIs with JS. It is clumsy and not very obvious that you
need to do var playing = !video.paused !video.ended
video.readyState = HTMLMediaElement.CAN_PLAY to get this information.]
For example a simple playing state indicator:
function updatePlayState() {
var playIndicator = document.getElementById(playIndicator);
var playing = !video.paused !video.ended video.readyState =
HTMLMediaElement.CAN_PLAY;
playIndicator.className = playing ? playing : stopped;
}
video.addEventListener(play, updatePlayState);
video.addEventListener(pause, updatePlayState);
video.addEventListener(ended, updatePlayState);
video.addEventListener(waiting, updatePlayState);
I don't think I've ever seen a video player that shows this indicator.
Could you show me an example of a video player UI that does this?
Knowing whether media is playing or not is needed for other common UI elements
too, for example to activate/deactivate time display timer,
I don't think the visibility of the time display timer in a typical video
UI is actually directly correlated to the playback state. Again, could you
show an example of this?
to do play/pause button etc.
The state of a play/pause button is definitely not correlated to the
playback state. It's correlated to the paused boolean.
A direct way to get this information (along with an associated event)
would be good for API usability I think:
function updatePlayState() {
var playIndicator = document.getElementById(playIndicator);
playIndicator.className = video.activelyPlaying ? playing :
stopped;
}
video.addEventListener(playstatechanged, updatePlayState);
Of course it is sort of syntactical sugar...
It's syntactical sugar for something which, in practice, I don't think
anyone would actually use.
If you know of any examples of video players that actually would (if
reimplemented in HTML) make use of this, though, that would be a different
matter.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some media element details
On Fri, 16 May 2008, James Justin Harrell wrote: The current HTMLMediaElement interface is inconsistent and is designed in such a way that making changes to it will be extremely difficult. The network state is given by the networkState attribute, and is one of: EMPTY, LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED The ready state is given by the readyState attribute, and is one of: DATA_UNAVAILABLE, CAN_SHOW_CURRENT_FRAME, CAN_PLAY, CAN_PLAY_THROUGH Although adding states for either of these would not be fun, it could be done. But the playback state is different. The consistent and upgradeable design would be to have a playbackState attribute that is one of: PAUSED, PLAYING But because there are currently only two states, we instead have a single boolean attribute. Boolean attributes are great when you're sure there will always be only two states, but they're terrible if there's a chance you'll want to add additional states. It isn't difficult to imagine all kinds of additional playback states. For example, what if there was great demand for forward-seeking and backward-seeking states? (e.g. the states that are usually associated with those and buttons) How could those states be added? This is already supported, and is independent of the pause state. (You could easily imagine a UI where you could pause while fast-forwarding.) The media error state is also inconsistent, and this time for no apparent reason, although it would at least be easy to update. A more consistent design would be to have an errorState attribute that is one of: NO_ERROR, ABORTED, NETWORK_ERROR, DECODING_ERROR We want to be able to include much more information, hence the use of an object for now. And why are the error state names prefixed with MEDIA_ERR when the names for the other states are not prefixed? e.g. LOADING instead of MEDIA_NET_LOADING. The other state constants are prefixed (LOAD and CAN_ respectively) except for the zero state (which doesn't have a constant at all for errors). On Fri, 16 May 2008, Maciej Stachowiak wrote: But because there are currently only two states, we instead have a single boolean attribute. Boolean attributes are great when you're sure there will always be only two states, but they're terrible if there's a chance you'll want to add additional states. I'm not sure adding states is all that safe. Any code that does a switch on the state would now fall through to an untested code path. Indeed, we're unlikely to ever add states, we're more likely to add orthogonal attributes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some media element details
On Fri, 23 May 2008, Bonner, Matt (IPG) wrote: Knowing if the playback is progressing is necessary for implementing basic playback UIs with JS. It is clumsy and not very obvious that you need to do var playing = !video.paused !video.ended video.readyState = HTMLMediaElement.CAN_PLAY to get this information. What's the use case? Wouldn't you want something like that to know, for example, whether to display a play or a pause button? We have that -- the paused attribute. When it's true, show play, and when it's paused, show false. You don't want to show play when the reason you aren't playing is that you're buffered or seeking for instance. The client is trying to play. It can't. Well I said for example, so let's pick another example. Wouldn't you need the state described to figure out whether enabling the pause/fast-forward/rewind buttons makes sense? Why would you disable the pause button when playing? Or when seeking? The pause button's disable state, as far as I can tell, need only be related to whether there is any media at all and whether the media playback is paused, not whether it is actively playing. Similarly for fast-forward. You can fast-forward from the paused state and from the playing state. It doesn't matter whether the media is actually playing or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] ***DHSPAM*** re-thinking cue ranges
On Thu, 22 May 2008, Dave Singer wrote: WARNING: this email is sent to both the WhatWG and W3C Public HTML list, as it is a proposal. Please be careful about where you reply/follow-up to. The editors may have a preference (and if they do, I hope they express it). My preference is to one list, either is fine. I've only cc'ed whatwg on this one, chosen merely because that's where most of the video discussion has been recently. In the current HTML5 draft cue ranges are available using a DOM API. This way of doing ranges is less than ideal. First of all, it is hard to use. The ranges must be added by script, can't be supplied with the media, and the callbacks are awkward to handle. The only way to identify the range a received callback applies to is by creating not one but two separate functions for each range: one for enter, one for exit. While creating functions on-demand is easy in JavaScript it does fall under advanced techniques that most authors will be unfamiliar with. One of the features proposed for the next version of the video API is chapter markers and other embedded timed metadata, with corresponding callbacks for authors to hook into. Would that resolve the problem you mention? This kind of feature is also not available in all languages that might provide access to the DOM API. JavaScript is really the only concern from HTML5's point of view; if other languages become relevant, they should get specially-crafted APIs for them when it comes to this kind of issue. Secondly this mechanism is not very powerful. You can't do anything else with the ranges besides receiving callbacks and removing them. You can't modify them. They are not visible to scripts or CSS. You can't link to them. You can't link out from them. I'm not sure what it would really mean to link to or from a range, unless you turned the entire video into a link, in which case you can just wrap the video in an a href= element for the duration of the range, using script. Thirdly, a script is somewhat strange place to define the ranges. A set of ranges usually relates closely to some particular piece of media content. The same set of ranges rarely makes much sense in the context of some other content. It seems that ranges should be defined or supplied along with the media content. For in-band data, callbacks for chapter markers as mentioned earlier seem like the best solution. For out-of-band data, if the ranges are just intended to trigger script, I don't think we gain much from providing a way to mark up ranges semi- declaratively as opposed to just having HTML-based media players define their own range markup and have them implement it using this API. It wouldn't be especially hard. Fourth, this kind of callback API is pretty strange creature in the HTML specification. The only other callback APIs are things like setTimeout() and the new SQL API which don't have associated elements. Events are the callback mechanism for everything else. Events use callbacks themselves, so it's not that unusual. I don't really think events would be a good interface for this. Consistency is good, but if one can come up with a better API, it's better to use that than just be consistent for the sake of it. In SMIL the equivalent concept is the area element which is used like this: video src=http://www.example.org/CoolStuff; area id=area1 begin=0s end=5s/ area id=area2 begin=5s end=10s/ /video This kind of approach has several advantages. * Ranges are defined as part of the document, in the context of a particular media stream. I'm not sure why that is an advantage in the context of HTML. * This uses events, a more flexible and more appropriate callback mechanism. I don't really see why the flexibility of events is useful here, and I don't see why it's more appropriate. * The callbacks have a JavaScript object associated with them, namely a DOM element, which carries information about the range. That's useful, yes. Should we include some data with the callback? We could include the class name, the start time, and the end time. Having said that, it's easy to use currying here to hook callbacks that know what they're expecting. We would like to suggest a timerange element that can be used as a child of the video and audio elements. It's not clear to me that this is solving any problems worth solving. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
