Making browsers behave the same
Tim Streater
for all browsers not behaving identically, I put some effort into making
my app work under Firefox. I got hold of FireBug to help with the
process. What I found was:
1) Firefox is rather stricter than Safari, so I fixed a few minor nits
in my JavaScript.
2) Firefox doesn't like innerText at all, so I went through and changed
my JS to use textContent instead. Not a bad thing perhaps.
3) Firefox won't, or can't, accept .tiff images in the <img> tag, so I
had to redo a number of small images I use as buttons, as .gifs.
4) Firefox can't accept UTF-8 files that have a BOM, so I had to
redefine a couple of my source files as "UTF-8 (no BOM)". Easy to do in
TextWrangler.
5) FF seems to have some different defaults than Safari, but by adding a
tiny amount of css here and there this was overcome.
So far, I ended up with an app that runs tolerably well under FF. However:
6) FF doesn't appear to allow the app designer (me) to use my own
cursor, but only one of the pre-defined set. In this regard it's not
following the standard.
7) Some of my buttons aren't rendering right (which I may yet be able to
fix).
8) Worst of all is the textarea, a space into which you can type. There
is no mechanism to allow the textarea to automatically expand and shrink
as you add or remove lines of text from it (true for all browsers). In
Safari the user can change its size with the mouse, rather like any
window, but not in FF. If the textarea gets too much text, you can
arrange for it to get scroll bars, but that is not what I want.
The upshot of this is that I have to employ a crude method of counting
characters to see how big I should, under program control, make the text
area, as text is entered/removed. This is not satisfactory and seems to
give different results for the two browsers. If I were to insist on
making this work perfectly and identically between the two, it could be
quite some effort, and I can't be bothered.
Still, the exercise has been interesting, and FireBug has some extra
facilities over Safari for debugging, and vice versa, so it's been
useful anyway.
--
Tim
"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"
Bill of Rights 1689
T i m
<timst...@waitrose.com> wrote:
>Following T i m's rather plaintive assertion that there is no excuse
>for all browsers not behaving identically, I put some effort into making
>my app work under Firefox. I got hold of FireBug to help with the
>process. What I found was:
>
<snip>
>
>
>Still, the exercise has been interesting, and FireBug has some extra
>facilities over Safari for debugging, and vice versa, so it's been
>useful anyway.
Glad to have been some inspiration. ;-)
Cheers, T i m
Ben Shimmin
[...]
> 8) Worst of all is the textarea, a space into which you can type. There
> is no mechanism to allow the textarea to automatically expand and shrink
> as you add or remove lines of text from it (true for all browsers). In
> Safari the user can change its size with the mouse, rather like any
> window, but not in FF. If the textarea gets too much text, you can
> arrange for it to get scroll bars, but that is not what I want.
>
> The upshot of this is that I have to employ a crude method of counting
> characters to see how big I should, under program control, make the text
> area, as text is entered/removed. This is not satisfactory and seems to
> give different results for the two browsers. If I were to insist on
> making this work perfectly and identically between the two, it could be
> quite some effort, and I can't be bothered.
TEXTAREAs and form inputs in general have always sucked in terms of
cross-browser consistency -- making a form use the same buttons, and
for everything to be similarly sized, between Safari, Firefox, and
Internet Explorer is... really rather a struggle.
I'm not sure Safari's neato ability to let the user resize a TEXTAREA
really makes matters any better (though I like it as a feature).
b.
--
<b...@bas.me.uk> <URL:http://bas.me.uk/>
`Property, marriage, the law; as the bed to the river, so rule
and convention to the instinct; and woe to him who tampers with
the banks while the flood is flowing.' -- Samuel Butler, _Erewhon_
Tim Streater
> Tim Streater<timst...@waitrose.com>:
>
> [...]
>
>> 8) Worst of all is the textarea, a space into which you can type. There
>> is no mechanism to allow the textarea to automatically expand and shrink
>> as you add or remove lines of text from it (true for all browsers). In
>> Safari the user can change its size with the mouse, rather like any
>> window, but not in FF. If the textarea gets too much text, you can
>> arrange for it to get scroll bars, but that is not what I want.
>>
>> The upshot of this is that I have to employ a crude method of counting
>> characters to see how big I should, under program control, make the text
>> area, as text is entered/removed. This is not satisfactory and seems to
>> give different results for the two browsers. If I were to insist on
>> making this work perfectly and identically between the two, it could be
>> quite some effort, and I can't be bothered.
>
> TEXTAREAs and form inputs in general have always sucked in terms of
> cross-browser consistency -- making a form use the same buttons, and
> for everything to be similarly sized, between Safari, Firefox, and
> Internet Explorer is... really rather a struggle.
>
> I'm not sure Safari's neato ability to let the user resize a TEXTAREA
> really makes matters any better (though I like it as a feature).
Agreed about the feature. It does help to the minor extent that if my
attempts to size it based on content fail, I can always resize by hand.
Gordon
> 3) Firefox won't, or can't, accept .tiff images in the <img> tag, so I
> had to redo a number of small images I use as buttons, as .gifs.
TIFF files tend to have massive file sizes compared to the usual web
image formats, GIF, JPEG or PNG, and as you noticed they don't work in
all browsers. I tend to prefer using PNG for most stuff, with JPEG
for files where the file size would be overlarge for PNG. Don't
forget people have to wait for all this stuff to download, so for that
reason alone TIFFs shouldn't be used for web graphics. Additionally
PNGs have some nifty transparency modes controlled by alpha channel
that are supported in modern browsers (even IE7+)
> 4) Firefox can't accept UTF-8 files that have a BOM, so I had to
> redefine a couple of my source files as "UTF-8 (no BOM)". Easy to do in
> TextWrangler.
That's odd, I've never noticed any problems caused by this, except
when building a page with a script assembling fragments together and
one of the fragments contains a BOM. Then you get a few odd
characters appearing.
> 6) FF doesn't appear to allow the app designer (me) to use my own
> cursor, but only one of the pre-defined set. In this regard it's not
> following the standard.
As far as I'm aware CSS only allows you to select cursors from a
predefined list guaranteed to work in all browsers. CSS 3 might have
a custom bitmap for cursors feature but I am not aware of it, and as
CSS 3 is still quite new you can't depend on it being fully supported
in all browsers.
> 7) Some of my buttons aren't rendering right (which I may yet be able to
> fix).
Form buttons are the bane of many a web designer. Getting them to
format uniformly across all browsers is a royal pain in the arse, and
if you try using <button> controls you can cause Internet Explorer to
throw a complete eppy.
> 8) Worst of all is the textarea, a space into which you can type. There
> is no mechanism to allow the textarea to automatically expand and shrink
> as you add or remove lines of text from it (true for all browsers). In
> Safari the user can change its size with the mouse, rather like any
> window, but not in FF. If the textarea gets too much text, you can
> arrange for it to get scroll bars, but that is not what I want.
Auto-sizing textareas can be achieved with a little javascript.
function textareaGrow ()
{
this.style.height = 'auto';
if (this.clientHeight < this.scrollHeight)
{
this.style.height = this.scrollHeight + 'px';
}
}
$('textarea').live ('keyup', textareaGrow).live ('focus',
textareaGrow);
The function is plain javascript, but the event trigger requires
jQuery. You can rewrite it to use your own method of event attachment
if you like, or you can add jQuery to your page quite easily.
Tim Streater
> On Nov 25, 11:35 pm, Tim Streater<timstrea...@waitrose.com> wrote:
>> 3) Firefox won't, or can't, accept .tiff images in the<img> tag, so I
>> had to redo a number of small images I use as buttons, as .gifs.
>
> TIFF files tend to have massive file sizes compared to the usual web
> image formats, GIF, JPEG or PNG, and as you noticed they don't work in
> all browsers. I tend to prefer using PNG for most stuff, with JPEG
> for files where the file size would be overlarge for PNG. Don't
> forget people have to wait for all this stuff to download, so for that
> reason alone TIFFs shouldn't be used for web graphics. Additionally
> PNGs have some nifty transparency modes controlled by alpha channel
> that are supported in modern browsers (even IE7+)
I changed them to .gifs, and their size went from typically 1.5k to 800
bytes or so. The only issue now (that the .tiffs in Safari didn't have)
is that if there is a background colour, there is some white speckle
around the image. I'll try .png.
>> 4) Firefox can't accept UTF-8 files that have a BOM, so I had to
>> redefine a couple of my source files as "UTF-8 (no BOM)". Easy to do in
>> TextWrangler.
>
> That's odd, I've never noticed any problems caused by this, except
> when building a page with a script assembling fragments together and
> one of the fragments contains a BOM. Then you get a few odd
> characters appearing.
Well, this was a complete source file (i.e., starting with <doctype> and
ending with </html>), loaded into a new window. FF 3.5 just displayed a
blank screen with a couple of odd chars (the BOM) and nothing else. I
could see the entire file, and the BOM chars, in FireBug's html tab.
>> 6) FF doesn't appear to allow the app designer (me) to use my own
>> cursor, but only one of the pre-defined set. In this regard it's not
>> following the standard.
>
> As far as I'm aware CSS only allows you to select cursors from a
> predefined list guaranteed to work in all browsers. CSS 3 might have
> a custom bitmap for cursors feature but I am not aware of it, and as
> CSS 3 is still quite new you can't depend on it being fully supported
> in all browsers.
OK - perhaps I was getting ahead of myself there. Safari even allows you
to specify the cursor's hotspot.
>> 8) Worst of all is the textarea, a space into which you can type. There
>> is no mechanism to allow the textarea to automatically expand and shrink
>> as you add or remove lines of text from it (true for all browsers). In
>> Safari the user can change its size with the mouse, rather like any
>> window, but not in FF. If the textarea gets too much text, you can
>> arrange for it to get scroll bars, but that is not what I want.
>
> Auto-sizing textareas can be achieved with a little javascript.
>
> function textareaGrow ()
> {
> this.style.height = 'auto';
> if (this.clientHeight< this.scrollHeight)
> {
> this.style.height = this.scrollHeight + 'px';
> }
> }
>
> $('textarea').live ('keyup', textareaGrow).live ('focus',
> textareaGrow);
>
> The function is plain javascript, but the event trigger requires
> jQuery. You can rewrite it to use your own method of event attachment
> if you like, or you can add jQuery to your page quite easily.
Thanks - that might be helpful. I won't use jQuery but I'll look into
adding the event separately. Does this auto-shrink as well as autogrow?
While investigating this issue, I did find some js that would do the
former. but not the latter.
Cheers,
Richard Tobin
Gordon <gordon...@ntlworld.com> wrote:
>That's odd, I've never noticed any problems caused by this, except
>when building a page with a script assembling fragments together and
>one of the fragments contains a BOM. Then you get a few odd
>characters appearing.
If it isn't at the beginning of a document, it isn't a BOM. Elsewhere,
it's a zero-width-non-breaking-space (ZWNBSP) and should be invisible,
assuming it's in a context where that character is allowed.
BOMs are fairly pointless for UTF-8 documents (since they don't have
a byte order). They weren't allowed in early versions of XML
(relevant if you're using XHTML), but were added mainly because
some Microsoft software insisted on producing them.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Tobin
Tim Streater <timst...@waitrose.com> wrote:
>Well, this was a complete source file (i.e., starting with <doctype> and
Presumably you mean <!DOCTYPE
>ending with </html>), loaded into a new window. FF 3.5 just displayed a
>blank screen with a couple of odd chars (the BOM) and nothing else.
If the file is being read as UTF-8, it should be read as a single
character. What media type and encoding did Firefox believe the page
was using?
Tim Streater
> In article<LKSdnQWmLbpfw5PW...@brightview.co.uk>,
> Tim Streater<timst...@waitrose.com> wrote:
>
>> Well, this was a complete source file (i.e., starting with<doctype> and
>
> Presumably you mean <!DOCTYPE
<grin> yes indeed.
>> ending with</html>), loaded into a new window. FF 3.5 just displayed a
>> blank screen with a couple of odd chars (the BOM) and nothing else.
>
> If the file is being read as UTF-8, it should be read as a single
> character. What media type and encoding did Firefox believe the page
> was using?
I'll check.
Tim Streater
> In article<420e5ac5-d4b3-4948...@a32g2000yqm.googlegroups.com>,
> Gordon<gordon...@ntlworld.com> wrote:
>
>> That's odd, I've never noticed any problems caused by this, except
>> when building a page with a script assembling fragments together and
>> one of the fragments contains a BOM. Then you get a few odd
>> characters appearing.
>
> If it isn't at the beginning of a document, it isn't a BOM. Elsewhere,
> it's a zero-width-non-breaking-space (ZWNBSP) and should be invisible,
> assuming it's in a context where that character is allowed.
Definitely at the beginning. A couple of years ago, I had this issue in
another context, and eventually (not knowing what was going on), did a
hex-dump of the file. Then I found these (this? one or two? can't
remember) chars at the beginning, and on looking further into the issue,
decided these were the BOM.
It only is an issue in my app now, as I want the � char to appear on the
screen.
Duncan Kennedy
Streater <timst...@waitrose.com> writes
>
>I changed them to .gifs, and their size went from typically 1.5k to 800
>bytes or so. The only issue now (that the .tiffs in Safari didn't have)
>is that if there is a background colour, there is some white speckle
>around the image.
This sounds very like the effect you get when you make a transparent GIF
on, say, a white background then make the background transparent before
inserting it on different colour. Say working on a white background,
selecting white as the transparency colour then inserting the result on
a blue background - this will give shades of white dots around the
graphic. It is an anti-aliasing effect usually.
If your end background is other than the one you made the graphic on try
making it again on a similar colour to the end use.
>I'll try .png.
>
I've always found PING to be rather bigger than GIF. However browsers
tend to see only 235 "browser safe" colours (I.E. mean of all common
browsers - as usual some Internet Explorer versions use a different 256
colours to all the other browsers) and that can result in strange
dithering patterns if you use GIF on, say, a photograph - JPEG is much
better for that but GIF comes into its own on areas of plain browser
safe colours.
--
Duncan K
Downtown Dalgety Bay
Tim Streater
> On 26/11/2009 11:47, Richard Tobin wrote:
>> In article<LKSdnQWmLbpfw5PW...@brightview.co.uk>,
>> Tim Streater<timst...@waitrose.com> wrote:
>>
>>> Well, this was a complete source file (i.e., starting with<doctype> and
>>
>> Presumably you mean <!DOCTYPE
>
> <grin> yes indeed.
>
>>> ending with</html>), loaded into a new window. FF 3.5 just displayed a
>>> blank screen with a couple of odd chars (the BOM) and nothing else.
>>
>> If the file is being read as UTF-8, it should be read as a single
>> character. What media type and encoding did Firefox believe the page
>> was using?
>
> I'll check.
OK, this was my fault. I'd saved the file as utf-8, but not changed the
charset in the <meta> tag to utf-8 away from iso-8859-1. When I did
this, FF had no BOM issue any longer.
Thanks for pressing me on that, I hadn't spotted it.
Gordon
wrote:
> I've always found PING to be rather bigger than GIF. However browsers
> tend to see only 235 "browser safe" colours (I.E. mean of all common
> browsers - as usual some Internet Explorer versions use a different 256
> colours to all the other browsers) and that can result in strange
> dithering patterns if you use GIF on, say, a photograph - JPEG is much
> better for that but GIF comes into its own on areas of plain browser
> safe colours.
File size for PNG depends on a few factors. If you're trying to save
truecolour (millions of colours) then PNG files tend to grow rather
large, because it is a lossless format. In such cases JPEG which is
lossy but offers better compression would be a better choice. For
indexed colour files (2-256 colours) PNG tends to work out smaller
than the same data saved as GIF if you use no transparency, or GIF-
style single colour transparency. If you use Alpha transparency then
the filesize can go up a bit, but the benefits of Alpha transparency
offset this, namely you can have partially transparent graphics,
antialiased graphics that will work against any background, etc.
The software used to generate the PNG file will also have an impact.
Photoshop tends to generate rather inefficient PNGs if you use the
standard file save procedure. Fireworks is even worse because it
stores its layers and other working data in the PNG file as extra
chunks. Perfectly legal for the file format, but leads to major
bloat.
If you use the Save for Web feature in Photoshop the PNGs produced
will have smaller file sizes because the save for web mode apparently
uses its own PNG code that's more efficient than the standard
Photoshop saver. In Fireworks, use Export to save just the image and
not the extra data when creating your file for the web.
Finally there are various utilities that can re-compress PNG files to
wring every last scrap out of the file format possible.
Gordon
Yes, it will auto shrink. It works by first setting the style.height
attribute to auto. This will cause the text area to shrink to its
default size as specified in your CSS. It then checks if the textarea
has gained a scroll bar. If it has it increases its size to that
needed to get rid of the scroll bar. As you remove text from the
textarea this size will become less and less.
Tim Streater
Oh, clever! Thanks! I will pursue that with great (well, some) vigour.