I was a little surprised to read Mozilla don't plan on shipping HTML
imports and will re-evaluate after modules are supported:
https://hacks.mozilla.org/2014/12/mozilla-and-web-components/
Why would modules affect the decision to ship HTML imports? Imports get you:
- the ability to import style
biases feedback towards the negative? I guess you never hear the
chorus of cool, can't wait! from everyone looking forwards to it?
On 15 December 2014 at 19:09, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/15/14, 1:10 PM, Ashley Gullen wrote:
Why would modules affect the decision to ship HTML
I am on the side that synchronous AJAX should definitely be deprecated,
except in web workers where sync stuff is OK.
Especially on the modern web, there are two really good alternatives:
- write your code in a web worker where synchronous calls don't hang the
browser
- write async code which
I filed crbug.com/458799 for Chrome recently since showing a dialog
defined in a HTML import did not work as I thought it should. I can't
compare to any other browsers since right now AFAIK Chrome is the only
browser shipping both HTML imports and dialog. There seemed to be some
confusion from the
=import%20Model
:DG
On Wed, Feb 18, 2015 at 5:18 AM, Ashley Gullen ash...@scirra.com wrote:
I filed crbug.com/458799 for Chrome recently since showing a dialog
defined in a HTML import did not work as I thought it should. I can't
compare to any other browsers since right now AFAIK Chrome
, then video
can already be rendered to canvases, so -webkit-canvas still covers that.
Therefore I would like to propose standardising this feature based off the
-webkit-canvas() implementation.
Ashley Gullen
Scirra.com
I think the existence of the API functions should indicate the browser has
the capability, and then the API returns an error if it's not allowed to be
used in the current context. I think this would improve the quality of
messages seen by users, since for example removing the Geolocation API
significant changes to the spec, but I think it's
necessary. It looks a bit like a first draft that never got reconsidered.
Ashley Gullen
Scirra.com
On 9 April 2015 at 12:52, Arthur Barstow art.bars...@gmail.com wrote:
Hi All,
A new Working Draft publication of Gamepad is planned for April 14
The browser could copy a terminal command to wipe the disk, and the user
could run it. Or copy a URL to a web page that has a known security
exploit, and then the user pastes it in to the address bar. Maybe we
shouldn't allow copying anything at all?
Actually I think this is just security by
I was advised to mark this as an Editor's draft, and have done so. I also
added a new proposed ImageData.fromImage method, with rationale included in
the document. It's at the same URL:
https://www.scirra.com/labs/specs/imagedata-blob-extensions.html
On 19 June 2015 at 13:43, Ashley Gullen ash
, 2015 at 1:28 PM, Ashley Gullen ash...@scirra.com 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
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
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
process. I'm happy to get involved in spec work though so please
let me know if you have any feedback/suggestions on anything I'm doing here.
Ashley
On 24 June 2015 at 19:12, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/19/15 5:43 AM, Ashley Gullen wrote:
I've not done this before, so I've
[mailto:a...@scirra.com] *On Behalf Of *Ashley
Gullen
*Sent:* Wednesday, June 17, 2015 2:06 PM
*To:* Travis Leithead
*Cc:* public-webapps@w3.org
*Subject:* Re: Async Image - ImageData conversion
That seems like a good start. I suppose there should be a
putImageDataAsync counterpart too
June 2015 at 14:10, Justin Novosad ju...@google.com wrote:
On Fri, Jun 26, 2015 at 7:07 AM, Ashley Gullen ash...@scirra.com wrote:
I've updated the draft with an ImageBitmap.transferToImageData() method:
https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html
It's also used
in
a worker could possibly help, but that would require both Blob and Image to
be transferable to be useful.
Ashley Gullen
Scirra.com
. Running a canvas in
a worker could possibly help, but that would require both Blob and Image to
be transferable to be useful.
Ashley Gullen
Scirra.com
2015 at 13:04, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jul 3, 2015 at 1:51 PM, Ashley Gullen ash...@scirra.com wrote:
These conversions are covered by what I proposed in my previous email,
so I
drafted another spec with them:
https://www.scirra.com/labs/specs/imagedata-conversion
it was created from, unlike ImageBitmap. Immutability is a significant
advantage of ImageBitmap, which allows for zero-copy code paths in many
cases, which helps with both performance and memory consumption.
On Tue, Jun 30, 2015 at 4:17 PM, Ashley Gullen ash...@scirra.com
wrote
I'm also wondering that if we have ImageBitmap.transferToImageData(),
should we not also have ImageData.transferToImageBitmap()? Currently
createImageBitmap(imageData) appears to require making a copy.
On 26 June 2015 at 12:07, Ashley Gullen ash...@scirra.com wrote:
I've updated the draft
I've updated the draft with an ImageBitmap.transferToImageData() method:
https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html
It's also used in Example 2 to demonstrate converting a Blob to an
ImageData without redundantly copying the pixel data.
I don't think we should extend
types can be added to ImageDataSource
allowing new types to be converted without a new method being added.
Does this approach sound better?
Ashley
On 26 June 2015 at 16:37, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/26/15 4:07 AM, Ashley Gullen wrote:
I don't think we should extend
:48, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jul 6, 2015 at 2:38 PM, Ashley Gullen ash...@scirra.com wrote:
I thought it would be more confusing to have separate competing
proposals in
one document? They are more like three revisions of the same document
anyway, the latest one
24 matches
Mail list logo
