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)

Product:
Camino Graveyard
Component:
HTML Form Controls
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Camino2.0

People

(Reporter: contact_marcos, Assigned: sfraser_bugs)

References

Details

Attachments

(2 files, 1 obsolete file)

html/css file illustrating camino button problem
852 bytes, text/html
Details
updated to handle disabled buttons correctly
967 bytes, patch
mikepinkerton
: review-
Details | Diff | Splinter Review 
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: