> On 16 Apr 2015, at 6:42 am, Elliott Sprehn wrote:
>
> 3. Accessing rendered pixel size is layout-inducing. To avoid layout
> thrashing, we should consider making this an asynchronous getter (e.g.
> asyncGetBoundignClientRect). This would also prevent renderedsizechanged
> events from firing fr
> On 24 Feb 2015, at 6:32 pm, Anne van Kesteren wrote:
>
> On Tue, Feb 24, 2015 at 2:40 AM, Dean Jackson wrote:
>> The idea was to allow the resize event on elements. I don't really care what
>> the solution is, so maybe someone here can come up with a better idea
At the recent Houdini meeting there was a vague agreement between the browser
engines on adding a way for elements to be notified when their size changes.
We've run into a number of scenarios where this is extremely useful, and is
otherwise difficult or annoying (e.g. checking your size on a tim
> On 20 Jun 2014, at 12:54 am, Stephen White wrote:
>
> On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan
> wrote:
> I think I'd rather not take control of canvas resizing away from
> applications, even opt-in. That leads to complexity such as extra API for
> slaving other canvases. I also
FWIW - I think that
ctx.currentPath != ctx.currentPath
is a horrible mistake and we should fix WebKit.
Dean
On 4 Nov 2013, at 2:47 pm, Rik Cabanier wrote:
> On Mon, Nov 4, 2013 at 11:25 AM, Rik Cabanier wrote:
>
>>
>>
>>
>> On Mon, Nov 4, 2013 at 1:49 AM, Jürg Lehni wrote:
>>
What's
On 17 Oct 2013, at 9:20 am, Ian Hickson wrote:
>> PS: iOS 7 is barely released, but the first bug reports are already
>> coming in, because the new Mobile Safari now defines Path, and clashes:
>>
>> https://twitter.com/danetag/status/380636739251220480
>
> Looks like this user solved the prob
On 11 Sep 2013, at 3:20 am, Robert O'Callahan wrote:
> On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier wrote:
> There's a thread on www-style:
> http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html
> It's been in firefox for a while and blink is going to ship it soon:
> https://groups.
On 11 Sep 2013, at 12:14 am, Stephen White wrote:
> now that some browsers are including browser zoom (page zoom) in
> window.devicePixelRatio
Ouch. Who is doing this and why?
Dean
On 11 Sep 2013, at 6:13 am, Ian Hickson wrote:
> On Wed, 11 Sep 2013, Dean Jackson wrote:
>> On 11 Sep 2013, at 5:32 am, Ian Hickson wrote:
>>> On Wed, 11 Sep 2013, Dean Jackson wrote:
>>>> On 11 Sep 2013, at 12:14 am, Stephen White
>>>> wrot
On 11 Sep 2013, at 5:32 am, Ian Hickson wrote:
> On Wed, 11 Sep 2013, Dean Jackson wrote:
>> On 11 Sep 2013, at 12:14 am, Stephen White
>> wrote:
>>>
>>> now that some browsers are including browser zoom (page zoom) in
>>> window.devicePixelRa
On 10 Sep 2013, at 10:00 am, Ian Hickson wrote:
> On Wed, 17 Jul 2013, Rik Cabanier wrote:
>> Ian wrote:
>>>
>>> The density aspect of this might be pointless, given the failure of
>>> getImageDataHD(); if we're dropping that one, I'll drop this one at
>>> the same time.
>>
>> Yes, please dr
On 4 Sep 2013, at 10:47 am, Boris Zbarsky wrote:
> On 9/3/13 7:13 PM, Ian Hickson wrote:
>> Wouldn't checking for window.WebGLRenderingContext be just as unreliable
>> then? I don't understand why it's ok to be able to test that, but why
>> probablySupportsContext() wouldn't be ok.
>
> I'm a lo
On 25/06/2013, at 5:54 PM, Simon Pieters wrote:
> On Mon, 24 Jun 2013 23:31:59 +0200, Dean Jackson wrote:
>
>> Also, the presence of window.WebGLRenderingContext doesn't necessarily
>> indicate
>> that WebGL is supported. On iOS for example, that object is a
On 25/06/2013, at 5:56 AM, Benoit Jacob wrote:
> 2013/6/21 Benoit Jacob
>
>> Any other application use cases?
>>
>
> Anyone?
>
> I believe that if no unquestionable application use case can be given, then
> this function should be removed from the spec.
I think I was the person who propose
On 09/01/2013, at 4:08 PM, Dirk Schulze wrote:
>
> On Jan 8, 2013, at 9:35 AM, Rik Cabanier wrote:
>
>> I looked at pdf2js which is using this fillRule property. As I expected,
>> introduction of the property results in code like this:
>>eoFill: function CanvasGraphics_eoFill() {
>>
On Sep 10, 2012, at 1:03 PM, Rick Waldron wrote:
>
>
> On Mon, Sep 10, 2012 at 3:56 PM, Tobie Langel wrote:
> > This is actually what we could do now. We could hide
> > window.WebGLRenderingContext
> > when we can't create one. But then we'd have to hide all these too:
> >
> >attribu
On Sep 10, 2012, at 12:44 PM, Tobie Langel wrote:
>>> What about enabling feature detection by providing a method per context?
>>>
>>> interface HTMLCanvasElement : HTMLElement {
>>> object get2DContext();
>>> object getWebGLContext(any... args);
>>> };
>>>
>>> That way, developers can use idi
> Despite the hardness to define it, I do feel there is a practical need for
> this.
>
> Ashley Gullen
> Scirra.com
>
>
> On 10 September 2012 19:14, Dean Jackson wrote:
> I sent this to the public-h...@w3.org list:
>
> http://www.w3.org/mid/b2fff68c-cd91-4273-8087-ec3
On Sep 10, 2012, at 12:28 PM, Tobie Langel wrote:
> On Sep 10, 2012, at 8:14 PM, Dean Jackson wrote:
>
>> I propose adding a new method to HTMLCanvasElement:
>>
>> interface HTMLCanvasElement : HTMLElement {
>> boolean supportsContext(DOMStri
I sent this to the public-h...@w3.org list:
http://www.w3.org/mid/b2fff68c-cd91-4273-8087-ec3058d24...@apple.com
Copied below.
[[[
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
}
On 07/07/2012, at 10:11 AM, Charles Pritchard wrote:
>> On Thu, Jul 5, 2012 at 1:05 PM, 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 b
On 31/12/2005, at 7:17 AM, Erik Arvidsson wrote:
Hi,
I might have missed something but why isn't there a generic
transform method for the CanvasRederingContext2D. Currently there
are scale, rotate and translate. Adding a generic transform might
make a few things easier.
void translate(in
22 matches
Mail list logo
