1357674 - CSS color is ignored on placeholder text in WebKit and Blink

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[Karl Dubost💡 :karlcow]

Attachment: Rendering in Firefox, Safari and Opera (left to right)

Rendering in Firefox, Safari and Opera (left to right)

This is a spin off of https://webcompat.com/issues/5895

The test case is 
<input placeholder="search" style="color:transparent;"/>
<input placeholder="search" style="color:red;"/>

in Gecko, the placeholder text is transparent (invisible) and red

in WebKit and Blink, the text is a shade of grey. color is ignored.

A test
https://codepen.io/webcompat/pen/bWEEJv

Comment 1

[Mike Taylor [:miketaylr]]

Attachment: chrome mobile vs fennec

This looks super busted on the site it was reported from.

Comment 2

[Mike Taylor [:miketaylr]]

AFAICT, rendering/color of placeholder is not defined (maybe I'm looking in the wrong place). https://html.spec.whatwg.org/multipage/forms.html#the-placeholder-attribute

Is that correct, Anne?

Comment 3

[Anne (:annevk)]

If HTML defined anything, it would be at https://html.spec.whatwg.org/multipage/rendering.html, but there's nothing there. However, this is a duplicate of bug 734337 looks like.

Comment 4

[Karl Dubost💡 :karlcow]

Ah thanks Anne. I had missed this one. Bug 734337

Comment 6

[Karl Dubost💡 :karlcow]

As we have more context here. I kept this one opened.

Comment 7

[Karl Dubost💡 :karlcow]

Filed an issue on the HTML spec
https://github.com/whatwg/html/issues/2561

Comment 8

[Boris Zbarsky [:bzbarsky]]

> As we have more context here.

Er... Bug 734337 wasn't actually a duplicate of this bug.  In fact that bug was worksforme as filed; it was describing a problem specific to our old :-moz-placeholder pseudoclass, which hasn't existed since we moved to a ::placeholder pseudo-element.

Anyway, the Blink/WebKit behavior here is an accessibility problem because it requires anyone changing an input background color to remember to change the color of both the text _and_ the placeholder.  Otherwise you can easily get unreadable placeholders.  That's why we use the same color for the input text and the placeholder and just make the latter a bit transparent.

Comment 9

[Karl Dubost💡 :karlcow]

Ah? Though the initial description is basically the same than this one with the same test. 

Agreed on the s/accessibility/visibility/ issue, 
but currently if you look at what is happening for Firefox 

   color:transparent;

makes the placeholder text completely vanish. 

We could try to open bugs on Chromium and WebKit to see if they are willing to change the behavior, but then they would have the same issue than us for the transparent value and it means the site would break.

I wish there was a way to say when you see "transparent": 
  color: "something with good enough contrast" :)


> Anyway, the Blink/WebKit behavior here is an accessibility 
> problem because it requires anyone changing an input background 
> color to remember to change the color of both the text _and_ the placeholder.

I guess with our current market share situation, people notice it on Chrome/Safari but not on Firefox. (mobile)


Note that I will try to reach out the Web site too.

Comment 10

[Karl Dubost💡 :karlcow]

Oh I had missed something and Boris' comment rang a (cow)bell. Thanks. 

Their CSS is 


menu.mobileMenu .mobileSearch .searchWrapper input:focus::-webkit-input-placeholder {
	opacity:0
}
menu.mobileMenu .mobileSearch .searchWrapper input:focus::-moz-input-placeholder {
	opacity:0
}
menu.mobileMenu .mobileSearch .searchWrapper input::-webkit-input-placeholder {
	font-family:Calibre-Bold;
	font-size:72px;
	line-height:72px;
	color:rgba(255,255,255,.5)
}
menu.mobileMenu .mobileSearch .searchWrapper input::-moz-input-placeholder {
	font-family:Calibre-Bold;
	font-size:72px;
	color:rgba(255,255,255,.5)
}


::-moz-input-placeholder instead of ::-moz-placeholder

This fixes the issue on this site.

Maybe the bug should be, we might have to implement 
::-moz-input-placeholder as an alias of ::-moz-placeholder


/me is checking the definition for WebKit.


Yeah WebKit is ::-webkit-input-placeholder
https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-input-placeholder

And Microsoft is :-ms-input-placeholder
https://developer.mozilla.org/en-US/docs/Web/CSS/:-ms-input-placeholder


Sigh!

Comment 11

[Karl Dubost💡 :karlcow]

And it seems it's a thing.
https://github.com/search?l=CSS&q=%3A%3A-moz-input-placeholder&type=Code&utf8=%E2%9C%93

Let me undup.

Comment 12

[Karl Dubost💡 :karlcow]

I wonder if we should open a separate bug on implementing

aliases for 

* ::-moz-input-placeholder    -> ::placeholder

and maybe (though I need to find cases where it would be specified without the other)
* ::-webkit-input-placeholder -> ::placeholder

Comment 13

[Karl Dubost💡 :karlcow]

In https://webcompat.com/issues/7639
slightly related.


::-webkit-input-placeholder {
 color:#d1d1d1
}
:-moz-placeholder {
 color:#d1d1d1
}
::-moz-placeholder {
 color:#d1d1d1;
}
:-ms-input-placeholder {
 color:#d1d1d1
}

Farther down the css, we can find…

*::-moz-placeholder {
 /*! color:#353535!important; */
 /*! opacity: 1; */
}

This set of rules is working in Firefox and this is the one taking over instead of the color:#d1d1d1

And in addition to that in Firefox, the default CSS has

input::placeholder,
textarea::placeholder {
  opacity: 0.54;
}
They should just specify
::-moz-placeholder {
color:#d1d1d1;
opacity: 1;
}

The opacity by default in Blink and WebKit is 1. 
I will contact them. But just giving that as another data point for placeholder and web compat.

Comment 14

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is an assigned P1 bug without activity in two weeks. 

If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword.

Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.

Comment 15

[Ya-Chieh Wu (inactive)]

I have looked into the report site, and it seems that the issue does not exist anymore.
And just read from the feedback of Comment 8, it does make sense that we do this for a reason (for accessibility). 
I think we can probably close this issue as WFM.

But just read the karl's comment above, it does look like that there has something
we can do for input-placeholder but not as the bug filed here. (we probably can file a separate
bug to describe the impact of input-placeholder for something. I am not very sure of.
karl might have better studies.)  

If anyone has any concerns, please leave feedback or I will close this on Monday.

Comment 16

[Karl Dubost💡 :karlcow]

So in 

* The CSS WG agreed that User Agent Stylesheets should be tested.
  https://github.com/w3c/web-platform-tests/issues/5625
* Someone at Google thinks it would be good to define what it should for interop
  https://github.com/whatwg/html/issues/2561#issuecomment-296130295

I added pointers to the different CSS.

Agreed about filing a separate bug for standardization of ::placeholder.

Comment 17

[Karl Dubost💡 :karlcow]

another case of CSS color being interpreted. 
https://webcompat.com/issues/13236

Comment 18

[Karl Dubost💡 :karlcow]

Another case of CSS color and placeholder where Firefox seems to introduce a bit of opacity when the background-color is specified. :/
https://webcompat.com/issues/12991

See also https://codepen.io/webcompat/pen/aqWaYJ