W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

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

From: Pierre-Antoine LaFayette <pierre.lafayette@gmail.com>
Date: Wed, 27 Jan 2010 07:49:54 -0500
Message-ID: <743256c51001270449w7692d62ag721eda930511302c@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Adam Barth <w3c@adambarth.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapps <public-webapps@w3.org>
2010/1/26 Maciej Stachowiak <mjs@apple.com>

>
> On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote:
>
> Yes, I wish to expose the platform and possibly Browser theme specific
> icons to web content with the Icon URI scheme. The idea is to allow the Icon
> URI scheme to be used anywhere an image is specifiable by a data URI in HTML
> and JavaScript. This will allow web content to emulate the look and feel of
> the native Operating System and of the Browser itself in the case of themed
> icons. I believe this will benefit both content creators and consumers.
>
>
> To gain an interoperability benefit, we would presumably need to define the
> set of icons available, right?
>
>
Why do you think that? Can you please elaborate? The icons should be the
native icons for a particular file type. What possibly need to define is
size, what to do if the filetype is unknown, whether we should include
Browser specific "stock" image identifiers to allow the use of Browser
themed icons, etc.

>
> Chromium currently has an internal scheme (chrome://fileicon/<path>) that
> it is using for internal HTML pages and Mozilla's moz-icon scheme is already
> exposed to web content. I am not sure if other browsers have similar schemes
> for providing icon resources internally.
>
> I am working on the Internet Draft for this and will be seeking feedback
> soon enough. If anyone has any thoughts on security issues, it would be most
> welcomed as a thorough security analysis is required for the draft.
>
>
> I would recommend not using "//" in URLs of this scheme unless they have an
> authority component. It is better for them not to look like a hierarchical
> URI in that case.
>
>
Agreed.


> Regards,
> Maciej
>
>
> Thanks.
>
> 2010/1/26 Adam Barth <w3c@adambarth.com>
>
>> On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt <lachlan.hunt@lachy.id.au>
>> wrote:
>> > Pierre-Antoine LaFayette wrote:
>> >>
>> >> So in HTML a user can have:
>> >>
>> >> <img src="moz-icon://unknown?size=16" alt="File:"/>
>> >>
>> >> If opened in Firefox, the browser will provide an icon for the
>> filetype. I
>> >> think this is a useful scheme that other browsers could benefit from.
>> >> There
>> >> is a chrome://fileicon/<path>  scheme in Chromium, however it is
>> purely
>> >> internal and not exposed to the Web. I thought that having a standard
>> >> icon:// scheme of some sort would be the best approach rather than
>> >> Chromium
>> >> and Mozilla having their own browser specific schemes for icon
>> retrieval.
>> >
>> > What benefit is there for trying to achieve interoperability by
>> > standardising this?  Are these icons meant to be used by web content, or
>> > meant only for internal use by the browser?
>>
>> I think Pierre-Antoine would like to expose this to web content.
>>
>> Adam
>>
>
>
>
> --
> Pierre.
>
>
>


-- 
Pierre.
Received on Wednesday, 27 January 2010 12:50:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT