890252 - File Inputs not usable on websites with dark background

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[geoffk]

Attachment: withcssonBHT.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

Created an input of type 'File' on a website with a dark background colour for the form.


Actual results:

The recently introduced 'text-only' input style puts black text on what may be a dark form background. This gives the appearance of the input being broken or mis-styled. 


Expected results:

It should be possible to view the printed text on any colour of background. Much better to restore the previous implementation, which also had significant extra functionality - people do copy and paste between file input boxes.

Comment 1

[geoffk]

The solution (for me, and currently for me only) is to for the file[input] to be given a default colour of #FFF in CSS. I have now set all inputs to default to a #FFF background-color via my reset CSS, which does no harm to the other input types because they (seemingly) have that already. This puts a white box around the text which can then continue to be #000 as suits text in all other form inputs on all other browsers. My SUGGESTED FIX is that the new file[input] be given a default background of white rather than 'None' as per all other input types, so that the displayed text (e.g. 'No file uploaded.' ) does not need to be a different color to the rest of the site/page.

Comment 2

[geoffk]

Just to say: I'm not a FF developer, and I respect the skills of those that are. What it boils down to is that there is often - certainly, on many existing sites - a strong contrast between the background-color of an input box and the background-color of the form around it. In fact, that contrast helps make form inputs easy to see and use. On FF22 and 23 the text (e.g. "No file selected." can be invisible when displayed outside of the input box, because setting a color that's high-contrast inside will be low-contrast color outside. This can be extreme - using black text on a form with a black background renders the text invisible.

Comment 3

[Mounir Lamouri (:mounir)]

The problem you are underlining doesn't seem to be specific to Firefox. How does your test page look like with Chrome or Safari? In addition, if you have a sane style sheet, you shouldn't see this problem because I would expect pages with background-color: black to also have a rule that says something like color: white. If you do that, I believe that <input type='file'> will by default have a white text on a black background.

Comment 4

[geoffk]

Hi Mounir. Well, no you would not expect a page with background-color: black to have color: white if the page is a form. If you change the text colour to be white, it will then be invisible for all the other text inputs, which have white backgrounds by default.  I'm going to give up saying the same thing now, after one last go: text has to be a contrasting color to its background. That means that a text color that is readable inside the text box (e.g. black on white) will not also work outside of the box, if the outside of the box has a dark background.
I've checked out Internet Explorer 7 to 10, Safari 5.1.7 and Chrome 29. (Without a CSS correction in place) Safari and Chrome are identical to FF22. Internet Explorer is fine. I know it's popular to say that IE is always wrong, but it looks fine and still has the copy/paste functionality that many users value.
As I have said in other posts, this is no longer a problem for me because I have put input {background-color: #FFF] in my reset CSS and will have it there forever, but any dark-backgrounded sites using inputs of type [file] without a background-color declared will be broken until the fix is more widely known. My style sheet is certainly "sane", and the screenshot I have uploaded shows the reasonably typical form it produces. Repeating myself again, setting a background-color on the form inputs (or just input[type="file"]) restores readability. Please see the two uploaded screenshots.

Comment 5

[geoffk]

Attachment: Screenshot with background color set to FFF in CSS, FF22

Previous attachement to this shows the close up of file type="input" without the CSS correction. This input looked perfectly fine on previous versions of FF, still looks fine on IE7 to 10, bad on Chrome, bad on Safari. Note that this page uses both white text and black text, problem is what shade to use when text can appear both inside and outside of a form input. Best fix is to set a background-color, which restores the old style (but without the old functionality).

Comment 6

[Mounir Lamouri (:mounir)]

I think this problem is a problem in your website, not in the UA. In the screenshots you attached, all the texts are white but not the one in the file picker. That means you whether don't want this text to be white or you have a CSS rules to exclude (or not include) the file picker.

Comment 7

[geoffk]

Mounir, take a look at the screenshot again. See the black text? It's black. See the the white text? It's white. It needs to be white on a dark background. See the black text on the dark background? That's what file inputs now look like on Firefox. I remind you, I have fixed this for my own use. I did this by applying a white background in CSS, exactly as the Bugzilla site does when demo'ing the new input[file]. ALL OF THE INPUTS have black text. Look at them.

Comment 8

[alexander :surkov (:asurkov)]

cc'ing David since iirc he was in touch with stuffs like this recently.

Comment 9

[j.j.]

Attachment: testcase

We are compatible with WebKit/Blink and it's far better than what we had before.
That said, well, I for one would consider this a bug.

Comment 10

[Mounir Lamouri (:mounir)]

The colour of the element is inheriting from its parent. I really do not think there is anything wrong with that, a sane style should take care of it, like:
data:text/html,<style>body { background: black; color: white; }</style><input type='file'>

Comment 11

[alexander :surkov (:asurkov)]

Looking at the testcase the text inside of file input behaves the same way as plain text of the page. So if web page background makes plain text unreadable then I don't see a point why text of file input must be different. That thinking makes me agree to invalid resolution. Did I miss anything?

Comment 12

[geoffk]

Hi Alexander, well yes, you did miss something! I've explained it a number of times now, can I ask you to re-read what I've written and look at the screenshots? Text color that is ideal and perfectly legible for most input types will now not be okay for input[file] on FF v22+ . It is possible to write a rule targetting input[file] to have white text when all other inputs need black, but how do you target that to operate for FF version 22 and later whilst continuing to show black text for earlier FF and for all Internet Explorer? Worse still, how do you tell the World that these rules now need to be written for the existing and future dark websites with file inputs? Mounir, apologies, but no-one reading or writing on these boards needs to be told how to use the very, very, very simple CSS you think I am unaware of and which doesn't relate to the issue. Please take a look at the form I screenshot, which has different colours of text for ordinary text (styled white) and for inputs (styled black). It's an absolutely typical form for a dark website. When input text is shown outside of an input box it becomes invisible, unless CSS is applied to address the problem.

Comment 13

[alexander :surkov (:asurkov)]

(In reply to geoffk from comment #12)
> Hi Alexander, well yes, you did miss something! I've explained it a number
> of times now, can I ask you to re-read what I've written and look at the
> screenshots?

Stating the problem clearly really helps. I bet there's bunch of people who could comment here but won't do this because they don't want to dive into reading.

> Text color that is ideal and perfectly legible for most input
> types will now not be okay for input[file] on FF v22+ . It is possible to
> write a rule targetting input[file] to have white text when all other inputs
> need black, but how do you target that to operate for FF version 22 and
> later whilst continuing to show black text for earlier FF and for all
> Internet Explorer?

the point is you don't need to have special CSS rules for file input, you need to have special CSS rules for text, as Mounir said in comment #10.

> Worse still, how do you tell the World that these rules
> now need to be written for the existing and future dark websites with file
> inputs? 

Ok, granted we have backward-compatibility problem. Is there anything else I could miss?

Comment 14

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

Hi Geoff, thanks for filing this bug.

I read through the comments once and hope I've understood things.

(In reply to geoffk from comment #4)
> If you change the text colour to
> be white, it will then be invisible for all the other text inputs, which
> have white backgrounds by default.

Luckily I think this is not the case. I think Mounir's css rules should work for you. If not, we may have a separate bug.

By the way could you file a separate bug for the copy and paste issue with a bit more details for that problem? (or is this a known bug?)

I think this contrast bug is really about trying to help web developer expectations. I agree it could catch people by surprise. Even though it won't help backwards compat breakage, would it be acceptable to turn this bug into a documentation bug to warn web devs?

Comment 15

[geoffk]

Hi David. With respect, Mounir's CSS rules are phenomonally basic and have no real world application at all. Dark background websites with lighter input boxes need light text outside of the input boxes and dark text inside the input boxes. Dark text will not show up against a dark background, so when the color of text that is shown inside a box is shown outside, it disappears or appears broken. On all inputs other than the new FF/Safari/Chrome file input, text is inside the box. Text cannot be dark and, simultaneously, be light.

As I have made clear, I personally have no problem making my site okay, it looks as I intended it to. Because I applied a background of white to all inputs. Dark background sites that do not usually have that CSS.

Now, to get involved with the real world: it is perfectly easy to target input[file] with a different colour of text to the other inputs IF you know that you need to. What is difficult is targetting that opposite shade of text at just 'Chrome/Safari/Versions of FF after v22'. Fortunatley, there is a workable solution, which is to put a background-color of #FFF on all inputs, so that the dark text shows up. Think though - how are all the developers in the world going to be informed that they might need to do that? Why not put a background behind the text by default, so that it is legible, and let people style background-color: none; if they genuinely want the 'No file selected.' message to sit directly against the form background? 
I really can't see why you would want to lose copy/paste functionality in favour of a default style that goes wrong on forms with dark backgrounds (unless corrected for) and does not have that functionality? Anyway, I have done enough. Good luck with FF, I personally have the knowledge I need to cope with the new input, just pointing out why there will others googling to these pages for many years to come.

Comment 16

[geoffk]

Okay, apologies David, it's me again! You say:

"(In reply to geoffk from comment #4)
> If you change the text colour to
> be white, it will then be invisible for all the other text inputs, which
> have white backgrounds by default.

Luckily I think this is not the case."

I've just checked, in case I was losing my mind. Which part of my statement is incorrect? Text inputs have white backgrounds if they are not styled to be otherwise. White text is invisible on a white background, isn't it?

I've only just recovered from when Mounir told me all the text on my screenshot is white!

Comment 17

[geoffk]

Hi Alexander... still missing it, I'm afraid. 
1. Dark website, so white text.
2. Dark website, so white input boxes.
3. White input boxes, so dark text for inputs.
4. Dark text now showing on a dark background for input[file].

Comment 18

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

Hi Geoff,

Since you have a workaround I won't spend too long here but I'll try to help find where I/we am misunderstanding.

How are you making the text in the text input white? I was only referring to this kind of thing (Mounir's styles):
<body style="background-color:black, color:white">
<form>
Alphabet:<input type="text" name="test" value="ABCDEFG"><br>
</form>
</body>

In this example I can read the text in the input of course.

(In reply to geoffk from comment #15)
> Why not put a background behind the text by default, so that it is
> legible, and let people style background-color: none; if they genuinely want
> the 'No file selected.'

I think that is a good question. My thinking is we'll reopen this if we get more feedback like this.

Comment 19

[alexander :surkov (:asurkov)]

Still trying to understand.

* You still able to change file input appearance by CSS rules so file input is usable on dark web sites but

1) there's a problem of backward compatibility, i.e. many existing dark sites have a problem until they change
2) you used to have rules for text and for all inputs but now you have to have a separate CSS rule for file inputs?

Is that correct? Anything else?

Comment 20

[philippe (part-time)]

(In reply to geoffk from comment #17)
> Hi Alexander... still missing it, I'm afraid. 
> 1. Dark website, so white text.
> 2. Dark website, so white input boxes.
> 3. White input boxes, so dark text for inputs.
> 4. Dark text now showing on a dark background for input[file].

If I understand correctly, you, as the page-author, have the habit of styling form controls (inout fields) with (e.g) 'colour: black'. Of course this now create sort-of-a-problem now for input[type=file] when the page background is black. However your styling is bad authoring practice, as you should always specify a background-color when you specify a (foreground) color - you can't rely on the default background for input fields being white. The user may be using a global theme that reverses the colours or the user's OS have have styled those input fields with a dark background by default. etc.

I still don't see any bug in here.

Comment 21

[geoffk]

Hi David, as per previous messages, I'm not making the text white for the input boxes (that would give problems with IE, where the file[input] has a white background, and with older versions of FF). What I do is style all inputs to have background-color: white, which puts a white background behind the text on a file[input] on FF22 and makes my black input text style legible.

If I did want to target inputs of type files (I don't), the CSS selector would be:

input[type="file"] {
//some style goes here
}
A lot of people will try the above, and then spend time trying to target the rule for Chrome, Safari and v22 FF only, using a CSS hack. I don't know if such as hack exists and suspect it doesn't.
My solution is to put a background-color of white on ALL inputs, which is okay because the other inputs have white backgrounds by default ( I'd want consistency of background-color even if it was say, a light cream colour on all).

Re the example you give, you say you can read the text in the text input and so can I. What I can't read is the text shown beside an input[file] positioned directly following the input[text] in that form, because that is then black text on a black background. Incidentally, should be background-color: black; color: white  [semicolon in place of comma]

Comment 22

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

(In reply to geoffk from comment #21)

> Re the example you give, you say you can read the text in the text input and
> so can I. What I can't read is the text shown beside an input[file]
> positioned directly following the input[text] in that form, because that is
> then black text on a black background.

Ah that clears it up for me - thanks.

> Incidentally, should be
> background-color: black; color: white  [semicolon in place of comma]

Good catch! I forgot to correct my cut and paste (I did test with ;).

Comment 23

[geoffk]

Hi Alexander
1) there's a problem of backward compatibility, i.e. many existing dark sites have a problem until they change ***true, agree***
2) You used to have rules for text and for all inputs but now you have to have a separate CSS rule for file inputs? ***No, but many people will be trying that before they find the solution (or give up). My solution is to specify a background-color for ALL inputs, which gives consistency. ***

"Anything else?" Well, what are we gaining in exchange for the loss of functionality and loss of backwards compatibility?

Comment 24

[geoffk]

Hi Phillippe, I agree that defining everything is best but do remember that form inputs are famous for not being stylable across browsers, so a lot of people don't style them - and certainly have not done that historically.

Comment 25

[alexander :surkov (:asurkov)]

So we have backward compatibility and likely discoverability issue. Is there proposals how to fix the problem? If file input text was styled same way as text input then would it resolve it? What disadvantages are?

Comment 26

[geoffk]

Hi Alexander, thanks for sticking with this, appreciated. I'm not a FireFox dev and don't have the skills required, but my thought is that input[file] could have a background-color of white by default, allowing anyone who actually wanted the text for input[file] to sit against the form background (i.e. as it is in FF22) to get that via CSS

input[type="file"] {background-color: none;}

This means that the normal colour of text for form inputs (black) will be legible when not styled, even on dark websites.

Comment 27

[alexander :surkov (:asurkov)]

Personally I don't see anything bad in reverting styles, it resolves backward compatibility problem. But since it's different UI control appearance then who's in charge to approve it? David, you know?

Comment 28

[tcaudilllg]

'(In reply to geoffk from comment #26)
> Hi Alexander, thanks for sticking with this, appreciated. I'm not a FireFox
> dev and don't have the skills required, but my thought is that input[file]
> could have a background-color of white by default, allowing anyone who
> actually wanted the text for input[file] to sit against the form background
> (i.e. as it is in FF22) to get that via CSS
> 
> input[type="file"] {background-color: none;}
> 
> This means that the normal colour of text for form inputs (black) will be
> legible when not styled, even on dark websites.

Geoff your pedantry is disgusting. Firefox is upending half the Internet and you are just concerned about your own little site!? You owe nothing to this PROFIT CORPORATION which masquerades as a non-profit for taxes and propaganda. Its users are but a bargaining chip that it uses to bribe the search firms. Now it has decided that it is in control of its users. These people bite the hand that feeds them... it's time to stop feeding.

Comment 29

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

I think if we default the background of the "No file selected." text to black on white we'll get bugs filed complaining about it looking funny on beige backgrounds. I'd say that this bug is more severe though.

cc+ Jennifer - responsible for FF look and feel.

cc+ overholt - do you know who arbitrates this area (default content styles)?

cc+ mhoye - community zen.

If you run the testcase you can see "No file selected." is barely noticeable.

Comment 30

[Mike Hoye [:mhoye]]

(In reply to tcaudilllg from comment #28)

Hi, tcaudilllg@gmail - 

Even though this bug is getting a little heated, comments like this do nothing to help us understand each other, or the problem in front of us, any better. We're all trying to make the Web a better place, and Bugzilla comments should aim to help everyone keep that goal, as complicated and contentious as it can be, in sharp focus.

Thanks,

- mhoye

Comment 31

[geoffk]

At tcaudillg
Sorry to be pedantic, but you'll notice that I have fixed the issue for myself and have been seeking to fix it for everyone else. 100% the reverse of your understanding (see comment #1). I'm giving an exact description of a fault so that people can understand what the problem is. My 'little site' will secure the employment of several people. Trust me, I am entirely happy to be different to you.

David B - actually, you won't get problems with beige backgrounds because that means that there is a background set for all inputs, including input[type = "file"]. The problem exists when there is no background set for inputs, which is the norm, on a dark website.