Intent to Implement and ship: brand-color meta tag

[Tao Bai]

Contact emails

micha...@chromium.org, klo...@chromium.org

Spec

brand-color

<meta name=’brand-color’ content=’#0000ff’’>

The content attribute can be any named color or hex color value, the agent could adjust the color if it is not proper for display, i.e. extremely bright.

Summary

The brand-color is the color of the brand, browser may use it when a distinct color representation is needed.

Motivation

Supporting brand-color gives great user experience. IE 10 has meta tag mapplication-navbutton-color, Apple has apple-mobile-web-app-status-bar-style, they are similar to brand-color, but use in different places.

Compatibility Risk

Low.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

No, only be supported on Android, I didn’t see the reason for other platforms need this features.

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=383941.

Link to entry on the feature dashboard

http://www.chromestatus.com/features/5398016231997440

Requesting approval to ship?

Yes

[Mark Pilgrim]

What the actual fuck.

[Daniel Freedman]

If I understand correctly, this would allow a site to provide a background color for the Android notification area?

[Elliott Sprehn]

Where is the spec for this feature? Have you sent an email to public-webapps@ or whatwg@?

[Alex Russell]

I'm excited to see any new feature that enables the web platform to do what native apps can.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alex Russell]

Specs aren't requirements for intent-to-impl.

[Jochen Eisinger]

but this is an intent to ship, no?

[Elliott Sprehn]

On Thu, Jun 12, 2014 at 12:21 PM, Alex Russell <sligh...@google.com> wrote:

Specs aren't requirements for intent-to-impl.

 

You can't just start writing code without a design doc or something that explains what you're doing and why it's important.

[Alex Russell]

Ah, good catch.

[Tao Bai]

Here is spec https://docs.google.com/a/chromium.org/document/d/1OipHnEozoncRZpVqSr-Reawp5O0eLWk_ySg5J6T150s/edit?usp=sharing

The feature is pretty simple and has been covered in 'intent to implement ship' email.

Let me know if any information needed.

[Ian Hickson]

On Thu, 12 Jun 2014, Tao Bai wrote:
>
> Here is spec
> https://docs.google.com/a/chromium.org/document/d/1OipHnEozoncRZpVqSr-Reawp5O0eLWk_ySg5J6T150s/edit?usp=sharing

(This doesn't appear to be publicly viewable.)

Is there any reason we're not pursuing a standardisd approach here? If
there are multiple other vendors already doing this or something very
similar, it seems like we should either get with them and all implement
the same standardised thing, or, we should just implement their
existing extension(s), rather than introducing yet another one.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Grace Kloba]

The spec will be public available on the day of IO.

But we need to implement for the IO.

--
thanks, Grace

[Tab Atkins Jr.]

On Thu, Jun 12, 2014 at 2:21 PM, 'Grace Kloba' via blink-dev
<blin...@chromium.org> wrote:
> The spec will be public available on the day of IO.

That's absolutely ridiculous, and there's no need for such a
restriction. We're not doing anything secret here - the entire
justification for the feature is right there in the Intent. (And
having the document is a requirement *before* an intent to implement
can go through. Saying you won't post it publicly until after it's
already shipped is, um, not exactly in accordance with that.)

> But we need to implement for the IO.

Google IO is in two weeks; any implementation you do won't be anywhere
near Chrome proper by then, it'll just be in Canary. If that's the
constraint you might as well make the change in a private branch and
just present from that; it'll have the same relevance to the project.

~TJ

[mar...@marcosc.com]

On Thursday, June 12, 2014 3:21:28 PM UTC-4, Elliott Sprehn wrote:

Where is the spec for this feature? Have you sent an email to public-webapps@ or whatwg@?

Added a feature request for inclusion in W3C's webapps's manifest format:

https://github.com/w3c/manifest/issues/225

Happy to discuss details there if you guys want to standardize this as part of the manifest. On the Gecko side, we are generally not in favor of adding more meta tags to do this kind of thing, so it's pretty unlikely we would ship this feature as currently proposed here. If you guys are going to ship it anyway, then I kindly ask that you prefix it with `blink-` or something to clearly indicate that this is a proprietary feature. 

[Adam Barth]

On Thu Jun 12 2014 at 4:34:06 PM, <mar...@marcosc.com> wrote:

On Thursday, June 12, 2014 3:21:28 PM UTC-4, Elliott Sprehn wrote:

Where is the spec for this feature? Have you sent an email to public-webapps@ or whatwg@?

Added a feature request for inclusion in W3C's webapps's manifest format:

https://github.com/w3c/manifest/issues/225

Happy to discuss details there if you guys want to standardize this as part of the manifest.

Unfortunately, the manifest isn't a good fit for this feature because the manifest is fetched asynchronously.  If we want to use the brand-color to select the color of the tabstrip or the omnibox, we'll have a jaring experience if the color appears asynchronously after a network round-trip.

 

On the Gecko side, we are generally not in favor of adding more meta tags to do this kind of thing, so it's pretty unlikely we would ship this feature as currently proposed here.

Generally speaking, I agree that it makes sense to move as much from meta tags to manifest as practical, but we need to weigh each feature individually to understand what creates the best user experience.  In this case, the user experience would be markedly worse if we used the manifest.

 

If you guys are going to ship it anyway, then I kindly ask that you prefix it with `blink-` or something to clearly indicate that this is a proprietary feature.

We're unlikely to use a blink-prefixed name.  The feature isn't in any way proprietary just because Gecko isn't currently interested in implementing it.

In any case, the bar for introducing new meta extensions to the web platform is quite like (e.g., edit the MetaExtensions wiki page).  As far as I know, there isn't any tradition of waiting for consensus from other browser vendors in this area.

Adam

[Marcos Caceres]

On Thursday, June 12, 2014 at 7:43 PM, Adam Barth wrote:

> On Thu Jun 12 2014 at 4:34:06 PM, <mar...@marcosc.com (mailto:mar...@marcosc.com)> wrote:
> > On Thursday, June 12, 2014 3:21:28 PM UTC-4, Elliott Sprehn wrote:
> > > Where is the spec for this feature? Have you sent an email to public-webapps@ or whatwg@?
> >
> >
> >
> > Added a feature request for inclusion in W3C's webapps's manifest format:
> > https://github.com/w3c/manifest/issues/225
> >
> > Happy to discuss details there if you guys want to standardize this as part of the manifest.
>
> Unfortunately, the manifest isn't a good fit for this feature because the manifest is fetched asynchronously. If we want to use the brand-color to select the color of the tabstrip or the omnibox, we'll have a jaring experience if the color appears asynchronously after a network round-trip.

That's fair. it was not clear to me to what extent this was to be applied within the browser from the description given. I see what you mean. It might also be good to have this in the manifest regardless. Even if the manifest is acquired async, the experience doesn't need to be jarring as the color change could be animated gradually once the manifest is applied.

>
>
> > On the Gecko side, we are generally not in favor of adding more meta tags to do this kind of thing, so it's pretty unlikely we would ship this feature as currently proposed here.
>
>
> Generally speaking, I agree that it makes sense to move as much from meta tags to manifest as practical, but we need to weigh each feature individually to understand what creates the best user experience. In this case, the user experience would be markedly worse if we used the manifest.

Potentially, yes.

>
>
> > If you guys are going to ship it anyway, then I kindly ask that you prefix it with `blink-` or something to clearly indicate that this is a proprietary feature.
>
>
> We're unlikely to use a blink-prefixed name. The feature isn't in any way proprietary just because Gecko isn't currently interested in implementing it.

Sorry, I certainly didn't mean to imply this. When I say "proprietary" I mean that the there has not been any effort to standardize this through either the WHATWG or W3C. As is the case with both Apple's and Microsoft's proprietary solutions, hence their prefixes with "apple-" and "ms-".

> In any case, the bar for introducing new meta extensions to the web platform is quite like (e.g., edit the MetaExtensions wiki page). As far as I know, there isn't any tradition of waiting for consensus from other browser vendors in this area.

99% of the stuff in the `MetaExtensions` page is metadata that browsers ignore, but are used by other consumers. When it's stuff that browsers need to act on in an interoperable manner, I think it's prudent to go through the agreed upon channels for adding stuff to the platform. Notice that both Apple and Microsoft have prefixed their proprietary solutions as to not cause confusion for developers.

[Tab Atkins Jr.]

On Jun 12, 2014 4:43 PM, "'Adam Barth' via blink-dev" <blin...@chromium.org> wrote:
> In any case, the bar for introducing new meta extensions to the web platform is quite like (e.g., edit the MetaExtensions wiki page).  As far as I know, there isn't any tradition of waiting for consensus from other browser vendors in this area.

Most meta extensions are worthless for the greater web, and are used only by some tiny subset of pages in an intranet or single domain, intended to be processed by some tiny proprietary tool. That's quite a bit different from one like this, which is intended to be respected by browsers, and ideally by all browser's in the same way. Something like this ticks all the boxes for "cross-browser coordination warranted", like any other new web platform feature.

~TJ

[anewpag...@gmail.com]

There was a WHATWG thread about this already:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038886.html

In that recommendation, the properties "color" and "image" are introduced.

The name "brand-color" is strange and presumptuous to me.

On Thursday, June 12, 2014 2:17:06 PM UTC-4, Tao Bai wrote:

[Adam Barth]

On Thu Jun 12 2014 at 6:00:55 PM, <anewpag...@gmail.com> wrote:

There was a WHATWG thread about this already:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038886.html

Thanks for the pointer.

 

In that recommendation, the properties "color" and "image" are introduced.

Do you know if many sites adopted <meta name="color">?  It doesn't look like you added it to the MetaExtensions registry after proposing it on to the WhatWG.

I'm not sure I agree.  The <meta> element is an open extension point for the platform, much like URLs.  URLs have an elaborate registry process, which can involve big money for desirable names in the registry.  MetaExtensions have a much lighter-weight registration process, presumably because they aren't as hotly contested as domain names.  In particularly, the HTML Living Standard states:

"Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a type."

Certainly it makes sense to write detailed specifications and to consult with other browser vendors for MetaExtensions that have elaborate or subtle interaction with web content (e.g., <meta name="referrer"> has subtle interactions with rel="nofollow").

For trivial MetaExtensions like brand-color, I think it's important that we add it to the MetaExtensions registry and explain its semantics, but I don't think we need to go through the same extensive process we use when adding a new HTML element, JavaScript interface, or CSS property.

Adam

[Ben Wells]

On Fri, Jun 13, 2014 at 4:17 AM, Tao Bai <micha...@chromium.org> wrote:

Contact emails

micha...@chromium.org, klo...@chromium.org

Spec

brand-color

<meta name=’brand-color’ content=’#0000ff’’>

The content attribute can be any named color or hex color value, the agent could adjust the color if it is not proper for display, i.e. extremely bright.

Summary

The brand-color is the color of the brand, browser may use it when a distinct color representation is needed.

Motivation

Supporting brand-color gives great user experience. IE 10 has meta tag mapplication-navbutton-color, Apple has apple-mobile-web-app-status-bar-style, they are similar to brand-color, but use in different places.

Compatibility Risk

Low.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

No, only be supported on Android, I didn’t see the reason for other platforms need this features.

FWIW this could be useful on ChromeOS, and in future possibly the other desktop platforms.

[Domenic Denicola]

I definitely agree that "color" is much better than "brand-color." The idea that I wouldn't use this for my personal website, because only "brands" can use it, is silly.

[Kenji Baheux]

I agree that color sounds better than brand-color but it feels rather generic.

I almost took the 色彩検定 and from what I remember, a color scheme can generally be characterized by the following components:

• the subordinate, or base color
• the dominant color
• an accent, or highlight color

It sounds like we are talking about a "dominant-color" here.

Maybe it's worth considering the other 2 as well.

[Tobie Langel]

On Fri, Jun 13, 2014 at 7:35 AM, Kenji Baheux <kenji...@chromium.org> wrote:

I agree that color sounds better than brand-color but it feels rather generic.

I almost took the 色彩検定 and from what I remember, a color scheme can generally be characterized by the following components:

• the subordinate, or base color
• the dominant color
• an accent, or highlight color

It sounds like we are talking about a "dominant-color" here.

Maybe it's worth considering the other 2 as well. 

This conversation belongs in a Web standards mailing list.

--tobie

[PhistucK]

On Fri, Jun 13, 2014 at 3:02 AM, Marcos Caceres <mar...@marcosc.com> wrote:

Even if the manifest is acquired async, the experience doesn't need to be jarring as the color change could be animated gradually once the manifest is applied.

​I support this view as well. We should no longer encourage web developers to add more meta tags.

​

On Fri, Jun 13, 2014 at 3:08 AM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

Most meta extensions are worthless for the greater web, and are used only by some tiny subset of pages in an intranet or single domain, intended to be processed by some tiny proprietary tool. That's quite a bit different from one like this, which is intended to be respected by browsers, and ideally by all browser's in the same way. Something like this ticks all the boxes for "cross-browser coordination warranted", like any other new web platform feature.

I support this view as well. Polluting the web with more meta tags, specifically ones that apply to browsers and especially ones that potentially apply to more than one browser must be a result of consensus and not just a wiki addition. Web developers want interoperability, not adding more and more code because browsers could not (and never tried to) agree on a name or on a behavior.

A rhetorical question - have you seen the size of CSS files used by websites that support all of the (mobile and non mobile, iOS and non iOS) browsers since iOS 4 got released when they show you a CSS based gradient?

​

On Fri, Jun 13, 2014 at 5:18 AM, 'Adam Barth' via blink-dev <blin...@chromium.org> wrote:

"Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a type."

Just because this generic text is included, it does not mean it applies to any meta extension. There is a specific purpose for these meta extensions and brand-color (or whatever it will be called) goes well beyond that purpose.

☆PhistucK

[Adam Barth]

Listen, I understand the Grace and Tao have said some offensive things in this thread and that it's tempting to be indignant and to make their lives harder in response, but that's not the way to build a strong community.  If we follow that path, the next time they want to add functionality to the platform, they'll be reticent to engage with this community and will be more likely to hack in their feature at the wrong implementation layer.

I think everyone would agree that their goal is reasonable: given that browsers need to intrude on the screen real estate of web sites to identify the current origin, browsers should give web sites some ability to customize the visual appearance of that intrusion.  Rather than throwing up roadblocks to their success, we'll be better off in the long term if we try to engage in a constructive conversation.

Detailed replies inline.

On Thu Jun 12 2014 at 8:32:37 PM, Ben Wells <benw...@chromium.org> wrote:

FWIW this could be useful on ChromeOS, and in future possibly the other desktop platforms.

Yeah, general idea has come up many times in many contexts.  For example, the NTP used to use a heuristic to compute a "dominant color" for its display of frequently used web sites.  Tao and Grace have a particular use in mind for this information (which apparently we'll learn more about at I/O), but I think it makes sense to keep the semantics general so that the information can be used by for other purposes and by other browsers.

On Thu Jun 12 2014 at 10:12:34 PM, Domenic Denicola <dom...@domenicdenicola.com> wrote:

I definitely agree that "color" is much better than "brand-color." The idea that I wouldn't use this for my personal website, because only "brands" can use it, is silly.

Indeed, we could bikeshed the name endlessly.  You're welcome to use it on your personal web site.  Presumably to build your personal brand (e.g. http://en.wikipedia.org/wiki/Personal_branding).

On Thu Jun 12 2014 at 10:35:23 PM, Kenji Baheux <kenji...@chromium.org> wrote:

I agree that color sounds better than brand-color but it feels rather generic.

I almost took the 色彩検定 and from what I remember, a color scheme can generally be characterized by the following components:

• the subordinate, or base color
  
• the dominant color
• an accent, or highlight color

It sounds like we are talking about a "dominant-color" here.

Maybe it's worth considering the other 2 as well.

Yeah, in the future we might want to expand the control the website have over the browser's visual intrusion.  The approach that other browsers have taken is to make the semantics of the meta tag be "this is the color that goes here in the UI," which makes it difficult semantically to reuse that information for other purposes.  My understand is that's Tao's motivation for picking more abstract semantics.  However, the downside of that approach is that websites and brands are not composed of a single color, which makes it difficult to decide abstractly which to use.

On Thu Jun 12 2014 at 11:43:16 PM, Tobie Langel <tobie....@gmail.com> wrote:

This conversation belongs in a Web standards mailing list.

Yes, tiling the semantic space of brand colors is a complex topic that's worth discussing on web standards mailing lists.  Perhaps we should continue this part of the discussion in the WhatWG?

On Fri Jun 13 2014 at 12:57:19 AM, PhistucK <phis...@gmail.com> wrote:

​I support this view as well. We should no longer encourage web developers to add more meta tags.

I disagree with that as a general statement.  For example, if we were introducing the viewport meta tag today, should we put that information in the manifest instead of in a meta tag?  I don't think the manifest is a good fit for the viewport meta tag because the manifest is fetched asynchronously and the viewport information has a large influence over the visual appearance of the page.  If we put the viewport information in the manifest, we'd either need to block rendering on fetching the manifest or we'd need to flash a rendering of the page at the wrong width and scale while we waited for the manifest to arrive over the network.

The manifest doesn't address all the same use cases as meta elements.  For that reason, sometimes the best design for a feature will be to introduce a new meta element and sometimes the best design will be to introduce a new key in the manifest.  We'll need to study each feature individually and decide which mechanism best addresses its use case.

​

On Fri, Jun 13, 2014 at 3:08 AM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

Most meta extensions are worthless for the greater web, and are used only by some tiny subset of pages in an intranet or single domain, intended to be processed by some tiny proprietary tool. That's quite a bit different from one like this, which is intended to be respected by browsers, and ideally by all browser's in the same way. Something like this ticks all the boxes for "cross-browser coordination warranted", like any other new web platform feature.

I support this view as well. Polluting the web with more meta tags, specifically ones that apply to browsers and especially ones that potentially apply to more than one browser must be a result of consensus and not just a wiki addition.

Your view is different from the view of the specification that defines such things.  Perhaps we should continue this part of the discussion in the WhatWG?  One possible outcome is that we change the HTML Living Standard to define which sorts of MetaExtensions require agreement before being added to the registry and which sorts can be added at any time by anyone.

 

Web developers want interoperability, not adding more and more code because browsers could not (and never tried to) agree on a name or on a behavior.

I agree that interoperability is an important goal.  I wish Apple hadn't picked the name apple-mobile-web-app-status-bar-style for a similar MetaExtension in Safari.  We're hesitant to adopt that MetaExtension because (1) it's vendor-prefixed, (2) it's limited to mobile web apps (see Ben's comment earlier on this thread), and (3) it's prescriptive about the UI treatment rather than descriptive about the semantics of the color.

Maybe we'll fail to interest web developers in describing their brand-color, but maybe we'll get enough developers interested that Mobile Safari will add support for wiring brand-color up to their status bar style.  My hope is that we'll eventually end up with interoperability and authors will be able to supply fewer meta tags.

If I were working on this feature, I'd probably take the approach you describe of building consensus with other vendors before implementing the feature.  However, the people working on this feature haven't chosen this path.  We can speculate as to why, but I don't think that's a productive discussion to have on a public mailing list.  Instead, I'd like to be supportive and help them engage productively with the community so that in the future their more likely to take a more consensus-based approach.

A rhetorical question - have you seen the size of CSS files used by websites that support all of the (mobile and non mobile, iOS and non iOS) browsers since iOS 4 got released when they show you a CSS based gradient?

I agree that CSS gradients were poorly handled and have caused much sadness, but that's off-topic for this thread.

 

​

On Fri, Jun 13, 2014 at 5:18 AM, 'Adam Barth' via blink-dev <blin...@chromium.org> wrote:

"Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a type."

Just because this generic text is included, it does not mean it applies to any meta extension.

If you read what I wrote, I don't think it's appropriate to use this path for every MetaExtensions.  For example, I wouldn't support this path for viewport because it has elaborate interactions with web content.  However, brand-color has neither elaborate nor subtle interactions with web content.  It's just a color that browsers can use to theme their UI if they think it will improve the user experience.

There is a specific purpose for these meta extensions and brand-color (or whatever it will be called) goes well beyond that purpose.

I don't agree with a teleological view of the universe, but now we're talking philosophy.

Adam

[Brian Blakely]

Do you know if many sites adopted <meta name="color">?

No user agents have adopted it, so I doubt any sites have.

 

It doesn't look like you added it to the MetaExtensions registry after proposing it on to the WhatWG.

 

Yes, I was unfamiliar with the registry at the time and didn't quite know what to do with it.  Then the topic fell of my radar.

[PhistucK]

Thank you for taking the time to respond in detail! Comments inline.

☆PhistucK

The viewport example is actually a pretty bad example if I understand correctly, because it was not a result of a consensus (Apple simply introduced it and others just had to follow if they wanted the web pages to display properly in their browsers) and not only that - it is now being standardized as a CSS at-rule instead. This heavy control of the design and zoom (and more, I do not remember) does not count as metadata to me.

Regarding brand-color, perhaps this should also be an at-rule. It is a stylistic concept, after all. This can help make it nicely dynamic (if the page changes its background color to convey a certain idea, so would the brand color, in order to match the atmosphere) with a known API and use known properties that convey specific ideas (color for text color and icon tints and background or background-color specifically for background related styles).

​

On Fri, Jun 13, 2014 at 3:08 AM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

Most meta extensions are worthless for the greater web, and are used only by some tiny subset of pages in an intranet or single domain, intended to be processed by some tiny proprietary tool. That's quite a bit different from one like this, which is intended to be respected by browsers, and ideally by all browser's in the same way. Something like this ticks all the boxes for "cross-browser coordination warranted", like any other new web platform feature.

I support this view as well. Polluting the web with more meta tags, specifically ones that apply to browsers and especially ones that potentially apply to more than one browser must be a result of consensus and not just a wiki addition.

Your view is different from the view of the specification that defines such things.  Perhaps we should continue this part of the discussion in the WhatWG?  One possible outcome is that we change the HTML Living Standard to define which sorts of MetaExtensions require agreement before being added to the registry and which sorts can be added at any time by anyone.

Well, metadata is supposed to be metadata, not concepts that change something stylistic (for example). It has been abused to include these stuff, that is not metadata and adding them as such was simply abusing the whole purpose of meta tags.

 

 

Web developers want interoperability, not adding more and more code because browsers could not (and never tried to) agree on a name or on a behavior.

I agree that interoperability is an important goal.  I wish Apple hadn't picked the name apple-mobile-web-app-status-bar-style for a similar MetaExtension in Safari.  We're hesitant to adopt that MetaExtension because (1) it's vendor-prefixed, (2) it's limited to mobile web apps (see Ben's comment earlier on this thread), and (3) it's prescriptive about the UI treatment rather than descriptive about the semantics of the color.

​And I agree that it should not be adopted, of course.​

 

Maybe we'll fail to interest web developers in describing their brand-color, but maybe we'll get enough developers interested that Mobile Safari will add support for wiring brand-color up to their status bar style.  My hope is that we'll eventually end up with interoperability and authors will be able to supply fewer meta tags.

​I hope so, too - but not as a meta tag. As a last resort, maybe.

​

If I were working on this feature, I'd probably take the approach you describe of building consensus with other vendors before implementing the feature.  However, the people working on this feature haven't chosen this path.  We can speculate as to why, but I don't think that's a productive discussion to have on a public mailing list.  Instead, I'd like to be supportive and help them engage productively with the community so that in the future their more likely to take a more consensus-based approach.

However, if it is not standardized, this does not belong in Blink​, so I think this discussion (in the standards bodies) is actually crucial to the acceptance of the feature.

Yes, people should be encouraged to propose ideas here - of course - but we should direct them to the right place - the standards bodies - unless we are totally against that (though, even then, we should still direct them to the right place, because we do not know everything, obviously).

If you are talking about getting a general sense of the usefulness and acceptance of the feature among the community, then, yes, this is the right place - but I do no think an intent to implement (let alone an intent to ship) is the right approach for getting a general sense. A simple probing thread about it would have drawn much less rudeness from the community. I agree that the responses were out of line.

 

A rhetorical question - have you seen the size of CSS files used by websites that support all of the (mobile and non mobile, iOS and non iOS) browsers since iOS 4 got released when they show you a CSS based gradient?

I agree that CSS gradients were poorly handled and have caused much sadness, but that's off-topic for this thread.

 

​

On Fri, Jun 13, 2014 at 5:18 AM, 'Adam Barth' via blink-dev <blin...@chromium.org> wrote:

"Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a type."

Just because this generic text is included, it does not mean it applies to any meta extension.

If you read what I wrote, I don't think it's appropriate to use this path for every MetaExtensions.  For example, I wouldn't support this path for viewport because it has elaborate interactions with web content.  However, brand-color has neither elaborate nor subtle interactions with web content.  It's just a color that browsers can use to theme their UI if they think it will improve the user experience.

​The browser can use whatever it wants to do whatever it wants if it thinks it will improve the user experience, this is not really an argument...

A theme color such as this can affect the general (look and) feel ​of the page (if it is implemented by the browser) and can make the experience feel more streamlined, I would not count that as metadata, but this might be just me.

 

There is a specific purpose for these meta extensions and brand-color (or whatever it will be called) goes well beyond that purpose.

I don't agree with a teleological view of the universe, but now we're talking philosophy.

I agree, I was being too philosophical​ here since I was sort of referring to MetaExtensions as any meta tag that was not already standardized (due to too much usage, of course) or otherwise abused (viewport, apple-x-x-x, ms-x-x-x). Metadata is metadata. Perhaps my idea of metadata is different than yours, of course.

 

Adam

[Tab Atkins Jr.]

On Fri, Jun 13, 2014 at 9:06 AM, Adam Barth <aba...@google.com> wrote:
> On Thu Jun 12 2014 at 11:43:16 PM, Tobie Langel <tobie....@gmail.com>
> wrote:
>> This conversation belongs in a Web standards mailing list.
>
> Yes, tiling the semantic space of brand colors is a complex topic that's
> worth discussing on web standards mailing lists. Perhaps we should continue
> this part of the discussion in the WhatWG?

Sarcasm is not helpful here, Adam.

>> On Fri, Jun 13, 2014 at 3:08 AM, Tab Atkins Jr. <jacka...@gmail.com>
>> wrote:
>>>
>>> Most meta extensions are worthless for the greater web, and are used only
>>> by some tiny subset of pages in an intranet or single domain, intended to be
>>> processed by some tiny proprietary tool. That's quite a bit different from
>>> one like this, which is intended to be respected by browsers, and ideally by
>>> all browser's in the same way. Something like this ticks all the boxes for
>>> "cross-browser coordination warranted", like any other new web platform
>>> feature.
>>
>> I support this view as well. Polluting the web with more meta tags,
>> specifically ones that apply to browsers and especially ones that
>> potentially apply to more than one browser must be a result of consensus and
>> not just a wiki addition.
>
> Your view is different from the view of the specification that defines such
> things. Perhaps we should continue this part of the discussion in the
> WhatWG? One possible outcome is that we change the HTML Living Standard to
> define which sorts of MetaExtensions require agreement before being added to
> the registry and which sorts can be added at any time by anyone.

No, it's not. The HTML spec deferring to the wiki for name
registration is for random proprietary <meta> values. Adding new
*browser-supported* <meta> values is a completely different beast, and
you know that; attempting to point to definitions to make your point
is not a useful move. I'm not sure why you're trying to say that it's
unimportant to get at least *minimal* consensus between implementors
on a name for something that is expected to be implemented by multiple
browsers. This is something which was proposed yesterday with zero
announcement, no design doc (*still* no design doc, that is, which
violates our processes), and no indication that this was even
mentioned to other browsers. It's clearly not proprietary, but you're
acting like it is.

This isn't hard. You don't need to get a spec to Rec. This just needs
to follow the project's established processes, and standard
good-neighbor behaviors.

~TJ

[Adam Barth]

On Fri Jun 13 2014 at 11:44:53 AM, PhistucK <phis...@gmail.com> wrote:

Thank you for taking the time to respond in detail! Comments inline.

Thank you for taking time out of your schedule to contribute to these discussions.

 

On Fri, Jun 13, 2014 at 7:06 PM, Adam Barth <aba...@google.com> wrote:

On Fri Jun 13 2014 at 12:57:19 AM, PhistucK <phis...@gmail.com> wrote:

I support this view as well. We should no longer encourage web developers to add more meta tags.

I disagree with that as a general statement.  For example, if we were introducing the viewport meta tag today, should we put that information in the manifest instead of in a meta tag?  I don't think the manifest is a good fit for the viewport meta tag because the manifest is fetched asynchronously and the viewport information has a large influence over the visual appearance of the page.  If we put the viewport information in the manifest, we'd either need to block rendering on fetching the manifest or we'd need to flash a rendering of the page at the wrong width and scale while we waited for the manifest to arrive over the network.

The manifest doesn't address all the same use cases as meta elements.  For that reason, sometimes the best design for a feature will be to introduce a new meta element and sometimes the best design will be to introduce a new key in the manifest.  We'll need to study each feature individually and decide which mechanism best addresses its use case.

The viewport example is actually a pretty bad example if I understand correctly, because it was not a result of a consensus (Apple simply introduced it and others just had to follow if they wanted the web pages to display properly in their browsers) and not only that - it is now being standardized as a CSS at-rule instead. This heavy control of the design and zoom (and more, I do not remember) does not count as metadata to me.

Yes, I wish Apple had built more consensus around viewport before shipping it, for the reasons you state.

Regarding brand-color, perhaps this should also be an at-rule. It is a stylistic concept, after all. This can help make it nicely dynamic (if the page changes its background color to convey a certain idea, so would the brand color, in order to match the atmosphere) with a known API and use known properties that convey specific ideas (color for text color and icon tints and background or background-color specifically for background related styles).

Perhaps if this feature is popular it would be worth adding CSS to control it.  I think makes sense for the first iteration to be simple though.

Your view is different from the view of the specification that defines such things.  Perhaps we should continue this part of the discussion in the WhatWG?  One possible outcome is that we change the HTML Living Standard to define which sorts of MetaExtensions require agreement before being added to the registry and which sorts can be added at any time by anyone.

Well, metadata is supposed to be metadata, not concepts that change something stylistic (for example). It has been abused to include these stuff, that is not metadata and adding them as such was simply abusing the whole purpose of meta tags.

That comes back to teleology.  MetaExtensions are an open extension point for the platform that many people have used for many different purposes.  In fact, both Safari and IE have MetaExtensions for something very similar to brand-color.  I wish they had picked more general names for their MetaExtensions so that we could reuse them for this purpose, but claiming that brand-color is somehow an unprecedented abusive MetaExtensions seems a bit far fetched.

 

If I were working on this feature, I'd probably take the approach you describe of building consensus with other vendors before implementing the feature.  However, the people working on this feature haven't chosen this path.  We can speculate as to why, but I don't think that's a productive discussion to have on a public mailing list.  Instead, I'd like to be supportive and help them engage productively with the community so that in the future their more likely to take a more consensus-based approach.

However, if it is not standardized, this does not belong in Blink, so I think this discussion (in the standards bodies) is actually crucial to the acceptance of the feature.

The goal we've set for ourselves is to play by the rules and to be transparent about what we're doing.  The rules for HTML elements, CSS properties, JavaScript interfaces (and the like) are different than the rules for MetaExtensions.

 

Yes, people should be encouraged to propose ideas here - of course - but we should direct them to the right place - the standards bodies - unless we are totally against that (though, even then, we should still direct them to the right place, because we do not know everything, obviously).

If you are talking about getting a general sense of the usefulness and acceptance of the feature among the community, then, yes, this is the right place - but I do no think an intent to implement (let alone an intent to ship) is the right approach for getting a general sense. A simple probing thread about it would have drawn much less rudeness from the community. I agree that the responses were out of line.

I agree that this topic could have been handled better on all sides.

 

On Fri Jun 13 2014 at 12:32:49 PM, <fri...@jeka.info> wrote:

Am Freitag, 13. Juni 2014 20:44:56 UTC+2 schrieb PhistucK:

Regarding brand-color, perhaps this should also be an at-rule. It is a stylistic concept, after all.

Indeed, it's about styling and belongs to CSS. And styling just a single color doesn't cover much usecases. 

It should be a special kind of Media Feature that requires a separate stylesheet but is invalid inside other stylesheets.

So you can do things like this simply in markup without mixing up UI and content styling:

<style media="UI-mobile"> /* add styling for your brand-color here */ </style>

or

<link rel=stylesheet media="UI-mobile" href="...">

@media UI-mobile {} (or whatever name the beast could have) should be invalid (ignored) inside content stylesheets.

You could even imagine exposing a number of pseudoclasses to let the page style particular aspects of the browser's UI.

One way to view MetaExtensions is as experiments.  Do authors want to have influence over the color of the browser's UI?  If so, we can invest more in this area and build more complex mechanism that give authors more control.  If not, brand-color will join the long list of not-very-popular MetaExtensions, which it won't do much (if any) harm to the platform.

On Fri Jun 13 2014 at 3:21:41 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

>> On Fri, Jun 13, 2014 at 3:08 AM, Tab Atkins Jr. <jacka...@gmail.com>
>> wrote:
>>>
>>> Most meta extensions are worthless for the greater web, and are used only
>>> by some tiny subset of pages in an intranet or single domain, intended to be
>>> processed by some tiny proprietary tool. That's quite a bit different from
>>> one like this, which is intended to be respected by browsers, and ideally by
>>> all browser's in the same way. Something like this ticks all the boxes for
>>> "cross-browser coordination warranted", like any other new web platform
>>> feature.
>>
>> I support this view as well. Polluting the web with more meta tags,
>> specifically ones that apply to browsers and especially ones that
>> potentially apply to more than one browser must be a result of consensus and
>> not just a wiki addition.
>
> Your view is different from the view of the specification that defines such
> things.  Perhaps we should continue this part of the discussion in the
> WhatWG?  One possible outcome is that we change the HTML Living Standard to
> define which sorts of MetaExtensions require agreement before being added to
> the registry and which sorts can be added at any time by anyone.

No, it's not.  The HTML spec deferring to the wiki for name
registration is for random proprietary <meta> values.  Adding new
*browser-supported* <meta> values is a completely different beast, and
you know that;

Where is a distinction between browser-support and other sorts of MetaExtensions?  Certainly there are W3C specifications that define MetaExtensions, but the MetaExtensions wiki also contains a large number of entries that are browser-supported.  Here are some examples:

* apple-*

* application-url

* handheldfriendly

* mobile-web-app-capable

* mobileoptimized

* msapplication-*

* referrer

* viewport

 

attempting to point to definitions to make your point
is not a useful move.

I find this comment very mysterious.  The HTML specification sets the rules for the MetaExtensions registry.

 

I'm not sure why you're trying to say that it's
unimportant to get at least *minimal* consensus between implementors
on a name for something that is expected to be implemented by multiple
browsers. This is something which was proposed yesterday with zero
announcement, no design doc (*still* no design doc, that is, which
violates our processes), and no indication that this was even
mentioned to other browsers.  It's clearly not proprietary, but you're
acting like it is.

This isn't hard. You don't need to get a spec to Rec.  This just needs
to follow the project's established processes, and standard
good-neighbor behaviors.

I think these comments are the core of the issue.

If you or I was working on this feature, I have no doubt that we'd do more to build consensus among implementers before moving forward.  However, the folks working on this feature aren't you or I.  They're folks who are working on some other part of the product and they're feature has one tiny piece that touches the web platform.  They could have left this piece off and not given authors any control over these colors, but they wanted to do something nice for developers and give them some input.

Now, these folks asked, "what do we need to do to give this control to web developers?"  Well, according to the HTML standard, what they need to do is register their MetaExtensions in the wiki and provide a description of what it means.

Your point is that's the bare minimum, and you're right.  You're saying that we should hold ourselves to a higher standard and do more than just the bare minimum:

https://www.youtube.com/watch?v=cg-6wbETtbo

I would certainly prefer that we did more than the bare minimum, but I don't see how to justify forcing them to wear more pieces of flare.

Another way to look at this issue is to think about which battles are worth fighting.  Do you really want to go to the mat about this trivial MetaExtension?  That doesn't seem worthwhile because the stakes are so low and their hearts are in the right place.  Instead, I'd rather go to mat about Geofencing.  From my perspective, it's much more important that the folks working on Geofencing engage with the Geolocation working group and end up with an API that's implemented on iOS, Firefox OS, and Windows Phone.

I'm sorry if that seems like selling out some idealism for pragmatism, but I think that's the right tradeoff here.

Adam

[PhistucK]

Except referrer (I think?), most of the examples you pointed out from MetaExtensions are indeed proprietary. If they happened to have gained support from more than one browser, it was just to align with the (proprietary) competitive features that that browser decided to introduce in order not to lose edge and not because they were standardized as such.

I might be missing your point there...?

☆PhistucK

[Adam Barth]

What do you mean by proprietary?

Adam

[PhistucK]

For example, those ms-x are proprietary features - it is a Microsoft specific feature, non standardized or proposed, prefixed. Same for apple-x.

And viewport was already mentioned as such.

☆PhistucK

[Elliott Sprehn]

I met with the API owners this week to discuss brand-color, and community driven features like <meta> where the spec leaves an open ended extension point.

Open ended extension points are interesting because the spec has a much lower bar for adding something new, and because the community and browser vendors drive what features are available by merely updating a wiki or registry without having to get consensus from a standards body.

First, I think it's important to note that while HTML allows anyone to define a new meta name, the HTML spec does require you to add an entry to the wiki, and to provide a link to a spec [a] (even if it's just another wiki page). brand-color does not currently meet either of those requirements.

Even if we meet those requirements, browser vendors are adding things to the namespace without a formal process which has lead to vendor prefixing and a lack of collaboration on what's being shipped.

The intent email is a great example where MS, Apple and Google are all solving similar problems, but not collaborating so authors end up forced to add big blocks of <meta>'s with each vendor's extensions. This process has also lead to things like meta viewport being poorly defined for parsing and error recovery. Worse when we did want to spec it we had to reverse-engineer Safari's parsing algorithm [b].

Given these issues, and Blink's desire to support an interoperable web, the API owners (and myself) have created a simple set of requirements to ship community driven features:

1) Don't prefix your feature.

2) Write a public spec, even if it's a paragraph on a wiki page.

3) Add your feature to the community registry and link the spec.

4) Email the whatwg@ to get opinions.

The spec can be very simple. In the case of brand-color it probably just wants to say it accepts any CSS color value and link to the css color spec [c].

Vendor consensus is not required to ship, but notifying the standards group is. That prevents having important discussions on blink-dev@, and makes sure that when other vendors go to implement similar features they're aware that we're already shipping something and can avoid adding more prefixed things.

Currently brand-color does not meet requirements 2-4 so it's not ready to ship, but should be fine once they are.

[a] http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names

[b] http://dev.w3.org/csswg/css-device-adapt/#parsing-algorithm

[c] http://www.w3.org/TR/css3-color/

[Marcos Caceres]

On Friday, June 20, 2014 at 10:46 PM, Elliott Sprehn wrote:

> Given these issues, and Blink's desire to support an interoperable web, the API owners (and myself) have created a simple set of requirements to ship community driven features:
>
> 1) Don't prefix your feature.
> 2) Write a public spec, even if it's a paragraph on a wiki page.
> 3) Add your feature to the community registry and link the spec.
> 4) Email the whatwg@ to get opinions.
>
> The spec can be very simple. In the case of brand-color it probably just wants to say it accepts any CSS color value and link to the css color spec [c].
>
> Vendor consensus is not required to ship, but notifying the standards group is. That prevents having important discussions on blink-dev@, and makes sure that when other vendors go to implement similar features they're aware that we're already shipping something and can avoid adding more prefixed things.
>
> Currently brand-color does not meet requirements 2-4 so it's not ready to ship, but should be fine once they are.

From the Mozilla side, we are also interested in shipping something extremely similar [1]. We would like to get agreement on the name and the use of CSS color values (so to avoid prefixing). We'd also like to make sure we have agreement on the use cases (our apps team want to dynamically update the color, based on what the user might be doing) so we want to make sure that we are aligned there.

Anyway, let's take this to the WHATWG and do as you suggest above - if you guys have some kind of rough spec already, even better. Otherwise, let's put something in a google doc and be done :)


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1013913

[Tao Bai]

It has been added in http://wiki.whatwg.org/wiki/MetaExtensions, and there is a link to the spec.

- Michael

[Tab Atkins Jr.]

On Wed, Jun 25, 2014 at 3:02 PM, Tao Bai <micha...@google.com> wrote:
> It has been added in http://wiki.whatwg.org/wiki/MetaExtensions, and there
> is a link to the spec.

Please send an email to wha...@whatwg.org about this, as there are
important details of this spec that are undefined and need
clarification, but blink-dev is not the appropriate place for that
kind of discussion.

(The first thing that jumps out at me is the line "the value might be
adjusted by browser if it is not proper for display". It's unclear
whether this means the browser will just use a similar nearby color in
some circumstances, or if the color it uses is actually reflected back
into the 'content' attribute at some point.)

~TJ

[Tao Bai]

The requirements 2-4 have done, is it fine to ship this feature?

- Michael

[Peter Beverloo]

People in various forums have given the feedback that they don't think "brand-color" is an appropriate name. Could you share your thoughts on that?

Thanks,

Peter

[Tobie Langel]

On Mon, Jun 30, 2014 at 7:50 PM, Peter Beverloo <pe...@chromium.org> wrote:

People in various forums have given the feedback that they don't think "brand-color" is an appropriate name. Could you share your thoughts on that?

FYI, there's a WHATWG spec stub right here:

https://github.com/whatwg/meta-brand-color

…and a number of open-issues, including one specifically about the name:

https://github.com/whatwg/meta-brand-color/issues/2

Hope this helps.

--tobie

 

[Tao Bai]

I felt like, there will have endless discussion out there, do we have to land this feature until all issues are resolved?

- Michael

[Marcos Caceres]

On Monday, June 30, 2014 at 2:37 PM, 'Tao Bai' via blink-dev wrote:

> I felt like, there will have endless discussion out there, do we have to land this feature until all issues are resolved?
>

No, it's not requirement to resolve all the issues. The point is to make sure that there is a adequate response for the technical issues that get raised. It might be that there is something that hasn't been thought about - particularly as it might affect interop across UAs.

--
Marcos Caceres

[Eric Seidel]

I'm not quite sure why we're even discussing this here.

This feature has basically zero affect on Blink. (I doubt you'll even
add Blink code to support it since it's always possible to just run JS
'document.getElementsByTagName('meta') and search for the one you
want.)

I'm sure there is a relevant web-standards discussion to be had. But
that discussion is about getting two browser/OS vendors to agree to
look for the same meta tag. Since there aren't necessarily the
relevant vendor representatives on this list, this is probably the
wrong place to have that discussion.

As far as I'm concerned, feel free to write Android/Chrome code to
look for "brand-color" in web pages and change the look of your
Blink-based browser based on the content of that "branch-color" tag.
In my opinion the name isn't worth bike-shedding over. If you feel
you need my LGTM to do that, you certainly have it. :)

I think if there is further discussion to be had here, we should take
it to a more neutral forum, and leave this list to discuss more
pressing technical issues of Blink.

Thank you Tao for the nicely written proposal.

Eric

[Tao Bai]

I need 3 API owners' approval to ship it.

- Michael

[Tao Bai]

BTW, the proposal has been revised by Tab, Thanks for his great effort.

- Michael

[Adam Barth]

On 1404157477109, Eric Seidel <ese...@chromium.org> wrote:

I'm not quite sure why we're even discussing this here.

This feature has basically zero affect on Blink.  (I doubt you'll even
add Blink code to support it since it's always possible to just run JS
'document.getElementsByTagName('meta') and search for the one you
want.)

I'm sure there is a relevant web-standards discussion to be had.  But
that discussion is about getting two browser/OS vendors to agree to
look for the same meta tag.  Since there aren't necessarily the
relevant vendor representatives on this list, this is probably the
wrong place to have that discussion.

When the API OWNERS met to discuss this proposal, we agreed on the following guidelines:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/nzRY-h_-_ig/KeRMwHE23JMJ

As far as I'm concerned, feel free to write Android/Chrome code to
look for "brand-color" in web pages and change the look of your
Blink-based browser based on the content of that "branch-color" tag.

In the meeting, we discussed that this approach would a number of negative consequences, which Elliott outlined in his email.

In my opinion the name isn't worth bike-shedding over.  If you feel
you need my LGTM to do that, you certainly have it. :)

I think if there is further discussion to be had here, we should take
it to a more neutral forum, and leave this list to discuss more
pressing technical issues of Blink.

Yes, we've asked that the technical discussion move to the WhatWG list where other vendors (e.g., Marcos) can participate on an equal footing.  The reason this discussion is resurfacing on this list is that Tao has done what we've asked and is now asking for approval to ship the feature.

Adam

[Tao Bai]

Hi API owners,

Can this feature be shipped now? it needs in M37/

- Michael

[Darin Fisher]

It looks like you have completed the recommended steps. The only remaining issue is the ongoing debate on the name. I'm with Eric in feeling that the name isn't worth bike-shedding over. The name works for me. If someone comes up with another name that more browsers support, we should consider recognizing that one too.

LGTM

[Tao Bai]

Thanks, I have 2 approvals, and need one more.

- Michael

[Ojan Vafai]

LGTM as well. Reading the github thread, I don't believe the name matters that much. All the proposed names (including brand-color) meet the main concern of a web standard, which is getting interoperable implementations of the platform. 

The majority of website authors and browser vendors won't care whether this is called brand-color or some other *-color name. Lets use our time discussing more pressing web standards concerns.

[Tao Bai]

As Adam's suggestion, we wanted this feature to be developer friendly and reviewed the suggested name, finally, came out 'theme-color'.

- Michael

[Elliott Sprehn]

On Wed, Jul 9, 2014 at 11:12 AM, 'Tao Bai' via blink-dev <blin...@chromium.org> wrote:

As Adam's suggestion, we wanted this feature to be developer friendly and reviewed the suggested name, finally, came out 'theme-color'.

Sounds reasonable to me. Given that we now have a spec, a public discussion, and some agreement on naming this seems good to ship.

- E

[Ojan Vafai]

Still LGTM.

[Darin Fisher]

Ditto, LGTM

[Jochen Eisinger]

LGTM3

[Tab Atkins Jr.]

On Wed, Jul 9, 2014 at 11:26 AM, Elliott Sprehn <esp...@chromium.org> wrote:

Note, though, that I have no idea precisely what our implementation
actually does. The spec clarified several aspects of the original
(extremely vague) design document, but Tao and others didn't
participate in that process, and I have no idea if they match the spec
or if they do something completely different that could also have been
inferred from the original vague wording. (When I wrote the spec, I
just came up with what I thought was the most reasonable
interpretation.)

I'd prefer it if we didn't get into another meta-viewport debacle,
where everyone implemented different unspecified behavior and had to
reverse-engineer each other. This is admittedly a simpler feature,
but it's more than large enough to admit a lot of weird corner cases.
It would be nice to get clarification from Tao on how well our impl
matches the spec.

~TJ

[Adam Barth]

Tao can confirm, but I believe https://github.com/whatwg/meta-theme-color is up to date.  Currently we only recognize theme-color meta tags in the head, but that's something we should fix in our implementation rather than in the spec.

Adam

[Tab Atkins Jr.]

Assuming Tao confirms, I'm happy with this.

~TJ

[Tao Bai]

Yes, the implementation pretty matches the spec except the head element thing mentioned by Adam.

- Michael

[mar...@marcosc.com]

On Tuesday, July 15, 2014 6:46:55 PM UTC-4, Tao Bai wrote:

Yes, the implementation pretty matches the spec except the head element thing mentioned by Adam.

Did you guys ship this already? We are interested on the Moz side on some details.

[Adam Barth]

I believe the feature is in M37 but the UX doesn't do anything any released OS versions.

Adam

[Ehsan Akhgari]

Hmm, so is the tag used for other purposes in Chrome in M37?  Or does Chrome just recognize the tag but not do anything with the information obtained through it?

Thanks!
--

Ehsan

[Adam Barth]

In the future, Chrome 37 might run on operating systems that have not been released as of now.  Hopefully the feature will do something then...

Adam

[Tao Bai]

The feature is launched in m39

http://www.androidpolice.com/2014/11/10/chrome-v39-on-lollipop-supports-custom-multitasking-headerstatus-bar-colors-with-a-simple-html-tag/

[PhistucK]

As theme-color (not brand-color) -

http://updates.html5rocks.com/2014/11/Support-for-theme-color-in-Chrome-39-for-Android

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.