CSS color is ignored on placeholder text in WebKit and Blink, applied in Gecko

[karlcow]

https://html.spec.whatwg.org/multipage/rendering.html#the-input-element-as-a-text-entry-widget

An input element whose type attribute is in the Text, Search, Telephone, URL, or E-mail state, is expected to render as an 'inline-block' box depicting a text control.

The section on rendering doesn't define the relation of placeholder text to color defined in CSS.
While Blink and WebKit ignores the color: color_value, Gecko creates a colored placeholder text.

This creates a Web Compatibility issue on deviantart
webcompat/web-bugs#5895

enu.mobileMenu .mobileSearch .searchWrapper input {
   /*… cut …*/
    color: transparent;
}

There's an open issue being discussed for Gecko
https://bugzilla.mozilla.org/show_bug.cgi?id=1357674

[bzbarsky]

Note that Gecko's behavior is based on accessibility considerations: it makes it much harder to accidentally create an unreadable placeholder when a page style backgrounds and colors across the board.

[annevk]

@bzbarsky it seems however to have the opposite effect in the example in OP.

Wasn't there a placeholder pseudo-class or pseudo-element? Did that ever get standardized and is that relevant here?

[bzbarsky]

@bzbarsky it seems however to have the opposite effect in the example in OP.

Well, yes, if you explicitly style the text in your input as "transparent", clearly you're not very interested in anyone reading it in the first place. Also, if you look at the webcompat report, they have other rules that are supposed to override it, but they don't manage to spell "::placeholder" right, so those rules get ignored.

Wasn't there a placeholder pseudo-class or pseudo-element?

There is a pseudo-element for the placeholder and a pseudo-class for an input with a placeholder. See https://drafts.csswg.org/css-pseudo-4/#placeholder-pseudo and https://drafts.csswg.org/selectors-4/#placeholder respectively.

Did that ever get standardized

It's in whatever state CSSWG stuff is in. I think these two are considered fairly stable. In terms of browser support, see http://caniuse.com/#feat=css-placeholder and http://caniuse.com/#feat=css-placeholder-shown respectively. The former is supported by everyone except Edge without prefix as of a few weeks ago, and by Edge with prefix. The latter is supported by everyone except Edge without prefix.

is that relevant here?

Sort of, in that the page in question tries to style the placeholder using various nonstandard prefix stuff and gets it wrong because the webkit thing is ::-webkit-input-placeholder but the standard thing is ::placeholder and the moz thing is therefore ::-moz-placeholder, but they assumed that the moz thing would look like the webkit thing and decided to just screw over Edge entirely...

Anyway, all the tools people need to get whatever styling they want are present, if they just use them correctly. The only thing missing is an interoperable set of UA styles. ;)

[annevk]

Okay, so am I correct that Gecko currently doesn't have default styles for either the pseudo-element or class? And that it's arguably better that way?

@tkent-google would you have opinions on this on behalf of Chrome? @hober on behalf of Safari?

(I guess a slightly different-but-related topic would be whether HTML needs to more explicitly define when this pseudo-element and class apply. It seems there's some potential for confusion there given the rather opaque descriptions in CSS.)

[bzbarsky]

Okay, so am I correct that Gecko currently doesn't have default styles for either the pseudo-element or class?

Gecko has all sorts of default styles for the the pseudo-element. Most of these are implementation-specific in some sense, because they rely on the details of the internal structure of <input> in Gecko, and apply to a similar non-web-exposed pseudo-element that represents the normal value. For example, we have text-decoration: inherit to make text-decoration on an input paint on the text inside it, white-space: pre for obvious reasons, etc. There's lots of rendering behavior here that I'm pretty sure the web assumes and HTML doesn't spec. For example, I see nothing in the spec about the white-space bit.

There is also one ::placeholder-specific UA rule:

input::placeholder,
textarea::placeholder {
  opacity: 0.54;
}

which allows users to visually distinguish placeholder text from a value while keeping their colors generally aligned in the common case.

[domenic]

I filed web-platform-tests/wpt#5625 as a broader issue to discuss whether we should be testing these UA stylesheet things comprehensively; people here may be interested.

I don't really know what to do about this particular issue.

[tkent-google]

@tkent-google would you have opinions on this on behalf of Chrome?

It's nice to define ::placeholder UA stylesheet in the HTML standard for better interoperability. Chrome will follow it.
However, because web authors can avoid this easily, i think this issue doesn't have high priority.

[karlcow]

so following up on @domenic the CSSWG has decided that UA stylesheet should be part of web platform tests.

@tkent-google is it a matter of creating a pull request on the HTML standard or does it need more discussion?

Default: As of today latest version of each browser (Canary, Tech Preview, Nightly), except Edge

in Gecko
https://dxr.mozilla.org/mozilla-central/rev/79d3e25106f8eb369dde6a47199547d131af8d3d/layout/style/res/forms.css

In Chromium (Blink)
https://chromium.googlesource.com/chromium/src.git/+/63.0.3239.86/third_party/WebKit/Source/core/css/html.css

In WebKit
WebKit/WebKit@eb08ce8

[domenic]

@tkent-google is out of office at least until January, but my reading is that he'd support efforts to converge here.

I think the first step is deciding which rules exactly were you thinking would be included in the UA stylesheet. Given your links, there is definitely some divergence; what were you hoping to include?

[karlcow]

Sniff sniff more interop issues.
https://codepen.io/webcompat/pen/aqWaYJ

https://webcompat.com/issues/12991
https://webcompat.com/issues/13236

[karlcow]

Another one https://webcompat.com/issues/17190

[domenic]

Is there a concrete proposal for a spec change to the UA stylesheet for all browsers to converge on?

[fvsch]

Current browser styles seem to be:

Engine	Source	Color	Opacity
Gecko	https://searchfox.org/mozilla-central/rev/029d9d2477ef0232bb08db94696badddec4d5bda/layout/style/res/forms.css#215-218	inherited	0.54
WebKit	https://github.com/WebKit/webkit/blob/65619d485251a3ffd87b48ab29b342956f3dcdc7/Source/WebCore/css/html.css#L672-L676	darkGray (#a9a9a9)	1
Blink	https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/resources/html.css?q=html.css&sq=package:chromium&g=0&l=512-516	#757575	1

Looks like WebKit diverged from Blink, using a less accessible color (2.8:1 contrast ratio on a white background).

If a web developer wants to use the same style in all browsers and to normalize on an existing browser's styles, they would need to use one of these three options:

/* Gecko style */
::placeholder {
  color: inherit;
  opacity: 0.54;
}

/* WebKit style */
::placeholder {
  color: #9a9a9a;
  opacity: 1;
}

/* Blink style */
::placeholder {
  color: #757575;
  opacity: 1;
}

One issue with the opacity approach is that partial opacity can show up as areas with increased contrast in some scripts such as Arabic. I remember similar issues with variable fonts.

This is likely a bug in engines, and probably platform-specific. On macOS, both Chrome and Firefox are affected, while Safari doesn't show this issue.

[sideshowbarker]

Given the info in #2561 (comment) about “One issue with the opacity approach is that partial opacity can show up as areas with increased contrast in some scripts such as Arabic”, I guess it also makes sense to make sure @whatwg/i18n are following this.

[xfq]

Related info from the W3C i18n WG:

• https://w3c.github.io/alreq/#h_joining_and_transparency
• https://w3c.github.io/alreq/gap-analysis/#cursive_opacity

Can anyone help add the i18n-tracker and i18n-alreq labels to this issue?

[sideshowbarker]

Can anyone help add the i18n-tracker and i18n-alreq labels to this issue?

yup, added

[othermaciej]

It seems better for the default style for ::placeholder to be a color rather than an opacity. Opacity can have all kinds of strange effects depending on the background. It alters anti-aliasing. And it may not be obvious that it's necessary to undo it to get a totally custom color. Or at the very least, defining a custom color for the placeholder would require setting two properties instead of one. We don't use the pattern of opacity to create colors computed from other colors elsewhere afaik.

It would be unfortunate to have to pick a specific shade of grey, since browsers may wish to follow a system convention on this by default, but if the UA stylesheet is to be tested, this seems like fair game.

(Also it seems like the real interop problem here might be the exposed name of the placeholder pseudo-class/pseudo-element.)

[fvsch]

(Also it seems like the real interop problem here might be the exposed name of the placeholder pseudo-class/pseudo-element.)

This might be sorted, since both ::placeholder and :placeholder-shown have been supported for a while in WebKit, Blink and Gecko.