Client side anything... Was:RE: Menus, navigation, and simplicity

>>> please pester more people with it, how about the html / xhtml lists?
>>> @include menu.html is every bit as valid as linking to an image, css,
>> or script.

>> Personally I cannot agree with you. Using a client-side methodology
>> to include content and structure is a Bad Idea.

> Why is this, in particular? This is what CSS is doing, <snip>

Yes and no... CSS imported using the @include adds *style*, not content.  If
you don't have the web pretty you still get the web content, which is
usually the real reason people come to any site... for it's content, not
it's designer's(sic) artistic skills (some sites excluded - art sites are
for art...)

> I thought the big move these days with extensibility? Pull the layout
> out of the html to separate form and content. Be able to create your
> own data structures with xml, etc. Why would it be a problem to be able
> to reference a document in another document?

ahhh... re-read the proposal.  Referencing a document in another document is
as old as html itself... remember the anchor tag (<a href...>)?  No, what
Mr. Chetwynd is proposing is using *client side* methodology to include
content, which is extremely dangerous from both accessibility and usability
perspectives.  For if the user agent does not support a particular form of
client side inclusion (be it JavaScript's document.write or Jonathan's
latest scheme to use @include menu.html) then SIGNIFICANT AND IMPORTANT
INFORMATION IS LOST TO THAT USER.  If my user agent did not support the
@import scheme as indicated above, then the navigation component of the site
would not be available to me or my user agent.  Do you think this is a
positive or beneficial thing? Progressive or useful?

> I do agree that lack of support would be a problem, but then again, if
> and when something like this were to be recognized as truly a standard
> (in that it's time to start using them), as CSS, XML, DTD, and a host of
> other standards have been, they will already be relatively mature and will
> have been integrated into browsers for a long time.

This broad statement is based upon what exactly?  DTD may very well be a
standard (and, according to the HTML 4.01 Standard of 1999 a *MANDATORY*
element in every HTML document), most WYSIWYG authoring tools (sadly,
including Dreamweaver) do not include a DTD in their final output (unless
manually added by the savvy developer).  Audio Style sheets have been
"standardized" for over 4 years now, yet no commercial browser or assistive
technology yet supports them (please people, if I am wrong correct me).  One
of the fastest growing segments of net delivery is to cellular phones (et
al), especially in Europe... I am currently unaware of any of those
generation of user agents which support JavaScript/EMACScript.  When 85% of
the web pages I view cannot pass a simple validation to HTML 4.01
Transitional, how can you talk about mature implementation of Standards
within the web community?


> My personal feeling is
> that backwards compatibility for every version of every browser is asanine
> and pointless.

You, like everyone else, are entitled to your opinions.  If you can convince
the people who pay you to develop web content of this opinion, then you can
sleep knowing that your paycheck is safe.  I suppose you are too young/new
to really remember the "best viewed with wars" eh?

Backwards compatibility (or more precisely graceful degradation) is not
asinine, it is in fact an art rarely practiced today by Dreamweaver jockeys
who figure if it looks good in IE 5.5 or higher then it must be OK.  Do not
confuse developing to faults or quirks of older, less refined browsers with
developing clean, valid HTML.  All stakeholders must accept the fact that a
web page is not a print medium output... it's perfectly OK to look different
in different browsers, as long as it "works" structurally and semantically.
The pixel perfect "designers" are the dangerous ones, not those who clamour
for standards compliance.  I had a recent client tell me to lock down the
font on their site to 9 points because it looked more professional.  Who is
asinine here?

>Why must we rely on server-side inclusion for things along these lines? I
>understand truly dynamic content, but (and maybe this is me being
idealistic),
>I thought the standards were not only to inspire combatability (pun
intended)
>but also to ease the job of the developer. Isn't that one of the many
reasons
>behind CSS?

Once again, do not confuse style with substance.  Why not use client side
inclusion/scripting/etc.?  If you can tell me which browser I am using
tonight, then I will give you the golden key.

But the problem is, you really can't now can you.  You can't tell if I am
using a Windows OS, a Mac OS or a different OS again to view web content.  I
*might* be using a mainstream browser... then again, maybe not.  Perhaps I
am using an assistive technology, but which one, and why? (or am I?)

So how can you be sure that the user agent / machine configuration I am
currently using supports client side anything?  More importantly, why do you
feel you have the right to judge me or the technology I choose to use should
I decide to use a combination of technologies which do not support your
client side wishes?  Do you think omitting key content (@include
menu.html... MENU for gosh sakes...)is a positive thing?  If I don't get a
style sheet... well, too bad, I don't get to see your lime green text on
pink and yellow background. (Trust me, I could live without that anyway
<grin>).  You pose your question, I believe, honestly and in search of a
real answer.  The simple answer lies in the truth that you cannot know what
technologies the end user (your customer) is using, so do not assume that to
deliver key content or functionality that *their* machine/system/set-up can
deliver client side anything... be sure, and do it from your end, the server
end.  Key rule of thumb, if it's mission critical, keep it server side.

>Again, I may be idealistic,

No, not idealistic, but perhaps naive... and I mean no offence.  This is not
about burying our heads in the sand or wishing to remain in 1996, but rather
ensuring that we do not repeat the mistakes of the past.  Use the "new"
technologies and developments to their full advantage whenever possible,
preach the gospel of upgrading to standards compliant user agents, *develop*
to the existing standards and encourage all that you work with to do the
same.  But never lose sight of the fact that content is, was, and always
will be king.  And from that perspective, I would NEVER do anything that
could possibly remove content from my site, least of all relying on a client
side solution to deliver it.

Cheers!

JF

--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   1.866.932.4878 (North America)

Received on Wednesday, 16 July 2003 00:09:18 UTC