Browser Detecting [was Re: CSS Font Sizes and Macs]

by "Kehvan M. Zydhek" <kehvan(at)zydhek.net>

 Date:  Sat, 23 Sep 2000 07:00:19 -0700
 To:  "Darrell King" <darrell(at)webctr.com>,
<hwg-techniques(at)hwg.org>
 References:  hotmail bellsouth tele rr
  todo: View Thread, Original
Having never used PHP, I could be wrong, but I think a browser detect script
COULD easily be hundreds of lines long. I have an older detector that I no
longer use that was written in JavaScript. It's 147 lines long and detects
quite a varied combination of browsers and platforms (or so I'm lead to
believe -- I have two platforms and nine browsers to test with). But the
problem inherent with any detector script that detects OS and/or browser
manufacture and/or browser version is that you will miss something. Granted,
what you miss may be insignificant, but if it exists at all, SOMEONE uses
it.

The thing about most detectors is that they assume the following:
OS: Windows or MacOS
Browser: Netscape or MSIE

Yes, there are more complicated scripts that include other OSs and browsers,
but let's face it, these four are the most common. But, based on the above
assumption, we completely miss Opera, K-Meleon, WebTV, iCab, Lynx, Amaya,
Netscape 6/Mozilla (detects and acts differently than current Netscape
browsers) and any of a hundred (or more) alternate browsers. We also miss
out on SunOS, UNIX/Linux, BeOS, WebTV, as well as at least a dozen other
operating systems (not including so-called ancient OSs like DOS, Amiga,
Atari, Commodore, CoCo, etc). Not included in the detect are the specialty
browsers such as braille and speaking browsers, which may or may not be
effected by the original discussion on font sizes. Add to this script the
detection of browser and OS versions (since there are differences between
versions) for each of the above. Add all these up and pair each browser (and
individual version) to each OS (and individual version), drop pairs that
aren't possible (like iCab on Windows), compact the detection algorhythm to
the tightest coding possible, and you may STILL wind up with a detector in
the hundreds of lines of code. On high-speed connections, who cares? It's
just a few extra milliseconds. But on slow or unreliable connections, a
couple hundred lines of code may be the difference between a site that's
visited or clicked away from.

You could trim out all the above paragraph and go with:
OS: Windows or MacOS or OTHER
Browser: Netscape or MSIE or OTHER

Probably 95% or better of your visitors would be accurately detected, but
what of the remaining 5%? How can you write a page if you're unsure how
it'll show up? That is the trick, and unfortunately, I can't give an answer,
because I'm sure even my detection scripts (which are based on the DOM, not
the browser manufacturer or OS) fail on the unknown SOMEWHERE.

Detection scripts are a fuzzy area, and you have to weigh the pros against
the cons. If your solution is sufficient for your needs, then go with it.
That's what I've done.

Good luck!
Kehvan

----- Original Message -----
From: "Darrell King" <darrell(at)webctr.com>
To: <hwg-techniques(at)hwg.org>
Sent: Saturday, September 23, 2000 04:46
Subject: Re: CSS Font Sizes and Macs


> I tried these as well, with predictable results.
>
> I can think of only two possiblities so far that service all crowds:
>
> 1) Use a scripting language to determine browser/OS combinations and
deliver
> the style sheet accordingly.
>
> 2) (untested except in IE5.5 on Windows) Set the basic font for the page
in
> the body description using pixels, and then use the variable ems to
control
> the subsequent displays within that document.
>
> Since ems use the parent element to set their base, they will follow
adjust
> according to the parent.  The problem here, of course, is that I am
deciding
> what the largest default value of the page is anyway, by setting that size
> in the body.
>
> This is against everything I believe right regarding accessibility.
>
> I can't leave out Mac users because my clients consist of them, and I
can't
> leave out people with accessiblity issues because it is against every
policy
> I have on the subject.
>
> I am stringly leaning toward using the first option.  I doubt it would
take
> more than a few lines of PHP to accomplish this.
>
> D
>
>
> ----- Original Message -----
> From: "Rebecca Jean Pedersen" <rjp(at)mail.tele.dk>
>
>
>
> yes... i find that small and x-small and xx-small give netscape vs ie
> problems, but going larger is okay (if i remember correctly)  basically
> xxsmall is okay on ie but unreadable on netscape. and i had a client who
> demanded it that tiny.  urgh. some just dont listen...
> but i like using relative sizes in case a user has it set higher for
> reasons of poor eye sight etc.
>
>
>

HWG hwg-techniques mailing list archives, maintained by Webmasters @ IWA