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

Thanks again for the feedback!

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

> Pierre-Antoine LaFayette wrote:
>
>> 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.
>>
>
> OK, and I suppose the standard directory listing pages that Apache
> generates could also make use of them.  It wasn't clear from your original
> mail that this was just about file type icons, based on the file extension.
>  You also mentioned:
>
>
>  <stock-image> is of the format:   stock/<icon-name>
>> <icon-name> is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'.
>>
>
> It's not clear what the use cases for these are, but for these, it does
> seem like we would need to define a common set of icons that are available,
> unlike the file type icons that can load the system's associated icon.
>

So Mozilla has special stock image identifiers, e.g.
*moz-icon://stock*/tab-new?size=menu,
that I believe return themed icons. I'm not entirely sure what all the
options are. There doesn't seem to be documentation for these, it is likely
that it is something mostly intended for internal use.

I've been thinking that including something like this would not be
reasonable as we probably won't be able to agree on some set of "stock"
icons and sizes or even simply which identifiers should be included. E.g.
endless variants of: Do we really need separate icons for 'ok' and 'yes' ?
Plus all Browsers have their own UIs and themes and as such have different
icon sets.


>
> Have you considered using the existing about: URI scheme for this?  This
> scheme is in the process of being standardised, and it is possible for specs
> to define URIs using it, which are then meant for resolving in
> application/platform specific ways.
>

The only thing is that about URIs are more for providing users information
(hence the name "about") and perhaps offering configuration options.

Such URIs have commonly been used by web
   browsers for providing access to built-in functionality, such as
   application information, preferences, settings, or "easter eggs"


While it would be nice to piggy-back on the about: scheme, it does not
seem appropriate. An icon: URI scheme is intuitive and concise. I
think the only about: URL that Browsers make web accessible is
about:blank (and about:mozilla in FF). You can have about:memory in an
anchor tag in Chromium for example. Not that making about:icon web
accessible would be that big of a deal but it may violate some design
principles, at least on the Chromium side.


Adam, could you provide your thoughts on using about:icon?


> See the draft here.
>
> http://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-03.txt
> The important part is defined in section 5, which has significant
> amendments described here, which have yet to be integrated into the draft.
> http://lists.w3.org/Archives/Public/public-html/2009Sep/0755.html
> http://lists.w3.org/Archives/Public/public-html/2009Sep/0767.html
>
> You could write a spec to define an about:icon URI to work like this like,
> e.g. "about:icon?html;32"  or "about:icon?ext=html&size=32" (though, I think
> being shorter and avoiding '&' is better, so authors don't have to bother
> escaping it in their HTML)
>
>
I like the shorter syntax as well.


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



-- 
Pierre.