> On Jun 15, 2017, at 7:27 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > > One issue we've noticed is there are many different nonstandard ways that > websites use to find icons. [1] details many of these: the Microsoft way, the > Apple way, the OpenGraph way... and even then the icons can be put in > different places... is this the problem Brady's code is designed to solve?
The WebCore::IconDatabase was extremely limited. It would look at only the last <link rel="icon"> or <link rel="shortcut icon"> (which are standardized in HTML5) and consider it "the one icon" for a page. If the <head> specified none, it would consider the default /favicon.ico the one icon. And all it could load/store is that one icon. The new mechanism already expands upon this by allowing for *each* <link> icon to be considered individually. It also expands upon this by having built-in support for apple-touch and apple-touch-precomposed icons. There's nothing stopping us from adding support for all of these icon types with only small changes to WebCore. Of the list in that blog post some might be considered relevant to Apple, others probably not - But LinkIconCollector is a tidy self-contained class that can easily have per-platform implementations. tl;dr - Yes, this is basically the problem the new mechanism solves. Thanks, Brady _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
