[Wylug-help] Browser Detection (and HTML loops)

[Peter Nix]

Dave,
I'm pretty much an empiricist about this. For ongoing css editing I put
a 10 second refresh in the page header and open the page in some
browsers on another machine[s]. AS you elaborate yr css you seen see
what works in wildly different ways on different browser/os
combinations.

To catch the less obvious quirks and deviations I highly recommend
Browsercam:
http://www.browsercam.com/
Does just what it says:
"Browser Cam creates screen captures of your web pages loaded in any
browser, and on any operating system, so you'll be 100% sure your web
pages look good-and work right-on any platform. Click here to register
now!" Couple of trial registrations are usually enough to pick most of
my problems up.
Interview with the author here:
http://meet-the-makers.com/conversations/witchel/
Peter


On 22 Nov 2004, at 12:33, Dave Fisher wrote:

> On Mon, Nov 22, 2004 at 11:57:36AM -0000, Andrew Teal wrote:
>> I'd have to ask why you wanted to do browser detection?
>
> Because anything approaching sophisticated CSS layout runs up against
> major browser differences in box model and float model implementation.
>
> The deliberate and consistent IE misimplementations can be handled
> reasonably elegantly, without resorting to nasty CSS hacks (mainly
> abusing
> unimplemeted CSS properties to hide stuff) or producing spaggetti code
> CSS, or using JavaScript.
>
> Unfortunately, none of the big browser layout engines (IE, Gecko,
> KHTML/Safari and Opera) are especially good on consistency (e.g. Opera
> has used both IE and standard float models, while there is great
> variation between the rules for quirks/standards modes and the
> conditions which trigger them). Hell, even the standard itself changed
> the box model between CSS2 and CSS2.1 !
>
>
>> Put "browser detection deprecated" into Google and you get a few
>> reasons
>> why you might no longer want to do it, not all JavaScript based. I
>> suspect that these, rather than any technical difficulties, are behind
>> the "not recommended" comment on the JavaScript version. And these
>> would
>> mostly carry forward into the perl version.
>
> Yes.  I think I am aware of most of the difficulties, including the
> often well-intentioned, but misguided practice of user agent spoofing.
>
> My problem is that I may not be aware of all the alternative
> 'solutions'.  Without such knowledge, it seems unreasonable to conclude
> that server-side browser detection combined with careful CSS
> modularisation is thoroughly irredeemable.
>
> One proferred 'solution' (JavaScript object detection in the browser
> DOM) seems to threaten more nasty side effects than the browser
> detection disease it claims to cure.
>
> Using the absolute minimum of common CSS or table-based layouts are
> also
> pretty problematic.
>
> I'm happy enough to abandon the idea of browser detection, if I can
> find
> an alternative which enables low cost, low maintenance, standards
> compliance, usability, visibility and accessibility.
>
> Not asking much am I?  ;-)
>
>
>> BTW, I was quite interested in your email on the gb course on "seo" --
>> however, we've already put in quite a lot of work on the technical
>> side
>> of our website. Do you think I'd get value from the course?! See
>> http://www.hud.ac.uk/hhs. The hardest job is to get up to date content
>> out of possible contributors, and I suspect that creation and
>> provision
>> of relevant up to date content is the best way to enhance the ranking?
>
> No question about it.  This is why even technically competent sites
> (most aren't) tend to fail.
>
> Dave
>
> _______________________________________________
> Wylug-help mailing list
> Wylug-help at wylug.org.uk
> http://list.wylug.org.uk/mailman/listinfo/wylug-help
>

--
Peter Nix, AHRB CentreCATH, School of Fine Art, History of Art &
Cultural Studies,
Old Mining Building, University of Leeds, Leeds, LS2 9JT, UK.
http://www.leeds.ac.uk/cath/  http://www.leeds.ac.uk/fine_art/
Eml: p.j.nix at leeds.ac.uk Tel: 0113 343 2580 Fax: 0113 343 1628