556145 - Placeholder text default style should use opacity instead of GrayText

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Mounir Lamouri (:mounir)]

We had a discussion in www-style and it looks like opacity could be a good replacement for GrayText. Indeed, we can assume the placeholder to be visible in (mostly) all situations while using opacity.

Comment 1

[Mounir Lamouri (:mounir)]

Adding faaborg in CC as he may have an opinion about this change.

Comment 2

[Dão Gottwald [:dao]]

Why is there a need for a replacement?

You're probably going to run into a Cairo+ClearType bug with opacity on Win XP.

Comment 3

[Mounir Lamouri (:mounir)]

Some people in www-style realized most UA have a grey placeholder which needs with no doubt to be customized when the background isn't white. Having a placeholder defined with opacity will not change so much than a grey one for a black on white configuration but may be very helpful for anything else because the author may not have to care about the placeholder color which is going to inherit from the text color.
Anyway, this in not changing the need of customization but it may help to have a common behavior between browsers.

What would be the symptoms of the "Cairo+ClearType bug with opacity on Win XP" ? (I'm will test)

Comment 4

[Dão Gottwald [:dao]]

(In reply to comment #3)
> Some people in www-style realized most UA have a grey placeholder which needs
> with no doubt to be customized when the background isn't white. Having a
> placeholder defined with opacity will not change so much than a grey one for a
> black on white configuration but may be very helpful for anything else because
> the author may not have to care about the placeholder color which is going to
> inherit from the text color.

Authors who set a placeholder and modify the background color should specify the placeholder color. I don't really see a problem with that. It's pretty straightforward and not a new pattern.

Using opacity is probably going to be wrong for OS themes with explicitly low contrast (for aesthetics) or high contrast (for accessibility), in case background-color and color haven't been modified.

> Anyway, this in not changing the need of customization but it may help to have
> a common behavior between browsers.

But it would require you to set opacity:1 when setting a placeholder color, right? Sounds inconvenient.

> What would be the symptoms of the "Cairo+ClearType bug with opacity on Win XP"
> ? (I'm will test)

See bug 363861.

Comment 5

[Mounir Lamouri (:mounir)]

So, I'm getting back on that because it might be interesting to change the default value for Firefox 4 if we want to.
The idea is to change :-moz-placeholder default value from color: GrayText; to opacity: 0.8; (or another opacity value...).

Pros:
- Should work for most all placeholder usage (ie. if the color isn't black on white the opacity might do the deal).

Cons:
- Might be unintuitive for authors to reset this (they could think about color) ;
- Might be an a11y issue because GrayText is a system color and changing the opacity might have a much more random result for some screens with hight/low contrast ;
- There are some small graphics bugs related to opacity.

I do not think the graphic bug (we can/should fix them) or the fact that changing color isn't going to revert the default style is a big deal.
However, I'm concerned by the a11y issue. Someone knows if that will be a big deal for low/hight contrast profile? At least for black on white with opacity=0.8. IIRC, opacity 0.8 is very similar from a classic GrayText. So I guess it might be a problem if those profile do not use the default GrayText value for some valid reasons.

Btw, I think using opacity makes more sense for people with different default colors. If someone browse the web with the text is red and the backgrounds in blue he might more understand if a placeholder is a semi-transparent red than a gray (or whatever the value for GrayText is for them).

Comment 6

[Tantek Çelik]

I agree with changing the placeholder styling to use opacity rather than GrayText.

For the cons:

1. The unintuitive for authors part can be partially addressed with in DevMo documentation of :-moz-placeholder

2. Re: a11y: It may actually be better for accessibility, as the current technique of *only* setting the foreground color without setting the background color is known to be a potential source of accessibility problems:

http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F24

OTOH, using opacity, whatever the combination of high contrast foreground/background color is chosen by the author, the contrast will at least be similar (and more fitting with the author's overall design), whereas there is less chance of GrayText being high contrast on some random author chosen background, not to mention that if the authors has highly stylized their form controls, the GrayText will likely look ugly.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I prefer leaving it as a color rather than changing it to opacity, largely since (a) I think authors will find it unintuitive to style a color by using opacity and (b) authors who are using this new feature will test with it to see what it looks like.

Comment 8

[Adam]

As I explain in bug 597382 comment 4, for GNOME the GrayText value comes from INSENSITIVE, which is not intended to be used in a sensitive GtkEntry.  A few applications roll their own hinting (equivalent to placeholder here).  Except for those uses, the INSENSITIVE text is only used on truly insensitive elements, and their background is not the Input box background.  

Likewise, the description of GrayText in CSS System Colors (http://www.w3.org/TR/CSS2/ui.html#system-colors) indicates it is for disabled text, not for hinting/placeholders.  I'm not sure if that is relevant as CSS System Colors are deprecated in CSS3.

Comment 9

[Mounir Lamouri (:mounir)]

Attachment: Patch

Comment 10

[Mounir Lamouri (:mounir)]

Comment on attachment 679149 [details] [diff] [review]
Patch

David, could you confirm this is fine regarding a11y?

Comment 11

[Mounir Lamouri (:mounir)]

You should note that bug 737786 is ready to land and makes this bug solvable. However, to prevent breaking websites too much, I want to land both bugs at the same time so, ideally, users of :-moz-placeholder will not fallback to a black color but to something that should be the right thing.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 679149 [details] [diff] [review]
Patch

r=me

Comment 13

[Dão Gottwald [:dao]]

Will this disable sub-pixel anti-aliasing for the placeholder text?

Comment 14

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 679149 [details] [diff] [review]
Patch

Review of attachment 679149 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for owning this tricky bug Mounir. Do you have a screen shot handy?

::: layout/reftests/forms/placeholder/placeholder-style.css
@@ +1,3 @@
>  textarea.placeholder,
>  input.placeholder {
> +  opacity: 0.4;

Curious why you went with 0.4? (0.54 was tested in bug 618260)

Comment 15

[Mounir Lamouri (:mounir)]

Roc, do you happen to know the answer of the question asked in comment 13?

Comment 16

[Mounir Lamouri (:mounir)]

(In reply to David Bolter [:davidb] from comment #14)
> Comment on attachment 679149 [details] [diff] [review]
> Patch
> 
> Review of attachment 679149 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks for owning this tricky bug Mounir. Do you have a screen shot handy?
> 
> ::: layout/reftests/forms/placeholder/placeholder-style.css
> @@ +1,3 @@
> >  textarea.placeholder,
> >  input.placeholder {
> > +  opacity: 0.4;
> 
> Curious why you went with 0.4? (0.54 was tested in bug 618260)

Ah! I remembered someone wrote something but I wasn't able to find where.
I don't mind changing the value - I used 0.4 because it is giving a value very close to what GrayText gives me on my system. I can use 0.54 if that seems better. We can also tweak the value later if we want to.

Comment 17

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 679149 [details] [diff] [review]
Patch

Sigh, there is likely to be controversy at least until a11y spec opinions converge. Either way your work here should actually improve/fix accessibility for some graytext cases so r almost= me.

I'd go with 0.54 for now since that is tested. The 508 refresh will help inform any tweaks (or larger changes) we may need to make in the future.

I tested your try build (thanks) in Windows HCM (high contrast mode) and the opacity remains which is probably not ideal. Is there an easy way to keep the existing (GrayText) behaviour for Windows HCM? I can't remember if we have a css selector for that...

Comment 18

[Mounir Lamouri (:mounir)]

(In reply to David Bolter [:davidb] from comment #17)
> Comment on attachment 679149 [details] [diff] [review]
> Patch
> 
> Sigh, there is likely to be controversy at least until a11y spec opinions
> converge. Either way your work here should actually improve/fix
> accessibility for some graytext cases so r almost= me.

Does that mean r+ or not r+? :)

> I'd go with 0.54 for now since that is tested. The 508 refresh will help
> inform any tweaks (or larger changes) we may need to make in the future.

I'm fine with that.

> I tested your try build (thanks) in Windows HCM (high contrast mode) and the
> opacity remains which is probably not ideal. Is there an easy way to keep
> the existing (GrayText) behaviour for Windows HCM? I can't remember if we
> have a css selector for that...

I wrote a patch that allows accessing the placeholder text to style it via a pseudo-element (::-moz-placeholder).

I feel like having two different set of UA styling is less than ideal because it might confuse users. However, I believe using opacity is better in most cases but if that's a clear no-go regarding a11y, I will just keep graytext and close that bug.

Comment 19

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 679149 [details] [diff] [review]
Patch

OK r=me. Let's try this and weigh the pushback in Aurora+ cycles. (Windows HCM is a bit messed up so I'd recommend third party tech to those users anyway)

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Dão Gottwald [:dao] from comment #13)
> Will this disable sub-pixel anti-aliasing for the placeholder text?

I think only in some rare situations.

Comment 21

[Mounir Lamouri (:mounir)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f3faea7f5112

Comment 22

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/f3faea7f5112

Comment 23

[Binyamin]

This approach is buggy. Be consistent with other browsers and apply just color like rgba(211,211,211,.54).

The current approach cases "bug" when user applies different color for ::-moz-placeholder - the user-agent opacity must be removed. Why not just allow developer to decide what color to use without applying user-agent opacity?

Comment 24

[(no longer active)]

I had no involvement in this bug.  Apparently there was a discussion where browser vendors agreed on this.  Perhaps roc remembers more.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Binyamin, consider the simple case of a site that does this:

  <style>
    input { color: yellow; background: rgb(165,165,165); }
  </style>
  <input placeholder="Enter stuff here">

Try that in a few different browsers.

The point is that setting opacity on the placeholder but otherwise using the input color allows it to gracefully handle the case of the input color being styled.  Using a fixed placeholder color means that any time you style the input color you also have to separately style the placeholder color, which web authors routinely forget to do, causing accessibility problems for users.

You're right that for authors who _want_ to change the placeholder color independently of the input color this requires a bit of extra work, but this is a much rarer case than the case of just changing the input color.

It looks like IE solves this problem by just using the input color for the placeholder, but then the placeholder text doesn't have the "faded" look web authors seem to want by default...

Comment 26

[Binyamin]

(In reply to Boris Zbarsky [:bz] from comment #25)
> Binyamin, consider the simple case of a site that does this:
> 
>   <style>
>     input { color: yellow; background: rgb(165,165,165); }
>   </style>
>   <input placeholder="Enter stuff here">
> 
> Try that in a few different browsers.

Different browsers has different approach. Chrome applies text color "rgb(169,169,169)" where Firefox and IE applies "inherit", only Firefox applies opacity too.

I agree that Firefox has the best approach and UX benefit for now, Keep till standards says anything else. By the way colors on Firefox are brighter-darker than on other browser and opacity: 0.54; is not enough, see http://jsbin.com/fesunu/1/quiet.

Comment 27

[Boris Zbarsky [:bzbarsky]]

I'm not sure what information you're asking for.  If you want something from me, please do say what the something is.

Comment 28

[Mikola]

+1 to Binyamin. Opacity for ::-moz-placeholder must be removed.
For example, I want to get color #008080 for <input> placeholder. And this color is used for other elements and it must be THE SAME.

input:-ms-input-placeholder {color: #008080}
input::-webkit-input-placeholder {color: #008080}
input::-moz-placeholder {color: #008080}

For IE I get color #008080,
for Chrome I get color #008080,
but for Mozilla I get color #75bbbb.

Is it a some kind of a joke? Or you think that developer should calculate NECESSARY color considering opacity? I think it is logical to type for placeholder in CSS the same color as I want to get.

Comment 29

[Boris Zbarsky [:bzbarsky]]

input::-moz-placeholder {color: #008080; opacity: 1; }

Comment 30

[Mikola]

(In reply to Not doing reviews right now from comment #29)
> input::-moz-placeholder {color: #008080; opacity: 1; }
Thanks.
This is the right solution for me.