- From: Matt Giuca <notifications@github.com>
- Date: Sun, 19 Jan 2020 20:59:13 -0800
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/pull/833/review/345079642@github.com>
mgiuca commented on this pull request. Just had a look over the PR. Looks great, but I want to discuss the greyscale vs monochrome thing, as well as terminology. Firstly (ignoring the terminology for a moment): it was my intention when we discussed this earlier that the icon would actually be greyscale (i.e., the user agent respects all shades of alpha), not pure black/white (i.e., the user agent treats 0 as transparent and >0 as opaque). The intention of this is to allow for antialiasing. Let's say the site uploads this icon:  Most of the pixels in this icon have alpha 0 or alpha 255, but some around the edges are semitransparent. According to the current text, user agents are required to treat all alphas >0 as fully opaque, which means they MUST render it like this:  Note the jagged edges and also the fact that there's "bleeding" across thin gaps, which is due to the fact that even an alpha value of 1 (out of 255) is treated as opaque. So I think we should actually specify this as a greyscale, not as a pure black/white image. That does give sites the option of having semi-transparent parts of the picture, which is not really the intention, but I don't think that's a serious problem if it happens. We could non-normatively encourage developers to have most of the non-transparent pixels be fully opaque, using partial transparency only for anti-aliasing. That means replacing this sentence: > If it has alpha equal to zero, the user agent SHOULD NOT display it. If it the alpha component is greater than zero, the user agent SHOULD display it with any tint. with (suggestion): > The user agent SHOULD display each pixel with its original alpha value, but with a red, green and blue value of the user agent's choosing. It is RECOMMENDED that the user agent use the same color value for all pixels. You could also say explicitly "User agents SHOULD NOT convert the alpha channel to a 1-bit (on/off) image where each pixel is either fully transparent or fully opaque, because the image may contain partially transparent pixels for anti-aliasing purposes." (On some platforms, it may be necessary to do this, but implementations should avoid it unless necessary, which matches the definition of SHOULD NOT.) Now onto the terminology. Given what I said above, "`greyscale`" would indeed be the most technically correct term. So I would be happy with that. My preference, however, is "`monochrome`", since that best conveys the intention. Even though we allow partially transparent pixels for anti-aliasing, we intend these icons to more or less contain fully transparent and fully opaque pixels. I do not like "`single_color`". It has the same meaning as "monochrome" (with the same potential ambiguities) but "monochrome" is an industry standard term (in computer graphics) whereas "single-color" feels like we're dumbing that term down for 6-year-olds. It's harder to type (with the underscore), harder to say, and doesn't really buy us anything in terms of clarity. (i.e., if you were confused by "monochrome" thinking for example it meant a black-and-white image as opposed to an alpha image, then calling it "single-color" would not alleviate that confusion.) So my votes, in order, are: 1. `monochrome` 2. `greyscale` 3. `single_color` I'm also not clear on why the spec uses the other term "solid color" to mean the same thing. Can we use one term throughout? > + When processing a <a>monochrome</a> icon, the user agent MUST NOT use + the red component, green component, or blue component of a pixel. If + it has alpha equal to zero, the user agent SHOULD NOT display it. + If it the alpha component is greater than zero, the user agent SHOULD + display it with any tint. + </p> + <p> + If no monochrome icon is defined when an icon with a solid icon must + be presented, the user agent MAY show a fallback icon. + </p> + <p class="note"> + Designers of <a>monochrome</a> icons are recommended to set all + pixels to black and use transparency to create a silhouette of their + icon. + </p> + <p> I think both of these are already implied by the spec. If a user agent wanted to, say, display the icon as pink-on-green, it would make the pixels pink, and then display the icon on a green background. If it wanted to invert that color scheme, it would make the pixels green and then display the icon on a pink background. The only thing that wouldn't be supported would be if the UA, for some reason, wanted to make the "transparent" part of the image a solid colour (say, pink), and then have the "opaque" part of the image show through some background underneath. I would say we explicitly do not want to support that, since then we're kinda messing with the brand logos in a way they don't necessarily want. > + platforms, it is possible to indicate that an icon can have a + user-agent-specified color applied by adding the <a>single-color</a> + purpose. This allows the platform to ensure that the icon looks well + integrated with the platform, and even apply different colors and + padding in different places throughout the platform. + </p> + <p> + When processing a <a>single-color</a> icon, the user agent MUST NOT use + the red component, green component, or blue component of a pixel. If + it has alpha equal to zero, the user agent SHOULD NOT display it. + If it the alpha component is greater than zero, the user agent SHOULD + display it with any tint. + </p> + <p> + If no single color icon is defined when an icon with a solid color is + expected to be presented, the user agent MAY show a fallback icon. It's unclear what this means. Does it mean it MAY fall back to using the standard icon? Or it MAY supply its own default icon? I'm not sure we need to say this at all. User agents can show any icon they want wherever they want, and don't need permission of the spec. We should just focus on how user agents are expected to treat these monochrome icons, if supplied, and not start dictating their UI more broadly. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/pull/833#pullrequestreview-345079642
Received on Monday, 20 January 2020 04:59:16 UTC