Re: [whatwg] instantiating display:none plugins
On Tue, 01 Nov 2011 19:36:44 -0400, Robert O'Callahan rob...@ocallahan.org wrote: http://www.whatwg.org/specs/web-apps/current-work/#the-object-element The above algorithm is independent of CSS properties (including 'display', 'overflow', and 'visibility'). For example, it runs even if the element is hidden with a 'display:none' CSS style, and does not run again if the element's visibility changes. Unfortunately this breaks real-world usage. The example we ran into is documented here: https://bugzilla.mozilla.org/show_bug.cgi?id=697651 In this case, the site has a display:none autoplay Youtube Flash video that's not supposed to play. I did some experiments on browser behavior, documented here: https://bugzilla.mozilla.org/show_bug.cgi?id=697651#c19 There are some variations but no browser instantiates a plugin that's always display:none. I recommend that the spec be changed so that the steps to (re)determine what the object element represents avoid instantiating plugins that are display:none (or have a display:none ancestor). Dynamic changes to the display state should queue a task that checks whether the display state of the element has changed since the last time the steps to (re)determine what the object element represents ran; if it has, it should rerun those steps. As far as I know, there is no need to consider any visibility state other than display:none. These threads (at least) have the discussion on object and the css display property: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/thread.html#22563 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-October/thread.html#23641 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-November/024010.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24434 Boris mention that it was considered a bug by Mozilla that object is affected by the display property (including display: none). Hixie agreed and said that the author is expected to use JS and not create and append the object until it's expected to be instantiated. I agreed with that, but also suggested a load-on-demand attribute for object for authors that want to create the object with parsed markup and just defer instantiation where just removing the attribute with JS would cause it to instantiate. That wasn't received well though. Also, the display property never really affected object in Opera except for display: none. But, that's was changed in Opera for images ( img and object I think and maybe everything) I think. Opera users are pissed by the change though because users used display: none for ad-blocking (including blocking the resource fetching) and Opera didn't provide an alternative when making the change. See http://my.opera.com/community/forums/topic.dml?id=1112972 and http://my.opera.com/community/forums/topic.dml?id=972092. But, that's not web-compat-related and not necessarily about plug-ins, but the users in those threads want the old display: none behavior back. I still think display: none shouldn't affect object instantiation and if there needs to be a solution, it should be an attribute and we should evangelize and get any problem sites fixed (by using the attribute for example). -- Michael
Re: [whatwg] instantiating display:none plugins
On 11/2/11 11:40 AM, Michael A. Puls II wrote: Boris mention that it was considered a bug by Mozilla that object is affected by the display property (including display: none). The bug in Mozilla was pretty broad: any changes to the CSS box structure affected the plug-in. That's the bug we have a fix for and are testing now. The initial fix made display:none not affect the plug-in; Robert is reporting that this was found to not be web-compatible. Hixie agreed and said that the author is expected to use JS and not create and append the object until it's expected to be instantiated. That's nice, but that expectation is broken since no commonly used browser requires authors to do that... so they don't. Also, the display property never really affected object in Opera except for display: none. Yes; this thread is about display:none and nothing else. I still think display: none shouldn't affect object instantiation and if there needs to be a solution, it should be an attribute and we should evangelize and get any problem sites fixed I'm not sure you understand. The patch to make display:none is not even checked into the main Mozilla source tree. The only people who have been running with that patch are those who manually applied it to a local source tree and then compiled. That's about 3 people or so. They've been running with this patch for a few weeks. As of a week ago, at least one site was identified that has issues as a result. So after a week or two of use by 3 people we already have one site the change is not compatible with. Statistically speaking, the chance that the number of such sites is small is very low. Just for scale, it usually it takes testing over months by millions of users to discover that something is not compatible enough with existing content. So I suspect that the evangelism effort here would be rather like carrying water in a sieve. Add to this the fact that currently all browsers agree with each other and disagree with the spec, and that implementing the behavior browsers agree on would keep the site working, and changing the spec to match reality seems like the sanest approach. -Boris
Re: [whatwg] Proposal: Remove canplaythrough event from audio/video tag
Hi Jer! Your email made me realize that instead of proposing the event's removal, what I really should have said was, I am confused about this event. Can someone help me understand what I am missing? Whoops. I retract my proposal; it was extreme because it was largely based on ignorance, it seems. Sorry about that! A few comments inline... The purpose of the canplaythrough event (and of the HAVE_ENOUGH_DATA ready state) are to signal to the page author that playback is likely to keep up without stalling. This seems to me to have a fairly obvious benefits. Here's a hypothetical scenario: Assume a 100% accurate implementation of canplaythrough (in that the UA can predict with 100% accuracy at what time in the future will the final byte of media data will be downloaded.) Assume magic or time travel if necessary. In this scenario, a media element with with a canplaythrough listener will always begin playing at the earliest possible time and will never stall during normal playback. This is a clear benefit. Yeah, and as Eric Carlson pointed out to me offline, this is very useful for scripting autoplay. Makes sense. The question I keep running into is *how inaccurate can the browser be until the event is no longer useful?* This seems to be a Quality of Service issue. Different UAs will have different implementations of canplaythough at varying degrees of accuracy. Some UAs will favor a lower possibility of stalling over an earlier start time. Others may cut closer to the margin-of-error and favor earlier start times. This was something I was more concerned about when I was aiming to calculate a precise download speed instead of thinking in terms of having buffered enough to for smooth playback. (See comments below.) I think this is a very bad example for your case. If the browser has decided to postpone further downloading once it has reached a comfortable buffer, shouldn't it have already fired a canplaythrough event and set its readyState to HAVE_ENOUGH_DATA? Isn't that the very definition of reaching a comfortable buffer? Ah -- actually, this made me realize that I was misinterpreting the spec a bit! I wasn't thinking about canplaythrough as something that could be a reflection of buffer state, but instead was focused on making it reflection of purely download speed (when buffering, of course, is an indirect indication of download speed). This makes sense! Thanks for pointing it out. Again, this is a clear example of a situation where the browser could easily and safely emit a canplaythrough event. Sure, this makes more sense now. The spec makes it clear that HAVE_ENOUGH_DATA is an estimate. And this situation makes a more compelling argument to /add/ a 'cannolongerplaythrough' event for use when the UA detects a suddenly bandwidth-limited connection. For example, with such an event, a page author may decide to switch to a lower-bitrate version of the media file. Yes, I agree that the spec makes it clear that HAVE_ENOUGH_DATA is an estimate. Still, somehow, until your email, I was hung up on the idea of calculating an accurate download rate... I guess it's because under the description of HAVE_ENOUGH_DATA, the spec says, the user agent estimates that data is being *fetched at a rate* where... [blah blah blah]. I'm trying to think if I would prefer some other wording, but it seems clear in retrospect. :) I also didn't realize the video ready state is expected to be moving between HAVE_CURRENT_DATA, HAVE_FUTURE_DATA, and HAVE_ENOUGH_DATA in response to the changing network condition and also possibly as the browser's adapts its estimation techniques. Again, I'm not sure if/how I would propose rewording the spec. A cannolongerplaythrough event (or similar) seems like something that would be useful, but I should probably think about this more. No, a page author cannot. For example: if progress events stall, a page author cannot tell that the UA has decided to postpone loading after reaching a comfortable buffer. The point of the event and the readyState is that the UA has knowledge of media loading and decoding that the page author does not. The UA is simply in a much better position to estimate whether a media can play though than is the page author. Sounds fair. The motivation and implementation for the event are much clearer now. I will come back with more questions as I approach them, with maybe a less scary subject-line! :) I will finish up my CL for this event now! Thanks again for the clarification! Victoria
[whatwg] MediaController feedback
Hi, I'm currently working on implementing MediaController in WebKit https://bugs.webkit.org/show_bug.cgi?id=71341, and have a couple pieces of feedback from an implementor's POV: * MediaController Playback State and Ready State The spec defines both a most recently reported readiness state[1] and a most recently reported playback state[2] which, when changed, trigger a variety of event. Because these previous values of these states must be compared each time they are recomputed[3], we must store these values in our MediaController implementation, which is no huge burdon. However, when I was writing testcases for my implementation, I noticed that there was no way to query the current value of either the playback state or the ready state, as neither was present in the IDL for MediaController. This makes writing test cases much more difficult, as they now much rely on waiting for edge-triggered events. In addition, there is a use case for having playbackState and readyState in the MediaController IDL. When adding a MediaController to an HTMLMediaElement, the spec does not require the media controller to report the controller state. (It does require that the MediaController bring the media element up to speed with the new controller.) In this case, the media controller should also be requried to report the controller state, as adding a blocking media element to a controller should probably cause the playbackState to revert to WAITING. But if the current playbackState is already WAITING, no waiting event will be emitted, and the client waiting on such an event will wait forever. So I would like to propose two changes to the spec: + MediaController should expose the following attributes in IDL: readonly attribute unsigned short readyState; readonly attribute unsigned short playbackState; Exposing these attributes would have approximately zero implementation cost (at least in my implementation) as these values are stored and easily queryable anyway. + Modify the media.controller()[4] section to require that the setting the controller report the controller state. * MediaController.play() The MediaController play() function does not actually cause its slaved media elements to play. If all the slaved media elements are paused, the MediaController is a blocked media controller, and none will play until at least one element has play() called on it directly. And even in that case, only the playing elements will begin playing. In addition, the user interface section of the spec says the following: When a media element has a current media controller, and all the slaved media elements of that MediaController are paused, the user agent should unpause all the slaved media elements when the user invokes a user agent interface control for beginning playback. So now, an individual media control must be able to access all other HTMLMediaElements associated with a given MediaController, because there is no facility in MediaController to actually unpause all the slaved media elements. In a previous paragraph in that same section: When a media element has a current media controller, the user agent's user interface for pausing and unpausing playback, for seeking, for changing the rate of playback, for fast-forwarding or rewinding, and for muting or changing the volume of audio of the entire group must be implemented in terms of the MediaController API exposed on that current media controller. Except, in the case of unpausing, this extra requirement of unpausing the slaved media elements is somewhat in conflict with this paragraph. I would like to propose three changes to the spec: + Modify the section bring the media element up to speed with the new controller[5] to require that a media element added to a playing media controller must begin playing, and one added to a paused media controller must pause. + Modiy the section controller . play()[6] to require that the user agent unpause all the slaved media elements. + Modify the section controller . pause()[7] to require that the user egent pause all the slaved media elements. + Remove the section from user interface[8] which requires the user agent unpause all the slaved media elements, quoted above. Thanks, -Jer [1] http://www.w3.org/TR/html5/video.html#most-recently-reported-playback-state [2] http://www.w3.org/TR/html5/video.html#most-recently-reported-playback-state [3] http://www.w3.org/TR/html5/video.html#report-the-controller-state [4] http://www.w3.org/TR/html5/video.html#dom-media-controller [5] http://www.w3.org/TR/html5/video.html#bring-the-media-element-up-to-speed-with-its-new-media-controller [6] http://www.w3.org/TR/html5/video.html#dom-mediacontroller-play [7] http://www.w3.org/TR/html5/video.html#dom-mediacontroller-pause [8] http://www.w3.org/TR/html5/video.html#user-interface
Re: [whatwg] MediaController feedback
Hi Jer, Feedback just on one component of your request: readyState. The suggestion of introducing a readyState IDL attribute on the MediaController was rejected previously: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12547 . You might want to reopen that bug and reply to the rejection reason there. Cheers, Silvia. On Thu, Nov 3, 2011 at 8:50 AM, Jer Noble jer.no...@apple.com wrote: Hi, I'm currently working on implementing MediaController in WebKit https://bugs.webkit.org/show_bug.cgi?id=71341, and have a couple pieces of feedback from an implementor's POV: * MediaController Playback State and Ready State The spec defines both a most recently reported readiness state[1] and a most recently reported playback state[2] which, when changed, trigger a variety of event. Because these previous values of these states must be compared each time they are recomputed[3], we must store these values in our MediaController implementation, which is no huge burdon. However, when I was writing testcases for my implementation, I noticed that there was no way to query the current value of either the playback state or the ready state, as neither was present in the IDL for MediaController. This makes writing test cases much more difficult, as they now much rely on waiting for edge-triggered events. In addition, there is a use case for having playbackState and readyState in the MediaController IDL. When adding a MediaController to an HTMLMediaElement, the spec does not require the media controller to report the controller state. (It does require that the MediaController bring the media element up to speed with the new controller.) In this case, the media controller should also be requried to report the controller state, as adding a blocking media element to a controller should probably cause the playbackState to revert to WAITING. But if the current playbackState is already WAITING, no waiting event will be emitted, and the client waiting on such an event will wait forever. So I would like to propose two changes to the spec: + MediaController should expose the following attributes in IDL: readonly attribute unsigned short readyState; readonly attribute unsigned short playbackState; Exposing these attributes would have approximately zero implementation cost (at least in my implementation) as these values are stored and easily queryable anyway. + Modify the media.controller()[4] section to require that the setting the controller report the controller state. * MediaController.play() The MediaController play() function does not actually cause its slaved media elements to play. If all the slaved media elements are paused, the MediaController is a blocked media controller, and none will play until at least one element has play() called on it directly. And even in that case, only the playing elements will begin playing. In addition, the user interface section of the spec says the following: When a media element has a current media controller, and all the slaved media elements of that MediaController are paused, the user agent should unpause all the slaved media elements when the user invokes a user agent interface control for beginning playback. So now, an individual media control must be able to access all other HTMLMediaElements associated with a given MediaController, because there is no facility in MediaController to actually unpause all the slaved media elements. In a previous paragraph in that same section: When a media element has a current media controller, the user agent's user interface for pausing and unpausing playback, for seeking, for changing the rate of playback, for fast-forwarding or rewinding, and for muting or changing the volume of audio of the entire group must be implemented in terms of the MediaController API exposed on that current media controller. Except, in the case of unpausing, this extra requirement of unpausing the slaved media elements is somewhat in conflict with this paragraph. I would like to propose three changes to the spec: + Modify the section bring the media element up to speed with the new controller[5] to require that a media element added to a playing media controller must begin playing, and one added to a paused media controller must pause. + Modiy the section controller . play()[6] to require that the user agent unpause all the slaved media elements. + Modify the section controller . pause()[7] to require that the user egent pause all the slaved media elements. + Remove the section from user interface[8] which requires the user agent unpause all the slaved media elements, quoted above. Thanks, -Jer [1] http://www.w3.org/TR/html5/video.html#most-recently-reported-playback-state [2] http://www.w3.org/TR/html5/video.html#most-recently-reported-playback-state [3] http://www.w3.org/TR/html5/video.html#report-the-controller-state [4]
[whatwg] document.write(\r): the spec doesn't say how to handle it.
The spec for document.write() http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-write says: ... have the tokenizer process the characters that were inserted, one at a time, processing resulting tokens as they are emitted, and stopping when the tokenizer reaches the insertion point... But what happens if the last character written by document.write() is a carriage return? The HTML parsing spec says that CR followed by LF is ignored but CR followed by anything else is converted to LF. So if the last character is CR, then the tokenizer can't process all characters up to the insertion point because it needs to lookahead at the next character, right? Firefox, Chrome and Safari all seem to do the right thing: wait for the next character before tokenizing the CR. And I think this means that the description of document.write needs to be changed. (Opera, on the other hand, just gets this wrong and emits a CR character). Similarly, what should the tokenizer do if the document.write emits half of a UTF-16 surrogate pair as the last character? David
Re: [whatwg] instantiating display:none plugins
On Wed, 02 Nov 2011 13:04:54 -0400, Boris Zbarsky bzbar...@mit.edu wrote: On 11/2/11 11:40 AM, Michael A. Puls II wrote: Boris mention that it was considered a bug by Mozilla that object is affected by the display property (including display: none). The bug in Mozilla was pretty broad: any changes to the CSS box structure affected the plug-in. That's the bug we have a fix for and are testing now. The initial fix made display:none not affect the plug-in; Robert is reporting that this was found to not be web-compatible. Understood. Hixie agreed and said that the author is expected to use JS and not create and append the object until it's expected to be instantiated. That's nice, but that expectation is broken since no commonly used browser requires authors to do that... so they don't. Understood. I thought they were all planning on doing it though and just haven't gotten to that part of HTML5 yet. Also, the display property never really affected object in Opera except for display: none. Yes; this thread is about display:none and nothing else. Understood. I still think display: none shouldn't affect object instantiation and if there needs to be a solution, it should be an attribute and we should evangelize and get any problem sites fixed I'm not sure you understand. The patch to make display:none is not even checked into the main Mozilla source tree. The only people who have been running with that patch are those who manually applied it to a local source tree and then compiled. That's about 3 people or so. They've been running with this patch for a few weeks. As of a week ago, at least one site was identified that has issues as a result. So after a week or two of use by 3 people we already have one site the change is not compatible with. Statistically speaking, the chance that the number of such sites is small is very low. Just for scale, it usually it takes testing over months by millions of users to discover that something is not compatible enough with existing content. So I suspect that the evangelism effort here would be rather like carrying water in a sieve. Add to this the fact that currently all browsers agree with each other and disagree with the spec, and that implementing the behavior browsers agree on would keep the site working, and changing the spec to match reality seems like the sanest approach. Understood. What I got from those threads at the time though was that we were saying to hell with the display: none behavior that's in current browsers (especially since I think there were use-cases for hiding an active plug-in with display: none (instead of visibility: hidden and absolute positioning etc.) while not having the plug-in instance get destroyed). If we want to keep the display: none behavior that's in current browsers, I'm not going to object. Just saying that it'd be nice (better/make more sense) if the use-case for display: none (deferring instantiation till it's shown) was handled by an attribute (instead of css) where removing the attribute made it come alive. That should be compatible with older browsers for sites already using display: none for deferring instantiation and would just be a minor change to the site. But, I realize that any change at all might not be welcome. -- Michael
Re: [whatwg] instantiating display:none plugins
On 11/2/11 11:52 PM, Michael A. Puls II wrote: If we want to keep the display: none behavior that's in current browsers, I'm not going to object. Just saying that it'd be nice (better/make more sense) if the use-case for display: none (deferring instantiation till it's shown) was handled by an attribute (instead of css) where removing the attribute made it come alive. That should be compatible with older browsers for sites already using display: none for deferring instantiation I think having an explicit instantiation trigger that works even if display:none would be a reasonable thing to do. -Boris
[whatwg] Proposal: Add CanvasRenderingContext2D.setDash()/.getDash()/.dashOffset for dashed stroking
Most 2d graphics libraries support stroking paths with a dash pattern of
on/off strokes. Canvas should have it for completeness. Because SVG already
offers a facility for dashed stroking, adding it to canvas is not expected to
be a big burden on implementors who have also implemented SVG. It's quite
nontrivial for authors to implement this functionality on top of canvas, and
those implementations are not likely to be performant.
The concrete proposal is
interface CanvasRenderingContext2D {
//...
void setDash(sequenceNumber); // array of on/off dash lengths
sequenceNumber getDash(); // return the current dash array, freshly
allocated
attribute Number dashOffset; // default 0; offset within dash pattern
to begin stroking
//...
};
setDash() sets the dash array, getDash() gets the current dash array. The
interpretation of the dash array is the analogue of the SVG stroke-dasharray
property[1]: the array specifies a sequence of alternating dashes and gaps.
The numbers are distances in the canvas userspace at the time of stroking. The
|dashOffset| specifies an offset into the dash pattern at which stroking should
begin, and has the same unit as the elements of |dash|. It's the analogue of
the SVG stroke-dashoffset property. The precise semantics of stroking a
dashed path are defined to be the same as in SVG. The dash array and offset
are saved and restored along with other canvas rendering state.
Note: a similar spec has been implemented in Gecko as
|mozDash/mozDashOffset|[2], however with mozDash as a sequence attribute, which
Cameron McCormack pointed out is forbidden by WebIDL[3]. In the API above,
the attribute is converted into explicit setDash()/getDash() methods. Mozilla
will update Gecko's implementation once the proposal here stabilizes.
Cheers,
Chris
[1] http://www.w3.org/TR/SVG11/painting.html#StrokeProperties
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=662038
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=683051
