Placeholder text default style should use opacity instead of GrayText

RESOLVED FIXED in mozilla19

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: mounir, Assigned: mounir)

Tracking

Trunk
mozilla19
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

7 years ago
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.
(Assignee)

Comment 1

7 years ago
Adding faaborg in CC as he may have an opinion about this change.
Why is there a need for a replacement?

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

Comment 3

7 years ago
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)
(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.
(Assignee)

Comment 5

7 years ago
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

7 years ago
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.
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

7 years ago
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.

Updated

5 years ago
Depends on: 737786
Blocks: 765646
(Assignee)

Comment 9

5 years ago
Created attachment 679149 [details] [diff] [review]
Patch
Attachment #679149 - Flags: review?(bzbarsky)
(Assignee)

Comment 10

5 years ago
Comment on attachment 679149 [details] [diff] [review]
Patch

David, could you confirm this is fine regarding a11y?
Attachment #679149 - Flags: review?(dbolter)
(Assignee)

Comment 11

5 years ago
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 on attachment 679149 [details] [diff] [review]
Patch

r=me
Attachment #679149 - Flags: review?(bzbarsky) → review+
Will this disable sub-pixel anti-aliasing for the placeholder text?
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)
(Assignee)

Updated

5 years ago
Blocks: 618260
(Assignee)

Comment 15

5 years ago
Roc, do you happen to know the answer of the question asked in comment 13?
(Assignee)

Comment 16

5 years ago
(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 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...
(Assignee)

Comment 18

5 years ago
(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 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)
Attachment #679149 - Flags: review?(dbolter) → review+
(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.
(Assignee)

Comment 21

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/f3faea7f5112
Flags: in-testsuite+
(Assignee)

Updated

5 years ago
Target Milestone: --- → mozilla19
https://hg.mozilla.org/mozilla-central/rev/f3faea7f5112
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 23

2 years ago
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?
Flags: needinfo?(mounir)
Flags: needinfo?(ehsan)
I had no involvement in this bug.  Apparently there was a discussion where browser vendors agreed on this.  Perhaps roc remembers more.
Flags: needinfo?(ehsan) → needinfo?(roc)
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...
Flags: needinfo?(roc)
Flags: needinfo?(mounir)

Comment 26

2 years ago
(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.
Flags: needinfo?(bzbarsky)
I'm not sure what information you're asking for.  If you want something from me, please do say what the something is.
Flags: needinfo?(bzbarsky)

Comment 28

2 years ago
+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.
input::-moz-placeholder {color: #008080; opacity: 1; }

Comment 30

2 years ago
(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.
You need to log in before you can comment on or make changes to this bug.