Spec -webkit-text-fill-color

[miketaylr]

It seems we need -webkit-text-fill-color: transparent so -webkit-background-clip: text does what is intended. Pretty much every example I see uses 'transparent', though WebKit and Blink allow you to specify any <color> for truly ugly artistic effects.

Introduced here: https://webkit.org/blog/85/introducing-text-stroke/ (with -webkit-text-stroke-color, -webkit-text-stroke-width, and the shorthand -webkit-text-stroke)

It may make sense to just spec transparent for now, so the main use case of #26 can work, but we can crawl some corpus data to better understand usage in the wild.

See also: https://www.chromestatus.com/metrics/css/popularity#webkit-text-fill-color -- this is twice as popular as the other 3 non-standard text props.

[miketaylr]

Messing with http://codepen.io/miketaylr/pen/eJbawd, it seems this might do the same thing as color: transparent? Needs more testing, but it would be nice to just map from one to the other.

[davatron5000]

Dusting off my 2010 brain here. color: transparent would do the same thing, but in order to supply fallbacks for non-Webkit browsers you didn't want to set color. Trying to do everything through the -webkit properties helped scope the technique to only Webkit.

http://trentwalton.com/2010/03/24/css3-background-clip-text/

[miketaylr]

Ah, cool. Thanks @davatron5000!

I was wondering if we could get away with speccing -webkit-text-fill-color: transparent as an alias for color: transparent (which makes it pretty darn simple to implement). It seems like mayyyybe. I need to do more research on https://webkit.org/blog/85/introducing-text-stroke/ and usage in the wild.

[davatron5000]

If it helps, it appears Edge does the alias thing for -webkit-text-fill-color and Trent's demo is broke because it doesn't support background-clip.

[miketaylr]

Cool, good to know.

[miketaylr]

Some tests: http://codepen.io/miketaylr/pen/RrvgMO

Seems like this plan will mostly work for UAs that don't already support -webkit-text-fill-color (which is the point...). There is the surprising property that the cascade doesn't work as I thought it would. The following two examples are always blue in the linked Pen.

color: red; 
-webkit-text-fill-color: blue;

-webkit-text-fill-color: blue; 
color: red;

[miketaylr]

OK, so the cascade bit complicates the simple alias solution to this.

Looking at the code on stripe.com, this example would work, but only by accident. If the devs had put color: #c5b3cb; after -webkit-text-fill-color: transparent;, the effect wouldn't work as desired (again, in the scenario that -webkit-text-fill-color is a simple alias for color.

body#checkout #slide0 > p {
    top: 270px;
    font-size: 34px;
    line-height: 1.2;
    color: #c5b3cb;
    background: -webkit-linear-gradient(0,rgba(180,180,250,0.7),#fadce5 50%,#fff);
    -webkit-background-clip: text;
    -webkit-text-fill-color: transparent;
}

Crazy idea: spec -webkit-text-fill-color as an alias to color but its value always is treated as !important. 👻

[miketaylr]

Less crazy idea: let's take a look at usage in the wild. Every blog post I've read on -webkit-text-fill-color recommends putting color before, as a fallback for non-supporting UAs. If people actually did that, the simple approach would be nicer.

[miketaylr]

Some examples from Bugzilla bugs, which seem OK. Need to look at corpus data.

q.p-pullquote, .m-entry-body q, .m-feature-body q, q.pullquote, .p-pullquote, .m-entry-body q, .m-feature-body q {
    display: block;
    color: #e60000;
    background: -webkit-gradient(linear, left top, left bottom, from(#e60000), to(#ff5a00));
    -webkit-background-clip: text;
    -webkit-text-fill-color: transparent;
    font-size: 1.5em;
    padding: 0;
    margin: 0 0 .1em 0;
    font-family: Georgia,serif;
    font-weight: normal;
}

h1 {
    background:-webkit-linear-gradient(#eee, #333);
    -moz-background-clip:text;
    -webkit-background-clip:text;
    -webkit-text-fill-color: transparent;
  }

[miketaylr]

OK, some results.

From the following search query: https://github.com/search?l=css&p=40&q=-webkit-text-fill-color%3A&ref=searchresults&type=Code&utf8=%E2%9C%93, I looked at the first 400 of some ~30,000 results.

Here's the things that stick out as interesting from the small sample:

Instances where color comes after and there are different values:

1):

sel {
 background: -webkit-linear-gradient(#fefffe, #858585);
 background: -o-linear-gradient(transparent, transparent);/* remove gradient in OPERA */
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
    color: #dfdfdf;
    text-shadow: none !important;
}

(Also of interest is the Opera workaround, from when Presto added basic support for -webkit- prefixed gradients -- but not -webkit-text-fill-color or background-clip: text)

2)

sel {
    font-size: 2.8em;
    font-family: "brevia",sans-serif;
    text-shadow: 0 1px 2px rgba(30, 30, 30, 0.3);
    background: -webkit-gradient(linear, left top, left bottom, from(#ffffff), to(#fafafa));
    -webkit-background-clip: text;
    -webkit-text-fill-color: transparent;
    text-align: center;
    font-weight: 400;
    color: #FFF;
}

3)

sel {
  background-color: #333;
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
  font-size: 16px;
  font-family: 'Brush Script MT', cursive;
  text-align: center;
  font-family: helvetica, arial, sans-serif;
  color: #4e5665;
}

4)

.Intro-fancy {
  background-image: linear-gradient(92deg,#f35626,#feab3a);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
  animation: hue 60s infinite linear;
  color: #f35626;
}

Instances where color comes after -webkit-text-fill-color, but they have the same value.

1)

sel {
    -webkit-text-fill-color: black !important;
    color: black !important;
}

2)

.stroked-blue {
  -webkit-text-stroke: 1px #1f6fd9;
  -webkit-text-fill-color: #1f6fd9;
  color: #1f6fd9;
}

(without -webkit-text-stroke support, the text will look slightly less "thick". But close enough...)

3)

sel {
  -webkit-text-fill-color : rgb(211, 211, 211);
  color: rgb(211, 211, 211);
  -webkit-transition: height 70ms ease;
  -moz-transition: height 70ms ease;
  -ms-transition: height 70ms ease;
  transition: height 70ms ease;
  overflow: hidden;
}

And finally, one interesting (or weird) result because the developer is using these as aliases already

3)

@-webkit-keyframes colorcycle {
    0%  { -webkit-text-fill-color: red;}
    20% { -webkit-text-fill-color: green;}
    40% { -webkit-text-fill-color: orange;}
    60% { -webkit-text-fill-color: purple;}
    80% { -webkit-text-fill-color: yellow;}
    100% { -webkit-text-fill-color: blue; }
}

@-moz-keyframes colorcycle {
    0%  { color: red;}
    20% { color: green;}
    40% { color: orange;}
    60% { color: purple;}
    80% { color: yellow;}
    100% { color: blue; }
}

Based on this quick sample of 400, 1% of the results would be broken by the simple alias approach. That's kind of better than I was expecting.

[miketaylr]

So to summarize, there's two possible ways I see to define -webkit-text-fill-color:

1. As a simple alias to color.
2. As an alias to color, but with a magical implied !important for its value.

1 seems simplest to implement, but has the downside that not everything works. That might be OK if it's indeed fixing 99% of usage that was broken before.

@dholbert, as someone who hacks on CSS parsers and layout what do you think?

There's a ton to read here, #38 (comment) is probably the most important to get up to speed.

[dholbert]

I think option (2) shouldn't be too hard, and I can see it being necessary for us to trump later color values, to make this feature actually usefully work. I'll bet authors who specify background:-webkit-gradient(...);-webkit-background-clip:text; -webkit-text-fill-color:transparent are likely to also specify a color alongside that CSS (and maybe after it), as a fallback for browsers that don't support webkit prefixes. And if we want to usefully support this feature, then we probably don't want to end up taking that fallback path.

So - I think I'm on board with option (2).

[miketaylr]

Cool, thanks for the feedback @dholbert!

[dholbert]

Actually, I think this might be specced incorrectly, from a "how it works in Chrome" standpoint. As I've just noted in bug 1247777, it seems to me that this really works like so:
(1) -webkit-text-fill-color is its own property, and it's what actually determines the color of text (always) -- not the color property.
(2) The initial value of -webkit-text-fill-color is currentColor (so, when it's unset, it takes whatever value is given in color).

See the bug for more details & justification. @miketaylr, does this make sense to you & is it consistent with your testing? (and perhaps the spec needs a tweak?)

[miketaylr]

Yep, I think you're right. Thank you!

[miketaylr]

OK, made suggested changes to actually reflect what Blink and WebKit do.