Re: [whatwg] base elements, again
On Mon, 2011-05-09 at 15:55 -0400, Boris Zbarsky wrote: On 5/8/11 12:11 AM, Ian Hickson wrote: On Mon, 24 Jan 2011, Boris Zbarsky wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=627361 The conclusion seems to have been to attempt to keep the spec as it stands, and try to get the remaining problems addressed via evangelism. I approve of such an approach because it means I don't have to do anything. Also, and more importantly, the spec as it stands now is somewhat sane and pretty much any behaviour to address the remaining compatibility issues moves us away from sanity. Have there been more compatibility problems reported withbase in the past few months that would change this conclusion? We've had more reports of the Unicenter failure, but no other new issues reported, I believe. On WHATWG IRC, there was one report: http://mathiasbynens.be/demo/base Not citing specific real site breakage, though. The problem is that Gecko re-resolves existing images when the base URI of the documnet changes. IIRC, Hixie said that a change of base URI is not supposed to trigger re-resolution of the src of images that are already in the doc. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] synchronization of (HTML5 video+audio) and (image) and (text/html/frames) = html5 multimedia presentation
I forget the API and project name. May someone tell me if there is any existing API/project for this kind of task. I am willing to sart/collaborate such work.. -- ┌─┐ │Narendra Sisodiya │http://narendrasisodiya.com └─┘
Re: [whatwg] synchronization of (HTML5 video+audio) and (image) and (text/html/frames) = html5 multimedia presentation
Are you maybe talking about popcorn.js ? Or are you after a certain API in HTML5? Silvia. On Wed, May 11, 2011 at 7:33 PM, Narendra Sisodiya naren...@narendrasisodiya.com wrote: I forget the API and project name. May someone tell me if there is any existing API/project for this kind of task. I am willing to sart/collaborate such work.. -- ┌─┐ │ Narendra Sisodiya │ http://narendrasisodiya.com └─┘
Re: [whatwg] synchronization of (HTML5 video+audio) and (image) and (text/html/frames) = html5 multimedia presentation
On Wed, May 11, 2011 at 5:02 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: Are you maybe talking about popcorn.js ? Or are you after a certain API in HTML5? I was looking for popcorn.js I got it. My purpose is to replace flash and create multimedia content using open web standards .. Hope I will be able to create good content soon
[whatwg] Full Screen API Feedback
WebKit is in the process of implementing Mozilla's proposed Full Screen API https://wiki.mozilla.org/Gecko:FullScreenAPI. Basic full screen support is available in WebKit Nightlies http://nightly.webkit.org/ on Mac and Windows (other ports are adding support as well), and can be enabled through user defaults (WebKitFullScreenEnabled=1). To test the feasibility of this API, we have mapped the full screen button in the default controls in video elements to this new API. The webkit-only webkitenterfullscreen() method on HTMLMediaElement has also been mapped to this new API. In so doing, we have been able to collect test case results from live websites. In this process, I believe we have uncovered a number of issues with the API proposal as it currently stands that I'd like to see addressed. 1. Z-index as the primary means of elevating full screen elements to the foreground. The spec suggests that a full screen element is given a z-index of BIGNUM in order to cause the full screen element to be visible on top of the rest of page content. The spec also notes that it is possible for a document to position content over an element with the :full-screen pseudo-class, for example if the :full-screen element is in a container with z-index not 'auto'. In our testing, we have found that this caveat causes extreme rendering issues on many major video-serving websites, including Vimeo and Apple.com. In order to fix rendering under the new full-screen API to be on par with WebKit's existing full-screen support for video elements, we chose to add a new pseudo-class and associated style rule to forcibly reset z-index styles and other stacking-context styles. This is of course not ideal, and we have only added this fix for full screen video elements. This rendering quirk makes it much more difficult for authors to elevate a single element to full-screen mode without modifying styles on the rest of their page. Proposal: the current API proposal simply recommends a set of CSS styles. The proposal should instead require that no other elements render above the current full-screen element and its children, and leave it up to implementers to achieve that requirement. (E.g., WebKit may implement this by walking up the ancestors of the full-screen element disabling any styles which create stacking contexts.) 2. Animating into and out of full screen. WebKit's current video full-screen support will animate an element between its full-screen and non-full-screen states. This has both security and user experience benefits. However, with the current z-index-based rendering technique recommended by the proposed Full Screen API, animating the full-screen transition is extremely difficult. Proposal: The full-screen element should create a new view, separate from its parent document's view. This would allow the UA to resize and animate the view separate from the parent document's view. This would also solve issue 1 above. 3. fullscreenchange events and their targets. The current proposal states that a fullscreenchange event must be dispatched when a document enters or leaves full-screen. Additionally, when the event is dispatched, if the document's current full-screen element is an element in the document, then the event target is that element, otherwise the event target is the document. This has the side effect that, if an author adds an event listener for this event to an element, he will get notified when an element enters full screen, but never when that element exits full-screen (if the current full screen element is cleared, as it should be, before the event is dispatched.) In addition, if the current full-screen element is changed while in full screen mode (e.g. by calling requestFullScreen() on a different element) then an event will be dispatched to only one of the two possible targets. Proposal: split the fullscreenchange events into two: fullscreenentered and fullscreenexited (or some variation thereof) and fire each at the appropriate element. 4. A lack of rejection. The current proposal provides no notification to authors that a request to enter full screen has been denied. From an UA implementor's perspective, it makes writing test cases much more difficult. From an author's perspective it makes failing over to another full screen technique (such as a full-window substitute mode) impossible. Proposal: add a fullscreenrequestdenied event and require it to be dispatched when and if the UA denies a full-screen request. Thanks, -Jer Jer Noble jer.no...@apple.com
Re: [whatwg] The PeerConnection onmessage function attribute
Hi Tommy, On 2011-05-11 14:59 CEST, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote: Hi gang, What is the event type for the onmessage event handler? I might have missed something but I can't find a suitable event for this one. A MessageEvent is already defined by the Communication spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html). /Tommy See step 18 under When a packet that is part of a data UDP media stream is received in http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-data-stream Create an event that uses the MessageEvent interface, with the name message, which does not bubble, is not cancelable, has no default action, and has a data attribute whose value is /message/, and queue a task to dispatch the event at the PeerConnection object responsible for this side of the data UDP media stream. The event type is message and the interface is MessageEvent. //Per-Erik
Re: [whatwg] Full Screen API Feedback
On Wed, May 11, 2011 at 11:27 AM, Jer Noble jer.no...@apple.com wrote: 3. fullscreenchange events and their targets. The current proposal states that a fullscreenchange event must be dispatched when a document enters or leaves full-screen. Additionally, when the event is dispatched, if the document's current full-screen element is an element in the document, then the event target is that element, otherwise the event target is the document. This has the side effect that, if an author adds an event listener for this event to an element, he will get notified when an element enters full screen, but never when that element exits full-screen (if the current full screen element is cleared, as it should be, before the event is dispatched.) In addition, if the current full-screen element is changed while in full screen mode (e.g. by calling requestFullScreen() on a different element) then an event will be dispatched to only one of the two possible targets. Proposal: split the fullscreenchange events into two: fullscreenentered and fullscreenexited (or some variation thereof) and fire each at the appropriate element. Couldn't you simply define that fullscreenchange is fired after the fullscreen is cleared, but still fire it on the element which used to be the fullscreened element. It's nicer for authors to not have to deal with two events. 4. A lack of rejection. The current proposal provides no notification to authors that a request to enter full screen has been denied. From an UA implementor's perspective, it makes writing test cases much more difficult. From an author's perspective it makes failing over to another full screen technique (such as a full-window substitute mode) impossible. Proposal: add a fullscreenrequestdenied event and require it to be dispatched when and if the UA denies a full-screen request. Wasn't the idea that if the user denies the fullscreen request, the browser can still full-window the element inside the normal browser window, thus taking care substitute for the website? / Jonas
Re: [whatwg] Specs for window.atob() and window.btoa()
On Fri, 4 Feb 2011, Jorge wrote:
Wrt to the note some base64 encoders add newlines or other whitespace
to their output. atob() throws an exception if its input contains
characters other than +/=0-9A-Za-z, so other characters need to be
removed before atob() is used for decoding in
http://aryeh.name/spec/base64.html , I think that in the end it's better
to ignore any other chars instead of throwing, because skipping over any
such chars while decoding is cheaper and requires less memory than
scanning the input twice, first to clean it and second to decode it,
something you'd not want to end up doing -just in case- everytime.
Say, for example, that you've got a 4MB base64 with (perhaps?) some
whitespace, in order to clean it up you're going to have to have it in
memory along the cleaned up version at least while constructing the
clean version, but if atob() skipped over anything other than
+/=0-9A-Za-z you could just pass it directly, and the whole process
would be even faster too, given there was no need to clean it up first.
FWIW, that's how nodejs is doing it right now.
Also, some tools (e.g. the openssl decoder) *expect* the newlines to be
there, and fail if they aren't.
On Fri, 4 Feb 2011, Boris Zbarsky wrote:
The problem is that at least some current browsers (which ones?) throw.
So you wouldn't be able to rely on the non-throwing behavior anyway
On Fri, 4 Feb 2011, Aryeh Gregor wrote:
Everyone except Opera throws on invalid characters in atob() input, and
IIRC, I was told by Opera devs that not throwing caused compat problems
for them. So I don't think this is worth trying to change.
On Fri, 4 Feb 2011, Jorge wrote:
On the other hand, it will be so forever unless the spec says *not* to
throw but to skip over instead, so that in a few years the cleanup can
be ~safely skipped.
On Fri, 4 Feb 2011, Aryeh Gregor wrote:
Nope. The spec isn't going to change browser behavior here if there are
sites that depend on the current behavior -- and reportedly there are.
There's just no incentive for browsers to change; the proposed behavior
isn't sufficiently superior to warrant even slight compatibility pain.
We can change web APIs in ways that might cause some compatibility pain
if we have good reason, but for really minor things like this it's just
not worth it. Browsers can only afford to break a certain number of
websites per release before users start to get annoyed, and we shouldn't
be wasting it on things like this.
On Sat, 5 Feb 2011, Jorge wrote:
How is this :
try {
var result= atob(input); // will throw if input has whitespace
}
catch (e) {
try {
var result= atob( input.replace(/\s/g, '') ); // will throw if input is
not proper base64
}
catch (e) {
throw e;
}
}
any better than :
var result= atob(input); // will throw if input is not proper base64
?
On Sat, 5 Feb 2011, Simon Pieters wrote:
Is the compat problem for not throwing for whitespace or for not
throwing for other garbage? If it's for other garbage, we could allow
whitespace but throw for other garbage. (The bugs I can find in our
database with a quick search is about non-ASCII characters not
throwing.)
Better performance seems like an incentive.
On Sat, 5 Feb 2011, Aryeh Gregor wrote:
Opera people were the only ones who told me about these compat problems,
so it could be just non-ASCII characters. I went with Gecko's behavior
exactly because it seemed simpler than WebKit's and I had been told
Opera's wasn't fully web-compatible. Both Gecko and WebKit do throw on
any whitespace.
On Sat, 5 Feb 2011, Jonas Sicking wrote:
As a firefox developer, I'd be interested in avoiding throwing if it can
make things easier for authors (and it is web compatible).
So my first question is, can someone give examples of sources of base64
data which contains whitespace?
I agree that this function probably doesn't appear in a lot of
performance critical code paths. However it might show up in places
which deal with large bodies of data, so if people can avoid cloning
that data unnecessarily then that's a win.
On Sat, 5 Feb 2011, Joshua Cranmer wrote:
The best guess I have is base64-encoding MIME parts, which would be
hardwrapped every 70-80 characters or so.
On Sat, 5 Feb 2011, Joshua Bell wrote:
RFC 3548 The Base16, Base32, and Base64 Data Encodings Section 2.1
discusses line feeds in encoded data, calling out the MIME line length
limit. For example, Perl's MIME::Base64 has an encode_base64() API that
by default inserts newlines after 76 characters. (An optional argument
allows this behavior to be overridden.)
Section 2.3 discusses Interpretation of non-alphabet characters in
encoded data specifically in base64 (etc) encoded data.
On Sun, 6 Feb 2011, Jorge wrote:
$ openssl enc -base64 ... inserts newlines too.
The argument for changing this seems somewhat
Re: [whatwg] Full Screen API Feedback
On May 11, 2011, at 3:03 PM, Jonas Sicking wrote: On Wed, May 11, 2011 at 11:27 AM, Jer Noble jer.no...@apple.com wrote: 3. fullscreenchange events and their targets. The current proposal states that a fullscreenchange event must be dispatched when a document enters or leaves full-screen. Additionally, when the event is dispatched, if the document's current full-screen element is an element in the document, then the event target is that element, otherwise the event target is the document. This has the side effect that, if an author adds an event listener for this event to an element, he will get notified when an element enters full screen, but never when that element exits full-screen (if the current full screen element is cleared, as it should be, before the event is dispatched.) In addition, if the current full-screen element is changed while in full screen mode (e.g. by calling requestFullScreen() on a different element) then an event will be dispatched to only one of the two possible targets. Proposal: split the fullscreenchange events into two: fullscreenentered and fullscreenexited (or some variation thereof) and fire each at the appropriate element. Couldn't you simply define that fullscreenchange is fired after the fullscreen is cleared, but still fire it on the element which used to be the fullscreened element. It's nicer for authors to not have to deal with two events. That takes care of one case. But for the case where the full-screen element changes due to requestFullScreen() being called while already in full-screen mode, which element should you fire the fullscreenchange event at? The first or the second? Or both? This would be made much clearer if the element which lost current full-screen element status received one message, and the one gaining that status received another. If requiring authors to deal with two event names is too cumbersome, (which I'm not sure I agree with) perhaps a new Event type is in order. Something like FullScreenEvent.targetEntered and FullScreenEvent.targetExited (or similar) would also solve the problem. 4. A lack of rejection. The current proposal provides no notification to authors that a request to enter full screen has been denied. From an UA implementor's perspective, it makes writing test cases much more difficult. From an author's perspective it makes failing over to another full screen technique (such as a full-window substitute mode) impossible. Proposal: add a fullscreenrequestdenied event and require it to be dispatched when and if the UA denies a full-screen request. Wasn't the idea that if the user denies the fullscreen request, the browser can still full-window the element inside the normal browser window, thus taking care substitute for the website? Was it? It doesn't seem to be in the proposed API document. And absent any explicit requirement that the browser also implement a pseudo-full-screen mode, I think that the above event is still necessary. -Jer Jer Noble jer.no...@apple.com
Re: [whatwg] Thoughts on recent WhatWG blog post
On Mon, 7 Feb 2011, Adam van den Hoven wrote: window.atob() and window.btoa() feel wrong, so does window.crypto.getRandomUint8Array(length), not because they're not useful but because there is no answer to 'what does converting binary data to a base 64 string have to do with window?' beyond 'nothing but where else would it go?'. In reality all these belong to javascript, but modifying JS to include them is not feasible. Modifying JS to include them would make no difference, in practice. For example, parseInt() is on window, as is Object, String, indeed everything is on window. Window is the global object. I think that we would all be better served if we were to introduce something like CommonJS to the browser, or perhaps a modified version of the require() method. This would allow us to move the crytpo and the atob/btoa into specific modules which could be loaded using: script var my_crypto = window.require( 'html:crypto' ); //or however you wanted to identify the 'crypto library defined by html' var my_util = window.require( 'html:util' ); // my_util.atob(); var $ = window.require( ' https://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js' ); /script and so on. We try to do that (but with far less verbosity) already. For example, the ApplicationCache API is not on Window, you have to get a handle to it: script var my_appcache = window.applicationCache; // now you can use my_appcache /script As a shorthand, you can also just directly access things on applicationCache: window.applicationCache.status The same applies to many other features, e.g. session history features are accessed via window.history, features relating to the UA and the environment as accessed through window.navigator, etc. Further, in CommonJS, the library has to export an object in order to make it available. If we could define things in such a way that the browser compiled the library independent of the page that loads it, the browser could cache the *compiled* code and provide that to the browser page. That kind of thing has been tried in the past, but in practice it turns out there are too many versions of too many libraries to actually make this workable, as I understand it. On Mon, 7 Feb 2011, Adam van den Hoven wrote: On Mon, Feb 7, 2011 at 12:03 PM, Aryeh Gregor wrote: Generally we try not to create new objects in the global namespace. Instead, we try sticking them on other preexisting global objects in most cases. But that is exactly what has happened, or perhaps some existing pollution is simply being codified. In this case, yes. There is no meaningful connection between atob and window. So yes it already exists... I'm just not sure that it should. Window is just the global object. Things that have no meaningful connection to anything go on window because there's nowhere else to put them (require() would have to go on window too). I wouldn't get too caught up in the name window. What problem does this solve? The problem of global namespace pollution? Why not just define window.html (or some other single name) and make all the functions methods of that object? This is kind of what we're doing already, although not so systematically. Your solution seems overly complicated. You could collect them into a single global object, and that was something I though about, as well. But I think that this is a more generally applicable solution. There are many libraries that do nothing but load javascript from within javascript. They all do it by writing a script tag to the DOM. I believe this is a code smell. Having a consistent way to do this sort of thing would improve the lives of a lot of code developers and create some consistency between what is happening on the server side as well. I don't really understand what problem you are describing here. On Tue, 8 Feb 2011, Brett Zamir wrote: [it would be good to have a script importing feature that] does not burden the user with needing to avoid names which could end up being co-opted by HTML in the future. My understanding is that this is being addressed in JS itself. (Also, just because WhatWG may verify names are fairly unique or unique on the public web, does not mean they are catching HTML uses off the web and for which there could be conflicts; abdicating responsibility for effects of such apps just because it is not within the scope of the spec would I think be rather shoddy stewardship of a language relied on for many purposes.) I think our first priority must be to the Web. If we try to make HTML appropriate for multiple different unrelated platforms, we will end up pulled in multiple directions. Naturally if there are multiple equally good ways to design a solution for a problem faced by the Web, we should pick the solutions that work for the most other environments as well, but that's not as strong a commitment as
Re: [whatwg] Full Screen API Feedback
On Wed, May 11, 2011 at 3:27 PM, Jer Noble jer.no...@apple.com wrote: On May 11, 2011, at 3:03 PM, Jonas Sicking wrote: On Wed, May 11, 2011 at 11:27 AM, Jer Noble jer.no...@apple.com wrote: 3. fullscreenchange events and their targets. The current proposal states that a fullscreenchange event must be dispatched when a document enters or leaves full-screen. Additionally, when the event is dispatched, if the document's current full-screen element is an element in the document, then the event target is that element, otherwise the event target is the document. This has the side effect that, if an author adds an event listener for this event to an element, he will get notified when an element enters full screen, but never when that element exits full-screen (if the current full screen element is cleared, as it should be, before the event is dispatched.) In addition, if the current full-screen element is changed while in full screen mode (e.g. by calling requestFullScreen() on a different element) then an event will be dispatched to only one of the two possible targets. Proposal: split the fullscreenchange events into two: fullscreenentered and fullscreenexited (or some variation thereof) and fire each at the appropriate element. Couldn't you simply define that fullscreenchange is fired after the fullscreen is cleared, but still fire it on the element which used to be the fullscreened element. It's nicer for authors to not have to deal with two events. That takes care of one case. But for the case where the full-screen element changes due to requestFullScreen() being called while already in full-screen mode, which element should you fire the fullscreenchange event at? The first or the second? Or both? On both. And make :full-screen match no element, and document.fullScreen return false, while the first event fires. This would be made much clearer if the element which lost current full-screen element status received one message, and the one gaining that status received another. If requiring authors to deal with two event names is too cumbersome, (which I'm not sure I agree with) perhaps a new Event type is in order. Something like FullScreenEvent.targetEntered and FullScreenEvent.targetExited (or similar) would also solve the problem. 4. A lack of rejection. The current proposal provides no notification to authors that a request to enter full screen has been denied. From an UA implementor's perspective, it makes writing test cases much more difficult. From an author's perspective it makes failing over to another full screen technique (such as a full-window substitute mode) impossible. Proposal: add a fullscreenrequestdenied event and require it to be dispatched when and if the UA denies a full-screen request. Wasn't the idea that if the user denies the fullscreen request, the browser can still full-window the element inside the normal browser window, thus taking care substitute for the website? Was it? It doesn't seem to be in the proposed API document. And absent any explicit requirement that the browser also implement a pseudo-full-screen mode, I think that the above event is still necessary. I could definitely be wrong. And I agree that if we want to go that route it should be explicitly required in the spec. / Jonas
[whatwg] Comments on the dropzone attributes
Hi, I'd like to propose a few changes to the definition of the dropzone attribute. 1. In the same sentence, the spec says that it is not valid to add the feedback value more than once, but it also says that the first occurrence is to be used. Can the spec change to simply say that the first occurrence of the feedback value will be used (and it is valid) ? 2. Using f: and s: for distinguishing strings from files seems needlessly confusing. Why not use string: and file: ? 3. It seems very useful to allow wildcards in the data type, so instead of defining multiple types for images, image/* should be allowed. Please note that this comments were suggested originally in https://bugs.webkit.org/show_bug.cgi?id=58210#c26 thanks, Yael
Re: [whatwg] Full Screen API Feedback
On Thu, May 12, 2011 at 6:27 AM, Jer Noble jer.no...@apple.com wrote: 1. Z-index as the primary means of elevating full screen elements to the foreground. The spec suggests that a full screen element is given a z-index of BIGNUM in order to cause the full screen element to be visible on top of the rest of page content. The spec also notes that it is possible for a document to position content over an element with the :full-screen pseudo-class, for example if the :full-screen element is in a container with z-index not 'auto'. In our testing, we have found that this caveat causes extreme rendering issues on many major video-serving websites, including Vimeo and Apple.com. Can you describe these issues in more detail? In order to fix rendering under the new full-screen API to be on par with WebKit's existing full-screen support for video elements, we chose to add a new pseudo-class and associated style rule to forcibly reset z-index styles and other stacking-context styles. This is of course not ideal, and we have only added this fix for full screen video elements. This rendering quirk makes it much more difficult for authors to elevate a single element to full-screen mode without modifying styles on the rest of their page. Proposal: the current API proposal simply recommends a set of CSS styles. The proposal should instead require that no other elements render above the current full-screen element and its children, and leave it up to implementers to achieve that requirement. (E.g., WebKit may implement this by walking up the ancestors of the full-screen element disabling any styles which create stacking contexts.) This could have side effects observable to the page. I'd prefer to standardize exactly what happens here. 2. Animating into and out of full screen. WebKit's current video full-screen support will animate an element between its full-screen and non-full-screen states. This has both security and user experience benefits. However, with the current z-index-based rendering technique recommended by the proposed Full Screen API, animating the full-screen transition is extremely difficult. Proposal: The full-screen element should create a new view, separate from its parent document's view. This would allow the UA to resize and animate the view separate from the parent document's view. This would also solve issue 1 above. I'm not sure what you mean exactly by a new view. Depending on what you mean, that could create all kinds of implementation and spec issues. For example, if an element can have different style or layout in the two views, DOM APIs that return those things become ambiguous. I would strongly object to that. It seems to me you could animate the transition without having multiple concurent views. For example, freeze the rendering of the document in its browser window, put the document into the fullscreen state, and display it in a popup window that starts off matching the geometry of the fullscreen element and zooms out to cover the screen. 3. fullscreenchange events and their targets. The current proposal states that a fullscreenchange event must be dispatched when a document enters or leaves full-screen. Additionally, when the event is dispatched, if the document's current full-screen element is an element in the document, then the event target is that element, otherwise the event target is the document. This has the side effect that, if an author adds an event listener for this event to an element, he will get notified when an element enters full screen, but never when that element exits full-screen (if the current full screen element is cleared, as it should be, before the event is dispatched.) In addition, if the current full-screen element is changed while in full screen mode (e.g. by calling requestFullScreen() on a different element) then an event will be dispatched to only one of the two possible targets. Proposal: split the fullscreenchange events into two: fullscreenentered and fullscreenexited (or some variation thereof) and fire each at the appropriate element. That sounds fine to me. 4. A lack of rejection. The current proposal provides no notification to authors that a request to enter full screen has been denied. From an UA implementor's perspective, it makes writing test cases much more difficult. From an author's perspective it makes failing over to another full screen technique (such as a full-window substitute mode) impossible. Proposal: add a fullscreenrequestdenied event and require it to be dispatched when and if the UA denies a full-screen request. My main concern is that with some UI scenarios there might not be a good time to fire the denied event. For example, in Firefox 4 when an application requests geolocation a popup appears, and if the user clicks anywhere outside the popup the popup disappears but there is still UI allowing the user to grant the request later. If we used
Re: [whatwg] Full Screen API Feedback
On May 11, 2011, at 7:41 PM, Robert O'Callahan wrote: On Thu, May 12, 2011 at 6:27 AM, Jer Noble jer.no...@apple.com wrote: 1. Z-index as the primary means of elevating full screen elements to the foreground. The spec suggests that a full screen element is given a z-index of BIGNUM in order to cause the full screen element to be visible on top of the rest of page content. The spec also notes that it is possible for a document to position content over an element with the :full-screen pseudo-class, for example if the :full-screen element is in a container with z-index not 'auto'. In our testing, we have found that this caveat causes extreme rendering issues on many major video-serving websites, including Vimeo and Apple.com. Can you describe these issues in more detail? Sure. Here's what Vimeo looked like in full-screen mode: http://i.imgur.com/Rl4Gp.png. And Apple.com: http://i.imgur.com/71Glg.png. Each page has already placed the video element in a stacking context one way or another. And so, even though the full screen element has a large z-index, many other elements of the page pop in front of it. In order to fix rendering under the new full-screen API to be on par with WebKit's existing full-screen support for video elements, we chose to add a new pseudo-class and associated style rule to forcibly reset z-index styles and other stacking-context styles. This is of course not ideal, and we have only added this fix for full screen video elements. This rendering quirk makes it much more difficult for authors to elevate a single element to full-screen mode without modifying styles on the rest of their page. Proposal: the current API proposal simply recommends a set of CSS styles. The proposal should instead require that no other elements render above the current full-screen element and its children, and leave it up to implementers to achieve that requirement. (E.g., WebKit may implement this by walking up the ancestors of the full-screen element disabling any styles which create stacking contexts.) This could have side effects observable to the page. I'd prefer to standardize exactly what happens here. I agree that an explicit requirement is desirable. 2. Animating into and out of full screen. WebKit's current video full-screen support will animate an element between its full-screen and non-full-screen states. This has both security and user experience benefits. However, with the current z-index-based rendering technique recommended by the proposed Full Screen API, animating the full-screen transition is extremely difficult. Proposal: The full-screen element should create a new view, separate from its parent document's view. This would allow the UA to resize and animate the view separate from the parent document's view. This would also solve issue 1 above. I'm not sure what you mean exactly by a new view. Depending on what you mean, that could create all kinds of implementation and spec issues. For example, if an element can have different style or layout in the two views, DOM APIs that return those things become ambiguous. I would strongly object to that. I'm not suggesting that the element exists in two views simultaneously, but rather that it becomes the root of a new viewport. It seems to me you could animate the transition without having multiple concurent views. For example, freeze the rendering of the document in its browser window, put the document into the fullscreen state, and display it in a popup window that starts off matching the geometry of the fullscreen element and zooms out to cover the screen. That is much more difficult than it sounds. :) Freezing the non-full-screen content is already undesirable. The animation can take an arbitrary amount of time to complete, an any animations or dynamic content will appear to hang until the animation completes or the dynamic content is obscured. But you're right that it would be required in order for this technique to work at all. I've managed to implement a full screen animation which allows the non-full-screen content to continue live during the full screen animation, but it relies on hardware acceleration and required a large number of intrusive changes to the rendering engine. Creating a new viewport for the full-screen content would serve the same purpose, and it would solve the z-index issue as well. Resizing the full-screen viewport wouldn't affect the layout of the non-full-screen content, allowing for efficient animation of just the full-screen element and its children. 3. fullscreenchange events and their targets. The current proposal states that a fullscreenchange event must be dispatched when a document enters or leaves full-screen. Additionally, when the event is dispatched, if the document's current full-screen element is an element in the document, then the event target is that element,
Re: [whatwg] Remove maxWidth from fillText and strokeText
On Sun, 13 Feb 2011, Charles Pritchard wrote: Could we remove the optional maxWidth parameter from fillText and strokeText of CanvasRenderingContext2D. I don't see them in use anywhere, they're not widely implemented, and I don't see them fitting any particular common purpose. Their intent is to ensure that when you have a specific amount of space in which text has to fit, and you don't know exactly what that space is or you don't know exactly what the text is, you can easily work around minor cases of limited space. For example, I use it on the issues chart: http://www.whatwg.org/issues/data.html The labels on the bottom have to fit in a variable amount of space depending on how many months are showing, and the labels on the left have to fit in a fixed amount of space but their length varies on the peak of the graph in the current view. fillText(this very long strong, maxWidth) does not ensure any kind of readability of the text. Sure, it's limited to cases where the amount of space varies only a little from the original expectation, or for where the strings to be drawn vary only a little from the original expectation, but that's actually a pretty common situation. For example, in the example above the strings are only going to be in the range of 1 to, at most, 5 digits (let's hope it never gets there). When the variance is much bigger, you can't rely on just squeezing the text, you need something more clever. Authors can use measureText to achieve the same effect, with more flexibility and better exposure to the actual size of the font that will be used. Yes, you can do it manually if your needs aren't met by the API. They can use clip() if they need to ensure glyphs stay within a bounding box (something which maxWidth does not provide, despite its intent. It's not intended for clipping. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for canvas src to allow images with structured fallback
On Wed, 2 Mar 2011, Tab Atkins Jr. wrote: img was designed in a broken manner, as it is a purely visual element with no way for non-sighted users, such as blind people or search engines, to view its contents. To fix this issue, @alt was added to img, to provide a textual alternative to the image. @alt is fine for images with simple textual equivalents, but some images are complex and can't be easily described in a single unstructured paragraph. For example, a complex graph may be best represented in textual form by presenting the data used to generate it in the form of a table. To fix this, @longdesc was added, which is a link to another page with a longer, and possibly structured, alternative representation of the image. This has several problems, however. First, data shows that many users of @longdesc don't realize that the value of the attribute should be a link to a page representing the longer description, and instead either point it to the embedding page or the image itself, or just fill it with nonsense. Second, the fact that the long description is a separate page means that it's possible that the linkage can be broken if the server is reorganized or the url structure of the site is altered, or if the code containing the img is copypasted between pages. Since the long description is not presented at all in all major visual user-agents, a breakage can go a long time before being detected. There's also a third problem, which is that this information, if useful to people who can't see the image, is usually _also_ useful to people who _can_ see the image. As such, the simplest solution is just to provide the information right there next to the image. 4. Some other elements, such as object and video, have conceptually similar issues, where they want to present alternative content in case their main content is unusable or unrecognized. These elements encode the fallback content as direct descendants, hiding them when they're not necessary. 5. The canvas element's situation is *directly* analogous, as canvas represents an image, and contains textual/structured alternative content as descendants. The problems with @longdesc described in #3 are not present in canvas - the descendants are clearly alternative content, and travel inline with the element, making them immune to linkrot. Actually canvas' fallback isn't quite the same as object's: it's still active even when the canvas is shown. You can tab into the canvas element's fallback content, screen readers render the fallback while letting the user interact with the image, etc. It's not fallback, like with object, or a description, like with longdesc=; it's a layer on top of the canvas, that just augments it. It thus seems that canvas represents a strictly better alternative to img when structured accessibility fallback content is required, except for one problem - canvas can only be scripted. It's not really fallback at all. I suggest that we can retain all the benefits of canvas over img longdesc while avoiding the above problem by adding an optional @src attribute to canvas. If present, the image linked by the attribute is loaded and drawn into the canvas automatically, without any script intervention required. canvas would then fire the same events that img currently does and generally expose the same API, in addition to the current canvas API. It would be used like: canvas src=complex-chart.png table -data that the chart represents- /table /canvas This seems exactly equivalent to: object data=complex-chart.png table -data that the chart represents- /table /object ...except that in the former case, the accessibility APIs would be quite confused since they would let visually impaired (but not blind) users navigate a table that wasn't displayed. On Fri, 4 Mar 2011, Tab Atkins Jr. wrote: On Thu, Mar 3, 2011 at 6:29 AM, Anne van Kesteren ann...@opera.com wrote: Why not use object? It already works and avoids overloading canvas for something it was not designed for. object doesn't expose image APIs like the 'complete' event. Sure it does; it fires a 'load' event once the resource is loaded. It doesn't have the .complete IDL attribute that HTMLImageElement does, but then nor does canvas. We could add it to object if it's really that useful. Also, it takes arbitrary content, not just images, so you can't use it to contain user-supplied urls. canvas doesn't currently take any URLs. What user-supplied URLs are you expecting to display that have structured fallback content? Surely if you can sanitise the fallback you can sanitise the URL as well. Finally, object has bad interactivity behavior - if you drop SVG into object, the SVG will swallow any clicks, while SVG-in-img doesn't. If you drop SVG into canvas, it'll presumably lose any interactivity whatsoever, which seems even
Re: [whatwg] Canvas and drawWindow
On Fri, 11 Mar 2011, Erik M�ller wrote: I bet this has been discussed before, but I'm curious as to what people think about breathing some life into a more general version of Mozillas canvas.drawWindow() that draws a snapshot of a DOM window into the canvas? This is something that is rife with serious security concerns: exposing history, the potential for cross-origin data leakage, introspecting spelling-checker user dictionaries, inspecting data that is otherwise hidden such as user theme preferences or file input paths... This is not something to undertake lightly. Even if we found a way to actually determine when to taint a drawn image, we could never allow such data to be uploaded to a server or reused in WebGL (due to the shader timing attacks). And working out when something has any cross-origin pixels is vastly more complicated than it appears. CSS reflections, SVG transforms, fonts, iframes, the CSS 'content' property... the list of possible ways one could taint something is absurdly high. This is an area where more than ever I think browsers will have to lead by experimentation. If a solid safe solution can be figured out and that everyone is willing to implement, meaning one that doesn't involve laundry lists of things to test for or risk a whack-a-mole race, then I'd be happy to specify it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
