[Webkit-unassigned] [Bug 65564] Support for multiple <link rel="icon"> favicon elements.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=65564





--- Comment #16 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2011-08-18 14:18:50 PST ---
(In reply to comment #15)
> > I would expect it to be able to return multiple entries for each type.  The first entry of any given type should probably be the preferred, default icon.
> 
> That won't work, unfortunately - the icon type is a bitmask (so you can e.g. get both FavIcon and TouchIcon in one go). That means a varying number of icons are default icons, followed by non-default ones. Since that's an API change, it might break other WebKit users.
> 
> I don't disagree that a second API is confounding - but in light of the fact that the old API is brittle *and* that we need backwards compatibility, it seemed best to pick an API that is completely invisible to clients relying on the old API.

Why is backwards compat an issue?  We are constantly evolving the WebKit API.  We only need backwards compat temporarily to support WebKit rolls.  We often invent the better API and deprecate the older API, but in this case, it sounds like you are proposing a new API that does not deprecate the old API.  That means a future that is more complex, which makes me sad.

Why do we need this sizes attribute at all?  An .ico file is basically a mipmap, containing multiple images at different resolutions.  Are you trying to use non-ico icons (e.g., PNGs)?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.