Re: [whatwg] `brand-color` meta extension
On 2014/06/26 12:58, Marcos Caceres wrote: I would be in favor of this. It would be good to support the legacy content as its use on the Web is significant. Search I did back in Oct 2013 found these proprietary tags appeared on something like 1% of pages in Alexa's top 78K pages 1%! Significant? Hardly. Typo? Regards -Mark -- 注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] `brand-color` meta extension
On Wed, Aug 20, 2014 at 12:39 PM, Mark Callow callow.m...@artspark.co.jp wrote: On 2014/06/26 12:58, Marcos Caceres wrote: I would be in favor of this. It would be good to support the legacy content as its use on the Web is significant. Search I did back in Oct 2013 found these proprietary tags appeared on something like 1% of pages in Alexa's top 78K pages 1%! Significant? Hardly. Typo? The web corpus is somewhere north of a trillion pages. 1% of that is still 10 billion+. Even for things that aren't evenly distributed, and so occur mostly on newer content, 1% is a large fraction, which people are likely to run into on a roughly daily basis. Chrome, for example, only starts considering whether a feature can be removed when its usage is under .01% (we usually prefer it to be less than .003% or so). ~TJ
Re: [whatwg] `brand-color` meta extension
On 06/26/2014 12:50 PM, Tobie Langel wrote: On Jun 26, 2014, at 21:20, Marcos Caceres w...@marcosc.com wrote: On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color Could we change the name to something a tad more neutral and extendable, e.g.: ua-background-color? Like that, people that use the Web for things other than brand promotion don't feel offended, and we can add ua-color once devs start requesting it while keeping consistent with CSS. It's not the UA's color you're after here, it's the page's own theming color, right? So theme-color or accent-color might make more sense. As a note, an old version of css3-ui used the term 'flavor' for something similar. Unsure about following that precendent. As another note, a request for something similar came up on the CSSWG ML just recently: http://lists.w3.org/Archives/Public/www-style/2014Jul/0131.html In that case it's about retrieving the OS's notion of this color. ~fantasai
Re: [whatwg] `brand-color` meta extension
On Tue, Aug 19, 2014 at 6:52 PM, fantasai fantasai.li...@inkedblade.net wrote: On 06/26/2014 12:50 PM, Tobie Langel wrote: On Jun 26, 2014, at 21:20, Marcos Caceres w...@marcosc.com wrote: On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color Could we change the name to something a tad more neutral and extendable, e.g.: ua-background-color? Like that, people that use the Web for things other than brand promotion don't feel offended, and we can add ua-color once devs start requesting it while keeping consistent with CSS. It's not the UA's color you're after here, it's the page's own theming color, right? So theme-color or accent-color might make more sense. Yeah, we ended up at theme-color after much back-and-forth: https://github.com/whatwg/meta-theme-color Adam
Re: [whatwg] brand-color meta extension
Shall we enforce brand-color in head elements? it could make the brand-color loaded ASAP, just like the favicon. - Michael On Thu, Jun 26, 2014 at 5:28 PM, Kit Grose k...@studioiq.com.au wrote: It feels utterly bizarre to me that this sort of property is declared in the markup and not in the CSS. If I have a site whose colour scheme is selectable in a CMS (picking different CSS), I'd also have to define this brand colour in a format that I can inject into the site's markup. If I change the CSS, I'd have to also change this value? Cheers, Kit Grose User Experience + Tech Director, Studio IQ +61 (0)2 4260 7946 k...@studioiq.com.au studioiq.com.au On 27 Jun 2014, at 2:52 am, Tao Bai michael...@google.com wrote: Hi, I have added brand-color meta extension in http://wiki.whatwg.org/wiki/MetaExtensions, and would like have your comment on it. Please check the detail on linked spec. Best Regards - Michael
Re: [whatwg] brand-color meta extension
On Mon, Jun 30, 2014 at 9:23 AM, Tao Bai michael...@google.com wrote: Shall we enforce brand-color in head elements? it could make the brand-color loaded ASAP, just like the favicon. Not needed, imo. If you put it in the head (or at least, early in the body), it'll get read early; if you put it late, it'll be read late. Since the first valid one gets used, if you put one in the head the browser doesn't have to worry about parsing to the end just in case someone put another declaration at the bottom of the document. meta elements already have authoring conformance criteria requiring them to be in the head when they're not being used for Microdata. ~TJ
Re: [whatwg] brand-color meta extension
On Thu, 26 Jun 2014, Tao Bai wrote: Hi, I have added brand-color meta extension in http://wiki.whatwg.org/wiki/MetaExtensions, and would like have your comment on it. Please check the detail on linked spec. The cited spec mentions mapplication-navbutton-color and apple-mobile-web-app-status-bar-style. Why don't we just register and use those? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] brand-color meta extension
The brand color is super set of them and not limited to use in the navbutton or status bar, furthermore, not all browsers have navbutton or status concept, it makes developer confused. The mapplication-navbutton-color and apple-mobile-web-app-status-bar-style are prefix and browser specific, brand-color is general and could be standard for all browsers. - Michael On Thu, Jun 26, 2014 at 10:08 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Jun 2014, Tao Bai wrote: Hi, I have added brand-color meta extension in http://wiki.whatwg.org/wiki/MetaExtensions, and would like have your comment on it. Please check the detail on linked spec. The cited spec mentions mapplication-navbutton-color and apple-mobile-web-app-status-bar-style. Why don't we just register and use those? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] `brand-color` meta extension
On Thu, Jun 26, 2014 at 10:35 AM, Marcos Caceres w...@marcosc.com wrote: Folks at Mozilla and Google would like to standardize the `brand-color` meta extension. The `brand-color` keyword has been added to the MetaExtensions WHATWG wiki and a rough spec is below (prepared by some folks at Google). # Overview The browser will use this brand color when distinct color is needed, i.e. it could be used as Web App’s title bar. Other browsers have similar features, but each defined as its own specific meta tag, IE uses mapplication-navbutton-color, Safari’s is apple-mobile-web-app-status-bar-style, they are all similar with brand-color, but have a little different usage. # Syntax meta name=brand-color content=#ff The content attribute can be any value defined in css color specification http://www.w3.org/TR/css3-color/ , the value might be adjusted by browser if it is not proper for display, i.e. extremely bright. the leading and trailing whitespace (defined in http://www.w3.org/TR/html401/struct/text.html) is permitted. The brand-color meta tag must be in head element, If there are multiple brand-color meta tags in head element, first one takes effect. Brand color could be changed by script, browser shall respect this change. Relevant issues/discussions: https://bugzilla.mozilla.org/show_bug.cgi?id=1013913 https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/IeXq74xUWzkJ Here's a first crack at a better spec: # Overview The 'brand-color' meta extension defines a suggested color that browsers and OSes displaying this page SHOULD use if they customize the display of individual pages in their UIs with varying colors. For example, a browser might color a web app's title bar with the specified 'brand-color' value, or use it as a color highlight in a task switcher. This feature has been developed in the past under multiple proprietary names, such as mapplication-navbutton-color for Internet Explorer and apple-mobile-web-app-status-bar-style for Mobile Safari. Authors MUST NOT use the proprietary variants of this meta extension. User agents that support proprietary variants of this meta extension must, if brand-color is specified, use brand-color for these purposes, and ignore any proprietary variants. # Syntax Example: meta name=brand-color content=#ff The content attribute for the brand-color meta extension can take any valid CSS color. To dfnfind a page's brand color/dfn: 1. Let varcandidate elements/var be a list of all the brand-color meta elements on the page, in document order. 2. For each varelement/var in varcandidate elements/var: 1. Parse a component value from varelement/var's content attribute value. [[css-syntax]] 2. Attempt to parse the result as a CSS color. If it succeeds, return the parsed color. Note: This implies that the first successfully parsed brand-color meta element defines the page's brand color. Any further brand-color meta elements have no effect. If brand-color meta elements are added or removed from the page, or have their content attribute changed, user agents MUST find the page's brand color again. When using the page's brand color, user agents MAY adjust the color in UA-defined ways to make it more suitable for particular uses. For example, if a UA intends to use the brand color as a background and display white text over it, it may use a darker variant of the brand color for that purpose, to ensure adequate contrast. ~TJ
Re: [whatwg] `brand-color` meta extension
On Thu, Jun 26, 2014 at 10:57 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: This feature has been developed in the past under multiple proprietary names, such as mapplication-navbutton-color for Internet Explorer and apple-mobile-web-app-status-bar-style for Mobile Safari. Authors MUST NOT use the proprietary variants of this meta extension. User agents that support proprietary variants of this meta extension must, if brand-color is specified, use brand-color for these purposes, and ignore any proprietary variants. In another thread, Hixie asks why we don't just standardize these proprietary variants. I think because they're horridly named is a sufficient answer, but there's a weaker proposal inside of that which I think is potentially valid: should we define that msapplication-navbutton-color and apple-mobile-web-app-status-bar-style are required-support variants? This requires a bit of additional parsing work, but it's not a big deal: * msapplication-navbutton-color only allows named and hex colors. * apple-mobile-web-app-status-bar-style appears to accept the values default, black, and black-translucent, which we can define as meaning, respectively, that the page has no brand color, that the brand color is black, or that the brand color is rgba(0,0,0,.5) (spitballing here, if someone can provide the real alpha that would be great). ~TJ
Re: [whatwg] brand-color meta extension
On Thu, 26 Jun 2014, Tao Bai wrote: The brand color is super set of them and not limited to use in the navbutton or status bar, furthermore, not all browsers have navbutton or status concept, it makes developer confused. I don't think it confuses authors any more, and possibly a lot less, than having three ways to do essentially the same thing. The msapplication-navbutton-color and apple-mobile-web-app-status-bar-style are prefix and browser specific, brand-color is general and could be standard for all browsers. That the keywords are prefixed is a mistake made by the relevant vendors, but I don't think it should stop us from using them if they are appropriate. Looking at those two keywords more closely, it seems that apple-mobile-web-app-status-bar-style wouldn't work because it doesn't take a CSS colour, it takes some specific keywords. However, msapplication-navbutton-color, and, maybe better, msapplication-TileColor, seem like pretty good fits to me. I don't really understand why one would avoid just reusing those, either instead of, or at least as well as, a newer more generic term. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] `brand-color` meta extension
On Thu, 26 Jun 2014, Tab Atkins Jr. wrote: On Thu, Jun 26, 2014 at 10:57 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: This feature has been developed in the past under multiple proprietary names, such as mapplication-navbutton-color for Internet Explorer and apple-mobile-web-app-status-bar-style for Mobile Safari. Authors MUST NOT use the proprietary variants of this meta extension. User agents that support proprietary variants of this meta extension must, if brand-color is specified, use brand-color for these purposes, and ignore any proprietary variants. In another thread, Hixie asks why we don't just standardize these proprietary variants. I think because they're horridly named is a sufficient answer, but there's a weaker proposal inside of that which I think is potentially valid: should we define that msapplication-navbutton-color and apple-mobile-web-app-status-bar-style are required-support variants? This requires a bit of additional parsing work, but it's not a big deal: * msapplication-navbutton-color only allows named and hex colors. * apple-mobile-web-app-status-bar-style appears to accept the values default, black, and black-translucent, which we can define as meaning, respectively, that the page has no brand color, that the brand color is black, or that the brand color is rgba(0,0,0,.5) (spitballing here, if someone can provide the real alpha that would be great). I think it would make sense to allow vendors to treat these all as independent values (in particular, we wouldn't want IE to be forced to extend their interpretation of msapplication-TileColor and msapplication-navbutton-color to be redundant), but I do think it would make sense to encourage UAs to draw colours from whichever values are provided, so that authors don't have to include different values for each browser. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 11:13 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Jun 2014, Tao Bai wrote: The brand color is super set of them and not limited to use in the navbutton or status bar, furthermore, not all browsers have navbutton or status concept, it makes developer confused. I don't think it confuses authors any more, and possibly a lot less, than having three ways to do essentially the same thing. The msapplication-navbutton-color and apple-mobile-web-app-status-bar-style are prefix and browser specific, brand-color is general and could be standard for all browsers. That the keywords are prefixed is a mistake made by the relevant vendors, but I don't think it should stop us from using them if they are appropriate. Looking at those two keywords more closely, it seems that apple-mobile-web-app-status-bar-style wouldn't work because it doesn't take a CSS colour, it takes some specific keywords. However, msapplication-navbutton-color, and, maybe better, msapplication-TileColor, seem like pretty good fits to me. I don't really understand why one would avoid just reusing those, either instead of, or at least as well as, a newer more generic term. If I were trying evangelize the use of this feature, I wouldn't want to recommend that web developers use a vendor-prefixed feature. I wish either Apple or Microsoft hadn't used a vendor-prefixed name, but they both did. Adam
Re: [whatwg] brand-color meta extension
I would like to reiterate that brand- is not a good prefix for this purpose. It has nothing to do with brands, and much more to do with the app or with system integration.
Re: [whatwg] `brand-color` meta extension
On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color We can better capture issues, etc. there. I also updated the Wiki to point there as the official version. We can put the right license and allow more people to edit the document on GH (it was a read only Google doc, which is not great). I'm not volunteer to edit it :) -- Marcos Caceres
Re: [whatwg] `brand-color` meta extension
On Jun 26, 2014, at 21:20, Marcos Caceres w...@marcosc.com wrote: On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Here's a first crack at a better spec: Moved your text here: https://github.com/whatwg/meta-brand-color Could we change the name to something a tad more neutral and extendable, e.g.: ua-background-color? Like that, people that use the Web for things other than brand promotion don't feel offended, and we can add ua-color once devs start requesting it while keeping consistent with CSS. --tobie
Re: [whatwg] `brand-color` meta extension
On June 26, 2014 at 2:17:22 PM, Ian Hickson (i...@hixie.ch) wrote: I think it would make sense to allow vendors to treat these all as independent values (in particular, we wouldn't want IE to be forced to extend their interpretation of msapplication-TileColor and msapplication-navbutton-color to be redundant), but I do think it would make sense to encourage UAs to draw colours from whichever values are provided, so that authors don't have to include different values for each browser. I would be in favor of this. It would be good to support the legacy content as its use on the Web is significant. Search I did back in Oct 2013 found these proprietary tags appeared on something like 1% of pages in Alexa's top 78K pages (specially the msTileColor one is quite popular). I don't have the data any more, unfortunately - but could get it again if needed. The thing would be to see if it really does make sense to reuse those things in contexts where `brand-color` is to be used and not produce unexpected results. -- Marcos Caceres
Re: [whatwg] brand-color meta extension
On 26 Jun 2014, at 20:45, Domenic Denicola dome...@domenicdenicola.com wrote: I would like to reiterate that brand- is not a good prefix for this purpose. It has nothing to do with brands, and much more to do with the app or with system integration. Major +1 here, seeing as this feedback was ignored before. Just `color` is simpler and makes much more sense. Interesting to see this would be only the second HTML attribute value to get parsed as a simple color (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) rather than a legacy color (the other one being `input type=color value=foo`).
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 1:24 PM, Mathias Bynens mathi...@opera.com wrote: Interesting to see this would be only the second HTML attribute value to get parsed as a simple color (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) rather than a legacy color (the other one being `input type=color value=foo`). The spec does not suggest that it would be a simple color; it says to allow any CSS color. simple color in HTML is solely a 6-digit hex color. ~TJ
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 1:33 PM, Mathias Bynens mathi...@opera.com wrote: On 26 Jun 2014, at 22:24, Mathias Bynens mathi...@opera.com wrote: Interesting to see this would be only the second HTML attribute value to get parsed as a simple color (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) rather than a legacy color (the other one being `input type=color value=foo`). Actually, the way it’s currently specced it wouldn’t be a parsed as a simple color value nor as a legacy color value. It should probably be one or the other (rather than introducing a third, new way to parse color values). https://github.com/whatwg/meta-brand-color/issues/1 Well, the third way is as CSS, which already exists in the platform. ~TJ
Re: [whatwg] brand-color meta extension
On Thu, Jun 26, 2014 at 10:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: The spec does not suggest that it would be a simple color; it says to allow any CSS color. simple color in HTML is solely a 6-digit hex color. In that case you want the same code path canvas uses. As well as setting some kind of initial color so currentColor makes sense. -- http://annevankesteren.nl/
Re: [whatwg] brand-color meta extension
On 26 Jun 2014, at 22:37, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Jun 26, 2014 at 1:33 PM, Mathias Bynens mathi...@opera.com wrote: On 26 Jun 2014, at 22:24, Mathias Bynens mathi...@opera.com wrote: Interesting to see this would be only the second HTML attribute value to get parsed as a simple color (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) rather than a legacy color (the other one being `input type=color value=foo`). Actually, the way it’s currently specced it wouldn’t be a parsed as a simple color value nor as a legacy color value. It should probably be one or the other (rather than introducing a third, new way to parse color values). https://github.com/whatwg/meta-brand-color/issues/1 Well, the third way is as CSS, which already exists in the platform. Parsing a legacy color value is also “as CSS”, with some extra fallback logic in case that fails (which is currently undefined in the `brand-color` spec), and this logic is already used for the majority of HTML attributes that represent a color value.