On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell wrote:
> It is a little unfortunate that a canvas-specific solution is needed.
> Is it known whether document.getBoxQuads solves this problem in
> Firefox?
>
It doesn't.
Gecko (and I assume other engines) typically snaps CSS box edges to device
p
On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad wrote:
> +1 from me too. But I have one concern in terms of future proofing, because
> I would like to keep the door open for auto-resizing as a possible future
> improvement. In an eventual auto-resize proposal, we will want to make
> the "preferre
On Fri, Jun 20, 2014 at 2:54 AM, Stephen White
wrote:
> I assume that the size change event would fire:
>
>- on browser page zoom
>- on pinch-zoom
>- when a CSS animation (e.g., scale) changes the canvas size in CSS
>pixels
>
> For browsers that implement the latter two off the ma
+1 from me too. But I have one concern in terms of future proofing, because
I would like to keep the door open for auto-resizing as a possible future
improvement. In an eventual auto-resize proposal, we will want to make
the "preferredsizechange"
event cancelable. If we make the event non-cancelab
> 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
On Thu, Jun 19, 2014 at 7: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
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 think we'd be better off sticking to the
> invariant that the
On Thu, Jun 19, 2014 at 2:04 PM, Jake Archibald wrote:
> Ah yes, the toJSON clash (thanks Tobie).
>
> asJSON
> asText
> asBlob
> asArrayBuffer
Thanks Jussi et al!
https://github.com/whatwg/fetch/commit/73834a6df143746cff278cf1a062be7eca781583
On Thu, Jun 19, 2014 at 12:01 AM, Robert O'Callahan
wrote:
> On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan
> wrote:
>
>> On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad wrote:
>>
>>> I am currently trying an experimental approach where canvases that are
>>> drawn to, but never read from (
A while ago I took over editing of a small part of the HTML spec,
involving the element.
http://html5.org/r/8612
That part is now maintained here:
https://github.com/ResponsiveImagesCG/picture-element/blob/gh-pages/source
I have in the past few weeks worked on making the spec more closely m
On 19 June 2014 12:56, Jake Archibald wrote:
>
> Good point.
>
> toJSON
> toText
> toBlob
> toArrayBuffer
>
> …works for me.
>
Ah yes, the toJSON clash (thanks Tobie).
asJSON
asText
asBlob
asArrayBuffer
On 18 June 2014 11:08, Jonas Sicking wrote:
> On Mon, Jun 16, 2014 at 6:57 PM, Jussi Kalliokoski
> wrote:
> >
> > var doesFetchSupportJson = function () {
> > return fetch("data:application/json;base64,e30=").then(function
> > (response) {
> > return response.body.to("json");
> >
12 matches
Mail list logo
