Re: [whatwg] Adding blending to the canvas API
On Wed, Apr 11, 2012 at 4:05 PM, Rik Cabanier wrote: > All, > > I'm working on a spec to add blending and compositing through simple CSS > keywords. It is trying to define a generic model that is not specific to > Canvas, HTML or SVG and then lists how the model could be implemented. > We've gotten some comments that this feature would be useful in Canvas as > well so I was wondering if it made sense to add it to the canvas API. > > I can see 2 ways of adding this: > 1. extend the list of compositing operators ( > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#compositing > ) > with blending. This is what is currently in the draft spec ( > https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html chapter 7) > > 2. create a new attribute on the context called 'globalBlendOperation' that > takes the same list of blend operations as css ( > https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blend-mode) > > Any thoughts? > This seems much more useful than the existing composite operations :)
Re: [whatwg] Canvas v5 API additions
On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp wrote: > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson wrote: > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote: >> > >> > I'd like to draw non-antialiased lines in a . Currently it seems >> > that the only way to do this is to directly access the pixel data. >> > >> > Is there a reason there's no way to turn off antialiasing? >> >> What's the use case? >> > > Pixel-art style games. > Specifically: even with the new image smoothing stuff in place for drawImage, a 1:2 diagonal line will still be anti-aliased (only the antialiasing will look silly scaled up to 2x).
Re: [whatwg] Canvas v5 API additions
On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson wrote: > On Fri, 13 Jan 2012, Jeremy Apthorp wrote: > > > > I'd like to draw non-antialiased lines in a . Currently it seems > > that the only way to do this is to directly access the pixel data. > > > > Is there a reason there's no way to turn off antialiasing? > > What's the use case? > Pixel-art style games.
[whatwg] Bresenham lines and circles in
Hi whatwg, I'd like to draw non-antialiased lines in a . Currently it seems that the only way to do this is to directly access the pixel data. Is there a reason there's no way to turn off antialiasing? Possible API: context.antialias = false
Re: [whatwg] Fullscreen and keyboard focus.
On Tue, Nov 29, 2011 at 6:25 AM, João Eiras wrote: > > Hi. > > Perhaps keyboard focus should be limited only to the fullscreen element or > its descendants. > > If you have a canvas or video fullscreen, alt-tabbing can move the focus > outside the fullscreen element, say into form elements. > > But then this would require giving focus, and dispatching focus events, if > the focused element is not inside the fullscreen element subtree. > I agree. (There's a WebKit bug for this: https://bugs.webkit.org/show_bug.cgi?id=69698)
Re: [whatwg] Fullscreen revision I
Another thing: I've heard from developers that it would be useful to allow popup windows to open in fullscreen mode. For example, in Google Docs presentations, the 'start presentation' button should open a new window in fullscreen, so that users can use the editor in the main Chrome window and see the presentation in a separate (fullscreen) window. I propose that window.open(url, name, "fullscreen=yes") should present the given url as fullscreen in a new window. Exiting fullscreen in that window (via cancelFullScreen or user action) should restore the window (if the author wants it to close, they can call window.close() on the fullscreenchange event). Of course, the request should only succeed if the UA is processing a user gesture.
Re: [whatwg] Fullscreen revision I
On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan wrote: > On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp wrote: > >> One problem with the existing implementation in WebKit of fullscreen is >> that it is possible to focus with Tab elements that are not contained >> within the fullscreened element. This is a problem for assistive devices in >> particular. >> >> Perhaps we should specify that elements outside the fullscreened subtree >> should be unfocusable? >> > > The display:none rule would achieve that. I can't find any references to display:none on http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html. Is that not the most recent revision of the spec?
Re: [whatwg] Fullscreen revision I
One problem with the existing implementation in WebKit of fullscreen is that it is possible to focus with Tab elements that are not contained within the fullscreened element. This is a problem for assistive devices in particular. Perhaps we should specify that elements outside the fullscreened subtree should be unfocusable?
Re: [whatwg] Fullscreen Update
On Thu, Oct 20, 2011 at 8:21 AM, João Eiras wrote: > On Wed, 19 Oct 2011 17:15:11 +0100, Glenn Maynard wrote: > > On Wed, Oct 19, 2011 at 11:49 AM, João Eiras wrote: >> >> F11 and document.requestFullscreen() should produce exactly the same >>> results, so, document.fullscreen would be enabled. And there's no reason >>> not >>> to (and otherwise would make the spec needlessly more complex). >>> >>> >> There's no such thing as "document.requestFullscreen()" in the current >> draft. (It was suggested in passing on IRC, but it hasn't been discussed >> here.) >> >> There's definitely a reason that the fullscreen API can't act like >> F11-fullscreen. F11 causes the whole browser window to be fullscreened, >> affecting all tabs in the window. If you change tabs or create a new tab, >> the browser window stays fullscreened. It isn't exited on navigation. >> Pages should no more be able to affect F11-fullscreen than they can resize >> the browser window. >> >> > I don't understand how that is an issue. It has been mentioned that > navigating a document which has a fullscreen element would exit fullscreen, > but not a document. > > Indeed the spec lacks document.requestFullscreen. It should be there for > the traditional fullscreen without browser chrome, just like F11. Or > instead, mention that calling requestFullscreen on the root would have the > same effect. I'd rather have it directly on Document though. > On Chrome for Mac things are a little different: - in F11 (cmd-shift-f) mode, browser UI can be summoned by moving the cursor to the top of the screen - on Lion, there are two "fullscreen" modes, one with UI permanently shown and the other with UI hidden, but available by mousing to the top of the screen I think it doesn't really make sense to mix "browser" fullscreen mode with "content" fullscreen mode. Content fullscreen mode should act like the element popped out of the page and covered the screen. No browser UI should be shown except the permission dialog. Navigating or switching to another tab should exit fullscreen. I don't know why a website would want to interact with browser fullscreen mode, and I don't think it should be allowed.
