Re: Menus, navigation, and simplicity (Perhaps slightly off-topic)

> 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, and personally, I 
think CSS is the next best thing since sliced bread (save with some issues 
I have with it). I thought the move was to give the client control over 
the web page, instead of forcing a look and feel onto them. My favorite 
explanation of why is here: http://www.alistapart.com/stories/dao/

>A web document is composed of, from the bottom up, structure,
>content, scripts, and layout. If the structure is missing, users are
>in trouble. If the content is missing, users are gone. If the scripts
>are missing, no big deal. If the layout is missing - well, it could
>look prettier for sure.[*]

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?

>If you create a mechanism for inclusion on the client - say OBJECT -
>and that mechanism doesn't work or isn't supported it is easy to
>include alternate content.

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. My personal feeling is that 
backwards compatibility for every version of every browser is asanine and 
pointless. Support for Lynx and other text-based browsers is fine, and can 
be accomplished by, for the most part, following good design standards, 
but catering to every version of Internet Explorer since 2.0 is ridiculous 
(as an example). Upgrade, people. Especially if you're using browsers from 
the dark ages of web standards, when nobody really followed them, or made 
up their own to follow.

>However that leaves you with updating two versions. 

As opposed to updating hundreds or thousands of versions? I'd rather 
update two versions than two hundred, even with a Perl script, batch file, 
whatever.

>So we'll include the alternate content from the same source
>as the OBJECT-included content at the servers-ide. But that defies
>the whole idea ...

>Today you can use frames to include content. And you can put
>alternatives in the noframes section. You can even include the same
>content in both places - if you have a server-side or pre-processing
>system.

Yes, but as has been discussed many times in the past, frames are old, 
outdated, and have terrible problems with accessibility, linkage, and 
many, many other issues.

>Done right, client-side inclusion of content and structure still
>leaves you with either doing the manual update job you wanted to
>avoid, leaving users with out-of-date versions, or using a
>server-side/off-line system to include the alternative. In which case
>you could just use the same system to include the content in the
>first place.

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? Again, I may be idealistic, 
but I envisioned a world where inaccessible, standards-failing 
enterprise-level web content management solutions would not really be as 
necessary, because the capability to include a standardized graphical 
identity across an enterprise is inherent in the standard to begin with.

>Back to square one.

Back to square one only for people who aren't willing to keep moving 
forward. Again, call me an idealist, or maybe even a perfectionist, but I 
think we really can get there someday. I'm sorry, but I just don't like 
the sentence "Back to square one." It sounds far too defeatist, and sounds 
like far too many of the managers, faculty, staff, and department heads I 
meet and talk to on a daily basis who are not willing to even consider a 
proactive response to accessibility in general.

I don't mean to say that the addition of such a capability would be easy 
or perfect. Far from it. I know it would take a while, and I know that the 
road is a long one, but that's not reason to give up without further 
consideration, at least in my mind.

Kevin A. Sesock, A+, NET+, CNA, MCSA
Deskside Computer Support Specialist
Student Disability Services
SLA Program
Information Technology Division
Oklahoma State University

"In theory there is no difference between theory and practice, but in 
practice there is." --Unknown