RE: The Age (AU) Technology Not Supporting Old Browsers

> -----Original Message-----
> From: Charles McCathieNevile
> As a long-time reader of the Age online, I noticed yesterday that it
> had changed and was going to write to this list to congratulate them.
> As Peter says, they have made serious (and I sadly agree brave in the
> current world of commercial web production) efforts to improve the
> site.
>
> Naturally there are improvements still to be made - some simple ones
> include

I agree.  My main point was that even when someone is trying to do better
design and deliver content for targeted user agents they can make a real
blunder when their browser sniffing logic is poor.  The Age is definitely
not alone in this, it's almost rampant if you are using Mozilla 1.6 on
Windows.

(My posting is for the list and not specifically for you Peter)

If you are going to browser sniff don't do this (which is the flawed and
lazy logic that gets caught out)

if
	/* known targeted browser do whatever ... */
else
	/* Unidentified browser, therefore categories as old browser, therefore do
old browser spiel ... */
endif

That's how a lot of developers write their case, identify everything that
you know, then lump everything else into the same basket as the old
browsers.  The problem is that you get caught with every new or unidentified
browser or user agent.

The logic instead should be complete and identify ever possible browser, and
for anything that can't be identified

else
	/* Unidentified user-agent, write details to custom log for identification
and testing */

endif

You might say that it's still not possible to identify the browser, which is
true, but if you identify the operating system and version you could make an
educated assumption on the browser.  Like if it is Mac running System 8 then
they probably have a really old browser not supporting CSS.  If it is
Windows XP, if the user agent can't be identified, it's more likely to be a
modern user-agent supporting CSS, (unless it is one of those pesky WCAG
developers that tests using every redundant browser under the sun:-).

It's flawed science because many masquerade as IE.

Even if it is truly the IE engine, you still do not know how it will behave
as far as workflow logic is concerned because there are all these browsers
that are built using the IE engine; NetCaptor, Crazy Browser, Advanced
Browser, etc, etc.  They are all shells built ontop of the IE engine.  They
all behave differently (their handling of CSS is consistent with IE), but
they handle JavaScript and pop windows differently, and a lot of sites popup
a window to start a new series of workflow, like filling in forms, then the
form post is done in JavaScript, etc, etc.  Just forgetting about all the
issues of JavaScript being disabled, in Crazy Browser, it just opens any
user triggered JavaScript new window action as a background tab.

So many users seem to prefer links being opened as background tabs.  The
development of browser design shows this; see how Opera has evolved in the
latest version to understand that this is a highly preferred way of browsing
(at least this is my observation and assumption).

The point I am making here, is that, I find as a web developer, that
following WCAG1 also helps me avert falling into so many potential design
traps that I would not so easily identify without following that design
discipline.  This is not even so much an accessibility issue as it is a
usability issue.  I find following WCAG actually helps me avoid falling into
flawed design issues.  It's a fundamental problem that the majority of
Business Analysts and UAT do not address.  WCAG can help avert so many
usability gotchas, let alone all the accessibility issues.

<for peter>
I'd like to see The Age address the (annoying) 8 minute refresh rate.  If
they have to use refresh
(http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-no-auto-forward)
does it have to be every 8 minutes?  Does the news changes that often on the
site?  Maybe I should just turn off refresh, maybe other users like it that
way?  I don't know.
</for peter>

It's great if you are using markup that conforms to a valid grammar, but it
not only  causes problems for user-agents when it is declared as a valid
grammar and doesn't conform or validate
(http://validator.w3.org/check?uri=http%3A%2F%2Fwww.theage.com.au%2Findex.ht
ml), as it actually takes the user agent longer to parse because it starts
in the mode identified by the doctype, and when it finds something that does
not conform to that doctype it flips out of parsing in that doctype mode and
has to revert to quirks mode (documents parse much faster if they are a
valid doctype, all the modern browsers support this).

Actually The Age should not be singled out here.  It's a real problem trying
to get any CMS producing quality valid markup grammar.  It's easy as a
developer just to forget an />.  But so many sites declare DOCTYPES and give
very little attention or effort to develop them.  It's not an easy issue to
address in large and complex organizations.  It's also something the
authoring tool vendors need to focus on and address.

I feel developing to a formal grammar is a high priority, I actually feel it
comes first, but as a general rule of thumb, I feel if there is no policy or
effort to comply, just don't bother declaring a doctype, use quirks mode and
hope for the best, cause there's no point in declaring a doctype if there is
no aim to comply with it(there, I have said something blasphemous on this
list:-).

Geoff

Received on Friday, 23 April 2004 15:20:20 UTC