[whatwg] Event loop processing model, and current time

https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 says: 1. Let now be the value that would be returned by the Performance object's now() method 2. Let docs be the list of Document objects associated with the event loop in question… ... 4. For each fully active Document in

Re: [whatwg] Canvas resetClip() API

On Oct 7, 2013, at 8:55 PM, Rashmi Shyamasundar wrote: > Hi All, > > This is regarding the resetClip() API for canvas. Please take a look at my > patches to the bug https://bugs.webkit.org/show_bug.cgi?id=82801. > resetClip() can be implemented in Cairo, without any overhead, since Cairo > suppo

Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions

On Jul 5, 2012, at 2:25 PM, Ian Hickson wrote: > On Thu, 5 Jul 2012, Edward O'Connor wrote: >> >> As things currently stand in the spec, implementations basically need to >> keep N+1 bitmaps per canvas, where N is the number of hit regions. I >> doubt any implementors would be enthusiastic to

[whatwg] Please rename this thread (Was: Re: whatwg Digest, Vol 82, Issue 10)

Please don't start or continue threads without a useful subject line. Simon

Re: [whatwg] CSS canvas() function

On Dec 1, 2010, at 5:37 PM, Robert O'Callahan wrote: > On Thu, Dec 2, 2010 at 2:25 PM, Tab Atkins Jr. wrote: > On Wed, Dec 1, 2010 at 5:20 PM, Robert O'Callahan > wrote: > > In the absence of compelling use cases, I'd just leave it at , > > and and whitelist in more elements later if necessar

Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?

On Nov 26, 2010, at 6:38 PM, Boris Zbarsky wrote: > On 11/26/10 4:09 PM, Simon Fraser wrote: >> This would be hard for WebKit, which relies on Core Graphics for gradients >> on some platforms. CG doesn't allow us to interpolate in premultiplied >> space. > &g

Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?

On Nov 23, 2010, at 12:43 PM, Tab Atkins Jr. wrote: > Implementors, does > this sounds like a change you can get behind? We already changed > canvas shadows to match behavior with CSS shadows; this is a much > smaller change for spec-equivalence. This would be hard for WebKit, which relies on C

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On Nov 20, 2010, at 7:46 AM, Ojan Vafai wrote: > On Fri, Nov 19, 2010 at 9:21 PM, Robert O'Callahan > wrote: > Most of the use cases for script access to the exact device pixel ratio that > I've heard boil down to "interfere with the user's ability to zoom", which is > why I haven't been eager

Re: [whatwg] Timeouts and monotonic vs clock time

On Nov 3, 2010, at 8:01 PM, and-py wrote: > Here's a curious little issue. > > When you use `setTimeout` or `setInterval`, the HTML5 spec seems to say > that the callback should occur after a certain amount of actual time has > elapsed. > > But what browsers might do is take the system clock, ad

Re: [whatwg] VIDEO Timeupdate event frequency.

On Sep 10, 2010, at 10:07 AM, Tab Atkins Jr. wrote: > On Fri, Sep 10, 2010 at 9:58 AM, Simon Fraser wrote: >> The problem with a 'newFrame' callback is what to do if the callback >> takes longer than the duration of a single frame. Does the video engine >> sta

Re: [whatwg] VIDEO Timeupdate event frequency.

On Sep 10, 2010, at 7:53 AM, Tab Atkins Jr. wrote: > On Fri, Sep 10, 2010 at 4:05 AM, Silvia Pfeiffer > wrote: >> On Fri, Sep 10, 2010 at 7:28 PM, Biju wrote: >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=571822 Firefox fires the timeupdate event once per frame. Safari 5 and Ch

Re: [whatwg] Feedback on the Mozilla FullScreen API proposal

On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote: > On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser wrote: > This is feedback on the Mozilla FullScreen API proposal here: > <https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI> > > > The user agent may tran

[whatwg] Feedback on the Mozilla FullScreen API proposal

This is feedback on the Mozilla FullScreen API proposal here: > The user agent may transition a Document into or out of the > fullscreen state at any time, whether or not script has requested > it. User agents are encouraged to provide

Re: [whatwg] suggestion for HTML5 spec

On May 2, 2010, at 2:20 am, Eduard Pascual wrote: > On Sun, May 2, 2010 at 5:55 AM, Tab Atkins Jr. wrote: >> On Sat, May 1, 2010 at 8:25 PM, wrote: >>> My suggestion for the HTML5 spec is that the video tag should have a feature >>> that can enable GPU acceleration on a user's graphics card, so

Re: [whatwg] Fullscreen for HTML5 Video element

On Mar 9, 2010, at 8:01 PM, Robert O'Callahan wrote: > On Wed, Mar 10, 2010 at 3:59 PM, Michael Dale wrote: > I was part of the initial thread that was left unresolved. I would just > re-iterate that its important the fullscreen system does not deprive the web > designer of flexibility to do DO

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:

Re: [whatwg] api for fullscreen() - security issues

On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote: > On Jan 31, 2010, at 05:08, Simon Fraser wrote: > >> * disallow enterFullscreen() from a frame or iframe > > This might be a problem if video sites transition their embedding boilerplate > to an iframe in order to be abl

Re: [whatwg] api for fullscreen() - security issues

On Jan 28, 2010, at 6:42 pm, Robert O'Callahan wrote: > On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser wrote: > We have been discussing a more general fullscreen API that lets you take the > page fullscreen (perhaps with the ability to focus on a single element), as > Maciej

Re: [whatwg] api for fullscreen()

On Jan 30, 2010, at 1:24 PM, Anne van Kesteren wrote: > On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser wrote: >> On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote: >>> So how about a Window API with an optional element component: >>> void enterFullsc

Re: [whatwg] api for fullscreen()

On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote: > So how about a Window API with an optional element component: > void enterFullscreen(optional DOMElement element, optional boolean > enableKeys); > void exitFullscreen(); > boolean attribute supportsFullscreen; > boolean attribute displaying

Re: [whatwg] api for fullscreen()

On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote: > On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser wrote: > We have been discussing a more general fullscreen API that lets you take the > page fullscreen (perhaps with the ability to focus on a single element), as > Maciej

Re: [whatwg] api for fullscreen()

On Jan 28, 2010, at 3:38 PM, Robert O'Callahan wrote: > On Thu, Jan 28, 2010 at 8:34 PM, Henri Sivonen wrote: > I haven't seen a proposal, but it looks like code has landed: > http://trac.webkit.org/changeset/50893 > > Demo: http://jilion.com/sublime/video > (option-click the full screen button

Re: [whatwg] : A 3D Equivalent to

On Nov 2, 2009, at 4:26 PM, Brian Blakely wrote: * Though it does not have properties for clipping, Webkit's proposed implementation of 3D CSS does have them for perspective. Clipping, lighting, texture stretching and additional considerations could also be a part of that spec, but those are di

Re: [whatwg] : A 3D Equivalent to

On Nov 2, 2009, at 3:41 PM, Brian Blakely wrote: Additional clarification on this proposal: A "model" Element Never Becomes a Wafer --- Right now, if you try to act on conventional HTML elements with 3D CSS, those elements become wafers.

Re: [whatwg] : A 3D Equivalent to

On Oct 30, 2009, at 6:09 PM, Brian Blakely wrote: To ensure HTML remains semantic as the web makes its gradual transition to 3D rich interfaces and content, I am submitting a proposal for WHATWG's consideration. The below examples contain HTML as it exists now, the current working standard

Re: [whatwg] Orientation event in Firefox

I'm a little concerned about use of the word "orientation" for these kinds of events. WebKit on iPhone already uses the term "orientation" to mean "which way up is the device", i.e. in portrait or landscape, right-way-up or upside-down:

Re: [whatwg] and acceleration

[Speaking with my Apple hat on.] We agree that upgrading the hardware is not an acceptable answer to this question. Many web-enabled devices have much less CPU power than the average laptop or desktop (think mobile devices), but many have quite capable GPUs. On desktop machines too, hardwar

Re: [whatwg] Video : Slow motion, fast forward effects

On Aug 7, 2008, at 12:23 PM, Charles Iliya Krempeaux wrote: Hello, On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote: Dave Singer wrote: At 20:10 +1200 7/08/08, Chris Double wrote: On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: On Thu, 7 Aug 2

[whatwg] Focus management

Some web applications may need more control over focus than is offered by the existing focus management proposal: Specifically, it's hard to write JavaScript that has more explicit control over focus changes. Functionality that is mi