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

2010/1/27 Lachlan Hunt <lachlan.hunt@lachy.id.au>

> 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.
>>
>
> Could you elaborate on the use cases for these icons?  What sort of web
> applications would really benefit from emulating the native look and feel of
> the user's OS, and in particular, what sort of functionality would these
> icons be used to represent?
>

The actual use case that triggered my want to have this was the FTP and
file:// URI directory listings pages in Chromium. They currently are quite
bland and without icons, as may be true for other browsers. Opera doesn't
have icons for files, i think Safari uses 2 stock icons for folders and
files. Firefox' equivalent pages use the moz-icon scheme and have the
platform specific icons. Makes for very nice directory listing pages. In
Chromium, these pages are generated within the render process and Chromium
keeps our icon manager in the Browser process. I thought that Firefox'
solution was much more elegant and it would avoid IPC from the Renderer to
the Browser requesting icon data. Rather that implement something Chromium
specific, it was advised that since both Firefox and Chromium found this
useful, and really every Browser could use this scheme for their FTP and
file:// pages, and it would indeed be useful to web developers, it should be
an open standard. And here we are.

Applications like Google docs could use the icon URIs in place of their
stock images to make the user experience seem more like their OS' file
browser. When you upload a file to Gmail and it doesn't have an icon for
that extension type, it just shows the unknown icon. It would be much better
if it could use the platform default icon for the file type. Really any
cloud "file browser" could benefit from this. Also any applications that
allow uploads can use icons to show users which types of files are
permitted. Gmail e-mail attachments could display have native icons. Any web
page that has downloadable files could use the icon URIs to visually
indicate to the user the filetype. I've seen use of moz-icon in place of
<li> tag ellipses, e.g. a list of HTML or pdf files. Mailto URLs can show
the native mail client icon, etc. The other good thing is that the icons
will reflect the user's associated default application for file types. So if
we show an icon for .html files, they will see the platform specific icon
for their browser. Any where a file of any type is included on a web page,
the icon for it's type could be shown. If we offer this to web developers,
I'm sure they'll find good uses for it :) People are already using the
moz-icon with @-moz-document url-prefix() { } to hide from non-Gecko
browsers.



>
> My concern is that application developers will find it difficult for their
> app's own custom theme to visually integrate well with system specific
> icons.  It seems much more likely that developers would want to have all
> icons used to be designed with a common style.
>
>
App developers may not want to have to produce icons for a hundred different
filetypes; why do so if you can access the user's platform icons? Web pages
that use a platform's icon may choose to have their theme match the icons.
But since we are talking about file icons, I don't think that web
applications will diverge from their own design by including platform
specific icons. How many applications that link to PDFs or have an export to
CSV icons make the icons match their web site's overall design? I don't
think anyone does this.


>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>



-- 
Pierre.