Custom Elements bugs will be also migrated. [Was: Re: Shadow DOM spec bugs will be migrated into GitHub issues]

I am thinking about migrating Custom Element bugs[1] to Web Components GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the consistency. Could someone turn off the automatic email to public-webapps for Custom Elements Bugs in the bugzilla so that we won't receive the mass flood o

Re: Async Image -> ImageData conversion

On Wed, Jun 24, 2015 at 1:28 PM, Ashley Gullen wrote: > Sorry for the confusion. Yes, the latest URL is: > https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html > I'm new to specs and WebIDL, my intent was to say those are new methods on > ImageBitmap. Is "partial interface Imag

Re: Async Image -> ImageData conversion

Sorry for the confusion. Yes, the latest URL is: https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html I'm new to specs and WebIDL, my intent was to say those are new methods on ImageBitmap. Is "partial interface ImageBitmap" the correct way to say that? (I updated the URL to say

Re: Clipboard API: remove dangerous formats from mandatory data types

No, but the specification doesn't require you to exclude it. So how're applications going to swap OpenEXR if you only let em stick in jpegs, pngs and gifs? On Wed, Jun 24, 2015 at 8:46 PM, Wez wrote: > I don't think OpenEXR is one of the formats required by the Clipboard > Events spec, is it..?

Re: Clipboard API: remove dangerous formats from mandatory data types

I don't think OpenEXR is one of the formats required by the Clipboard Events spec, is it..? On Wed, Jun 24, 2015, 18:49 Florian Bösch wrote: > And how exactly do you intend to support for instance OpenEXR? > > On Wed, Jun 24, 2015 at 5:44 PM, Wez wrote: > >> Hallvord, >> >> Yes, content would b

Re: Async Image -> ImageData conversion

On 6/19/15 5:43 AM, Ashley Gullen wrote: I've not done this before, so I've no idea if this is the right/useful approach, but I drafted a spec for it here: https://www.scirra.com/labs/specs/imagedata-blob-extensions.html Ashley, We at Mozilla were just discussing this proposal, and we have a

Re: Clipboard API: remove dangerous formats from mandatory data types

And how exactly do you intend to support for instance OpenEXR? On Wed, Jun 24, 2015 at 5:44 PM, Wez wrote: > Hallvord, > > Yes, content would be limited to providing text, image etc data to the > user agent to place on the clipboard, and letting the user agent synthesize > whatever formats (JPEG

Re: Async Image -> ImageData conversion

On 6/19/15 5:43 AM, Ashley Gullen wrote: I've not done this before, so I've no idea if this is the right/useful approach, but I drafted a spec for it here: https://www.scirra.com/labs/specs/imagedata-blob-extensions.html Let me know if you have any feedback on this. Ashley, I assume the rele

Re: Clipboard API: remove dangerous formats from mandatory data types

Hallvord, Yes, content would be limited to providing text, image etc data to the user agent to place on the clipboard, and letting the user agent synthesize whatever formats (JPEG, PNG etc) other apps require. That has the advantage of preventing malicious content using esoteric flags or features

Detecting image encoding/decoding support

While drafting https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html I realised that there is no way to tell in JS what image formats the browser can decode (with Image or ImageBitmap objects) or encode (with canvas toDataURL()/toBlob() or the ImageBitmap.toBlob() method I was pr

Re: Subject=Re: Async Image -> ImageData conversion

Good point - it makes sense to have ImageBitmap as the "hub" of all conversion. I've drafted a new spec which instead proposes ImageBitmap.toBlob() and ImageBitmap.toImageData(): https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html This should cover all conversion cases asynch