Closed Bug 205136 Opened 21 years ago Closed 17 years ago

Aqua form buttons obey CSS text rules which cause inconsistent and unwanted behavior

Categories

(Camino Graveyard :: HTML Form Controls, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME
Camino2.0

People

(Reporter: contact_marcos, Assigned: sfraser_bugs)

References

Details

Attachments

(2 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030509 Camino/0.7+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030509 Camino/0.7+ Camino ignores CSS rules related to html form button background image and color, but obeys rules regarding the button text. This causes inconsistent and unwanted behaviour for some page authors who rely on CSS to display image based buttons. Generally: I think that if the decision has been made to use aqua widgets all extraneous CSS text rules should be overidden by default to prevent unforseen inconsistent behavior. This is the case with Opera 6, Safari and Omniweb. Specifically: I use the letter-spacing (and word-spacing) attribute to hide the text of my form buttons and use a background image to give the appearance of a graphical button. Most browsers display the buttons using my image. Most OS X Browsers display an aqua button with the correct text. Camino displays an aqua button AND NO TEXT. I will attach a file illustrating this test case. Reproducible: Always Steps to Reproduce: 1. Browse to a page which uses the aforementioned CSS rules (see attachment for example) Actual Results: Camino displays and aqua button with no text Expected Results: Camino should have displayed and aqua button with the apropriate text
This test case uses a background color instead of a background image just to make it simpler.
Camino is doing exactly what it should based on the testcase. There's no reason page authors shouldn't be able to use letter-spacing for the purpose for which it was intended. When faced with letter-spacing alone, Camino makes buttons as wide as necessary to accomodate increased letter spacing. The problem arises not because of your use of letter-spacing, but your combining a large letter-spacing value with a small width value. If you want to make a graphical submit button, why not just use an <input type="image"/>? Then all browsers will show it.
My concern is with CONSISTENCY, not what Camino SHOULD be doing. Of course the text should be hidden, that was my intention, if my background image was also shown (as it should be) there would be no problem. The developers have decided to always use aqua widgets a prevent CSS from overidding the button design. That's fine. But if you are going to divert from the norm, you should be consistent so as to prevent unexpected results. Another example of this occurrs (or occurred) when setting the text color for form buttons white. Camino SHOULD allow page authors to use whatever colors they want but because it makes the text unreadable when using aqua buttons and since they don't allow the button background to be overridden, button text color has to be restricted. As for <input type="image"/>, there are a couple reasons why I would prefer to use <input type="submit/reset"/> 1) Simpler Server-side programming: <input type="image"> buttons return image map-like xy coordinates instead of name=value pairs to server side scripts. This can be annoying when trying to test to see which button was pressed (not impossible, just annoying). 2) Separation of Design & Content: If I specify ALL design realted material in my style sheets and completely separate it from the content, I can update my entire site (including fancy buttons) by simply switching style sheets. 3) Device independence: If I specify the image and image size within HTML they end up looking WAY too big on handheld devices. If I was to do it using CSS, I could send them a different style sheet with smaller buttons or no style sheet at all and let them render their own buttons. 4) Consistency: I make heavy use of CSS for design, but I prevent older browsers from seeing my style sheets so they don't mess it up. They basically just get very plain html markup, but when I use "image buttons" they get plain markup + fancy images, which just looks weird...I would prefer for it to be more consistent. 5) Reset button: "image buttons" only work as submit buttons, not reset buttons. This is actually the least important issue for me since Reset buttons are usually more harmful than helpful and I rarely use them. I realize that these issues aren't a big deal to everyone, but it was important enough for me to start fiddling around and now I have come SOOOO close to getting it to work...but Camino breaks it :(
Confirming for the text color issue, and updating summary correspondingly (was "Aqua form buttons obey CSS text rules which cause inconsistent and unwanted behavior"). There's no question that we need to override changes to button foreground colors if we prevent background changes; there's a reason CSS complains if you set one but not the other. As an example, http://www.travelocity.com recently started using <button> input elements with a colored background and white text. Camino renders them as Aqua buttons with white text, which is basically impossible to read. As for the width+letter spacing issue, I agree that we should leave it alone: -There is nothing inherently incompatible between text/backround color, and letter spacing. -This method of hiding text a hack which shouldn't be expected to work. For example, anyone with a user CSS file with !important text and background colors (which is not uncommon for accessibility reasons) would also encounter unlabelled buttons.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Aqua form buttons obey CSS text rules which cause inconsistent and unwanted behavior → Aqua form buttons obey CSS foreground color while ignoring background color
Taking, nominating for 0.8, and raising severity, since it renders some sites mostly unusable and seems to be becoming more popular. Forcing the text color to black should be a simple fix, and is the only behavior that makes sense given that we are restricting the background color. CC'ing pink, so he can veto my 0.8 nomination if he so chooses.
Assignee: bryner → sbm5
Severity: normal → major
Target Milestone: --- → Camino0.8
(In reply to comment #4) > As for the width+letter spacing issue, I agree that we should leave it alone: > -There is nothing inherently incompatible between text/backround color, and > letter spacing. The conflict is between letter-spacing and background-image and while it is not "inherent" I definitely think it makes sense to restrict what can done with the foreground element if you have decided to restrict what can be done with the background element. > -This method of hiding text a hack which shouldn't be expected to work. It is definitely a hack, unfortunately that is the name of the game with complex CSS. All I can say is that "all other aqua using browsers do it", and I think it makes sense. > For example, anyone with a user CSS file with !important text and background > colors (which is not uncommon for accessibility reasons) would also encounter > unlabelled buttons. That's not true. Maybe you misunderstood my test case (which admitedly sucks). What I am trying to do is set a background *image* and hide the text. background-color sits below background-image, so setting !important on it wouldn't change any thing; neither would setting !important on the text (which would be hidden). What I want camino to do is to NOT hide the text, since it has decided to NOT show the background image.
Sorry, I wasn't clear. The setup I intended to describe was something like: background-image: none !important background: white !important color: black !important Stylesheets like this one are not uncommon for visually impared people, or even other people who are simply tired of reading sites with yellow text on a grey stone-textured background. I understand your points though. Another argument against other styling is that it's not OS-consistent (and we probably can't do it if we switch to native buttons, although I'm not sure about that). Regardless, the issue of other text CSS can be discussed later; I think that only the background-color/foreground-color issue is severe enough to warrant consideration for 0.8. Once that's resolved, we can morph this back into a lower severity bug about text styling in general.
Supresses text color for <button> elements, since |-moz-appearance: button-bevel| apparently supresses background images and colors. (see www.travelocity.com). This makes button elements behave more like <input type="button">.
Comment on attachment 148481 [details] [diff] [review] Overrides text color for button elements Unfortunately, this is a general Browser OS X bug, so it needs both an external sr= and an a= for 1.7 in order to get into Camino's 0.8. Pinkerton, please reassign as necessary to try to get this landed into 1.7/0.8 if you think it's important enough.
Attachment #148481 - Flags: review?(pinkerton)
Hm, I take back the part about it being a general browser bug. FF doesn't supress any button colors. Apparently, only Camino uses mac/platform-forms.css (?)
yes, only camino currently uses this file.
Uses black text for normal buttons, and grey text for disabled buttons.
Attachment #148481 - Attachment is obsolete: true
Attachment #148481 - Flags: review?(pinkerton)
Attachment #148503 - Flags: review?(pinkerton)
Comment on attachment 148503 [details] [diff] [review] updated to handle disabled buttons correctly r- (from pink and bryner) this forces black text in *all* cases, even when aqua is turned off for buttons. with this patch, no css could ever change the text color of a button.
Attachment #148503 - Flags: review?(pinkerton) → review-
> > this forces black text in *all* cases, even when aqua is turned off for > buttons. with this patch, no css could ever change the text color of a button. > How do you turn aqua off for buttons? Can it be done in the author style sheet or is it a (hidden) user pref?
It turns out the <button> issue is very different (<button> elements shouldn't always be native), so I'm going to open that as a new bug and put this one back the way I found it. Sorry for the noise.
Assignee: sbm5 → bryner
Severity: major → normal
Summary: Aqua form buttons obey CSS foreground color while ignoring background color → Aqua form buttons obey CSS text rules which cause inconsistent and unwanted behavior
Target Milestone: Camino0.8 → ---
*** Bug 263910 has been marked as a duplicate of this bug. ***
*** Bug 274348 has been marked as a duplicate of this bug. ***
*** Bug 287645 has been marked as a duplicate of this bug. ***
*** Bug 299265 has been marked as a duplicate of this bug. ***
The most egregious parts of this should probably be fixed by 1.0, so putting this on the 1.0 list for now so it doesn't get lost.
Target Milestone: --- → Camino1.0
Assignee: bryner → sfraser_bugs
*** Bug 301597 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > It turns out the <button> issue is very different (<button> elements shouldn't > always be native), so I'm going to open that as a new bug and put this one back > the way I found it. Sorry for the noise. I never found that bug, so styling <button> is now bug 309556.
The new bug I had opened is bug 244058. It's actually the opposite of what you were looking for, I think. I'll comment further there.
(In reply to comment #23) > The new bug I had opened is bug 244058. It's actually the opposite of what you > were looking for, I think. I'll comment further there. Why did we do that for <button> but not <intput type="button"> ?
I think because <input type="button"> can't contain arbitrary HTML.
(In reply to comment #25) > I think because <input type="button"> can't contain arbitrary HTML. Yes. (And when I said I'd comment further 'there', I actally meant bug 309556, so see there for the rehash.)
FYI, here is how the Safari guys are planning on handling buttons going forward. http://webkit.opendarwin.org/blog/?p=28 If I am reading it correctly, it is pretty much in line with what I would like to see in Camino, though obviously non-trivial.
Target Milestone: Camino1.0 → Camino1.2
*** Bug 315024 has been marked as a duplicate of this bug. ***
*** Bug 323141 has been marked as a duplicate of this bug. ***
QA Contact: winnie → form.controls
Target Milestone: Camino1.2 → Camino2.0
Fixed by trunk widget rewrite. Buttons now fall back to fully styleable, non-aqua buttons when necessary.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
I'm not a programmer, just a fan of Camino because it's so fast. I'm still seeing SOME aqua buttons that show no next, at 1.6.8 in 2009. Seems like a pretty important item to me. I'm providing sample HTML from 2 sources, neither of which is public. Here's a HELP page from SwitchVox v4 (a VoIP Asterisk phone system): <body > <table style="height: 100%; width: 100%"> <tr> <td style="height:100%"> <div id="content_help_popup"> <div class="help_popup_closewin"> <input type="button" class="closewinbtn" onclick="window.close();" value=" " onmouseover="this.className='closewinbtn closewinbtnhov'" onmouseout="this.className='closewinbtn'" /> </div> <!--END common/incl_help_header.html --> Please note that the files that you upload must be in OGG Vorbis (.ogg) format. <br/><br/> Many free programs exist to convert mp3s, wavs, etc. to .ogg. <br/> <a href="http://www.google.com/search?hl=en&amp;lr=&amp;q=software+convert+to+ogg&amp;btnG=Search" target="blank">Find a converter program.</a> <br/> <br/> It is possible to add support for other file types such as MP3, by uploading a new codec to your system. Selecting "Codec" from the "Add New" drop down and clicking the "Go" button next to it will take you to a page where you can upload the new codecs. This page also has instructions on how to add MP3 support for Music on Hold files. <br/> <br/> The Music On Hold manager allows you to upload files to be played to callers while they are on hold, being transferred, etc. If you would like to have different types of music played for different circumstances, departments, etc., create a group with a descriptive name (E.g. "Holiday Music") and then assign music files to that group. You can also specify in what order and at what volume you would like the music to be played. <br/><br/> Don't forget that you can also use this feature to make announcements to your callers. Just upload a file with your recorded message and treat it the same way that you would if it were a music file, changing it as often as you wish. <!--START common/incl_help_footer.html --> </div> <!-- closing content div --> </td></tr> <tr> <td> <iframe id="iframe_result_popup" src="/images/common/trans.gif" frameborder="0" scrolling="no" class="frame_iframe"></iframe> <div id="result_popup" class="result_popup" style="width:550px; display:none"> <div id="new_result_message"></div> <div id="close" style="float:right"> <a id="close_href" href="javascript:void(0);" onclick="javascript:$('result_popup').style.display = 'none'; $('iframe_result_popup').style.display = 'none'; return; ">Close</a> </div> </div> <!-- borrowed from admin/incl_footer.html --> <div id="footer">Copyright &copy; 2009, <a href="http://www.digium.com">Digium, Inc</a></div> <script type="text/javascript"> ; </script> </td></tr></table> </body> Here's part of ssSettingsView.html from a SonicWALL TZ210. The APPLY button is void of text while the CANCEL button is not: <title>Security Service Settings View</title> <LINK REL=STYLESHEET HREF="wndStyle.css" TYPE="text/css"> <link rel=stylesheet href="swl_styles-5-0o-3718570608.css" TYPE="text/css"> </head> <body> <div id="tabData" align="left"> <form name="thisForm" id="thisForm" action="main.cgi" method="POST" enctype="x-www-form-encoded" target="statusFrame_0017C52DBD61"> <div id="pageHeader"> </div> <br /> <table width="97%" border="0" cellspacing="0" cellpadding="0" summary=""> <tr> <td bgcolor="#7f7f91"><img src="clear.gif" width="1" height="1" alt=""></td> </tr> <tr> <td background="bbar_back.gif"> <table width="100%" border="0" cellspacing="0" cellpadding="0" summary=""> <tr> <td width="6"><img src="clear.gif" width="6" height="35" alt=""></td> <td> <input class="applyButton" type="button" value="Apply" name="applyButt" onclick="applyChanges();" title="Apply changes to this page" id="applyButt" width="74" height="21" > <input value="Cancel" name="cancelButt" style="right:34px;" onclick="cancelChanges();" title="Cancel changes to this page" class="applyButton" type="button" > </td> <td><div align="right"></div></td> <td width="6"><img src="clear.gif" width="6" height="1" alt=""></td> </tr> </table> </td> </tr> <tr> <td bgcolor="#7f7f91"><img src="clear.gif" width="1" height="1" alt=""></td> </tr> </table> I've seen this many times on public sites and if you need more samples, email me and I'll try to collect some. Keep up the good work.
This is fixed in Camino 2, not 1.6.8
(In reply to comment #34) > I'm not a programmer, just a fan of Camino because it's so fast. I'm still > seeing SOME aqua buttons that show no next, at 1.6.8 in 2009. Seems like a This is expected for 1.6.x. > I've seen this many times on public sites and if you need more samples, email Camino 2 betas use a new algorithm, so it's no longer useful to collect samples of problems with 1.6.x.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: