Opened 16 years ago
Closed 14 years ago
#8545 closed enhancement (fixed)
Incorrect background colour for 'Select Files' button (file uploader)
Reported by: | johnbillion | Owned by: | |
---|---|---|---|
Milestone: | 3.1 | Priority: | low |
Severity: | trivial | Version: | 2.7 |
Component: | UI | Keywords: | needs-ui has-patch |
Focuses: | Cc: |
Description
The background colour for the 'Select Files' button that shows when using the Flash uploader is off-white (#fbfbfb), but the page background is white (#ffffff).
The file affected is wp-includes/images/upload.png
.
Attachments (12)
Change History (56)
#2
@
16 years ago
The button is inside a Flash file. I should take a look at how does it inherit the css properties because I don't think that its style is hard coded inside. If that is just the problem maybe we just have to change the class to "button-primary"
#3
@
16 years ago
Oh stupid commment! No more late night bug revision. I will try to check the file you mentioned tomorrow and if it solves the problem just take the blue button style to replace it. Does any other button depend on this image?
#4
@
16 years ago
- Milestone changed from 2.8 to Future Release
Punting to be evaluated in next development cycle due to time constraints.
#5
follow-up:
↓ 14
@
15 years ago
- Milestone changed from Future Release to 2.8.1
Confirmed in 2.8-rc1. It's hard to see. It's around the corners of the select files button.
#7
@
15 years ago
The button is actually a graphic, I've made a blue one (attached) but can't force the button text to white to ensure consistent with other buttons. I've amend the CSS in wp-admin/includes/media.php but it doesn't seem to stick.
#8
@
15 years ago
- Keywords has-patch 2nd-opinion commit tested added
Found time to look at this again. SWFUpload takes the color attribute as a hex value rather than English words. Fix also applied to the HTML Upload button.
#10
@
15 years ago
Updating these to commit candidates - it's a very disheartening situation when seeming good patches are apparently ignored. It does not motivate me to look at more.
#12
@
15 years ago
- Milestone changed from 2.9 to Future Release
This thing is, having a white button is correct in terms of following UI standards. The blue buttons are reserved for actually submitting something to the db. A better solution would be to darken the outline of the button if you feel it's too hard to see.
#14
in reply to:
↑ 5
;
follow-up:
↓ 15
@
15 years ago
@Jane:
Confirmed in 2.8-rc1. It's hard to see. It's around the corners of the select files button.
I'm pretty sure you misunderstood the ticket. Iit's actually the button's background that is a very slight gray (something like fdfdfd?) instead of fff.
@MattrRob:
Updating these to commit candidates - it's a very disheartening situation when seeming good patches are apparently ignored. It does not motivate me to look at more.
I know the feeling...
#15
in reply to:
↑ 14
@
15 years ago
Replying to Denis-de-Bernardy:
@MattyRob:
Updating these to commit candidates - it's a very disheartening situation when seeming good patches are apparently ignored. It does not motivate me to look at more.
I know the feeling...
Especially when patches get punted without the ticket being read.
#16
@
15 years ago
- Milestone changed from Future Release to 2.9
The reasons given for punting this ticket are totally invalid - blue buttons are for database entries? what like the "Visit Site" and "New Post" drop downs in the header area?
Like the "Update File" button when editing plugins that saves the plugin files and never touches the database.
The 'better solution' would be to come up with a better reason for not committing this ticket patch or to just commit it.
But, final straw for me - I quit fixing up these little tickets because it seems quite apparent that no one can be bothered taking them seriously, giving reasoned or committing them!
#17
follow-up:
↓ 21
@
15 years ago
- Keywords developer-feedback added
Let's stay focused on the ticket! The key to communication is empathy.
Denis, there is a great opportunity to be positive and solution oriented! Complaints are bes done directly with the people involved.
MattyRob, please don't go! Personally, I've really appreciated your contributions over the years -- it's been at least a few years.
My own contributions tend to also be the all important polish -- but I also have to be extremely patience as there is most often multiple elephants in the room.
Often it's just a matter of describing the issue in different terms -- it can be frustrating, but the simplest with good images best help others champion as issue. I can't really understand the issue from the screenshot
When I look at wp-admin/media-new.php I see a "Select Files" button with overly black text and no hover effect (in Safari). Seems like the button has quite a few things wrong with it.
I vote for pushing this out to 3.0 and getting the whole thing fixed well.
#19
@
15 years ago
Replying to lloydbudd:
The key to communication is empathy.
Denis, there is a great opportunity to be positive and solution oriented! Complaints are bes done directly with the people involved.
Believe me, I normally am a can-do, solution oriented person. And I'd have wholeheartedly agreed with you a few months back when I got so involved in WP again that I lost heaps of customers.
That being said, have you not noticed that complaints tend to get some kind of f*** off when brought to the people involved, and that the wp devel blog's comments are closed?
Some will argue I'm not diplomatic. But the truth is, it's hard to be so when speaking to a wall. And we French are, well... French: we jump two feet into the the bowl when we need to, and to hell if it makes a person or two unhappy if the mess is exposed as what it is.
I rose an alarm bell a few months back, hoping it would bring a reaction. My thought was that WP was slowly but surely going down the drain.
Point taken, I was told. Surely, some things have evolved on the PR front, yes.
At the end of the day, though, WP is still under-staffed, under-managed, under-architected, and it's losing momentum each and every time a new contributor gets no attention.
Consider this thread, which is patented WP workflow it its sheer horror:
http://core.trac.wordpress.org/ticket/8730#comment:12
Don't get me wrong, I hold each of our 4 core devs in high respect. But there should be two or three times more of them. As in now, before this thing blows up.
#20
@
15 years ago
and by the way... I hate to bring this up, but are we getting gaged or anything?
This thread no longer accepting comments:
http://wpdevel.wordpress.com/2009/11/23/next-dev-chat-will-be-on-thursday-3rd-de/
http://screencast.com/t/NGJjNDk0
... and it was indeed getting sour. I was assuming that it was due to a close comments after XYZ days option.
Then again, this older one still accepts them:
http://wpdevel.wordpress.com/2009/11/19/suggest-agenda-items-for-nov-26th-dev-ch/
http://screencast.com/t/NTliNzczNT
Why is that?
#21
in reply to:
↑ 17
;
follow-up:
↓ 22
@
15 years ago
Replying to lloydbudd:
Let's stay focused on the ticket! The key to communication is empathy.
You couldn't be more right but empathy in communication has to be a two way thing and I really am not feeling any empathy coming back!
This button is different from many others in the backend because it's a Flash button. I've got it as close as I can to the look and feel of other primary action buttons. Now, if that isn't quite good enough then that would be fine with me provided those reasons were put forward.
Instead the ticket has been open for months, had a patch for many of those months and then immediately prior to an expected release of a new version gets punted with the reasons given for the punt being utter rubbish! I found 2 areas within 15 seconds of logging into the admin area where the "UI standards" are already broken.
Okay, that's not reason to break them elsewhere but it is reason to make you 'standard' one that is evenly applied. Also, can anyone tell me where this standard is published? And why it was linked by the person who punted the ticket? You see I can;t find the 'standard' so if it's a closed one how are we supposed to help fix bugs anyway?
I tell you what though, I'll stick around for a little longer but my patience is stretched to the limit and I'll be spending very little time on this from now on unless things change for the better in respect to communication with bit-part donators of code like myself.
#22
in reply to:
↑ 21
;
follow-up:
↓ 23
@
15 years ago
/me focusing on the issue and where we are now
Replying to MattyRob:
Replying to lloydbudd:
Let's stay focused on the ticket! The key to communication is empathy.
You couldn't be more right but empathy in communication has to be a two way thing and I really am not feeling any empathy coming back!
Absolutely.
This button is different from many others in the backend because it's a Flash button. I've got it as close as I can to the look and feel of other primary action buttons. Now, if that isn't quite good enough then that would be fine with me provided those reasons were put forward.
I'm no hackers, so you will have to excuse me, but I've opened and stared at
image (http://core.trac.wordpress.org/attachment/ticket/8545/upload.png)?
a few times... and can't really figure it out. A new screenshot highlighting the specific issue would help me and others also be your champions. A 2nd screenshot highlighting the fix would also be awesome!
can anyone tell me where this standard is published?
I'm also going to be bugging Jane about this one ;-) I'm hoping it's already planned to be a by product of 3.0 work, if not ... ;-)
unless things change for the better in respect to communication with bit-part donators of code like myself.
Always feel free to hit me or anyone else up on email to tickle any of your issues. That's what I do... it's not ideal, but it works.
#23
in reply to:
↑ 22
@
15 years ago
Replying to lloydbudd:
This button is different from many others in the backend because it's a Flash button. I've got it as close as I can to the look and feel of other primary action buttons. Now, if that isn't quite good enough then that would be fine with me provided those reasons were put forward.
I'm no hackers, so you will have to excuse me, but I've opened and stared at
image (http://core.trac.wordpress.org/attachment/ticket/8545/upload.png)?
a few times... and can't really figure it out. A new screenshot highlighting the specific issue would help me and others also be your champions. A 2nd screenshot highlighting the fix would also be awesome!
As mentioned in my initial comment:
Confirmed in 2.8-rc1. It's hard to see. It's around the corners of the select files button.
Here's a x3 zoom:
#24
@
15 years ago
The graphic you've been looking at is a replacement for the white one that comes with the current WordPress distro at:
http://core.trac.wordpress.org/browser/trunk/wp-includes/images/upload.png
Also, I've grabbed a poor quality screen shot of the fix in action so you can see how much better it looks :-)
@
15 years ago
WP flash uploader "Select File"button slightly visable grey border 3x zoom, posted by Denis in comment 23 @ screencast.com/t/YjcxZTA2Mz
#25
@
15 years ago
- Milestone changed from 2.9 to Future Release
MattyRob — it's not about how it looks, it's about consistency for our uses of the primary button style. Selecting files for upload isn't a primary action like saving... it's one of many steps involved in uploading media.
I think we should fix the background issue, and not change the overall look of the button.
#26
@
15 years ago
I disagree - this is totally about how it looks and in more ways than one.
The "Primary Button" line has been used before but no body can refer me to a GUI standard that classifies what a "primary button" actually is! It's interesting that you used the word "Saving" in your comment above - because Save Draft is considered a secondary action in the current UI.
Quite why it takes a year and so much naval gazing to fix a button colour is beyond my comprehension. Still - I'm past caring now. I think I'll stick with coding my own plugin and leave you all alone.
#28
@
15 years ago
See also #11448.
IIRC, this image is also used on a gray background somewhere. So we'll need to add a white background version to the sprite, or have a second image.
Moved to 3.1 for the tentative media/upload overhaul (which may replace all of this anyway).
#30
@
14 years ago
- Milestone changed from Future Release to 3.1
It would be awesome just to fix this for 3.1 instead of waiting for media overhaul, which is probably still a release or two away. This is a small thing but makes us look sloppy for not addressing it by now.
#31
@
14 years ago
From what I can tell, the best solution for this would be to make the background on the swf transparent, and use the transparent background version of the png. Is that possible?
#32
follow-ups:
↓ 33
↓ 34
@
14 years ago
@TECannon beat me to uploading a new upload.png image with a transparent background, but the "wp-includes/js/swfupload/swfupload.swf" file also needs to have this parameter added:
<param name="bgcolor" value="#F9F9F9">
{I don't have a decompiler}
#33
in reply to:
↑ 32
@
14 years ago
Replying to Craiger:
@TECannon beat me to uploading a new upload.png image with a transparent background, but the "wp-includes/js/swfupload/swfupload.swf" file also needs to have this parameter added:
<param name="bgcolor" value="#F9F9F9">
{I don't have an editor for mac}
@TECannon ... I tested this out & no, 'transparent' is not possible for swf. It has to be a hex code.
#34
in reply to:
↑ 32
@
14 years ago
Replying to Craiger:
@TECannon beat me to uploading a new upload.png image with a transparent background, but the "wp-includes/js/swfupload/swfupload.swf" file also needs to have this parameter added:
<param name="bgcolor" value="#F9F9F9">
{I don't have a decompiler}
It has to be able to work on both white (the lightbox version that comes up while editing a post or page) as well as the #f9f9f9 background (Media -> Add New) so I'm not sure that's the best answer either. The background of the new blue color scheme is (will be) slightly different as well (#fdfcfb)
#36
follow-up:
↓ 37
@
14 years ago
and add wmode="transparent"
to embed
http://kb2.adobe.com/cps/142/tn_14201.html
This will ignore the background that's set in the swf making the bg transparent.
#37
in reply to:
↑ 36
@
14 years ago
Replying to WraithKenny:
and add
wmode="transparent"
toembed
http://kb2.adobe.com/cps/142/tn_14201.html
This will ignore the background that's set in the swf making the bg transparent.
That works.
#38
@
14 years ago
Should probably be tested a little more, but it looks like it just needed an additional javascript setting ("button_window_mode: 'transparent'")
#39
@
14 years ago
From http://demo.swfupload.org/Documentation/#knownissues
WMODE / BUTTON_WINDOW_MODE
In some browsers the selected WMODE (which is set using the BUTTON_WINDOW_MODE) can prevent the Flash Control from loading if the control is not on screen. The control will finally load once the user scrolls the page so the control becomes visible.
This behavior can adversely affect the SWFObject plugin. No SWFUpload events will be fire and the button image will not be loaded until the control becomes visible.
#41
@
14 years ago
- Keywords needs-ui needs-patch added; has-patch tested dev-feedback removed
Due to the warnings that ocean90 linked to, we should add two new images -- we'll need one for each color scheme.
So, upload-fresh.png (#f9f9f9), upload-classic.png (for #fcfcfb). Tracy, can you create these? I can make the appropriate patch.
There's a filter on includes_url() so I'm not worried about ensuring that this can be filtered for other color schemes (of which there are very few, and this is a very minor UI inconsistency).
Sounds like it is designated as a secondary button rather than a primary button?