whatwg / meta-theme-color Goto Github PK

Rather than adding an extra meta tag for theme-color, couldn't this info be added to web application manifest specification?

Adding yet another meta tag to the page seems unnecessary and feels like going backwards. The first network packet is already too crowded.
Since this is a style and design feature - a presentation feature - it belongs in CSS.

You can find the discussion here -
https://groups.google.com/a/chromium.org/d/msg/blink-dev/nzRY-h_-_ig/WClEljhYFswJ

Basically, something like -

@media ui
{
 ::header, ::footer, ::top, ::bottom, ::chrome, ::brand,
 ::header:inactive, ::header:active, ::header:translucent
 {
  color: blue;
  background-color: white;
 }
}

@tobie says:

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.

the first successfully parsed "brand-color" meta element defines the page's "brand color". Any further "brand-color" meta elements have no effect.

This seems inconsistent with CSS and other meta tags like "viewport", where later duplicate definitions override earlier definitions.

For example if you append a new brand-color meta element to your without removing the old one, it will have no effect, whereas with viewport meta tags appending a new one would override the old one.

Perhaps the "finding the brand color" algorithm should be modified to iterate through in reverse document order?

Using the simple color microsyntax is a no-go, as it wouldn’t be the same as what’s currently in the spec.

Step 2 in the current spec says:

Attempt to parse the result as a CSS color. If it succeeds, return the parsed color.

What if it fails?

Is there a reason we can’t just use the legacy color value microsyntax (this deals with failing in the above case) rather than invent a third microsyntax for color parsing?

Chrome uses theme-color as a background color of browser's toolbar and background of background Android app's title bar.

Safari 9 uses theme-color as a foreground color of pinned icons.

For a brand like FT, which is black text on a branded "pink" background, this causes a conflict. We use the light "pink" as the theme-color which so far works great everywhere except the new Safari.

If we set theme-color to black to have an appropriate icon in Safari, it'll cause Chrome's UI to look unacceptably bad.

The spec doesn't define whether the theme color is supposed to be used as a foreground or background oclor, and whether it should be light or dark.

I think the spec must take a stance on that to stop different vendors interpreting this color in conflicting ways.

Because Safari's interpretation is new, and has other compatibility problems (caused by non-standard mask attribute) I hope Safari can still back out and the theme-color can be standardized to mean background color.

FT's logo is:

http://image.webservices.ft.com/v1/images/raw/fticon:brand-ft?format=jpg&bgcolor=fff1e0&quality=highest&source=example

and for the monochrome Safari icon we'd like to use:

http://image.webservices.ft.com/v1/images/raw/fticon:brand-ft?format=svg&source=example

but when Safari applies theme-color to it, it's a mess:

http://image.webservices.ft.com/v1/images/raw/fticon:brand-ft?format=svg&tint=fff1e0,fff1e0&source=example

@tabatkins says:

• "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).

Hixie says:

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.