TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Browser capabilities? Stick to the standards. From:Arlen -dot- P -dot- Walker -at- jci -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 31 Mar 2000 14:12:30 -0600
subtitled: Standards? What Standards?
>It's amazing what you can do
>with vanilla HTML if you try. And if everyone ignored proprietary
Microsoft
>and Netscape extensions, just maybe we wouldn't have all this grief
>designing multiple pages with different features.
Except, of course, for all those areas where browser-builders implemented
standard features in different, mutually-exclusive, ways. Or failed to
implement a standard feature at all (a lot of CSS and DHTML falls into
these categories, for example).
Certain browser-specific workarounds are easy, as they fix a problem in one
browser but don't adversely affect the other browser (Netscape's
implementation of CSS background colors, for example, or the margins around
the window). Others are more, um, interesting (for example, I can't get
iCab to recognize an external style sheet no matter what I try) and require
some javascript coding to get around, which, of course, won't work for
those who have turned off javascript in their browsers.
The best technique I've seen for working around these "features" involved
XML, XSL and server-side java. The pages were written in XML, and the java
servlet matched the browser type with an XSL template and rendered the page
in HTML tailored for that particular browser.
Performance was acceptable, but the server also wasn't on one of those
million-hits-per-day sites.
BTW, I'd be the last one to say you need to write for 100% of the browsers
out there; I'm not nearly sadistic enough to say that nor masochistic
enough to try it. You have to decide for yourself where the cutoff point
is.
But beware of the net survey sites. They measure only their own audience.
There is *no* valid sampling method supporting their results. Your audience
may overlap with theirs. But then again it may not. For example, if you're
Apple Computer, I can guarantee the visitor numbers for your site will be
different from, say, Enprise. And I doubt seriously SGI will get many
visitors from WebTV, but TVGuide, OTOH, probably will. It *might* be OK to
base your preliminary work on net surveys, but get your own site usage
statistics as quickly as possible and find out for yourself who your
customers are. Then decide how many of them you can live with offending,
and use that as a guideline for your first *real* site design.
As in so many other areas, making life easy for my customer involves making
life hard for me. My job is find the LaGrange point between customer
hostility and designer suicide. Everything else is mere detail.
Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 224
Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.