Re: [whatwg] api for fullscreen()
On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell lam...@continuation.orgwrote: I'm a bit concerned about when the fullscreen events and styles apply, though. If the page can tell whether or not the user has actually allowed it to enter fullscreen mode, it can refuse to display content until the user gives it permission to enter fullscreen mode. Or even if it's not refusing to display content, it may simply not scale the content up to the full window if the user neglects to give permission for full screen. We could simply modify the proposal to apply the fullscreen pseudoclass (but not fullscreen the window) if permission is denied. However, in general I don't think we can prevent Web content from detecting that it is not fullscreen. For example it could check whether the window size is one of a set of common screen sizes. 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] Notification API
On Thu, Feb 4, 2010 at 6:17 AM, John Gregg john...@google.com wrote: The Webapps WG is working on a spec for a Web Notification API. You can see the current draft at http://dev.w3.org/2006/webapi/WebNotifications/publish/, and I would suggest sending comments to the public-webapps mailing list. That spec attempts to address the icon+title+text use case, and allows a user agent to use a third party presentation system as long as that system can notify of notifications being acknowledged, but also allows HTML as an option if the device supports it. I disagree with the claim that HTML notifications are overkill as long as they can be done securely, it opens up a lot of benefit to have dynamic interactive notifications. Even for the simple case of Calendar reminders which might have multiple forms of acknowledgement: snooze for N minutes (a select would be nice), or dismiss. If the underlying platform notification system (e.g. Growl or libnotification) doesn't support that functionality, how should the UA behave? I suppose the UA could distinguish between notifications that can be supported by the platform and those that can't, and use the platform notification system when possible, otherwise fall back to its own notifications, but that could be a jarring user experience. 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] Notification API
On Thu, Feb 4, 2010 at 11:34 AM, Drew Wilson atwil...@google.com wrote: 2) Allow more full-featured HTML notifications on the overwhelming majority of platforms that support them. Given that Mac and Linux don't support HTML notifications, what platforms are those? 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] Canvas size and double buffering.
On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell lam...@continuation.orgwrote: I think the most reasonable approach would be to say that the getBoundingClientRect().width or height is rounded to the nearest pixel. Boxes are displayed rounded to the nearest pixel, with no fractional pixels being drawn, right? No. Why would they report a width or height that is different than how they are displayed? All browsers that I've tested (the ones listed above, so not IE) report integral values for getBoundingClientRect().width and height (or for left and right in the case of Opera, which doesn't support width and height). Firefox often returns non-integral values for getBoundingClientRect().width or height. 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] Canvas size and double buffering.
On Thu, Feb 4, 2010 at 1:00 PM, Tim Hutt tdh...@gmail.com wrote: http://concentriclivers.com/canvas.html (the source is nicely formatted and very short) canvas.style.width = ww; canvas.style.height = hh; Perhaps you meant ww + px and hh + px? 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] Canvas size and double buffering.
In general, keeping the canvas buffer size matching its rendered size so that no resampling occurs requires clearing and repainting the canvas during browser zoom changes as well as layout changes (and possibly during other changes such as changes to the transforms of ancestors). It also requires more than just getBoundingClientRect(). Authors can't do this without some new feature(s). Perhaps something like an attribute autoresize which automatically sets the buffer size, clears the canvas and fires a redraw event at the canvas element whenever the ideal canvas buffer size changes? Sounds like a v2 feature to me though. In the meantime, use SVG if you can. 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] Canvas size and double buffering.
On Fri, Feb 5, 2010 at 3:25 AM, Brian Campbell lam...@continuation.orgwrote: On Feb 4, 2010, at 1:55 AM, Robert O'Callahan wrote: On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell lam...@continuation.org wrote: I think the most reasonable approach would be to say that the getBoundingClientRect().width or height is rounded to the nearest pixel. Boxes are displayed rounded to the nearest pixel, with no fractional pixels being drawn, right? No. In what cases are fractional pixels drawn? I see fractional widths being returned here, but it seems to be drawing rounded to the nearest pixel: http://ephemera.continuation.org/percentage-width.html Box edges are (usually) snapped to the nearest *device pixel* boundary. That is not the same as rounding the CSS pixel width or height to the nearest integer. 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] video feedback
On Thu, Feb 11, 2010 at 8:19 AM, Brian Campbell lam...@continuation.orgwrote: But no, this isn't something I would consider to be production quality. But perhaps if the WebGL typed arrays catch on, and start being used in more places, you might be able to start doing this with reasonable performance. With WebGL you could do the chroma-key processing on the GPU, and performance should be excellent. In fact you could probably prototype this today in Firefox. 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] Adding FormData support to form
On Fri, Feb 19, 2010 at 1:52 PM, Ian Hickson i...@hixie.ch wrote: toDataURL() was named that way for consistency with toString(), which seems a closer analogue here than getElementById() and friends. bikeshed But you're not really converting the form element into something equivalent, are you? That's what to methods usually imply, IMHO. Maybe it should be createFormData or extractFormData? /bikeshed 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] [html5] Attaching option elements to select elements in different documents
Apart from compatibility issues, there's also the fact that requiring explicit adopt/import is a pointless burden on authors. 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] Fullscreen for HTML5 Video element
On Wed, Mar 10, 2010 at 3:59 PM, Michael Dale d...@ucsc.edu wrote: I was part of the initial thread that was left unresolved. I would just re-iterate that its important the fullscreen system does not deprive the web designer of flexibility to do DOM overlays / layouts. You mean the thread api for fullscreen()? Actually I thought that thread ended with reasonably strong consensus on what the API should be. 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] Introduction of media accessibility features
On Tue, Apr 13, 2010 at 7:28 PM, Jonas Sicking jo...@sicking.cc wrote: Will implementations want to do the rendering of the subtitles off the main thread? I believe many browsers are, or are planning to, render the actual video graphics using a separate thread. If that is correct, do we want to support rendering of the subtitles on a separate thread too? No. Or is it enough to do the rendering on the main thread, but composit using a separate thread? It is. 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] Introduction of media accessibility features
On Mon, Apr 12, 2010 at 12:47 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Understood. But what is actually the cost of implementing all of TTML? The features in TTML all map onto existing Web technology, so all it takes is a bit more parsing code over time. When implementing one complex spec (TTML + XSL-FO) in terms of another complex spec (HTML + CSS), you have to be very very lucky to find that all the features map perfectly, even if the specs were designed to work together that way, which in this case they are not. Even if you're lucky today, evolution of the specs could easily accidentally break things. We could make that problem go away by normatively defining something that looks like TTML in terms of a translation to HTML + CSS. It wouldn't really be TTML though, and where's the added value for authors? I understand the deep political problems here, but I think it's most logical for styled content for the Web to use (possibly a subset of) HTML and CSS. Server-side tools to translate between TTML and HTML+CSS would be one way to address the desire to interoperate with TTML. 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]
[whatwg] Should scripts and plugins in contenteditable content be enabled or disabled?
See https://bugzilla.mozilla.org/show_bug.cgi?id=519928 Suppose we have a script element inside a contenteditable parent. Should the script run? What about on* attribute event handlers, should they fire in response to events? What about object plugins inside a contenteditable parent, should they be instantiated? In Webkit, scripts, event handlers and plugins run normally. IE disables them. Gecko disables them when designmode is used but enables them for contenteditable. In https://bugzilla.mozilla.org/show_bug.cgi?id=519928#c46a CKEditor developer argues forcefully that we should disable them. If we do choose to disable them, exactly how this should be specced is not completely clear to me. There is a side issue of how editable iframes should be treated. Presumably we should load the subdocument, but if we disabled scripts for editable content, should we allow scripts to run inside the iframe document? Probably yes to allow framebusting to run. Perhaps we should prevent user events from being delivered to the iframe document though? 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] Dealing with Stereoscopic displays
I think it's interesting to think about what browsers could do with stereo output. We already have three features that could produce useful stereo output today: 1) WebGL 2) CSS 3D Transforms 3) video (assuming there was some kind of 3D video format defined elsewhere) What are the use cases for stereo output? Would those features be sufficient? 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] Dealing with Stereoscopic displays
On Tue, Apr 27, 2010 at 8:38 PM, Eoin Kilfeather ekilfeat...@dmc.dit.iewrote: * A user visits the National Museum site and wants to see a time-machine view of objects in the collection with a sense of 3D depth based on their age I think this is the closest you get to an actual use-case :-). The rest is mixed up with information about possible solutions. Also, it's highly unlikely the a user will visit your site with a fully formed desire to view objects in a collection with a sense of 3D depth based on their age :-). But let's say the authors of that site want to visualize objects in the collection with different objects at different depths. It seems to me either WebGL or CSS 3D transforms --- or a mixture --- could be used for this, maybe with some extra information provided to identity the camera positions for rendering the stereo views. Actually, I probably shouldn't be involved in this discussion since I'm monocular :-). 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] Dealing with Stereoscopic displays
On Wed, Apr 28, 2010 at 8:09 PM, Eoin Kilfeather ekilfeat...@dmc.dit.iewrote: If we take the case of the Blu-Ray 3D specification it is neutral about how the hardware is implemented, but the hardware is expected to respect the flags indicating whether a frame is for the left or right virtual display. In order to work with HTML the UA has to have some awareness of the hardware and way of signalling with view is for which virtual display. Sure, but this seems like a UA-specific issue that the Web author should not need to worry about. UAs already coordinate with the underlying software and hardware platform to render Web content. 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] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Tue, May 18, 2010 at 8:23 PM, Odin Omdal Hørthe odin.om...@gmail.comwrote: Justin Dolske's idea looks rather nice: This seems like a somewhat unfortunate thing for the spec, I bet everyone's going to get it wrong because it won't be common. :( I can't help but wonder if it would be better to have a startTimeOffset property, so that .currentTime et al are all still have a timeline starting from 0, and if you want the real time you'd use .currentTime + .startTimeOffset. I'd also suspect we'll want the default video controls to normalize everything to 0 (.currentTime - .startTime), since it would be really confusing otherwise. That's exactly what I've advocated before. I lost the argument, but I forget why, probably because I didn't understand the reasons. 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] Should scripts and plugins in contenteditable content be enabled or disabled?
On Wed, May 19, 2010 at 5:35 AM, Ojan Vafai o...@chromium.org wrote: The webkit behavior of allowing all scripts makes the most sense to me. It should be possible to disable scripts, but that capability shouldn't be tied to editability. The clean solution for the CKEditor developer is to use a sandboxed iframe. I don't see a security benefit for disabling script as you'd have all the same issues with loading any user-content in a non-editable area. The only catch is that you *do* need to disable script from pasted and drag-dropped content (see http://trac.webkit.org/changeset/53442). Basically, any site serving user-content will already need to mitigate XSS some other way, so disabling script in editable areas is not necessary, but paste/drag-drop can't reasonably rely on server-side solutions, so must be done by the UA. Putting my developer hat on, trying to make Google Gadgets work in Google's rich text editor inside Firefox designMode was awful due to https://bugzilla.mozilla.org/show_bug.cgi?id=519928. A large percentage of Google Gadgets load as iframes and require javascript onload. We had to play tricks with turning off designMode, appending the iframe and turning designMode back on. It was an awful solution that never worked very well. That makes sense to me. I'll see what the other editor developers think. 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] Should scripts and plugins in contenteditable content be enabled or disabled?
On Wed, May 19, 2010 at 5:35 AM, Ojan Vafai o...@chromium.org wrote: The webkit behavior of allowing all scripts makes the most sense to me. It should be possible to disable scripts, but that capability shouldn't be tied to editability. The clean solution for the CKEditor developer is to use a sandboxed iframe. Discussion led to the point that there's a fundamental conflict between sandboxed iframes and JS-based framebusting techniques. The point of https://bugzilla.mozilla.org/show_bug.cgi?id=519928 is that Web sites using JS-based techniques to prevent clickjacking can be thwarted if the containing page has a way to disable JS in the child document. Currently 'designmode' is usable that way in Gecko, but 'sandbox' would work even better. Maybe sites should all move to declarative techniques such as CSP or X-Frame-Options (although there are suggestions that maybe they don't want to for some reason --- see https://bugzilla.mozilla.org/show_bug.cgi?id=519928#c5 ). But there are still issues with existing sites. Should we care? 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]
[whatwg] Video with MIME type application/octet-stream
I just became aware that application/octet-stream is excluded from being a type the user agent knows it cannot render. http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render Apparently this was done in response to a bug report: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977 Neither the bug report nor the editor's response give any indication why this change was made. This change means files served with application/octet-stream will make it all the way to the step If the media datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datacan be fetched but is found by inspection to be in an unsupported format ..., so implementations have to add support for binary sniffing for all the types they support. We didn't need this before in Gecko. What was the motivation for adding this implementation requirement? Thanks, 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] Video with MIME type application/octet-stream
On Thu, May 20, 2010 at 9:55 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I just became aware that application/octet-stream is excluded from being a type the user agent knows it cannot render. http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render Apparently this was done in response to a bug report: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977 Neither the bug report nor the editor's response give any indication why this change was made. This change means files served with application/octet-stream will make it all the way to the step If the media datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datacan be fetched but is found by inspection to be in an unsupported format ..., so implementations have to add support for binary sniffing for all the types they support. We didn't need this before in Gecko. What was the motivation for adding this implementation requirement? Hmm. I guess it doesn't add any implementation requirements beyond what you need to handle the complete absence of a Content-Type (which we currently don't handle, but I suppose we should). So this isn't really a problem. I'd still like to know why application/octet-stream has been added here, though. 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] Video with MIME type application/octet-stream
On Fri, May 21, 2010 at 2:00 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/20/10 5:59 AM, Robert O'Callahan wrote: Hmm. I guess it doesn't add any implementation requirements beyond what you need to handle the complete absence of a Content-Type (which we currently don't handle, but I suppose we should). For what it's worth, the above-necko layer in Gecko never sees absence of a Content-Type. If there isn't one, necko will sniff, period. Of course that sniffing knows nothing about video at the moment, and will likely just detect it as application/octet-stream (modulo the extension-sniffing bits). Ah, right. Thanks. 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] Image resize API proposal
On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak m...@apple.com wrote: I'd also love to hear from Mike Shaver and others from the original thread what they think of this API proposal. I think Shaver's feedback still applies: on any device with a GPU, we can optimize canvas and/or rendering enough that scaling images is no problem on the main thread. So this API would have a short useful lifetime ... possibly negative. Coming thread full circle, I now think there are good use cases for off-main-thread canvas, in particular with WebGL, but I guess that deserves its own thread again :-). 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] Image resize API proposal
On Sat, May 22, 2010 at 10:12 AM, David Levin le...@google.com wrote: There are a few issues here: 1. This only applies when you can accelerate with a GPU. Not all devices may support this. 2. This only applies to browsers that implement the acceleration with a GPU. When Mike Shaver mentioned this, he referred to a Windows version of Firefox. It is unclear if Firefox supports this on any other platform nor does it seem that all other browsers will support the accelerated canvas in the near-ish future. 3. The gpu results are due to the fact that the operation is done async from the call (which is great as far as not hanging the UI until you try to get the data out of the canvas, which leads to...). 4. Even with gpu acceleration, in order to use the result in an xhr, one has to get back the result from the gpu and this is a more expensive operation (because getting the data out of the gpu is slow) as indicated by the indirect copy results from Firefox and forces the completion of all of the operations that were being done async. 1. Phones have GPUs now. You won't see new devices being built that can run real Web browsers but don't have some kind of GPU, because the limiting factor on hardware now is not silicon but power. 2. Your proposal depends on browsers that implement your new API. As a browser developer, I would rather make canvas faster across the board than implement new API. 3. The GPU results are largely because GPUs are massively parallel. 4. The Firefox results include time to unpremultiply data and premultiply it again, all on the CPU. They don't indicate how long readback from the GPU actually takes on that machine. Also: 4a) the cost of readback is proportional to the size of the scaled image, so if your use case is scaling down images to small sizes, readback is cheap. 4b) you can easily read back and send one chunk of the scaled image at a time 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] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Tue, May 18, 2010 at 9:46 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: To be honest, it doesn't make much sense to display the wrong time in a player. If a video stream starts at 10:30am and goes for 30 min, then a person joining the stream 10 min in should see a time of 10min - or better even 10:40am - which is in sync with what others see that joined at the start. It would be rather confusing if the same position in a video would be linked by one person as at offset 10min while another would say at offset 0min. And since the W3C Media Fragments WG is defining temporal addressing, such diverging pointers will even end up in a URL and how should that be interpreted then? Here's how I think it should work: -- currentTime (and related times, such as times in TimeRanges) range from 0 to 'duration' -- media resources are allowed to have a non-zero initial playback time. This is what currentTime should be set to on media load. We could create a new DOM attribute to expose this. -- media resources are allowed to have a real time offset. This is an optional date+time (in UTC) that corresponds to currentTime=0, exposed as a DOM attribute. Players would be encouraged to use this to display real times, when it's present. This would be similar in power to what the spec already has. In your example you could either let currentTime=0 be the start of the stream that the user's loading, and use the real time offset to get the correct time displayed, or you could let 0 be the real start, and set the initial playback time to match where the user joined. However, I think describing things the way I just did is simpler and avoids weirdness like the start time changing dynamically. It also preserves the invariant that currentTime ranges from 0 to 'duration', which I think players will come to depend on if the cases where it's not true are rare. 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] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Mon, May 24, 2010 at 2:55 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: Just to clarify: what time would a video display as it is playing back in the browser? The currentTime+realTimeOffset (if any), where currentTime would include any initialPlaybackOffset? Yes. 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] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Mon, May 24, 2010 at 3:52 PM, Philip Jägenstedt phil...@opera.comwrote: On Mon, 24 May 2010 03:03:15 +0200, Robert O'Callahan rob...@ocallahan.org wrote: Here's how I think it should work: -- currentTime (and related times, such as times in TimeRanges) range from 0 to 'duration' -- media resources are allowed to have a non-zero initial playback time. This is what currentTime should be set to on media load. We could create a new DOM attribute to expose this. Is this a typo? If currentTime runes of 0 to duration, how can it begin at something non-zero? Let me rephrase (English is such a bad language!): -- The valid values for currentTime (and related times) range from 0 to 'duration', inclusive. -- A media resource can specify an initial value for currentTime. What concretely should we change? Should we drop startTime, or redefine it? We could redefine it but it might be less confusing to drop it and use another name for the initial value of currentTime. Currently startTime means something quite different to that (as others have noted, it means basically the first time in the 'seekable' TimeRanges, or currentTime if those ranges are empty). So I would change: -- get rid of startTime and the concept of earliest possible position, plus the related dispatching of timeupdate events -- create a new readonly DOM attribute, say call it initialTime that returns the default initial playback position for the media resource -- during media resource loading, when metadata loads set the current playback position to initialTime -- note that currentTime is always between 0 and 'duration' (if duration is known) Is it necessary to have the offset as an absolute date, or could that probably odd case be handled in other ways? I can't really see a browser UI making use of it, so I'd be happy to put it in a data-* attribute or using microdata. The real time offset is a property of the media resource (although I suppose we could have it settable via a content attribute as well) so it would need to be supported by the browser as an API on media elements. The question is whether there's enough demand to justify it. I don't know how widely supported this data is in media resource formats; Ogg Skeleton supports it, but I don't know about others. 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] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Mon, May 24, 2010 at 5:54 PM, Philip Jägenstedt phil...@opera.comwrote: So from this I gather that either: 1. initialTime is always 0 or 2. duration is not the duration of resource, but the time at the end. I wouldn't say that. If you can seek backwards to before the initial time, then clearly 'duration' really is still the duration, you just didn't start at the beginning. Same goes even if you can't seek backwards; e.g. this live stream is an hour long and you have started 20 minutes into it. This seems to be what is already in the spec. Instead of guessing what everyone means, here's what I'd want: 1. let currentTime always start at 0, regardless of what the timestamps or other metadata of the media resource says. 2. let currentTime always end at duration. 3. expose an offset from 0 in startTime or a renamed attribute for cases like live streaming so that the client can e.g. sync slides. The difference from what the spec says is that the concept of earliest possible position is dropped. I think the current spec allows you to seek backwards from the starting point. So would my proposal. Would yours? Would you allow 'seekable' to contain negative times? I think it's slightly simpler to allow currentTime to start at a non-zero position than to allow negative times and to support the offset in your point 3. I also think your point 3 would be slightly harder to spec. I'm not sure what you'd say. 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] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Mon, May 24, 2010 at 10:13 PM, Philip Jägenstedt phil...@opera.comwrote: Oh, so the idea is that the earlier data might actually be seekable, it's just that the UA seeks to an offset, much like with media fragments? The exception might be live streaming, where the duration is +Inf anyway. Yes. I don't think the current spec allows you to seek to before the earliest possible position, pretty much by definition. These are the cases I know of where an offset of some kind may be relevant: * live streaming. * server-applied media fragments where the offset of the fragment is given in a header of the resource. For live streaming, I'm not sure the current spec has a problem, if browsers would implement the startTime property. But you just said you want to get rid of startTime regardless of anything else! For resources which themself claim an offset, I think we should let them start at 0 anyway and let people who really want a weird timeline fix it themselves. That means they basically won't work with most players, which won't be expecting to deal with negative seekable times or the weird timeline. 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] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Mon, May 24, 2010 at 11:29 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Here's how I've understood it would work with the attributes: * currentTime is the video's timeline as described, so since we are at offset (3), currentTime = t2. * initialTime = t1, namely the offset at where the video playback started. * dateTime = 2010-01-01T10:00:00.000 That is exactly what I was suggesting. 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] Exposing framerate / statistics of video playback
On Sat, May 29, 2010 at 11:16 AM, Ian Fette i...@chromium.org wrote: Has any thought been given to exposing such metrics as framerate, how many frames are dropped, rebuffering, etc from the video tag? My understanding is that in the Flash player, many of these types of statistics are readily available. This is interesting for things not just like benchmarking, but for a site to determine if it is not working well for clients and should instead e.g. switch down to a lower bitrate video. Hasn't been discussed AFAIK, but I'd like to see a proposal. 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] Built-in image sprite support in HTML5
On Sun, May 30, 2010 at 3:58 AM, Mike Hearn m...@plan99.net wrote: Yeah, I'd think this isn't really a problem that should be solved as part of HTML5 but rather as improvements to the protocol level. Spriting is after all just a hack around the strict 1-file-1-request nature of HTTP and not something that's really fundamental. For instance theoretically SPDY should solve this problem. Or indeed so would HTTP pipelining, if it was used more often. HTTP-level solutions are vulnerable to broken proxies and caches, of which there are many. This is why HTTP pipelining doesn't really work. 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] Built-in image sprite support in HTML5
On Tue, Jun 1, 2010 at 9:22 AM, Mike Hearn m...@plan99.net wrote: HTTP-level solutions are vulnerable to broken proxies and caches, of which there are many. This is why HTTP pipelining doesn't really work. Yeah I know, but does that mean HTML should work around lack of features in HTTP? I mean you could say HTML5 is vulnerable to broken browsers :-) Yes, but if the browser has a bug it is much easier to detect, fix and deploy the fix. 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] video
On Mon, Jun 21, 2010 at 1:06 PM, Gregory Maxwell gmaxw...@gmail.com wrote: So... an interesting bit of fun comes up when you use layout tricks to prevent the context menu in order to make save as impossible, and you eliminate the full screen option as an unwanted side effect. We actually have a patch that works harder to find a video element under the mouse position, to show the full-screen option in such cases. Of course, it could still be defeated. There is also the issue of the context menu not being an especially intuitive or discoverable way of activating it, especially if all the rest of the controls are buttons below the video. I agree. We do need an API for scripted fullscreen. 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] video
On Tue, Jun 22, 2010 at 11:22 AM, Kevin Carle kca...@google.com wrote: It's important to realize that Flash fullscreen is about a lot more than just having the video play. For many sites (such as us at YouTube), the controls/UI are part of the fullscreen experience. Unless you can fullscreen a canvas or somehow allow controls and other elements (subtitles, annotations, etc) it's simply not competitive with Flash. Right now there is no way to implement the YouTube player and features in HTML5 in fullscreen. This thread contains an API proposal for doing all that: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg19915.html 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] Technical Parity with W3C HTML Spec
On Sat, Jun 26, 2010 at 11:00 AM, Mike Shaver mike.sha...@gmail.com wrote: That is not my recollection of what happened with offline, for what it's worth. Mozilla and Google had a relatively small set of deviations between approaches (ours developed on the whatwg list and Google's developed behind closed doors prior to the Gears announcement) and Ian specified an entirely different model, over the objections of both Mozilla and Google. Who from Mozilla objected? I didn't object, because I thought Ian's approach (manifests) was better than ours (JAR files). And I thought ours was quite different from Gears' (which used manifests, IIRC). 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] video application/octet-stream
On Mon, Jul 19, 2010 at 11:20 PM, Philip Jägenstedt phil...@opera.comwrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types There was some discussion about this, last in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026409.html I've tested Firefox 3.6.4, Firefox 4.0b1 and Chrome 5.0.375.99 and none return maybe for canPlayType(application/octet-stream). I couldn't get meaningful results from Safari on Windows (requires restart to detect QuickTime, perhaps?). It would appear that Opera is the only browser that supports application/octet-stream. At the time I added this, it was simply because it is true, maybe we can play it. However, I see no practical benefit of this spec-wise or implementation-wise. Since no other browsers have implemented it, I am going to remove it from Opera and hope that the spec will be changed to match this. I actually think we should add support for application/octet-stream media resources to Firefox, and if we're going to do that then I think we should be consistent and return maybe for canPlayType too. So I don't think you should remove this. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] video application/octet-stream
On Thu, Jul 22, 2010 at 2:07 AM, Chris Double chris.dou...@double.co.nzwrote: When content sniffing are we ignoring the mime type served by the server and always sniffing? If so then incorrectly configured servers can result in more downloaded data due to having to read the data looking for a valid video. For example: video source src='foo.ogg' source src='foo.mkv' /video If the web browser doesn't support Ogg but does support matroska, and the server sends the video/ogg content type, the browser can stop and go to the next source after downloading very little data. If the web browser is expected to ignore the mime type and content sniff it must see if 'foo.ogg' is a matroska file. According to the matroska spec arbitary ASCII data can be placed before the EBML identifier. This means reading a possible large amount of data (even the entire file) before being able to say that it's not a matroska file. That type of scenario is what I was getting at about how much of the file should be read before giving up. While that's true, in practice binary data will appear quite early in the file, and we could even tighten up WebM to restrict the amount of ASCII data that appears before the EBML identifier (perhaps to zero). Also, in your example the author could have provided type= attributes on the source elements to control what gets downloaded. I assume that no-one is proposing we ignore those. While I don't like sniffing, apparently Safari and Chrome have already raced straight to the bottom of the poisoned well here, so I don't think we really have a choice. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Canvas: clarification of compositing operations needed
On Thu, Jul 29, 2010 at 10:09 AM, Oliver Hunt oli...@apple.com wrote: This is the way the webkit canvas implementation has always worked, firefox implemented this incorrectly, and the spec was based off of that implementation. I don't think the spec was based off of that implementation is true, since Firefox never matched the spec (certain operators such as copy were treated as source-bounded, because cairo does it that way, just like CG) until I fixed that relatively recently. Additionally the webkit behaviour is more powerful than the spec behaviour as the spec behaviour can be emulated trivially on top of the webkit model, but vice versa is much harder and much more expensive. They're both pretty easy to emulate in terms of the other. But I agree that emulating an unbounded operator in terms of the source-bounded operator has a higher performance penalty, since the easy implementation is to use a temporary surface, where as to emulate source-bounded using unbounded you just do some extra clipping. As it happens, I'm expecting to see a proposal on public-canvas-api sometime soon that makes all composition source-bounded and has acceptable text defining the shape affected by the composition operation. It's tricky though, especially regarding shadows. But since I agree source-boundedness is more intuitive for authors, I'm open to changing Firefox to support it. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] An API to resize and rotate images client-side
Although I was kinda against adding canvas-2D to workers in the past, I think adding canvas, at least canvas-3D, to workers is going to be essential for advanced Web gaming to achieve steady frame rates, so I think we're going to be going there sooner or later. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser s...@me.com wrote: This is feedback on the Mozilla FullScreen API proposal here: https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI The user agent may transition a Document into or out of the fullscreen state at any time, whether or not script has requested it. User agents are encouraged to provide standard UI to exit the fullscreen state, for example if the user presses the Escape key. Does this imply that the UA has a fullscreen button, when the user uses this to make the window fullscreen, then the CSS pseudoclasses described in this document are applied? Yes, that's the idea. We want to be able to integrate fullscreen UI with scripted fullscreen. I'm not sure that's always desirable; I think it might result in unexpected behavior for users who use the fullscreen button as an equivalent to maximizing the window. I'd suggest that the CSS pseudoclasses are only applied when the fullscreen JS API has been called by the web content. Well, that's up to the UA; you can have a fullscreen mode that doesn't put the document into the fullscreen state, if you want. Note that the API lets authors distinguish fullscreen with a specific targeted element vs fullscreen with no targeted element, and a basic fullscreen UI would only enter the latter mode. So I don't think you'll get unexpected behavior in practice if they're integrated. Personally I think they should be integrated. For example, if you have a canvas game that occupies most of the window except for some instruction text, and the game has a fullscreen command that makes the canvas fill the window and resizes the canvas buffer to the window size, I think it would be nice for the UA's fullscreen UI to trigger the same behavior. Or maybe you have a slide viewer and you want the UA's fullscreen UI to trigger fullscreen presentation mode. This API makes that possible. * void cancelFullScreen() I think exit would be better than cancel. The only problem with exit is that you might call it when you're not actually in fullscreen state, since requests are asynchronous. I think of it more as cancelling the request than actually forcing a change. New methods of Document: * void requestFullScreen() * void requestFullScreenWithKeys() New methods of Element: * void requestFullScreen() * void requestFullScreenWithKeys() Do we really need to add these to both Document and Element? It seems like the Document ones could be removed; if an author wants to take the Documemnt fullscreen, they simply call the methods on document.documentElement. Yes, we can do that. This means getting rid of the concept of not having a fullscreen element, and instead special-casing the case where the fullscreen element is the root element in a few places. But I think that's probably a win. Thanks. I'm not fan of WithKeys in the method names. Out of context, it's not clear what keys means. I think keyboardInput or keyInput would be more understandable. OK. Also, why not just use a parameter: void requestFullScreen(bool allowKeyboardInput) boolean parameters are bad style IMHO. It's hard to tell at the call site what they mean. or have some constants for behavior: const unsigned short ALLOW_KEYBOARD_INPUT = 1; void requestFullScreen(unsigned short behavior) This would be extensible, and would allow us to permit other behaviors later. Sure. Why don't requestFullScreen()/requestFullScreenWithKeys() return a boolean value indicating whether the UA will allow the request to proceed? The author has no information about whether fullscreen is going to happen after making this call, and UAs will certainly want to deny fullscreen in various situations. The UA may not be able to make a decision synchronously. Permitting asynchronous decisions about whether to permit fullscreen was a key goal here. For example that gives UAs the option of presenting passive confirmation UI. New content attribute of the iframe element: * allowfullscreen This is a boolean attribute. When this attribute is not set, UAs should ignore fullscreen requests in the iframe or its descendants. Descendant nodes, or descendant iframes? Descendant frames. I'll clarify that. * :full-screen-doc I don't like the abbreviation of document here. Would page be a better term to use than document for these? We can just make it ':full-screen-document'. * :full-screen-doc While a Document is in the fullscreen state, the 'full-screen-doc' pseudoclass applies to the root element of that Document. * :full-screen-doc-with-target While a Document is in the fullscreen state and the document's current fullscreen element is an element in the document, the 'full-screen-doc-with-target' pseudoclass applies to the root element of that Document. Just to be clear, if a document is fullscreen, and the fullscreen element is not the document element, then the document
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Fri, Aug 6, 2010 at 1:37 PM, Simon Fraser s...@me.com wrote: On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote: On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser s...@me.com wrote: * void cancelFullScreen() I think exit would be better than cancel. The only problem with exit is that you might call it when you're not actually in fullscreen state, since requests are asynchronous. I think of it more as cancelling the request than actually forcing a change. That explains the method name, but I think the most common usage will be to exit fullscreen, rather than to cancel a recent request to enter fullscreen. Sure. But I still want to convey that this is a request, not a command. In Gecko I'd like to ensure that if a user activated fullscreen via browser UI, cancelFullScreen will be ignored. Why don't requestFullScreen()/requestFullScreenWithKeys() return a boolean value indicating whether the UA will allow the request to proceed? The author has no information about whether fullscreen is going to happen after making this call, and UAs will certainly want to deny fullscreen in various situations. The UA may not be able to make a decision synchronously. Permitting asynchronous decisions about whether to permit fullscreen was a key goal here. For example that gives UAs the option of presenting passive confirmation UI. Right. However, I think we need a fullscreenDenied event in that case, so the author is informed that their request failed for whatever reason. The most common cause of failure may be that the UA doesn't allow it (e.g. WebKit may make this opt-in for embedding applications, so calling this API in your RSS reader would result in a denied request). It's probably worth having such an event, but there will be times when neither fullscreendenied or fullscreenchanged are fired. I hope authors don't write apps that break in such cases. I'd like to see the proposal fleshed out to address the following scenarios: * the document is fullscreen, and navigation happens * the document is fullscreen, and the content calls requestFullScreen() again (possibly with a different element, possibly inside an iframe). I think the spec needs to at least say what happens here. Does the second call change the fullscreen element to the new element, or is it simply ignored? The spec says that the fullscreen element is changed. * the document is fullscreen, and the fullscreen element is removed from the DOM In this case I think you'd either exit fullscreen, or update the pseudostyles to make the document element the new fullscreen element. The spec currently says that in this case, no element gets the :fullscreen pseudostyle. I don't see any problem with that. This isn't something useful for authors to do, so I don't think it really matters what we do here as long as the result is well-defined and there aren't security issues. * the document is fullscreen, and the fullscreen element has display:none set on it. I guess the window just goes blank in this case? No, you'll see the page laid out in the viewport. * consideration of whether the fullscreen API can be called at any time (risk of drive-by-fullscreening). We've talked before about limiting the API so fullscreen can only be entered in response to a user event, and I still think that's sensible. It is sensible, and we should recommend that behavior, but it may not make sense for some UAs/UIs so I don't think it should be a hard requirement. Do we specify popup blocking behavior anywhere? This is just like that. Done. In most of those cases, nothing special happens. That is intentional; for example, I think trying to special-case handling of display:none or focus would quickly add a lot of complexity. Are you saying that the spec should not prescribe these behaviors? I think the UA should be permitted to exit fullscreen in certain scenarios if it deems that necessary for security reasons, as we've discussed before: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024897.html The spec is completely clear that UAs are allowed to exit fullscreen at any time, for any of the reasons mentioned in your email or for any other reason. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Sat, Aug 7, 2010 at 1:39 AM, Mike Wilcox m...@mikewilcox.net wrote: Kudos to Mozilla (and Robert?). This is awesome. It does appear that you plan to allow fullscreen without the use of a user-trigggered event such as a button-click like Flash does. The proposed spec allows that, but I think browsers are likely to prevent drive-by fullscreen. First a small thing. The format of the CSS style: :full-screen :full-screen-root-with-target I don't see why fullscreen should be hyphenated. Even the title of the page uses it as one word. I could go either way, but full-screen technically more correct. BTW you seem to be reading an old version of the spec. I don't understand the use of requestFullScreenWithKeys(). Why would I ever use a more restrictive method? As the spec explains, by opting into more restrictions, you can get a lower bar to access fullscreen mode. I assume the entire reason for security is for third party apps (video) and advertisements (have I missed an actor?). There's a set of problems there, but there's another set of problems where the user simply visits evil.com and that site tries to go fullscreen to launch some kind of spoofing attack. The first, simple use case I'm looking to solve is to block your ads from using fullscreen. I don't see a way to do that in the spec. I recommend the above options are properties of the document.body: body allowFullscreen=blocked This kind of thing would be better expressed with CSP. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Sat, Aug 7, 2010 at 1:57 AM, Mike Wilcox m...@mikewilcox.net wrote: Regarding fullscreen elements: I appreciate the initiative, but I wonder if it's necessary to allow fullscreen at the element level? It's not necessary, but it's a very useful convenience. It also allows the UA to perform transition effects that are impossible just at the author level. I think Simon is already pointing out potential gotchas. What exactly is the difference between a fullscreen-element and a fullscreen-page that has an element in absolutely position, top z-index, at 100% width and height? Nothing; see the proposed UA style sheet additions in the spec. As a developer, after entering fullscreen I could possibly do a fancy transition of the element to take up 100%. You can't do it as well as the UA can, because a really good transition effect involves desktop-level effects that authors don't have access to. For example you might want part of the window to zoom out and cover the entire screen, semi-transparent over the desktop while zooming. I would disrecommend authors trying to create custom transition effects that depend on geometry; they probably won't work across browsers because they'll interfere with the UA's effects. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
Fullscreen support for specific elements is more than just a convenience - it's fairly common to have multiple elements on a page that could be made to go fullscreen If the browser fullscreen API only supported making the entire page fullscreen, you could make an element fullscreen by making the page fullscreen and then making the element fill the page. This is in fact what the proposed API does. It just provides a convenient way for authors to achieve it. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Mon, Aug 9, 2010 at 5:58 PM, John Harding jhard...@google.com wrote: If there are multiple elements on the page (e.g. multiple inline video players) that could go fullscreen, you still need some way to determine which of them the user intended to make fullscreen. It's up to the script in the page to decide which element should be fullscreen. If scripts try to make different elements fullscreen at the same time, with the proposed spec, the most recent one to call requestFullscreen wins. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Sun, Aug 15, 2010 at 12:17 PM, Adam Barth w...@adambarth.com wrote: That's difficult to say given that it's supported in most browsers. We'd need to look for folks complaining to Mozilla. There's a tree of duplicate bug reports that lead to https://bugzilla.mozilla.org/show_bug.cgi?id=264412, but none since 2006. In 2006, you said you'd probably add it to HTML5: https://bugzilla.mozilla.org/show_bug.cgi?id=343357#c2. :) I doubt that IE or WebKit will remove support at this point, which leaves this as an inviting interoperability trap for developers who don't test in every browser. If it's not needed for compatibility, why wouldn't Webkit consider removing it? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Sun, Aug 15, 2010 at 5:57 PM, Adam Barth w...@adambarth.com wrote: On Sat, Aug 14, 2010 at 10:14 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Aug 15, 2010 at 12:17 PM, Adam Barth w...@adambarth.com wrote: That's difficult to say given that it's supported in most browsers. We'd need to look for folks complaining to Mozilla. There's a tree of duplicate bug reports that lead to https://bugzilla.mozilla.org/show_bug.cgi?id=264412, but none since 2006. In 2006, you said you'd probably add it to HTML5: https://bugzilla.mozilla.org/show_bug.cgi?id=343357#c2. :) I doubt that IE or WebKit will remove support at this point, which leaves this as an inviting interoperability trap for developers who don't test in every browser. If it's not needed for compatibility, why wouldn't Webkit consider removing it? Oh, you're certainly welcome to send in a patch and see what the project thinks, but my guess is the risk of removing the feature would outweigh the cost of keeping it (which is essentially zero). Wouldn't you consider the interoperability benefits to the Web platform? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Sun, Aug 15, 2010 at 6:16 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Wouldn't you consider the interoperability benefits to the Web platform? Not to mention the benefit of simplifying the platform a tiny bit by removing a feature which mostly duplicates another much more well-known feature. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Sun, Aug 15, 2010 at 6:30 PM, Adam Barth w...@adambarth.com wrote: On Sat, Aug 14, 2010 at 11:18 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Aug 15, 2010 at 6:16 PM, Robert O'Callahan rob...@ocallahan.org wrote: Wouldn't you consider the interoperability benefits to the Web platform? Not to mention the benefit of simplifying the platform a tiny bit by removing a feature which mostly duplicates another much more well-known feature. I'm all for interoperability, but who's going to twist Microsoft's arm to remove the feature from IE? I don't know, but even if they keep it, we'll be OK. As far as simplifying the platform, innerText is but one grain of sand on the beach. Perhaps, but it's a popular beach. Every grain matters. I think we agree innerText is redundant. The only reason to spec it would be for Web compatibility. But if we have no evidence it is needed for compatibility, we shouldn't spec it. (And personally, I think browsers should refrain from exposing Web-facing features that are neither in standards nor considered suitable for standarization, especially without a prefix.) From my point of view, the status quo of innerText being supported in IE and Webkit but unspecified and ignored by authors in practice is actually better than adding innerText to the spec. If it's added to the spec, more authors will discover it and start using it. Maybe someone could do a search to find out how much innerText is used on the Web? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: Add HTMLElement.innerText
What about lists? Alt text in img? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Mon, Aug 16, 2010 at 12:35 PM, Mike Wilcox m...@mikewilcox.net wrote: On Aug 15, 2010, at 7:29 PM, Robert O'Callahan wrote: What about lists? Alt text in img? It handles lists and the line breaks, but it doesn't indent. Image attributes are ignored. Tables? Is there any documentation for how the serialization works? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Mon, Aug 16, 2010 at 9:23 PM, Maciej Stachowiak m...@apple.com wrote: A more hypothetical use would be a rich text editor that has a convert to plaintext feature. textContent is not as useful for these use cases, since it doesn't handle line breaks and unrendered whitespace properly. There are lots of ways people might want to do that. For example, convert to plaintext features often introduce characters for list bullets (e.g. '*') and item numbers. (E.g., Mac TextEdit does.) Safari 5 doesn't do either. The Gecko plaintext serializer has a comment: // Output methods flag bits. There are a frightening number of these, // because everyone wants something a little bit different Satisfying more than a small number of potential users with a single attribute may be difficult. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, Aug 17, 2010 at 4:05 PM, Ian Hickson i...@hixie.ch wrote: Hmm, good point. Any other suggestions? Mozilla has already added a number of extensions using just a moz prefix ... e.g. mozInnerScreenX, mozPaintCount, mozRequestAnimationFrame. Webkit has added extensions using a webkit prefx ... e.g. webkitDisplayingFullscreen. In theory I guess that pattern could conflict with new features. But in practice it doesn't seem likely unless new engines enter the market and choose prefixes poorly. (I.e., don't choose a prefix that matches an English verb or noun.) Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] scrollIntoView()
On Tue, Aug 17, 2010 at 11:56 PM, Anne van Kesteren ann...@opera.comwrote: On Tue, 17 Aug 2010 13:53:59 +0200, Olli Pettay o...@pettay.fi wrote: What is your testcase here? I was looking at the code and seems like scrollToView is sync in Gecko. And a simple testcase showed that window.scrollY was updated right after the method call. (note, scroll events aren't sync). I was talking about the events. They are synchronous in WebKit as far as I can tell. I'm happy to define them as asynchronous though. Being compatible with Gecko seems better. Async events are also generally safer to implement and use. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fullscreen feedback
On Sat, Aug 21, 2010 at 8:24 AM, Ian Hickson i...@hixie.ch wrote: One comment: Rather than adding an allowfullscreen attribute on iframe, I would suggest just assuing that sandboxed content (i.e. content of iframes with the sandbox= attribute) can't go fullscreen. I can provide a sandbox flag for this state. If we think there are use cases for allowing sandboxed iframes to go fullscreen, then I can also add a keyword that turns off the flag when present (like allow-scripts does for scripts). (I'm assuming there are no cases for disabling fullscreen for unsandboxed iframes; are there?) What about legacy content that doesn't use sandbox? It might expect cross-origin IFRAMEs to not be able to take over its window, but if the IFRAME content goes fullscreen, it effectively can. I think allowing subframes to go fullscreen should always be opt-in. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fullscreen feedback
On Sat, Aug 21, 2010 at 5:21 PM, Adam Barth w...@adambarth.com wrote: How is going fullscreen different from opening a popup window? That depends on how the UA chooses to handle it. But this proposed fullscreen API is based on the idea that the fullscreen content takes over the toplevel browsing context to which it belongs. (The content is styled to fill the IFRAME, and the IFRAME element is styled to fill the parent document's viewport.) Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fullscreen feedback
On Sun, Aug 22, 2010 at 4:12 AM, Adam Barth w...@adambarth.com wrote: On Sat, Aug 21, 2010 at 2:00 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Aug 21, 2010 at 5:21 PM, Adam Barth w...@adambarth.com wrote: How is going fullscreen different from opening a popup window? That depends on how the UA chooses to handle it. But this proposed fullscreen API is based on the idea that the fullscreen content takes over the toplevel browsing context to which it belongs. (The content is styled to fill the IFRAME, and the IFRAME element is styled to fill the parent document's viewport.) That does seem dangerous if the location bar still displays the URL of the top-level browsing context because it violates the constraint principle of display delegation. That's why I want to default to prohibiting subframe content from going fullscreen. This doesn't seem like a good model for full-screen. I would think the model of re-parenting the content to a popup window that fills the entire screen would be a better model. I think that model is a lot harder to spec and a lot harder for Web authors to understand. I'd certainly be interested in looking at a proposal if someone wants to pursue that approach. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fullscreen feedback
On Mon, Aug 23, 2010 at 3:46 PM, Adam Barth w...@adambarth.com wrote: Yeah, I agree that we'd need something like that in this model. It's unfortunate though. Won't folks package video widgets using iframes? I guess they'll need to include this silly attribute in their copy-and-paste this markup code in order for full screen to work. Right. On Sun, Aug 22, 2010 at 8:00 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Aug 22, 2010 at 4:12 AM, Adam Barth w...@adambarth.com wrote: This doesn't seem like a good model for full-screen. I would think the model of re-parenting the content to a popup window that fills the entire screen would be a better model. I think that model is a lot harder to spec and a lot harder for Web authors to understand. I'd certainly be interested in looking at a proposal if someone wants to pursue that approach. There's been some work in WebKit around the concept of a magic iframe that keeps it's environment intact even when it's adopted from one document to another. I'm not sure how much of that has been discussed for standardization, but you could imagine a model like that working where a frame is adopted into a popup window that fills the screen. That's sorta-ok if your video is a subframe that you treat as a black box. But if your video element is just an element in your page with event handlers attached to it, and with various scripts that interact with it, and you rip that element out (plus maybe some supporting elements representing your player UI) and drop it in another document, it seems to me you're going to have to code very carefully to ensure it keeps working over there (and the original page doesn't get into a bad state). If there's confirmation UI so that the movement between documents happens asynchronously, it's even more exciting. Moving the element back when the user exits fullscreen has similar issues. Maybe there are ways to make that model easy and convenient for authors. I'd like to see a proposal. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fullscreen feedback
On Mon, Aug 23, 2010 at 4:42 PM, Adam Barth w...@adambarth.com wrote: Oh, I think the iframe-at-a-time is an easier model to work with since the scripting context will get adopted into the full-screen view together with the elements. It requires the author to put each part of their page that they want to go fullscreen into its own subframe. That is cumbersome. With my proposal, most existing pages and player UIs would work if you just call element.requestFullScreen() in some event handler. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fullscreen feedback
On Mon, Aug 23, 2010 at 5:03 PM, Adam Barth w...@adambarth.com wrote: On Sun, Aug 22, 2010 at 9:56 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Aug 23, 2010 at 4:42 PM, Adam Barth w...@adambarth.com wrote: Oh, I think the iframe-at-a-time is an easier model to work with since the scripting context will get adopted into the full-screen view together with the elements. It requires the author to put each part of their page that they want to go fullscreen into its own subframe. That is cumbersome. With my proposal, most existing pages and player UIs would work if you just call element.requestFullScreen() in some event handler. But it doesn't go full screen, right? Didn't you say above that the location bar is still there? That depends on the UA. Assuming we implement this API using our existing fullscreen functionality, in Firefox the element would be fullscreen, but if the user moves the mouse to the very top of the screen some browser chrome will pop down temporarily, including the URL bar. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fullscreen feedback
On Mon, Aug 23, 2010 at 5:25 PM, Adam Barth w...@adambarth.com wrote: So... The trade-off is: 1) Only browsing contexts can go full-screen (since they have URLs that we could display). 2) Any element can go full-screen, but we'll need to add a nasty non-semantic attribute. Is allowfullscreen really less semantic than sandbox? Actually one option here is to only allow sandboxed iframes to go fullscreen, deny fullscreen to sandboxed iframes by default, and provide a sandbox token (e.g. allow-fullscreen) that allows fullscreen. So you could add sandbox=allow-scripts allow-fullscreen to a video embedding IFRAME. Another idea is that we could let any element go full-screen, but then we'd show the URL of its browsing context. There's some subtleties here about overlays from parent frames, but those seem solvable. Doable, but maybe painful to implement, and there are numerous spec and UI issues to do with navigation, history, etc. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] VIDEO Timeupdate event frequency.
I think an ideal API for video frame processing would involve handing video frames to a Worker for processing. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] VIDEO Timeupdate event frequency.
On Sat, Sep 11, 2010 at 11:03 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Fri, Sep 10, 2010 at 4:01 PM, Robert O'Callahan rob...@ocallahan.org wrote: I think an ideal API for video frame processing would involve handing video frames to a Worker for processing. Mm, yeah, probably. But then you'd need to be able to do canvas on workers, and hand the data back... This is a complex problem. Most of the usecases I've seen just do get/putImageData, so it might make sense to just provide raw frame data to the Worker and not introduce a canvas dependency. So... no newframe event for now, leave timeupdate as it is, and fix this in the future? I think so. Another factor is that a lot of the video effects people have been using canvas for can actually be done with SVG filters, which can be GPU-accelerated and are compatible with asynchronous compositing. So it might be wise to focus on use-cases for video processing that aren't amenable to SVG filters (or extensions thereof), and understand what their requirements are. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
2010/9/19 Julian Reschke julian.resc...@gmx.de On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote: Hi, I'm working on link tags inside of chrome. We're now experimenting with an optimization that uses link tags and headers to avoid round trips for cache validation in many cases. ... Clarifying: essentially that's a workaround for resources for which the actual cache information returned by HTTP GET isn't accurate, right? Which of course leads to the question: if the maintainers of a site can't get their cache information right, what makes you think they can get their HTML right instead? No, it's a performance optimization. I presume that if the link attributes indicate that the browser's cached resource is valid, the browser does not issue a network request to validate the resource. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
2010/9/19 Julian Reschke julian.resc...@gmx.de So it's a workaround that causes a performance optimization. It wouldn't be necessary if the linked resource would have the right caching information in the first place I think you're misunderstanding the proposal. If present for an http uri, these tags represent an assertion about the current cache status of the target resource. A browser that has a cached resource for that uri with the same etags and/or last-modified may present the link data without validation in connection with the link retrieval. So for example, page A links to resource B. The browser does a GET on A, and receives a document containing a link to B, and the link element has etags or last-modified attributes. The browser has a cached resource for B, whose etags/last-modified matches the link attribute, so the browser knows its cached B is valid and no further network transactions are required. The linked resource B having the right caching information in the first place (when the browser first fetched it) isn't enough to eliminate the need for an HTTP transaction to validate B later. Rob
Re: [whatwg] Html 5 video element's poster attribute
On Sun, Sep 19, 2010 at 10:57 PM, Shiv Kumar sku...@exposureroom.comwrote: I'm glad to see that people do see the need to change (or specify in more detail) the behavior of the poster at least insofar as it disappearing before the video is played. As far as I know, every major browser (IE 9 beta, Firefox, Safari, Chrome and Opera) do this. As Monty discovered, Firefox does not make the poster disappear until the video is played. Feel free to file bugs against any browsers that behave differently; just because the spec allows something doesn't mean it's a good idea! Tightening up the spec to require the poster to remain until the video is played does sound like a good idea. We do need a spec change to allow the poster to be shown when the video has ended, if that is the most commonly desired behavior. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 5:03 PM, Shiv Kumar sku...@exposureroom.com wrote: Of course we wouldn’t want the user to see the poster during the time it takes to switch so we clear value of the poster before doing this, which is one of the issues cited in my very first post on this subject. I don't see why providing a scriptable API to hide the poster image is better than just having authors use existing APIs to clear the poster attribute. In my mind, “load()” does not imply that the poster should also show. The video stream and poster are quite frankly independent of each other. One is a video stream and the other is an image. They are not designed to be independent. If you want them to be independent, use a real independent image placed over the video. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 10:31 PM, Shiv Kumar sku...@exposureroom.comwrote: Rob, I don't see why providing a scriptable API to hide the poster image is better than just having authors use existing APIs to clear the poster attribute. What is the existing API to clear and show the poster? element.removeAttribute(poster)? As it stands today, the poster is not usable (probably because as you state it has not been designed to be independent). Every website that has implemented their own Html 5 video player have had to hack their way to get things to work the way they’d expect. I explained this part in my first post. Basically ,what they do is assign the poster and not the source. Then when the user clicks play, they assign the source. Then each time the user skips ahead, they need to null out the poster attribute (otherwise in some browsers the poster flashes during buffering periods) and then set the currentTime to skip ahead. Now if you want to change the source of the video in mid play to a better or lower quality version of the same video then you have to go through a few more hoops (and the load() method is used at this time – but you don’t want the poster to show either). I think we have a consensus on the need to change the way the poster behaves. 1. The poster should remain visible till the video is played. 2. Once the video has been played, the poster should not show during buffering or skipping ahead or any other action. I agree with all that. Firefox already does what you want there. The only thing that remains then is if web developers would like control over the poster, such as to show the poster after the video has ended, then there should be a way to do that. For this we need a method to show the poster once again. Current there is no way to get the poster to show again and the load() method is not the answer, nor is resetting. A simple method that does not impact anything else will do the trick. I am trying to understand why load() is not an adequate answer. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 11:36 PM, Shiv Kumar sku...@exposureroom.comwrote: Here are some contradictory cases that may serve as use cases to justify the need to have a spate method: 1. Some websites, don’t bother showing the poster after the video ends while providing the content producer to override. 2. Some websites (and mobile devices) default to showing the poster after the video ends and allowing the content producer to override 3. Some websites show the poster whenever the video is paused. Given the above cases, having a method the specifically controls the visibility of the poster (alone) will allow all of the above cases to be implemented. A side question: do any of these sites want a poster that has dynamic/interactive content in it? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Scriptable interface for video element FullScreen mode
On Thu, Sep 23, 2010 at 10:11 PM, Mikko Rantalainen mikko.rantalai...@peda.net wrote: What kind of digesting and analyzing do you think is required? An UA is free to implement support for this API in a way that will ever accept the request only if the requested element is the video element. In that case, the API is a specialized video fullscreen API only. In fact, there has been a lot of clear feedback that an API that only works on video elements is unlikely to get much use, since major video sites very strongly prefer to use their own player UI in fullscreen mode. And of course their own player UI consists of non-video elements... Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] SearchBox API
On Thu, Oct 14, 2010 at 11:59 AM, Tony Gentilcore to...@chromium.orgwrote: // Dimensions of the portion of the search box (e.g. a dropdown) // that overlaps the window. readonly attribute unsigned long x; readonly attribute unsigned long y; readonly attribute unsigned long width; readonly attribute unsigned long height; How is this information expected to be used? Is there expected to be some kind of policy that controls which pages are allowed to access the searchBox API? I assume that if I'm currently visiting evil.com and I start typing in a search, evil.com should not be able to see that. How should the searchBox API behave in that case? Is the intent that the browser load a normal search page for some partial query and then expose the rest of the search query through this searchBox API? If so, it seems we'll need a way to detect ahead of time that a search service expects/supports such behavior. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] SearchBox API
On Fri, Oct 15, 2010 at 12:53 PM, Tony Gentilcore to...@chromium.orgwrote: The simplest way to address this is probably to advertise support via an agreed upon meta tag. e.g. meta name=NavigatorSearchBoxSupport content=true The UA populates the API only if the page advertises support via the metatag. Otherwise, it works as it does today. How would that work? The browser can only get that metadata by fetching the search page. So the browser should fetch the search page when the user starts typing in a search query, and if the page doesn't advertise instant search, the browser just throws that page away? If so, presumably you'd want some kind of back-off to avoid lots of useless traffic. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Autoplaying media elements not in a document
On Mon, Oct 18, 2010 at 12:22 PM, timeless timel...@gmail.com wrote: On Mon, Oct 18, 2010 at 2:01 AM, Chris Pearce ch...@pearce.org.nz wrote: Unless there's a good reason not to, and since most browsers have implemented autoplay when not in a document anyway, perhaps we should update the spec to match the implemented behaviour? Accessibility tools only have access to the document. This means that they will not be able to help a user STOP, pause, play, seek a video / audio resource. This really isn't ok. You can pretend DOM Inspector is an accessibility aid if you want to experience this. It sounds like you're arguing that elements not in a document should not play at all. That is a separate issue, so please raise it yourself if you think it's important. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Exposing filenames in DataTransfer
On Tue, Oct 19, 2010 at 9:59 AM, Daniel Cheng dch...@chromium.org wrote: However, this leads to issues like file system paths being exposed through properties like x-special/gnome-icon-list or even text/plain. What is the expected behavior here? Mirroring the native dragging clipboard allows for a much richer interaction with the system, but I'm not sure if we need to go out of our way to try to scrub all paths from the drag. After all, if you're dropping the file on the page, you're already exposing the contents of the file, which are probably much more interesting than just the path. Thoughts? The path can expose interesting metadata, such as the local username (useful for dictionary attacks!), the names of file servers, names of projects, etc. Obviously the filename can expose some too, but hopefully the user's more aware of that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Autoplaying media elements not in a document
On Tue, Oct 19, 2010 at 12:57 PM, David Singer sin...@apple.com wrote: isn't autoplaying a media element over which the user may well have no control (unless the page offers a script to control it), inappropriate? Maybe, but elements not in a document can only be created by script in the first place. If script wants to have a disconnected autoplay element, why not let it? If it wants to be annoying it can just call play(). Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Autoplaying media elements not in a document
On Sat, Oct 23, 2010 at 11:14 AM, Jonas Sicking jo...@sicking.cc wrote: I think browsers will have to develop APIs, both for AT users and non-AT-users which allow things like indicating which window is playing audio, as well as tell it to mute (without allowing the page to unmute) a given window or website. You mean standardized APIs? They could be useful for controlling IFRAMEs, I guess. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Sat, Nov 20, 2010 at 10:42 AM, Boris Zbarsky bzbar...@mit.edu wrote: We (Mozilla) have no plans to expose screen pixels to untrusted content at the moment, more or less as a policy decision. We actually do support the -moz-device-pixel-ratio CSS media query. There are legitimate use cases for that. Most of the use cases for script access to the exact device pixel ratio that I've heard boil down to interfere with the user's ability to zoom, which is why I haven't been eager to make it easier. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Mon, Nov 22, 2010 at 10:07 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Sat, Nov 20, 2010 at 12:21 AM, Robert O'Callahan rob...@ocallahan.org wrote: Most of the use cases for script access to the exact device pixel ratio that I've heard boil down to interfere with the user's ability to zoom, which is why I haven't been eager to make it easier. Might there be some web pages that have good reason to interfere with the user's ability to zoom? For instance, Google's Quick View for PDFs: http://docs.google.com/viewer?a=vq=cache:D8hHb4MTkS4J:www.irs.gov/pub/irs-pdf/fw4.pdf (Apparently the W-4 form is the first PDF hit when you Google for PDF, who knew.) Over at the side there are zoom buttons, but they do something quite different from using the browser's built-in zoom function. However the in-page zoom buttons work is a lot more legible and smooth than using browser zoom. So allowing the page to hijack browser zoom requests in this specific case would actually be a usability improvement, as far as I can tell. I don't mind a browser allowing a page to override the default behavior of a browser's zoom keybindings or possibly even menu items. But ultimate control still has to reside with the user and user-agent. Web designers are notorious for declaring that their content should be viewed at a certain size; if an obnoxious designer tries to disable browser zooming, I insist that the browser be able to override that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard ch...@jumis.com wrote: Rob: Mobile deployments using dpiPixelRatio (as has been adopted by Moz and Webkit) and target-DpiDensity work well on the mobile, they are not hooked to zoom on the desktop, It is in Firefox. and they were not designed for desktop-style zoom. Trying to overload these variables leads to difficulties between the various mobile style zooms and desktop zoom. I'm not sure why. Device-pixel-ratio should give you the ratio of device pixels to CSS pixels, full stop. You can use matchMedium to use it from JS. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard ch...@jumis.com wrote: I would point out that the MS proposal has an independent X and Y scaling mechanism. Does anyone know of any modern displays which have different X and Y resolution? I believe that dpi ratio is simply set to 2 (or .5... sorry a bit rusty) on the iOS 4 retina display. There will be cases where zooming doesn't change device-pixel-ratio. Mobile browsers tend to have a fast zoom out which doesn't change the layout (mostly), and that might not change device-pixel-ratio. I think that's OK for your use cases as long as device-pixel-ratio reports the ratio as if the page is zoomed in. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard ch...@jumis.com wrote: I've a deep and detailed understanding of the SVG, HTML, DOM and CSS specs. Just out of interest, why aren't you using SVG? I understand the need to make canvas backing store pixels map to device pixels when possible. Suppose that, on clearing the canvas (e.g. by setting the width or height attribute), the browser automatically set the canvas backing store density so that canvas backing store pixels map to device pixels (taking into account the current zoom settings). Suppose further that browsers fired the 'resize' event when they zoom in a way that changes the window size (as they should, even if they currently don't). Then on 'resize' you could clear your canvas and redraw it, and automatically get a canvas backing store with the right resolution with no further code changes. Would that address your use case? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks kevinma...@gmail.com wrote: Well, if we care about doing video processing with Canvas, understanding anamorphic pixels is needed. You mean the aspect ratio of the video source? Sure, but here we're talking about the output device. Anyway, adding APIs to help browsers display better quality output on NTSC or PAL TVs seems like a waste of time to me. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] CSS canvas() function
On Wed, Nov 24, 2010 at 2:23 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: For example, I've recently been playing with fractals in canvas, and temporarily set my blog to have a screen-filling canvas z-index'd below the content, filled with an interactive fractal (the mandelbrot set, overlaid with the julia set for the point your mouse was over). It would be better/cleaner/easier/more semantic to just draw directly into the body background, which is what I was faking with abspos and z-index. OK. How about just using canvas() to refer to setImageElement() things? This retains the flexibility that setImageElement has over getCSSCanvasContext, while removing the weirdness of transparently overriding #ids and keeping element() open to accept arbitrary selectors? Special syntax to refer to setImageElement elements would be OK, but I wouldn't choose canvas(), since the element can also be a video or img. How about element(ident) to refer to setImageElements, element(#id) for DOM IDs, and element(first(selector)) for selectors? (I don't necessarily endorse the idea of extending to selectors, FWIW, but I appreciate the desire to keep the possibility open.) Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard ch...@jumis.com wrote:
SVG is a document format. It is not reliably implemented. It's far more
expensive to implement SVG on a new environment than Canvas.
So? You don't have to implement it.
I can't do much for you here other than explain to you what I'm hearing.
a) Why are you using our Canvas implementation instead of our SVG
implementation.
b) Why are you using ctx.fillText('Test') instead of
element.appendChild(document.createElement('text')).textContent = 'Test'.
For answers
a: I'm using it because I work across a variety of browser platforms.
Canvas is far better supported.
It doesn't make sense to request entirely new features (that by definition
aren't currently supported) because existing features aren't widely
supported.
Anyway, I'm not sure why you think canvas is far better supported than
SVG. What browser supports canvas but not SVG?
Sure, but there are plenty of canvas uses that aren't animating all the
time (I've seen image editing apps, sites that use canvas as their
_input_, not their output, etc).
1. Name one.
http://arewefastyet.com
http://www.simile-widgets.org/timeplot/
http://jwf.us/blog_apps/mandelbrot_canvas/
Robert's suggestion would radically alter the existing functionality of
canvas
Only in a way that maintains compatibility with existing content. Otherwise
I wouldn't have suggested it.
and require a whole lot of work from other vendors.
Not really.
Rob
--
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Wed, Nov 24, 2010 at 10:14 PM, Charles Pritchard ch...@jumis.com wrote: window.dpiPixelRatio does not change. Is it mozDpiPixelRatio ? There is no such property. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] CSS canvas() function
On Thu, Dec 2, 2010 at 12:43 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: My question was specifically for an out-of-document iframe. In-document, all elements are obviously valid. Something like: script var frame = document.createElement(iframe); frame.src = http://www.example.com; document.cssElementMap.foo = frame; /script Should this work? The rendering of a non-seamless iframe doesn't depend on any other elements in the document. In general, any replaced element seems to fall into this camp. It depends on viewport size and medium, at least. In the absence of compelling use cases, I'd just leave it at img, canvas and video and whitelist in more elements later if necessary. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] CSS canvas() function
On Thu, Dec 2, 2010 at 2:25 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Dec 1, 2010 at 5:20 PM, Robert O'Callahan rob...@ocallahan.org wrote: In the absence of compelling use cases, I'd just leave it at img, canvas and video and whitelist in more elements later if necessary. input type=image? object/embed seem to have roughly equivalent use-cases to video (though perhaps we just want to encourage video). object can contain fallback content which might get tricky. Also, plugin objects don't have a useful intrinsic size. Why would anyone use input type=image instead of img? Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] CSS canvas() function
On Thu, Dec 2, 2010 at 6:34 PM, Simon Fraser s...@me.com wrote: On Dec 1, 2010, at 5:37 PM, Robert O'Callahan wrote: On Thu, Dec 2, 2010 at 2:25 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Dec 1, 2010 at 5:20 PM, Robert O'Callahan rob...@ocallahan.org wrote: In the absence of compelling use cases, I'd just leave it at img, canvas and video and whitelist in more elements later if necessary. input type=image? object/embed seem to have roughly equivalent use-cases to video (though perhaps we just want to encourage video). object can contain fallback content which might get tricky. So can video. Actually video can't, although I think it should. It's a shame to disallow HTML elements with known width and height, e.g. if you want to render a small disconnected div subtree into a canvas or map it onto a WebGL texture. You'd have to decide how to resolve style (maybe assume it's a child of the body?). That gets tricky fast, as Boris explained. I think we could spec the following cases: 1) img containing a fully loaded image; size is the intrinsic size of the image 2) video when it's displaying a video or fully loaded poster image; size is the intrinsic size of the video or poster image 3) canvas; size is the size of the canvas buffer We could add object and embed to the list, for the cases where they contain a plugin or a fully loaded image, except I don't know what size you'd use. Maybe resolve style, use the resolved width and height if they're both lengths, otherwise rendering nothing? I'm not terribly motivated to add new features for plugins though. I think after the behaviour of not-in-document IFRAMEs is properly specced out (e.g. defining the viewport size), we could add them here too. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
[whatwg] Handling unknown 'duration's
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-durationsays: The duration attribute must return the time of the end of the media resourcehttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-resource, in seconds, on the media timelinehttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-timeline. If no media datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datais available, then the attributes must return the Not-a-Number (NaN) value. If the media resourcehttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-resourceis known to be unbounded (e.g. a streaming radio), then the attribute must return the positive Infinity value. What if the duration is not currently known? I think in general it will be very difficult for a user-agent to know that a stream is unbounded. In Ogg or WebM a stream might not contain an explicit duration but still eventually end. Maybe it would make more sense for the last sentence to read If the media resource is not known to be bounded, ... Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Handling unknown 'duration's
On Sat, Dec 18, 2010 at 11:27 PM, Philip Jägenstedt phil...@opera.comwrote: Agreed, this is how I've interpreted the spec already. If a server replies with 200 OK instead of 206 Partial Content and the duration isn't in the header of the resource, then the duration is reported to be Infinity. If the resource eventually ends another durationchange event is fired and the duration is reported to be the (now known) length of the resource. That sounds good to me. We'll probably do that. The spec will need to be changed though. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property
On Tue, Jan 4, 2011 at 7:25 AM, carol.sz...@nokia.com wrote: I thought that the issue was settled as well, but after talking to Ian Hixie and Philip Taylor, Ian indicated that if someone provides a clear formulation of the spec text that matches webkit behavior, the spec would likely be changed to match that. I have proposed the changes below, but got no reply (or if I got any I missed them): Sorry, I should have replied earlier. HTML5 - Canvas. I have read this thread (from and of July 2010) and I happen to agree that the Safari/Chromium implementation is more intuitive, and likely less expensive to implement, therefore I offer these 2 proposals for changing the spec's Drawing model section to match what I perceive to be the preference of most people in that discussion. Of note: According to the current Drawing model, an opaque shape's shadow would be erased as part of step 6 when drawn with source-in composite Mode if globalAlpha is 1, which is probably not the intended behavior. Version 1: 4.8.11.1.13 Drawing model When a shape or image is painted, user agents must follow these steps, in the order given (or act as if they do): 1. Render the shape or image onto an infinite transparent black bitmap, creating image M1, as described in the previous sections except that for the purpose of this step every pixel of the image will be considered to be fully opaque white and the current fillStyle will be considered to be solid fully opaque white and the strokeStyle will be considered fullyOpaque white as well 2. When shadows are drawn, render the shadow from image M1, using a fully opaque white shadow color as described in the shadows section, creating image M2. 3. Let C1 be a region obtained by intersecting the canvas's cliping region with the set of pixels in the canvas that correspond to pixels in M1 (by having the same coordinates) that are not fully transparent. 4. Let C2 be a region obtained by intersecting the canvas's cliping region with the set of pixels in the canvas that correspond to pixels in M2 (by having the same coordinates) that are not fully transparent. 5. Render the shape or image onto an infinite transparent black bitmap, creating image A, as described in the previous sections. For shapes, the current fill, stroke, and line styles must be honored, and the stroke must itself also be subjected to the current transformation matrix. 6. When shadows are drawn, render the shadow from image A, using the current shadow styles, creating image B. 7. When shadows are drawn, multiply the alpha component of every pixel in B by globalAlpha. 8. When shadows are drawn, composite B with the current canvas bitmap, cliping results to region C2 defined above, using the current composition operator. 9. Multiply the alpha component of every pixel in A by globalAlpha. 10. Composite A with the current canvas bitmap, cliping results to region C1 defined above, using the current composition operator. Making a binary fully-transparent/not-fully-transparent per-pixel decision to create regions C1 and C2 seems like it can't be right in the presence of antialiasing. Suppose we have a path filled with black and operator copy. Any pixel on the edge of that path that gets any nonzero coverage value from antialiasing will end up solid black with this proposal. That's going to look very ugly. We'll want a solution where any canvas pixel which has a very small amount of coverage by the path will be mostly unchanged in the final result. Version 2: 4.8.11.1.13 Drawing model When a shape or image is painted, user agents must follow these steps, in the order given (or act as if they do): 1. Render the shape or image onto an infinite transparent black bitmap, creating image A, as described in the previous sections. For shapes, the current fill, stroke, and line styles must be honored, and the stroke must itself also be subjected to the current transformation matrix. 2. When shadows are drawn, render the shadow from image A, using the current shadow styles, creating image B. 3. When shadows are drawn, multiply the alpha component of every pixel in B by globalAlpha. 4. When shadows are drawn, composite, using the current composition operator, B with the current canvas bitmap, cliping results to the cliping region of the canvas and to the pixels that would have taken the shadow's color if the composition operator would have been source-over and the shadow would have been fully opaque and the globalAlpha would have been 1. 5. Multiply the alpha component of every pixel in A by globalAlpha. 6. Composite, using the current composition operator, A with the current canvas bitmap, cliping results to the cliping region of the canvas and to the pixels that would have taken the shape's or image's pixel color if the composition operator would have been source-over and the image would have been fully opaque, the fillStyle and strokeStyle
Re: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property - Drawing model discussion
On Wed, Jan 5, 2011 at 8:12 AM, carol.sz...@nokia.com wrote: Please see my in-line comments below: -- Version 1: 4.8.11.1.13 Drawing model When a shape or image is painted, user agents must follow these steps, in the order given (or act as if they do): 1. Render the shape or image onto an infinite transparent black bitmap, creating image M1, as described in the previous sections except that for the purpose of this step every pixel of the image will be considered to be fully opaque white and the current fillStyle will be considered to be solid fully opaque white and the strokeStyle will be considered fullyOpaque white as well 2. When shadows are drawn, render the shadow from image M1, using a fully opaque white shadow color as described in the shadows section, creating image M2. 3. Let C1 be a region obtained by intersecting the canvas's cliping region with the set of pixels in the canvas that correspond to pixels in M1 (by having the same coordinates) that are not fully transparent. 4. Let C2 be a region obtained by intersecting the canvas's cliping region with the set of pixels in the canvas that correspond to pixels in M2 (by having the same coordinates) that are not fully transparent. 5. Render the shape or image onto an infinite transparent black bitmap, creating image A, as described in the previous sections. For shapes, the current fill, stroke, and line styles must be honored, and the stroke must itself also be subjected to the current transformation matrix. 6. When shadows are drawn, render the shadow from image A, using the current shadow styles, creating image B. 7. When shadows are drawn, multiply the alpha component of every pixel in B by globalAlpha. 8. When shadows are drawn, composite B with the current canvas bitmap, cliping results to region C2 defined above, using the current composition operator. 9. Multiply the alpha component of every pixel in A by globalAlpha. 10. Composite A with the current canvas bitmap, cliping results to region C1 defined above, using the current composition operator. Making a binary fully-transparent/not-fully-transparent per-pixel decision to create regions C1 and C2 seems like it can't be right in the presence of antialiasing. Suppose we have a path filled with black and operator copy. Any pixel on the edge of that path that gets any nonzero coverage value from antialiasing will end up solid black with this proposal. That's going to look very ugly. We'll want a solution where any canvas pixel which has a very small amount of coverage by the path will be mostly unchanged in the final result. I do not understand why pixels touched by antialiasing are going to be solid black. Yes, I made a mistake. The actual result will be mostly-transparent black, but that is equally unacceptable. In step 1, every pixel which is very slightly covered by the path will be filled with mostly-transparent white. In step 3, all such pixels will be added to C1. In step 5, those pixels will be set to mostly-transparent black in image A. In step 10, for those pixels we'll composite mostly-transparent black onto the canvas with operator copy, setting the canvas pixels to mostly-transparent black. The core problem is steps 3 and 4. Making a binary decision for each pixel whether it's in or out of the shape simply can't work well when coverage-based antialiasing is being used. If you generalize C1 and C2 to be alpha masks, or rephrase the approach so that it permits such generalization, then this could work. But you have to be careful about how you use partial alpha values in step 10. The way I understand antialiasing (and maybe I am wrong), pixels that are partly touched retained partly their old color and transparency and get parly the new color and transparency. More precisely the resulting transparency and color components an average of the color component being painted and the previous color component weighted by the coverage fraction of the pixel. Hence partially covered pixels are partially transparent, thus the background behind the canvas should shine through and the partially covered pixels won't be entirely black unless that background is black as well. That's right, but your proposal interacts with this process. I agree with you though that there are cases when inappropriately using globalCompositeOperation can yield ugly and perhaps surprising results, such as in the case you described if the canvas is completely red before the operation and it is put on a page that has green background, thus the shape will acquire an unexpected slightly green rim between black and red. Yes, it's easy to produce ugliness. With great power comes great responsibility :-). Version 2: 4.8.11.1.13 Drawing model When a shape or image is painted, user agents must follow these steps, in the order given (or act as if they do): 1. Render the shape or image onto
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
On Wed, Jan 12, 2011 at 9:42 PM, Philip Jägenstedt phil...@opera.comwrote: For the record, this is the solution I've been imagining: * add HTMLMediaElement.seek(t, [exact]), where exact defaults to false if missing * make setting HTMLMediaElement.currentTime be a non-exact seek, as that seems to be the most common case I think setting currentTime should be exact, since a) exact seeking is simpler from the author's point of view and b) it would be unfortunate to set currentTime to value T and then discover that getting currentTime gives you a value other than T (assuming you're paused). Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Web DOM Core feedback
On Fri, Jan 14, 2011 at 11:41 PM, James Graham jgra...@opera.com wrote: On 01/13/2011 10:05 PM, Aryeh Gregor wrote: There are a bunch of places where it says When invoked with the same argument the same NodeList object may be returned as returned by an earlier call. Shouldn't this be either required or prohibited in any given case, not left undefined? It seems like making this a requirement would interact badly with GC e.g. if I have some call that produces a huge NodeList that is then not referenced, I don't want to keep it around just in case some future script returns the same NodeList. On the other hand, there are scripts that put calls returning identical NodeLists in inner loops. In these cases not recreating the object every time is a big performance win. The usual trick here is to weakly reference the cached NodeList. So if the script holds onto a reference, then future calls will return that NodeList, but if the script does not hold onto a reference, it can be GCed and future calls will return a different NodeList. Then the spec can say that the same NodeList will be returned, and that implementation satisfies the spec since a script can't tell that the NodeList has changed without holding onto a reference to the old NodeList. ... except I guess it can, because it could set expando properties on the old NodeList and check for their presence later. Sigh. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Tue, Jan 18, 2011 at 10:08 AM, Chris Pearce ch...@pearce.org.nz wrote: Can this not be implemented on the server side? If you know the media has an average playback rate of X KB/s, can the server reliably throttle its transmission at 1.5X? Yes, it seems to me that if you simply throttle the rate at which the server delivers data to the video rate plus some safety margin, that should help. It won't be as efficient as it could be if the user pauses the video, though. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Limiting the amount of downloaded but not watched video
One solution that could work here is to honour dynamic changes to 'preload', so switching preload to 'none' would stop buffering. Then a script could do that, for example, after the user has paused the video for ten seconds. The script could also look at 'buffered' to make its decision. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Wed, Jan 19, 2011 at 6:11 AM, Zachary Ozer z...@longtailvideo.comwrote: (Side note: I also haven't found a browser that stops loading the resource even if you destroy the video tag.) Setting the source URI to should stop the download. Personally I think having browsers honor dynamic changes to the preload attribute is the best way to solve this. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Wed, Jan 19, 2011 at 1:35 PM, Andy Berkheimer andyberkhei...@youtube.com wrote: As an example, I believe Chrome's current implementation _does_ stall the HTTP connection (stop reading from the socket interface but keep it open) after some amount of readahead - a magic hardcoded constant. We've run into issues there - their browser readahead buffer is too small and causing a lot of underruns. For the record, Firefox does this too, but only when we run out of storage on the client. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
