Re: [whatwg] api for fullscreen()
Brian Campbell writes: 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. Why is that a problem? 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. If the user wants the content to be large, why would he withhold permission? As I understand it, the risk with full-screen view is that a malicous site may spoof browser chrome, such as the URL bar, thereby tricking a user who isn't aware the site is full-screen. So these scenarios seem relevant: 1 A malicious site wishes to switch to full-screen view and spoof chrome. The user hadn't asked for full-screen, so withholds permission. The site may at this point refuse to display content as you put it, but since that content's only purpose is to trick the user, its non-display is a good thing. 2 A user wishes to display some content full-screen, so grants permission and views it. 3 A user doesn't wish to display some content full-screen, so ignores any attempt by the site to become full-screen, and continues to view it normal size. I'm struggling to come up with a scenario in which your concerns apply. Please could you elaborate. Thanks. Smylers -- Watch fiendish TV quiz 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/programmes/b00lskhg
[whatwg] Notification API
I noticed that there's a Chromium-specific API for notifications: http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification Opera has an Opera Widgets-specific API: http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#wo_showNotification What's the right mailing list for discussing notification APIs? Since the right people are likely reading this list: It seems to me that it would be desirable to have an API that authorized Web apps can use to post notifications to Growl (Mac) or NotifyOSD (Ubuntu). HTML notifications look like an overkill to me. It seems to me that Growl and NotifyOSD notifications have these things in common: 1) Title 2) Description 3) Icon 4) Ability to find out if the user clicked the notification. (Not yet in Karmic?) To map that to a really simply Web API, a single method with four arguments could be added to the navigator object. The arguments would be: 1) DOMString title (required) 2) DOMString description (optional, LF means rendered line break) 3) DOMString iconURL (optional, defaults to the favicon of the root browsing context of the script invoking the API) 4) function acknowledgement (optional, callback that is called if the user clicks the notification; clicking should always bring the window/tab of the page that invoked the notification to front) Does Chromium have use cases for HTML notifications that wouldn't be addressed by the simpler API outlined above? Does Opera have a reason for not allowing an icon and two distinct strings in notifications? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Notification API
On Wed, Feb 3, 2010 at 12:55, Henri Sivonen hsivo...@iki.fi wrote: It seems to me that Growl and NotifyOSD notifications have these things in common: 4) Ability to find out if the user clicked the notification. (Not yet in Karmic?) You can't click on a NotifyOSD notification by design. It's supposed to disappear or become translucent when you hover over it, so you can click behind it. -- Remco
[whatwg] Canvas size and double buffering.
Hi, I've been trying to use the HTML5 canvas to implement a slippy map. It works ( http://concentriclivers.com/ ), but there were a couple of issues I had for which there seems to be no good solution. 1. You can only set the size exactly in pixels. It is very hard to get a resizable canvas that fills the page. You *can* set the size in CSS, but it doesn't work very well (e.g. using left,right-margin: auto; to centre the canvas doesn't work. Also it scales the canvas rather than resizes it. 2. There doesn't appear to be any kind of double buffering capability. This is pretty critical for animations where you might need to clear the canvas and then draw stuff. You currently get flickering if you try. As for solutions I propose: 1. Allow width=20%, 3em, and so on. The pixel size is then decided by the device, but it's very easy to query it in javascript (all the examples I've seen do this anyway). CSS sizes should definitely resize the canvas rather than scale it. 2. Add a .flipBuffers() method, and either make all canvases double buffered, or add a 'doublebuffered' tag attribute (which would be more backwards compatible). Tim
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 9:05 AM, Tim Hutt wrote: 1. You can only set the size exactly in pixels. It is very hard to get a resizable canvas that fills the page. You *can* set the size in CSS, but it doesn't work very well (e.g. using left,right-margin: auto; to centre the canvas doesn't work. Also it scales the canvas rather than resizes it. That's right, because resizing the canvas (as in, changing the number of pixels in the backing store) involves clearing it at the moment. Your proposal would mean that if the user changes the window size your canvas will immediately get cleared. Is that what you're after? If not, how do you envision the backing-store resize being performed? 2. There doesn't appear to be any kind of double buffering capability. This is pretty critical for animations where you might need to clear the canvas and then draw stuff. You currently get flickering if you try. You do? Under what circumstances? At least in Gecko, run-to-completion means that while you script is running the canvas won't be painted. What UAs are you seeing flicker in, and under what circumstances? -Boris
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 7:59 AM, Boris Zbarsky wrote: On 2/3/10 9:05 AM, Tim Hutt wrote: 1. You can only set the size exactly in pixels. It is very hard to get a resizable canvas that fills the page. You *can* set the size in CSS, but it doesn't work very well (e.g. using left,right-margin: auto; to centre the canvas doesn't work. Also it scales the canvas rather than resizes it. That's right, because resizing the canvas (as in, changing the number of pixels in the backing store) involves clearing it at the moment. Your proposal would mean that if the user changes the window size your canvas will immediately get cleared. Is that what you're after? If not, how do you envision the backing-store resize being performed? Canvas drawing should have been callback-based from the start. Maybe we can retrofit this by having a way the author can specify that the canvas backing store resizes with the element, and firing an event when the backing store size changes. 2. There doesn't appear to be any kind of double buffering capability. This is pretty critical for animations where you might need to clear the canvas and then draw stuff. You currently get flickering if you try. You do? Under what circumstances? At least in Gecko, run-to-completion means that while you script is running the canvas won't be painted. What UAs are you seeing flicker in, and under what circumstances? Same with WebKit. As long as you clear and redraw at the same time, there should not be flicker. Simon
Re: [whatwg] Notification API
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. Thanks, -John On Wed, Feb 3, 2010 at 3:55 AM, Henri Sivonen hsivo...@iki.fi wrote: I noticed that there's a Chromium-specific API for notifications: http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification Opera has an Opera Widgets-specific API: http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#wo_showNotification What's the right mailing list for discussing notification APIs? Since the right people are likely reading this list: It seems to me that it would be desirable to have an API that authorized Web apps can use to post notifications to Growl (Mac) or NotifyOSD (Ubuntu). HTML notifications look like an overkill to me. It seems to me that Growl and NotifyOSD notifications have these things in common: 1) Title 2) Description 3) Icon 4) Ability to find out if the user clicked the notification. (Not yet in Karmic?) To map that to a really simply Web API, a single method with four arguments could be added to the navigator object. The arguments would be: 1) DOMString title (required) 2) DOMString description (optional, LF means rendered line break) 3) DOMString iconURL (optional, defaults to the favicon of the root browsing context of the script invoking the API) 4) function acknowledgement (optional, callback that is called if the user clicks the notification; clicking should always bring the window/tab of the page that invoked the notification to front) Does Chromium have use cases for HTML notifications that wouldn't be addressed by the simpler API outlined above? Does Opera have a reason for not allowing an icon and two distinct strings in notifications? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 16:50, Simon Fraser s...@me.com wrote: On Feb 3, 2010, at 7:59 AM, Boris Zbarsky wrote: On 2/3/10 9:05 AM, Tim Hutt wrote: 1. You can only set the size exactly in pixels. It is very hard to get a resizable canvas that fills the page. You *can* set the size in CSS, but it doesn't work very well (e.g. using left,right-margin: auto; to centre the canvas doesn't work. Also it scales the canvas rather than resizes it. That's right, because resizing the canvas (as in, changing the number of pixels in the backing store) involves clearing it at the moment. Your proposal would mean that if the user changes the window size your canvas will immediately get cleared. Is that what you're after? If not, how do you envision the backing-store resize being performed? Canvas drawing should have been callback-based from the start. Maybe we can retrofit this by having a way the author can specify that the canvas backing store resizes with the element, and firing an event when the backing store size changes. Yes it should be cleared and there should be a oncanvasresize() callback. 2. There doesn't appear to be any kind of double buffering capability. This is pretty critical for animations where you might need to clear the canvas and then draw stuff. You currently get flickering if you try. You do? Under what circumstances? Ahem, I was sure I got flickering, but I just tested firefox 3.5 and chrome 4 and actually they do behave as you describe. Tim
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 12:22 PM, Tim Hutt wrote: Yes it should be cleared and there should be a oncanvasresize() callback. What uses cases does this cover that are not covered by a general resize event? -Boris
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 1:01 PM, Tim Hutt wrote: Good point, it would be better to call it 'onresize' for consistency. So my revised suggestion is: 1. Support more length specifiers for the width and height of a canvas(%, em, etc.). 2. Add an onresize event to the canvas tag. When the canvas is resized it is reset and this event is fired. 3. CSS size specifiers resize rather than scale the canvas. I.e. it should always be that 1 unit = 1 pixel initially. #3 would break existing canvas content. #2 would work if all elements supported onresize (as has been proposed), right? Given that, a resize handler could simply reset the canvas width/height attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? Hence my question: what use cases here would not be covered simply by having a general resize event on all elements? -Boris
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 17:45, Boris Zbarsky bzbar...@mit.edu wrote: On 2/3/10 12:22 PM, Tim Hutt wrote: Yes it should be cleared and there should be a oncanvasresize() callback. What uses cases does this cover that are not covered by a general resize event? Good point, it would be better to call it 'onresize' for consistency. So my revised suggestion is: 1. Support more length specifiers for the width and height of a canvas(%, em, etc.). 2. Add an onresize event to the canvas tag. When the canvas is resized it is reset and this event is fired. 3. CSS size specifiers resize rather than scale the canvas. I.e. it should always be that 1 unit = 1 pixel initially.
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 10:01 AM, Tim Hutt wrote: On 3 February 2010 17:45, Boris Zbarsky bzbar...@mit.edu wrote: On 2/3/10 12:22 PM, Tim Hutt wrote: Yes it should be cleared and there should be a oncanvasresize() callback. What uses cases does this cover that are not covered by a general resize event? Good point, it would be better to call it 'onresize' for consistency. So my revised suggestion is: 1. Support more length specifiers for the width and height of a canvas(%, em, etc.). This doesn't really make sense for the backing buffer as it is logically defined in terms of pixel. 2. Add an onresize event to the canvas tag. When the canvas is resized it is reset and this event is fired. We actually need this for webgl as well. 3. CSS size specifiers resize rather than scale the canvas. I.e. it should always be that 1 unit = 1 pixel initially. This would break content
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 19:23, Oliver Hunt oli...@apple.com wrote: 1. Support more length specifiers for the width and height of a canvas(%, em, etc.). This doesn't really make sense for the backing buffer as it is logically defined in terms of pixel. The layout engine would decide how many pixels big it is, in exactly the same way that it decides how big to draw a image that has width specified in non-pixel units. 2. Add an onresize event to the canvas tag. When the canvas is resized it is reset and this event is fired. We actually need this for webgl as well. 3. CSS size specifiers resize rather than scale the canvas. I.e. it should always be that 1 unit = 1 pixel initially. This would break content On 3 February 2010 18:07, Boris Zbarsky bzbar...@mit.edu wrote: #3 would break existing canvas content. True, but: a) Otherwise width:100% in CSS and width=100% in HTML would have different meanings. Confusing! b) Nobody uses it currently anyway - there's no content to break! I'm not exaggerating - look through canvasdemos.com and I bet you won't find a single case where the canvas is sized using CSS, for the very reasons I have given, specifically: c) It's slow, and looks rubbish. I suppose an alternative might be to have some way of retrieving the true size of the canvas, then you could do something like: canvas.width = canvas.trueWidthInPixels; #2 would work if all elements supported onresize (as has been proposed), right? Given that, a resize handler could simply reset the canvas width/height attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? Hence my question: what use cases here would not be covered simply by having a general resize event on all elements? Well, yes it would be good to have onresize for all elements. But you still need to add width=...% support to the canvas tag otherwise it will never *be* resized, so you couldn't achieve #1 with #2. I may have misunderstood you here.
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 2:54 PM, Tim Hutt wrote: a) Otherwise width:100% in CSS and width=100% in HTML would have different meanings. Confusing! I'm not suggesting that. I'm saying we keep supporting only integers in the width attribute and if you put width:100% in your CSS and the canvas resizes you can do whatever you want (change the width attribute or not, whatever you want). b) Nobody uses it currently anyway - there's no content to break! I'm not exaggerating - look through canvasdemos.com and I bet you won't find a single case where the canvas is sized using CSS And no UA stylesheets? No user stylesheets? No non-demo things actually using canvas for something? I actually have a hard time believing this, honestly. c) It's slow, and looks rubbish. While true, repainting the whole canvas from scratch on resize is not likely to be faster. And will look like rubbish by default (as in, look blank) unless the author writes script to make it otherwise. If the author is writing such script it's two extra line to set the canvas size too. I suppose an alternative might be to have some way of retrieving the true size of the canvas Like getBoundingClientRect()? canvas.width = canvas.trueWidthInPixels; Yep. canvas.width = canvas.getBoundingClientRect().width; Well, yes it would be good to have onresize for all elements. Which is why it's being worked on anyway. But you still need to add width=...% support to the canvas tag otherwise it will never *be* resized, so you couldn't achieve #1 with #2. I may have misunderstood you here. You put the % sizing in your CSS and reset the canvas width/height attributes if you want to. -Boris
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 Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan rob...@ocallahan.orgwrote: 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. The spec states that HTML is an optional part of the implementation. If the UA intends to use a presentation system that doesn't support HTML it should not expose the HTML API and just expose the plain one. This isn't ideal as it requires authors to check the capabilities of the UA, but it does provide consistency for the user. -John
Re: [whatwg] Notification API
BTW, I would highly recommend that we move this conversation to the public-webapps list. I'm not sure about the best way to do this other than to stop posting here, starting...um...right after my reply :) Anyhow, your question below outlines is why there are two exposed notification APIs - one is simple, lowest-common-denominator text + icon notifications (createNotification()), and the other is HTML (createHTMLNotification()). Platforms (such as mobile devices) that can't support popup HTML notifications can just not expose the createHTMLNotification attribute. Likewise, if the user on a given system just wants to force everyone to use text + icon notifications because he finds the mix of (say) Growl and HTML notifications jarring, then the UA could provide an option for that (which would cause the UA to not expose the createHTMLNotification attribute). -atw On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan rob...@ocallahan.orgwrote: 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] api for fullscreen()
On Feb 3, 2010, at 5:04 AM, Smylers wrote: Brian Campbell writes: 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. Why is that a problem? 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. If the user wants the content to be large, why would he withhold permission? A user may want to view the content scaled up to the full size of the window, without it being full-screen. As I understand it, the risk with full-screen view is that a malicous site may spoof browser chrome, such as the URL bar, thereby tricking a user who isn't aware the site is full-screen. This is addressing a different scenario; not malicious sites per-se, but sites that insist on being displayed full screen. So these scenarios seem relevant: 1 A malicious site wishes to switch to full-screen view and spoof chrome. The user hadn't asked for full-screen, so withholds permission. The site may at this point refuse to display content as you put it, but since that content's only purpose is to trick the user, its non-display is a good thing. 2 A user wishes to display some content full-screen, so grants permission and views it. 3 A user doesn't wish to display some content full-screen, so ignores any attempt by the site to become full-screen, and continues to view it normal size. I'm struggling to come up with a scenario in which your concerns apply. Please could you elaborate. Thanks. Sure. At my previous job, I wrote immersive interactive educational multimedia. My boss was very insistent about content being displayed full screen, to make the experience more immersive and reduce distractions (given the content, this wasn't unreasonable; there were parts that were time-critical simulations in which you wouldn't want to be distracted part way through by a chat window popping up). Had we been developing for the web, I could imagine him asking us to start with something that said Please press the button to enter full-screen mode and start the program, and the program would not start until full-screen mode was entered. I could imagine games, and other content doing the same as well. I think that this behavior is fairly user hostile, however. There are some times when a user really doesn't want his entire screen filled, for a good reason. If there is content that won't start until the fullscreen event has fired, or fullscreen pseudo-class has been applied, then that user has no choice but to skip that content or allow it to enter fullscreen mode. Another scenario applies to most video player sites. Almost all video player sites using Flash have a full screen button. Many of them do not have a full window button, however. If a user wishes to view content scaled up to fill the window, without the distractions of navigational links, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content. In short, there are several scenarios in which certain functionality in a web content is not available unless you enter fullscreen mode. Content authors should not be able to force fullscreen mode on users, however, so I think it would be best if the spec allows UAs to send the fullscreen event and set the fullscreen pseudoclass even if the content is not actually filling the entire screen. How exactly the UAs implement this is up to them, though I would recommend scaling the content up to the full window and sending the fullscreen events immediately, if they are waiting for permission to scale to fill the full screen. All the spec would have to say to cover all of the possible implementations is that the fullscreen events may be sent even if the content isn't actually filling an entire screen, and that the screen size may be changed even if you are already in fullscreen mode (which would need to be the case anyhow, since you may change the resolution of the screen when attaching a projector, or for devices in which the screen can rotate). Does this make it any clearer? -- Brian
Re: [whatwg] Notification API
On Wed, Feb 3, 2010 at 1:00 PM, John Gregg john...@google.com wrote: On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org wrote: 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. The spec states that HTML is an optional part of the implementation. If the UA intends to use a presentation system that doesn't support HTML it should not expose the HTML API and just expose the plain one. This isn't ideal as it requires authors to check the capabilities of the UA, but it does provide consistency for the user. This is a very bad idea. Sites are going to forget to do this, or rather not know that they need to do this. At some point a high-profile site is going to not do this check, and from that point on all UAs will effectively be forced to support HTML notifications or not be compatible with the web. I can't think of a single time when optional web features have succeeded. / Jonas
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote: On 3 February 2010 19:23, Oliver Hunt oli...@apple.com wrote: 1. Support more length specifiers for the width and height of a canvas(%, em, etc.). This doesn't really make sense for the backing buffer as it is logically defined in terms of pixel. The layout engine would decide how many pixels big it is, in exactly the same way that it decides how big to draw a image that has width specified in non-pixel units. But that's css scaling the image, which is what currently happens with canvas: the natural width/height of the canvas is specified and is used as the default css size. 3. CSS size specifiers resize rather than scale the canvas. I.e. it should always be that 1 unit = 1 pixel initially. This would break content On 3 February 2010 18:07, Boris Zbarsky bzbar...@mit.edu wrote: #3 would break existing canvas content. True, but: a) Otherwise width:100% in CSS and width=100% in HTML would have different meanings. Confusing! width=100% makes no sense for canvas as it means you're no longer specifying the size of the backing buffer, which is inherently pixel based. b) Nobody uses it currently anyway - there's no content to break! I'm not exaggerating - look through canvasdemos.com and I bet you won't Because canvasdemos.com is the only site in the world that uses canvas. find a single case where the canvas is sized using CSS, for the very reasons I have given, specifically: c) It's slow, and looks rubbish. This sounds like you want SVG not canvas -- by definition canvas is a bitmap, scaling behaviour is identical to scaling of an image. I suppose an alternative might be to have some way of retrieving the true size of the canvas, then you could do something like: canvas.width = canvas.trueWidthInPixels; #2 would work if all elements supported onresize (as has been proposed), right? Given that, a resize handler could simply reset the canvas width/height attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? Hence my question: what use cases here would not be covered simply by having a general resize event on all elements? Well, yes it would be good to have onresize for all elements. But you still need to add width=...% support to the canvas tag otherwise it will never *be* resized, so you couldn't achieve #1 with #2. I may have misunderstood you here. The onresize event would fire on the css size changing, not the canvas resolution changing -- size != resolution. --Oliver
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote: On 3 February 2010 19:23, Oliver Hunt oli...@apple.com wrote: 1. Support more length specifiers for the width and height of a canvas(%, em, etc.). This doesn't really make sense for the backing buffer as it is logically defined in terms of pixel. The layout engine would decide how many pixels big it is, in exactly the same way that it decides how big to draw a image that has width specified in non-pixel units. But that's css scaling the image, which is what currently happens with canvas: the natural width/height of the canvas is specified and is used as the default css size. 3. CSS size specifiers resize rather than scale the canvas. I.e. it should always be that 1 unit = 1 pixel initially. This would break content On 3 February 2010 18:07, Boris Zbarsky bzbar...@mit.edu wrote: #3 would break existing canvas content. True, but: a) Otherwise width:100% in CSS and width=100% in HTML would have different meanings. Confusing! width=100% makes no sense for canvas as it means you're no longer specifying the size of the backing buffer, which is inherently pixel based. b) Nobody uses it currently anyway - there's no content to break! I'm not exaggerating - look through canvasdemos.com and I bet you won't Because canvasdemos.com is the only site in the world that uses canvas. find a single case where the canvas is sized using CSS, for the very reasons I have given, specifically: c) It's slow, and looks rubbish. This sounds like you want SVG not canvas -- by definition canvas is a bitmap, scaling behaviour is identical to scaling of an image. I suppose an alternative might be to have some way of retrieving the true size of the canvas, then you could do something like: canvas.width = canvas.trueWidthInPixels; #2 would work if all elements supported onresize (as has been proposed), right? Given that, a resize handler could simply reset the canvas width/height attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? Hence my question: what use cases here would not be covered simply by having a general resize event on all elements? Well, yes it would be good to have onresize for all elements. But you still need to add width=...% support to the canvas tag otherwise it will never *be* resized, so you couldn't achieve #1 with #2. I may have misunderstood you here. The onresize event would fire on the css size changing, not the canvas resolution changing -- size != resolution. --Oliver
Re: [whatwg] [hybi] Websocket algorithmic specification
Jamie Lokier wrote: Greg Wilkins wrote: send the following bytes to the remote server 47 45 54 20 A literal reading of the spec would interpret that as meaning that the bytes actually have to be sent, while any sane implementation is going to append the bytes to a buffer to be sent/flushed sometime later. Does this mean that ws server could validly reject a handshake as non compliant if these bytes arrived in the same packet as the subsequent bytes? No, because TCP does not preserve write boundaries. I know that... you know that. but will the script kiddie trying his hand at writing his own server know that? Anyway, I think the point is moot, as Ian has been adding text to the spec (in imperative voice :) to specify what send means. cheers
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 3:14 PM, Boris Zbarsky wrote: On 2/3/10 2:54 PM, Tim Hutt wrote: Well, yes it would be good to have onresize for all elements. Which is why it's being worked on anyway. I'm curious; where is this being worked on? Discussed here on this list? On another list? Or is it just being implemented by some browser vendors independently? I don't see discussion of it recently on this list, so I'm curious as to where the discussion would be; there seem to be a lot of lists in a lot of places these days for discussing various bits of browser standards, and it's hard to figure out what goes where. For core HTML the DOM, there's this group, public-html at the W3C, and public-webapps at the W3C; am I missing any? There's also the Device API groups which seems to overlap the domain of the webapps group quite a bit. There are of course the more clearly delineated groups, such as es-discuss, www-style, SVG, MathML, and the like, but I sometimes find it a bit hard to figure out where I should look for discussion about HTML and the HTML DOM because it's spread out over several lists which don't seem like they have clear boundaries. Has anyone written up an explanation of where to look for what? -- Brian
Re: [whatwg] Notification API
Apps on the iphone using SQL data storage might disagree with you about the value of optional web features :) But I do understand your point, and perhaps there's a better way to achieve the goals of the notification API. The goals as I understand them are: 1) Support simple text + icon notifications on devices that are unable to support full HTML notifications (I'm thinking of mobile devices specifically, such as the Palm Pre which exposes a similar JS notification API, but some system notification frameworks also fall under this category). 2) Allow more full-featured HTML notifications on the overwhelming majority of platforms that support them. 3) Give web applications the ability to tell whether a given UA supports HTML notifications so they can choose not to display any notification at all if the system does not support HTML. A corollary to #3 may be that a given UA could make it possible for the user to disable HTML notifications even though they would theoretically be possible to support on that platform, if it is believed that there are user benefits to only allowing text + icon notifications on that specific installation (e.g. tighter integration with system notification frameworks). It's possible that Goal #3 is unimportant, or that it could be satisfied through some other mechanism (like a capabilities attribute? ick?) - if so, then it seems like an option to fold createNotification() and createHTMLNotification() together by adding an optional htmlUrl parameter to createNotification() which would be ignored on systems that don't want to display HTML notifications. -atw On Wed, Feb 3, 2010 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 3, 2010 at 1:00 PM, John Gregg john...@google.com wrote: On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org wrote: 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. The spec states that HTML is an optional part of the implementation. If the UA intends to use a presentation system that doesn't support HTML it should not expose the HTML API and just expose the plain one. This isn't ideal as it requires authors to check the capabilities of the UA, but it does provide consistency for the user. This is a very bad idea. Sites are going to forget to do this, or rather not know that they need to do this. At some point a high-profile site is going to not do this check, and from that point on all UAs will effectively be forced to support HTML notifications or not be compatible with the web. I can't think of a single time when optional web features have succeeded. / Jonas
Re: [whatwg] api for fullscreen()
Another scenario applies to most video player sites. Almost all video player sites using Flash have a full screen button. Many of them do not have a full window button, however. If a user wishes to view content scaled up to fill the window, without the distractions of navigational links, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content. I don't agree that this behaviour is not expected. Many kinds of full-screen applications (web/Flash or otherwise) require that they are run at the highest window level for the reasons you mentioned (distractions, time-sensitive response; a web-based IDE like Bespin could, with a full-screen mode, become a WriteRoom equivalent for the web). Imagine an educational website where the page gives the user a passage of text then asks to go full-screen to perform an examination on that material; having the ability to have other windows open concurrently defeats the purpose of the application. I feel that the user shouldn't have the ability to enter into some sort of pseudo-fullscreen. If the content needs to be displayed full-screen, a user denying the application access to that full-screen capability is a user who does not wish to engage with that application as designed. When it comes to the user wishing to view content scaled up to fill the window, that's functionality we can already provide and should continue to be the onus of the site's developer if the content is suitable for that kind of consumption (YouTube already has a similar mode, for example). The advantage to removing that sort of ambiguity is that the page can be clever about how or when it offers fullscreen modes. If, inspecting the window.screen object, the developer determines that the user's screen is not sufficiently large to display his or her game in fullscreen (e.g. on a mobile device), he or she can choose to not show a fullscreen button, ensuring that all UI elements of the game are accommodated. If the user's screen is large, but they choose to reject the application's wishes to go fullscreen, the game may not fit (in fullscreen mode) in the browser window. I think that this behavior is fairly user hostile, however. There are some times when a user really doesn't want his entire screen filled, for a good reason. If there is content that won't start until the fullscreen event has fired, or fullscreen pseudo-class has been applied, then that user has no choice but to skip that content or allow it to enter fullscreen mode. If the user does not wish to view the content in full-screen and the developer feels that content can only be reasonably viewed full-screen, I feel the user has opted not to view that content at all. I don't mind at all that the user has no choice but to skip that content; it's similar behaviour to a user quitting a desktop application that insists on running full-screen. —Kit
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 5:27 PM, Brian Campbell wrote: I'm curious; where is this being worked on? Discussed here on this list? On another list? I believe it's been discussed on public-webapps. It's also implemented in IE, to some extent. -Boris
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 20:14, Boris Zbarsky bzbar...@mit.edu wrote: Yep. canvas.width = canvas.getBoundingClientRect().width; Ah yes that works nicely, with one minor caveat: it seems to include the width of the border if there is one, so you have to take that into account. You're right, this is a better solution. Cheers.
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 6:12 PM, Tim Hutt wrote: Ah yes that works nicely, with one minor caveat: it seems to include the width of the border if there is one, so you have to take that into account. You're right, this is a better solution. Ah, yes. Padding too. You could instead ask for the computed style width, but I'm not sure whether that does what it does in Gecko (return the actual used width) in all browsers. It might be good to create some APIs to query these sorts of box properties. Anne, are you on this list, by chance? ;) -Boris
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] Notification API
On Wed, Feb 3, 2010 at 3:18 PM, Robert O'Callahan rob...@ocallahan.org wrote: 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? Additionally, how full fledged HTML are we talking? Do you want script to be running in the notification? Should forms work? Plugins? HTML is a very powerful format, not really the best choice if all you need is some basic text formatting. / Jonas
Re: [whatwg] Notification API
On Wed, Feb 3, 2010 at 3:25 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 3, 2010 at 3:18 PM, Robert O'Callahan rob...@ocallahan.org wrote: 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? Additionally, how full fledged HTML are we talking? Do you want script to be running in the notification? Should forms work? Plugins? HTML is a very powerful format, not really the best choice if all you need is some basic text formatting. I was about to comment, but then I realized this is all on the wrong alias (whatwg instead of public-webapps) as Drew pointed out a little earlier. dave
Re: [whatwg] Canvas size and double buffering.
On 3 February 2010 23:16, Boris Zbarsky bzbar...@mit.edu wrote: On 2/3/10 6:12 PM, Tim Hutt wrote: Ah yes that works nicely Hmm maybe I spoke too soon. The interaction of the CSS size and the canvas.width/height is confounding! It seems if you set a CSS width of, say 80% then that is that and you are stuck with it. Unfortunately it doesn't round to the nearest pixel! I have created a test case here: http://concentriclivers.com/canvas.html (the source is nicely formatted and very short) If anyone can get it to work as described on that page, then thank you! Otherwise I think things need to be changed to make it possible.
Re: [whatwg] api for fullscreen()
Brian Campbell writes: As I understand it, the risk with full-screen view is that a malicous site may spoof browser chrome, such as the URL bar, thereby tricking a user who isn't aware the site is full-screen. This is addressing a different scenario; not malicious sites per-se, but sites that insist on being displayed full screen. OK. That's 'merely' an annoyance, not a security threat. There are lots of ways authors can be obnoxious if they choose; I'm not sure it's desirable, or even possible, to outlaw them. My boss was very insistent about content being displayed full screen, to make the experience more immersive and reduce distractions ... Please press the button to enter full-screen mode and start the program, and the program would not start until full-screen mode was entered. I could imagine games, and other content doing the same as well. I think that this behavior is fairly user hostile, however. In general user-agents are allowed to display content in anyway that a user has configured them to do, regardless of what the spec gives as the normal behaviour. If a user wishes to view content scaled up to fill the window, without the distractions of navigational links, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content. I've seen Firefox options (possibly in an extension) which allow users to tweak which toolbars and the like are still displayed when in full-screen view. If a browser (or an extension) wished to implement full-screen view as still having borders, the title bar, status bar, and so on then it could. And there's nothing an author could do about it. Content authors should not be able to force fullscreen mode on users, however, so I think it would be best if the spec allows UAs to send the fullscreen event and set the fullscreen pseudoclass even if the content is not actually filling the entire screen. To say that slightly differently: authors can dictate that certain output is only displayed when in full-screen view; but they have no control how full-screen view looks for a particular user and user-agent. All the spec would have to say to cover all of the possible implementations is that the fullscreen events may be sent even if the content isn't actually filling an entire screen, Allowing that behaviour is entirely reasonable. Though I think it should be covered by a more general statement that user-agents may display things however they want if so-configured, rather than just stating it for this particular narrow case. Smylers -- Watch fiendish TV quiz 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/programmes/b00lskhg
Re: [whatwg] Canvas size and double buffering.
On 2/3/10 7:00 PM, Tim Hutt wrote: http://concentriclivers.com/canvas.html (the source is nicely formatted and very short) So you want a canvas that takes 80% of the horizontal space but has an integer width in pixels? Which of those constraints do you really want to relax? Presumably the 80% one? -Boris
Re: [whatwg] Drag-and-drop feedback
On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. On Sat, 23 Jan 2010, Maciej Stachowiak wrote: The HTML5 drag-and-drop model (or rather, the IE drag-and-drop model that it is based on) doesn't really work for this case anyway, regardless of the copy/paste issue, since there doesn't seem to be any sane way to distinguish between an in-page drag and a drag to an external application such as a clipboard. If you can drag to a clipboard, I don't see why we would _disallow_ the copy/paste interaction. That sounds like a design flaw with the drag and drop model. One of many. Sounds like something to fix not something to compound with another design flaw. Fair enough. I've removed the copy/paste mode of drag-and-drop. I'll deal with the copy/cut/paste events separately. On Mon, 25 Jan 2010, Jian Li wrote: DownloadURL. The data associated with the DownloadURL format should be parsed similar to the URL format. When the drag ends in another application, the remote file described in the associated data URL should be downloaded and provided to the target application. How would this be exposed to other apps? Is it possible in Windows to drop something and then have the application that received the drop wait for a download (which could take hours) to complete? How does that work? On Windows, [...] we use the file stream to transfer the data between the source application and the target application and thus the target application will not be blocked if it uses a background thread (this is what Windows Shell does). On MacOSX, a file stream is also used for such purpose. However, we need to provide more metadata about the download when we call DataTransfer.setData(DownloadURL, ...). This is because on Windows we need to know about the file name and size when the drag is initiated. We can wait till we get the headers to extract the file name and size but this is blocking. Even more, if the http chunk mode is used, we cannot get the size from the headers. So how would you provide the file size? On MacOSX, we need to provide the mime type and file name. Could we consider adding mime type, file name and size information into the data value parameter of setData method? For example, dataTransfer.setData(DownloadURL, text/plain:1000:http://example.com/download.txt;); I think we should just have a promise mechanism rather than one hard-coded for URLs. But I think it's probably best for us to wait until we have the current spec implemented reliably and sanely before adding something like that. We don't even have a good test suite for the drag-and-drop API yet. On Mon, 25 Jan 2010, Michael Davidson wrote: The issue that I'm having is that if the DataTransfer object says that it has Files, I have no way to determine what type those files are. (In this case, I only want to accept image files.) I understand that the DataTransfer shouldn't have the content of the files for security reasons, but it would be helpful if it did contain the file names and/or MIME types. I could provide a second attribute with the types of the files, would that work? I suppose if we did this, we should remove the Files fake type. That might not be a bad idea in general, it's kind of a hack. I'm not sure how I feel about having multiple different ways of representing the data in a DataTransfer object... It would give a clean precedent for adding other features, though, like promises, which some people have requested. Multiple different ways to get the same info doesn't seem great, but it doesn't matter to me as long as the information is available. Another option is to throw an error if developers try to access forbidden attributes during dragenter/dragover. I haven't added this for now, because Firefox 3.6 already shipped with Files and I think it'd be better to get the API stablised on what's already specified before adding more (and since it's shipped, I'd rather not remove the existing features). However, what I think we should do in the next version (in a few months, maybe) is have a new way of exposing the data, as Eduard suggested, which has one item per thing in the data, and which in all but the dragstart and drop events only exposes the type information. I've noted this in a comment in the spec. On Sat, 23 Jan 2010, Daniel Cheng wrote: Formats are generally given by MIME types, with some values special-cased for legacy reasons. For the purposes of this API, however, the format strings are opaque, case-sensitive, strings, and the empty string is a valid format string. RFC 2616
Re: [whatwg] api for fullscreen()
On Feb 3, 2010, at 7:19 PM, Smylers wrote: Brian Campbell writes: As I understand it, the risk with full-screen view is that a malicous site may spoof browser chrome, such as the URL bar, thereby tricking a user who isn't aware the site is full-screen. This is addressing a different scenario; not malicious sites per-se, but sites that insist on being displayed full screen. OK. That's 'merely' an annoyance, not a security threat. There are lots of ways authors can be obnoxious if they choose; I'm not sure it's desirable, or even possible, to outlaw them. Annoyances can turn into security threats if they train the user to click through security questions without thinking. And actually, this can be a security issue as well. A malicious site could entice the user by offering some sort of desirable content (a movie or TV show, porn, a game), but only if the user allows it to go fullscreen with keyboard access. It could then wait until the user has been idle for a bit, and display something that looks like a standard login screen for the operating system in question. The user may then be enticed to enter their password without realizing it's still the full-screen site they were using and not a real login screen. As ROC points out, it may be impossible to completely avoid a malicious site detecting whether you are fullscreen, as it can detect when the content is at one of the standard screen sizes; but we can make it a bit more difficult, and less likely that the user will be used to sites that require full screen, by providing the user an easy way to display full screen content in a window. My boss was very insistent about content being displayed full screen, to make the experience more immersive and reduce distractions ... Please press the button to enter full-screen mode and start the program, and the program would not start until full-screen mode was entered. I could imagine games, and other content doing the same as well. I think that this behavior is fairly user hostile, however. In general user-agents are allowed to display content in anyway that a user has configured them to do, regardless of what the spec gives as the normal behaviour. Yes. As I said, most of this is a UA issue, not a spec issue. I just want to encourage a usage that does not wind up with content locked behind requiring you to enter an actual full screen mode. If a user wishes to view content scaled up to fill the window, without the distractions of navigational links, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content. I've seen Firefox options (possibly in an extension) which allow users to tweak which toolbars and the like are still displayed when in full-screen view. If a browser (or an extension) wished to implement full-screen view as still having borders, the title bar, status bar, and so on then it could. And there's nothing an author could do about it. Of course. Obviously, the UA gets the final say on how the content is displayed. I just want to encourage the UAs to have a mode that tells the application it's in fullscreen mode even if it really is not, and have that mode be easy to get into for the majority of users (thus, not depend on an extension or obscure configuration somewhere). Content authors should not be able to force fullscreen mode on users, however, so I think it would be best if the spec allows UAs to send the fullscreen event and set the fullscreen pseudoclass even if the content is not actually filling the entire screen. To say that slightly differently: authors can dictate that certain output is only displayed when in full-screen view; but they have no control how full-screen view looks for a particular user and user-agent. Yes, exactly. All the spec would have to say to cover all of the possible implementations is that the fullscreen events may be sent even if the content isn't actually filling an entire screen, Allowing that behaviour is entirely reasonable. Though I think it should be covered by a more general statement that user-agents may display things however they want if so-configured, rather than just stating it for this particular narrow case. Well, user agents may display things however they want, but I think it's worth pointing out that the events may not correspond to the time that the user actually gives permission to enter full screen mode, in those cases in which permission is required. Instead, content may be scaled to the full window and the events sent as soon as the button is pushed, and then the content resized to the actual full screen once permission has been granted. -- Brian
Re: [whatwg] Canvas size and double buffering.
On Feb 3, 2010, at 7:00 PM, Tim Hutt wrote: On 3 February 2010 23:16, Boris Zbarsky bzbar...@mit.edu wrote: On 2/3/10 6:12 PM, Tim Hutt wrote: Ah yes that works nicely Hmm maybe I spoke too soon. The interaction of the CSS size and the canvas.width/height is confounding! It seems if you set a CSS width of, say 80% then that is that and you are stuck with it. Unfortunately it doesn't round to the nearest pixel! I have created a test case here: http://concentriclivers.com/canvas.html (the source is nicely formatted and very short) If anyone can get it to work as described on that page, then thank you! Otherwise I think things need to be changed to make it possible. That example: * Works for me in Chrome (5.0.307.1 dev, all browsers listed are on Mac OS X 10.6.2). * Works in Safari (WebKit nightly 6531.21.10, r54122) except for when you cause a scroll bar to appear or disappear by resizing; then you get a moiré pattern in the vertical stripes until you resize again. It appears that you get the resize event before the scrollbar appears, so the scrollbar appearing causes the canvas to scale down without sending a resize event allowing the canvas to redraw. * Doesn't work in Firefox (3.6). At most sizes, you get grey lines, due to the non-integral width; only occasionally does it look correct. Also, the canvas always resizes to a square; does Firefox try to preserve the aspect ratio when scaling a canvas in one dimension only? * Fails badly in Opera (10.10). It fails to redraw because width and height aren't defined on the BoundingClientRect; just left, right, top, and bottom. For some reason it also ignores the 500px height of the canvas given in the HTML, instead using the default of 300x150, with the width overridden to 80%. 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? 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). -- Brian
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]
