I spent ages trying to work out why Firefox wasn't rendering a change of width for a DIV until either an alert() call or the user clicked elsewhere on the page. By contrast, IE suffered no delay.
I looked to see if there was a Javascript equivalent to DoEvents() from VBA - but seemingly not.
The eventual answer?
I was specifying
thisDiv.style.width=500;
wheras I should have been using:
thisDiv.style.width="500px";
Strangely, FF doesn't complain, or even ignore, the measurement - it just waits for another event before rendering.
Wednesday, 7 November 2007
Wednesday, 5 September 2007
Firefox buttons with text - bug in onClick and mouseover
There is an odd bug in Firefox (1.5 and 2) affecting the BUTTON tag:
Text to recreate the behaviour:
- Where the button has text below an image
- Where the button is within a table, with "display:inline" applying
- Where the button is in a cell in the last row of the table
- Where the button is wrapped in a div with "float:left" or "float:right"
Text to recreate the behaviour:
<html>
<head>
<style type="text/css">
<!--
#table2, .divInline {
display:inline;
}
.floatThis
{
float: left;
}
-->
</style>
</head>
<body>
<p>Problem is show in the button in this table:</p>
<table id="table2" border="0" cellpadding="0" cellspacing="0">
<tr>
<td>
<div class="floatThis">
<button type="button" ><img src="dummy.png" height="26" width="38"><br>TEXT</button>
</div>
</td>
</tr>
</table>
</div>
<p>Without a table, problem is gone</p>
<div class="floatThis divInline">
<button type="button" ><img src="dummy.png" height="26" width="38"><br>TEXT</button>
</div>
</body></html>
Monday, 27 August 2007
Background for Table Caption in Opera9
If you set your CSS to include "display: inline" for a table, then Opera9 will screw up any background colour (or color) for the tag - the color will expand to fill the maximum available width - far wider than the table!
The following document shows the problem (if you view it in Opera 9):
The following document shows the problem (if you view it in Opera 9):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<style type="text/css">
<!--
#table2 {
display:inline
}
.c1{
background-color:yellow;
}
.w1{
width: 6em;
}
-->
</style>
</head>
<body>
<p>table 1 - without the INLINE declaration:</p>
<table id="table1" border="1" cellpadding="0" cellspacing="0">
<caption class='c1'>Here is a caption, which goes on and on and on</caption>
<tr>
<td class='w1'>Cell 1</td>
<td class='w1'>Cell 2</td>
</tr>
</table>
<p>table 2 - without the INLINE declaration:</p>
<table id="table2" border="1" cellpadding="0" cellspacing="0">
<caption class='c1'>Here is a caption, which goes on and on and on</caption>
<tr>
<td class='w1'>Cell 1</td>
<td class='w1'>Cell 2</td>
</tr>
</table>
</body>
</html>
Wednesday, 25 July 2007
Google Autofill - taming its overenthusiasm
Google's autofill is very clever, but sometimes too clever for its own good.
Google are very sketchy on details of how developers can work with the feature, and experimentation indicates that the rules at work are anything but predictable.
I had trouble with a field labelled "Country" where I wanted to set a code using my own country notation (England/Wales/Scotland/Northern Ireland - there seems no standard coding for these, and Google Autofill has no field that is relevant).
Google insisted that it could autofill this field (but got it wrong).
Step 1 - rename the Select field to exclude "Country" : no change.
Step 2 - insert a spurious and empty "span" tag in the middle of the word "Country" in the label field - ie Country
Success. Google no longer reckons it knows about how to fill the field and it remains uncoloured. But it's in no way elegant, and I fear that it may cause problems for some screen reader programs
Update 26 September 2007:
It gets worse. Google Autofill has picked up the word "Area" in a table of user-generated content, and decided that the field next to it (which has nothing to do with any sort of area, but is an edit box) must want my Area Phone Code. Except that I am in the UK, and our area codes aren't in the 3-digit format that Google expects. No worry, Google will decide that I'd probably like the first three digits of my UK area telephone code inserting whenever the word "area" appears next to a text box.
Fair enough - Google does enter that value automatically. But if the user has signed up for Autofill, Google interferes with the page to change the input to have a yellow background [background-color: rgb(255,255,160); - ie
There is a solution in IE using "attachevent"
but it doesn't work in Firefox. Some have suggested adding
For Firefox, the best that can be done is to over-rule the change to the background-color setting by using CSS like this:
Autofill is neat, but surely Google owes the world a method that allows developers to indicate that a form field - whatever its name or nearby text - is liable to fool the Autofill program, and so should be granted exemption from having its colour modified and Autofill enabled.
Google are very sketchy on details of how developers can work with the feature, and experimentation indicates that the rules at work are anything but predictable.
I had trouble with a field labelled "Country" where I wanted to set a code using my own country notation (England/Wales/Scotland/Northern Ireland - there seems no standard coding for these, and Google Autofill has no field that is relevant).
Google insisted that it could autofill this field (but got it wrong).
Step 1 - rename the Select field to exclude "Country" : no change.
Step 2 - insert a spurious and empty "span" tag in the middle of the word "Country" in the label field - ie Country
Success. Google no longer reckons it knows about how to fill the field and it remains uncoloured. But it's in no way elegant, and I fear that it may cause problems for some screen reader programs
Update 26 September 2007:
It gets worse. Google Autofill has picked up the word "Area" in a table of user-generated content, and decided that the field next to it (which has nothing to do with any sort of area, but is an edit box) must want my Area Phone Code. Except that I am in the UK, and our area codes aren't in the 3-digit format that Google expects. No worry, Google will decide that I'd probably like the first three digits of my UK area telephone code inserting whenever the word "area" appears next to a text box.
Fair enough - Google does enter that value automatically. But if the user has signed up for Autofill, Google interferes with the page to change the input to have a yellow background [background-color: rgb(255,255,160); - ie
#ffffa0]There is a solution in IE using "attachevent"
but it doesn't work in Firefox. Some have suggested adding
autocomplete='off'
to the specification of the input box, but that doesn't work in Firefox either.For Firefox, the best that can be done is to over-rule the change to the background-color setting by using CSS like this:
.whitebox{
background-color: white !important;
}
(or an inline style that does the same). The "Important" setting will overrule the Google setting. However, anyone hitting the Autofill button on the toolbar will still get the nonsense data inserted.background-color: white !important;
}
Autofill is neat, but surely Google owes the world a method that allows developers to indicate that a form field - whatever its name or nearby text - is liable to fool the Autofill program, and so should be granted exemption from having its colour modified and Autofill enabled.
Firefox - preselecting a Select Option
Firefox doesn't cope with
selected value='3'>Pineapple
If you load a page, select the option, then use View Selection Source - you find that Firefox comes up with:
selected='selected' value='3'>Pineapple
BUT if you then put that into your HTML, it ignores that too.
Answer: use selected='true'.
Simple, but it took me a while to find it. Hope this saves grief for someone else
POSTSCRIPT - further woes on a field that had an ID containing two underscores (not adjacent to each other: it was "bookMode_0none_1RequestForm") - where Firefox (1.5.0.12) preselected the LAST option whilst it happily reported coding that showed a previous option selected.
Replacing the second underscore with an alphanumeric character sorted the problem. (No problem with the two-underscore term for name - it was ID that was the issue). But it's spooky stuff - extract the code with View Selection Source and paste into a new document and Firefox is fine with the two underscores. Could it be related to the fact that the code is being served up by php? No time to experiment more.
selected value='3'>Pineapple
If you load a page, select the option, then use View Selection Source - you find that Firefox comes up with:
selected='selected' value='3'>Pineapple
BUT if you then put that into your HTML, it ignores that too.
Answer: use selected='true'.
Simple, but it took me a while to find it. Hope this saves grief for someone else
POSTSCRIPT - further woes on a field that had an ID containing two underscores (not adjacent to each other: it was "bookMode_0none_1RequestForm") - where Firefox (1.5.0.12) preselected the LAST option whilst it happily reported coding that showed a previous option selected.
Replacing the second underscore with an alphanumeric character sorted the problem. (No problem with the two-underscore term for name - it was ID that was the issue). But it's spooky stuff - extract the code with View Selection Source and paste into a new document and Firefox is fine with the two underscores. Could it be related to the fact that the code is being served up by php? No time to experiment more.
Friday, 20 July 2007
IE workaround - Losing unwanted padding within Input buttons in IE 6 (and perhaps IE7) using CSS
PROBLEM - IE adds over-generous padding to left and right of an input type="submit" button - and this gets to be a real problem at larger font sizes. The padding cannot be removed by adjusting padding or margin settings, but there is a way ...
Subscribe to:
Posts (Atom)