Re: [whatwg] Canonical Image and Color
On Tue, Sep 9, 2014 at 5:13 PM, Marcos Caceres mar...@marcosc.com wrote: What about icons that need to change daily? E.g. for a calendaring site? This is scary, IMO. A hijacked site could have its icon replaced for a bank's icon or something. I dunno. At least in FirefoxOS we found that we need to support applications updating their icons as part of an update. So in our manifest implementation, we check for updates of the manifest on a daily basis and if the manifest has been updated to point to a new icon, we use that new icon. Applications do on a fairly regular basis release visual updates, and as part of that it's critical that they also update the application icon. We do however not allow applications to change their names. For the reason that you mention. I agree there's still a risk that just changing the icon means that the user won't notice that the name doesn't match, however I don't think disallowing icons to be updated is an option. Even forbidding names to be changed has been a major headache and something we're looking to enable somehow. / Jonas
Re: [whatwg] Canonical Image and Color
On Tue, Sep 9, 2014 at 6:21 PM, Marcos Caceres mar...@marcosc.com wrote: On September 9, 2014 at 9:10:27 PM, Jonas Sicking (jo...@sicking.cc) wrote: On Tue, Sep 9, 2014 at 5:13 PM, Marcos Caceres wrote: What about icons that need to change daily? E.g. for a calendaring site? This is scary, IMO. A hijacked site could have its icon replaced for a bank's icon or something. I dunno. At least in FirefoxOS we found that we need to support applications updating their icons as part of an update. So in our manifest implementation, we check for updates of the manifest on a daily basis and if the manifest has been updated to point to a new icon, we use that new icon. I don't know if it makes any difference, but the process of updating installed apps unusually involves notifying the user that updates are available and the user taking explicit action to update the apps. Where updates happen automatically, there is usually some kind of notification and/or indicator that makes the user aware of what has changed. That will long term not be the case in FirefoxOS. I can't speak for other platforms, but I'll note that Chrome has always updated with no notification to the user, Firefox has over time gotten fewer and fewer notifications, and platforms like Android, iOS and Windows have been moving towards more and more automatic updates with fewer and fewer notifications. So my assumption is that we'll end up with updates being completely transparent on many platforms. At least as default behavior. What I'm concerned about is the application updating the icon while the application is running. Although it works fine for calendar, that seems confusing to me. What is your concern? Applications do on a fairly regular basis release visual updates, and as part of that it's critical that they also update the application icon. Yes, that makes total sense. My concern is more about a sneaky attack where the app icon changes as the user switches from one app to another and then back. Why is the changing back part more concerning than the initial change? Or am I misunderstanding you? We do however not allow applications to change their names. For the reason that you mention. Oddly, I don't see a problem with updating the name of an application in an update. I don't have proof, but I would imagine most people look of icons and take little notice of the name of apps on the home screen. Names are only really relevant for searching. I agree. However I've found forbidding updating icons a no-go. Not to mention that since we support different icon files for different render sizes and pixel densities, it's probably possible for an attacker to hide a bank icon somewhere even without updates. The reason we've locked down name and not icon was because that's all that we could do. Not because it was safer from a security perspective. I agree there's still a risk that just changing the icon means that the user won't notice that the name doesn't match, however I don't think disallowing icons to be updated is an option. Remember, we are talking about changing it in real time VS changing it from an update while the application is (maybe?) shut down. I'm more concerned about an app changing icon when it's *not* running than when it is running. My concern is that the user launches an app that they think is another app, either from the homescreen or from an activity picker. / Jonas
Re: [whatwg] Canonical Image and Color
On Wed, Aug 27, 2014 at 9:42 PM, Marcos Caceres mar...@marcosc.com wrote: There are also some notifications that don't make sense as badges: for instance, iTunes shows me a notification every time a new track starts playing, but doesn't get added as a badge. Hmm yeah. Should probably be a distinct API then. Is numeric sufficient? What about icons that need to change daily? E.g. for a calendaring site? So, it would be great to be able to show a notification and also indicate that its badge-worthy. But at the same time, *some* badges have to be saved across sessions (if the device is rebooted, badges should be shown after reboot - as iOS does - without needing to relaunch an application). That's also true for notifications.I wouldn't want to lose notifications if I suddenly run out of battery. -- http://annevankesteren.nl/
Re: [whatwg] Canonical Image and Color
On Mon, Aug 25, 2014 at 8:59 PM, Mike tomshin...@yandex-team.ru wrote: 2) There is already a couple of standards or quasi-standads: - favicons (most promising seems to be the increasing of their size and svg support) - apple-touch-icon used by Apple and Android - msapplication-TileImage used by MS - Firefox OS icon (detached case) - SpeedDial API by Opera (as an extension) There's also link rel=icon, which is the way to do this. -- http://annevankesteren.nl/
Re: [whatwg] Canonical Image and Color
On Tue, Aug 26, 2014 at 4:21 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 25, 2014 at 8:59 PM, Mike tomshin...@yandex-team.ru wrote: 2) There is already a couple of standards or quasi-standads: - favicons (most promising seems to be the increasing of their size and svg support) - apple-touch-icon used by Apple and Android - msapplication-TileImage used by MS - Firefox OS icon (detached case) - SpeedDial API by Opera (as an extension) There's also link rel=icon, which is the way to do this. Particularly when used with the sizes='' attribute, which lets you provide small favicons *and* large icons suitable for use in tiles like this. ~TJ
Re: [whatwg] Canonical Image and Color
On Tue, Aug 26, 2014 at 8:21 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 25, 2014 at 8:59 PM, Mike tomshin...@yandex-team.ru wrote: 2) There is already a couple of standards or quasi-standads: - favicons (most promising seems to be the increasing of their size and svg support) - apple-touch-icon used by Apple and Android - msapplication-TileImage used by MS - Firefox OS icon (detached case) - SpeedDial API by Opera (as an extension) There's also link rel=icon, which is the way to do this. Sure, but what about the “notification counter” use case that Mike outlined?
Re: [whatwg] Canonical Image and Color
On Tue, Aug 26, 2014 at 8:46 AM, Mathias Bynens mathi...@opera.com wrote: Sure, but what about the “notification counter” use case that Mike outlined? We should investigate that as a feature of the notifications API I think. Someone suggested that last week: https://github.com/whatwg/notifications/issues/23 I haven't really put much thought into how exactly we should go about it though, API-wise. -- http://annevankesteren.nl/
Re: [whatwg] Canonical Image and Color
Tab, You’re right if we take as given that: 1. FF and Chrome will finally fix the bug with handling different size attributes (hopefully they will) 2.standard aspect ratio will be 1:1 (although maybe it can be different) 3.the layout of hi-res favicon will differ from a standard (16x16/32x32) favicon. Compare those: https://dl.dropboxusercontent.com/u/1830800/temp/icons.jpg Generally seems like it could work. But on other hand the battle for high-res icons has been won by Apple’s Touch Icons. Almost sure that more websites have a touch icon than an icon with a size attribute exceeding 128px. Around 20% has an apple icon from top-1. What do you think could be the fallback scenario (in case there is no proper icon)? Generated by browser? In a case someone wanna see grabbed touch icons for top-1000 website: https://yadi.sk/d/CZgnIW6UZxpTg When I see it my sense of beauty says no to any API;) Mike Tomshinsky tomshin...@yandex-team.ru On 26 авг. 2014 г., at 10:42, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 26, 2014 at 4:21 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 25, 2014 at 8:59 PM, Mike tomshin...@yandex-team.ru wrote: 2) There is already a couple of standards or quasi-standads: - favicons (most promising seems to be the increasing of their size and svg support) - apple-touch-icon used by Apple and Android - msapplication-TileImage used by MS - Firefox OS icon (detached case) - SpeedDial API by Opera (as an extension) There's also link rel=icon, which is the way to do this. Particularly when used with the sizes='' attribute, which lets you provide small favicons *and* large icons suitable for use in tiles like this. ~TJ
Re: [whatwg] Canonical Image and Color
Mathias, Anne I really believe that the notification api is a related topic but can exist as a separate api used in page icon. I think it’s a good idea not to bind them together. Mike Tomshinsky tomshin...@yandex-team.ru On 26 авг. 2014 г., at 10:50, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 26, 2014 at 8:46 AM, Mathias Bynens mathi...@opera.com wrote: Sure, but what about the “notification counter” use case that Mike outlined? We should investigate that as a feature of the notifications API I think. Someone suggested that last week: https://github.com/whatwg/notifications/issues/23 I haven't really put much thought into how exactly we should go about it though, API-wise. -- http://annevankesteren.nl/
Re: [whatwg] Canonical Image and Color
From: whatwg whatwg-boun...@lists.whatwg.org on behalf of Mike tomshin...@yandex-team.ru I really believe that the notification api is a related topic but can exist as a separate api used in page icon. I think it’s a good idea not to bind them together. I think there are potentially three distinct APIs: 1. Icons 2. Notifications 3. Numeric badge 1 is clearly solved by link rel=icon already. Proposing new solutions is pointless since by the time browsers implement those they might as well implement/fix their link rel=icon handling. 2 already exists The question I see you raising is whether 3 should be tied to 2 or separate. I believe in most native platforms they are tied together, but I agree that they could be separate. More investigative work would be needed to really explore the problem space. +Marcos because he is really good at that kind of investigative work, and might have some idea what FFOS is doing for numeric badges.
Re: [whatwg] Canonical Image and Color
On Tue, Aug 26, 2014 at 10:36 AM, Domenic Denicola dome...@domenicdenicola.com wrote: +Marcos because he is really good at that kind of investigative work, and might have some idea what FFOS is doing for numeric badges. We don't do anything yet. But we'd like to. I definitely feel like having a badge is a separate API from notifications. For example a badge could show how many unread emails are in the inbox of a webmail client, but you woudn't want to create a notification for every one of them. / Jonas / Jonas
Re: [whatwg] Canonical Image and Color
On Tue, Aug 26, 2014 at 4:59 AM, Mike tomshin...@yandex-team.ru wrote: Hey Folks, Let’s get back to this subject as it seems there is still no solution. Recently we - Yandex.Browser - discussed with Opera if there could be a standard for page icons (let’s call it so) on NewTabPage that replace small screenshots with nice logos like this: https://dl.dropboxusercontent.com/u/1830800/ss_tablo.jpg This page icon might also contain a notification counter that would enable website to communicate with user and improve retention. Similar to mobile icons and notifications. But on desktop there might be more than one counter. * Counter use-cases: 1.Mail (gmail, yahoo, yandex) - number of unread/new emails. 2.Social Networks (Facebook, Twitter, LinkedIn etc) - number of notifications, messages, friends requests. 3.E-commerce (Amazon, eBay, TaoBao etc) - number of cart items (waiting list items) 4.Microblogs and contend-based platforms (tumblr, youtube, ask, quora, news website etc) - number of new content. * How the standard could look like: link rel=“newtabpage_icon href=“logo_url show_title=“true/false” (optional attribute; default: false - for main page; true - for internal) ntp_manifest=“manifest_url” (optional attribute; only for counter implementation) / * How the manifest could look like: I would suggest to postpone this discussion for later and focus on the first part. Step by step. * What kind of issues do I see: 1) There’re 3 general formats of page icons: a) square in Chrome, Opera b) floating in FF and Safari c) fixed ratio in Yandex (1:2), Maxthon (1:1,4) Obvious there should just one icon provided by webmaster. So we need to agree on the aspect ratio (and size). Thus some developers will need to find a way how to handle it. But I believe it’s just a matter of fitting and resizing. 2) There is already a couple of standards or quasi-standads: - favicons (most promising seems to be the increasing of their size and svg support) - apple-touch-icon used by Apple and Android - msapplication-TileImage used by MS - Firefox OS icon (detached case) - SpeedDial API by Opera (as an extension) In Yandex.Browser we think how to improve our Tablo API and we would prefer to use some common approach rather than developing a proprietary standard. So guys, what do you think? Is there a place for such kind of standard or it’s already too tight among those semi-standards? The 'theme-color' meta value recently proposed and standardized by Android covers the color use-case, at least. ~TJ
Re: [whatwg] Canonical Image and Color
On Wed, 28 Aug 2013, Brian Blakely wrote: On Fri, Jul 12, 2013 at 1:32 PM, Ian Hickson i...@hixie.ch wrote: You are welcome to register these on the wiki and convince people to use them, sure. Would you kindly link me to the wiki? http://wiki.whatwg.org/wiki/MetaExtensions -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canonical Image and Color
On Fri, Jul 12, 2013 at 1:32 PM, Ian Hickson i...@hixie.ch wrote: You are welcome to register these on the wiki and convince people to use them, sure. Seems like they already have solutions, though, as you show: Would you kindly link me to the wiki? Sounds like this is already solved, then. In a sense, but ultimately with caveats. OpenGraph is very useful right now, but Facebook can unilaterally change it or wipe it out entirely (both have already happened to a degree). Microsoft's color properties possess mechanics that are extremely specific to how IE uses color in Windows. Why isn't link rel=icon sizes= sufficient? That should suffice, I agree. Meta Image can serve as a fallback when an icon is not available – specifically, as an alternative to using a programmatic screenshot of the app. The principal concept in this Meta Image proposal is to specify a graphic that represents the page content.
Re: [whatwg] Canonical Image and Color
On Mon, 11 Feb 2013, Brian Blakely wrote: Meta elements for defining a canonical image and color to be associated with the page(s) in which they are included. This is intended for use by user agents and third-party applications (such as social networks), referred to collectively as parsers in this document. It is inspired by Microsoft's recent work in site pinning and Apple's standalone webapp implementation in iOS Safari. meta name=image content=path/to/image.png / meta name=color content=#123456 / * Image Value may be a relative or absolute path to file. No restrictions on filetype or resolution. May also be an animated image or video format. Filetypes supported and handling therein is relegated to the parser. * Color Value may be any of the CSS named colors, hex codes, RGB, HSL and their alpha-channel variants. Once attained by the parser, use is at that parser's discretion. You are welcome to register these on the wiki and convince people to use them, sure. Seems like they already have solutions, though, as you show: On Mon, 11 Feb 2013, Brian Blakely wrote: * Social network sharing Facebook currently scrapes OpenGraph tags from shared pages to create a content snippet. One such tag is og:image, which specifies the image to display in that snippet. Twitter and Google+ use these same tags in addition to their own implementations for developers. For the title and description of the snippet, scrapers will fall back to title and the meta description. A canonical image would serve the same purpose, but for visual content. Sounds like this is already solved, then. * News aggregation Flipboard, a highly visual, magazine-style news and article reader, displays a hero image from the target page. It does this by parsing and analyzing the img elements in a page, sometimes displaying a non-optimal or even vacant result. A canonical image would allow developers to control this kind of representation with more specificity, and provide the 3rd party app with another presentation option. Why don't they use the data that Facebook, Twitter, and Google+ use? * OS Integration Apple currently parses their own apple-touch-icon element that specifies which image will serve as a web application's icon after the user has added to the homescreen. Android's browser uses this same element, while Microsoft uses a similar msapplication-TileImage. When these element is not specified, a screenshot of the website is used instead or, in Microsoft's case, the favicon. Firefox OS has still another means of implementation for this. A canonical image could either replace or provide an additional fallback for this functionality. Why isn't link rel=icon sizes= sufficient? * Color In all these cases, a canonical color allows external parsers to provide further branding or additional flourish in their representation of apps and pages. Microsoft's msapplication-TileColor and msapplication-navbutton-color elements aim to fulfill this purpose in IE by coloring the app's tile on the Windows 8 homescreen and IE's own navigation UI, respectively. Seems like there's already a solution, then. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canonical Image and Color
On Mon, Feb 11, 2013 at 2:33 PM, Brian Blakely anewpage.me...@gmail.com wrote: * Proposal Meta elements for defining a canonical image and color to be associated with the page(s) in which they are included. This is intended for use by user agents and third-party applications (such as social networks), referred to collectively as parsers in this document. It is inspired by Microsoft's recent work in site pinning and Apple's standalone webapp implementation in iOS Safari. Can you elaborate? I have no idea what UAs and third-party apps would do with a canonical image or canonical color. ~TJ
Re: [whatwg] Canonical Image and Color
Sure thing. Let me go through the use cases that I see as applicable today, derived from instances where an existing vendor or service currently utilizes a non-standard implementation. * Social network sharing Facebook currently scrapes OpenGraph tags from shared pages to create a content snippet. One such tag is og:image, which specifies the image to display in that snippet. Twitter and Google+ use these same tags in addition to their own implementations for developers. For the title and description of the snippet, scrapers will fall back to title and the meta description. A canonical image would serve the same purpose, but for visual content. * News aggregation Flipboard, a highly visual, magazine-style news and article reader, displays a hero image from the target page. It does this by parsing and analyzing the img elements in a page, sometimes displaying a non-optimal or even vacant result. A canonical image would allow developers to control this kind of representation with more specificity, and provide the 3rd party app with another presentation option. * OS Integration Apple currently parses their own apple-touch-icon element that specifies which image will serve as a web application's icon after the user has added to the homescreen. Android's browser uses this same element, while Microsoft uses a similar msapplication-TileImage. When these element is not specified, a screenshot of the website is used instead or, in Microsoft's case, the favicon. Firefox OS has still another means of implementation for this. A canonical image could either replace or provide an additional fallback for this functionality. * Color In all these cases, a canonical color allows external parsers to provide further branding or additional flourish in their representation of apps and pages. Microsoft's msapplication-TileColor and msapplication-navbutton-color elements aim to fulfill this purpose in IE by coloring the app's tile on the Windows 8 homescreen and IE's own navigation UI, respectively. On Mon, Feb 11, 2013 at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Feb 11, 2013 at 2:33 PM, Brian Blakely anewpage.me...@gmail.com wrote: * Proposal Meta elements for defining a canonical image and color to be associated with the page(s) in which they are included. This is intended for use by user agents and third-party applications (such as social networks), referred to collectively as parsers in this document. It is inspired by Microsoft's recent work in site pinning and Apple's standalone webapp implementation in iOS Safari. Can you elaborate? I have no idea what UAs and third-party apps would do with a canonical image or canonical color. ~TJ
Re: [whatwg] Canonical Image and Color
On Mon, Feb 11, 2013 at 4:17 PM, Brian Blakely anewpage.me...@gmail.com wrote: Sure thing. Let me go through the use cases that I see as applicable today, derived from instances where an existing vendor or service currently utilizes a non-standard implementation. * Social network sharing Facebook currently scrapes OpenGraph tags from shared pages to create a content snippet. One such tag is og:image, which specifies the image to display in that snippet. Twitter and Google+ use these same tags in addition to their own implementations for developers. For the title and description of the snippet, scrapers will fall back to title and the meta description. A canonical image would serve the same purpose, but for visual content. * News aggregation Flipboard, a highly visual, magazine-style news and article reader, displays a hero image from the target page. It does this by parsing and analyzing the img elements in a page, sometimes displaying a non-optimal or even vacant result. A canonical image would allow developers to control this kind of representation with more specificity, and provide the 3rd party app with another presentation option. * OS Integration Apple currently parses their own apple-touch-icon element that specifies which image will serve as a web application's icon after the user has added to the homescreen. Android's browser uses this same element, while Microsoft uses a similar msapplication-TileImage. When these element is not specified, a screenshot of the website is used instead or, in Microsoft's case, the favicon. Firefox OS has still another means of implementation for this. A canonical image could either replace or provide an additional fallback for this functionality. These all seem fairly reasonable. Are you sure that all of the use-cases would use the same image? * Color In all these cases, a canonical color allows external parsers to provide further branding or additional flourish in their representation of apps and pages. Microsoft's msapplication-TileColor and msapplication-navbutton-color elements aim to fulfill this purpose in IE by coloring the app's tile on the Windows 8 homescreen and IE's own navigation UI, respectively. Sure, seems reasonable. ~TJ
