Re: Steps to creating a browser standard for the moz-icon:// scheme

Hi,

On Sun, Mar 21, 2010 at 4:16 PM, Pierre-Antoine LaFayette
<pierre.lafayette@gmail.com> wrote:
> Hi everyone!
> Sorry I've let this thread go a bit stale. I've been tied up with more
> pressing matters for a while now :(
> From the all the great feedback in this thread, I've been able to determine
> that there really should be 2 parts to this proposal:
>
> The specification of an icon URI scheme that resolves platform icons by
> filetype
> The extension of the File object interface to include methods to retrieve
> its icon data or perhaps an icon URI that doesn't taint the canvas
>
> The first part is a reduction of the original scope of the icon URI scheme
> to the essential functionality that everyone seemed (if I'm not mistaken) to
> be okay with. I'm sure further functionality could be added in the future if
> needed.
> Everyone seemed to agree that #2 is a good idea --albeit not mine; credit to
> Maciej for this one.
> So for the first part, I've put together a draft document that I'd really
> like everyone to comment on before I even consider sending it out to
> uri-review@ietf.org.
> It is located
> here: http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html.

Just had a quick read... overall, the document reads quite well.

However, I think the following might be a little bit underspecified:

"Applications MUST NOT allow the getImageData and toDataURL methods to
access to the Image data of platform icons drawn to the canvas."

I agree with the rationale of the security consideration, but perhaps
it would be nice to throw an appropriate DOM exception here... might
help developers know programmatically why they are not allowed to
access these things. Without some kind of indication, it might leave
people thinking that there is a bug in the browser or that they've
done something wrong.

> I hope it correctly interprets the issues we've discussed.
> For the second part, I'm not exactly sure what the correct procedure is. I
> imagine it would involve making an addendum to the existing File interface
> specification. So if anyone has any guidance on this, it would be greatly
> appreciated.
> Once again; thanks for everyone's help and patience in this process.
> --
> Pierre.
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Sunday, 21 March 2010 18:05:28 UTC