Re: B vs Strong

Kynn,

I'm often amused by the limitations of E-mail and how easy it is for civil
discussions to morph into digital road rage. Must be something volatile in
the mix of human nature and the particular pheromones of E-mail. But damn
the torpedoes...

I am not an expert (I freely confess to being an English teacher who
wandered down a strange aisle of the bookstore). But to my credit, I
recognize this and so seek out folks who seem to know more than I do. I pin
them in a corner and grill 'em till some lights go on in my dim dome. You're
the current hapless victim of my quest.

But I don't know *what* the heck you're saying and it's really starting to
fry my little lizard brain.

Here's my confusion. On the one hand, I hear you saying something like:
A)  XHTML is 'obsolete'--from its very conceptual roots upward it's 100%
wrong-headed. If you're not using XML and XSL to transform it into XML, then
wake up, you sap, because you're absolutely wasting your time backing a very
dead horse. 

On the other hand, I hear you saying something like:
B)  moderation and realism are called for and if you don't have time to
learn the basic concepts of HTML, then don't sweat it. Do the best you can
with what you've got.

Why is WYSIWYG--and colorful code it tends to generate--a reasonable
compromise, but XHTML the Devil's Own Spawn? Or is that not what you are
saying?

What are you saying?

Regards,
Davey Leslie

Thus spake Kynn Bartlett on 01.1.20 1:13 AM at kynn-edapta@idyllmtn.com:

> At 5:03 PM +0900 1/19/01, Davey Leslie wrote:
>> Twice recently you've mentioned that you consider XHTML to be "obsolete."
>> As far as I can tell, the W3C considers XHTML 1.0 to be the current W3C
>> Recommendation.
> 
> I know this.  As I don't work for the W3C, please don't expect me to
> fully support every activity undertaken by the W3C.
> 
> I feel that attempts to make XHTML -- an XML dialect based on XHTML --
> into a structured language for content are way off.  HTML is already
> pretty much a lost cause, and attempting to build on that base is
> just going to be unproductive.  So far all the efforts at building
> XHTML have taken a very long time and have produced very little
> beyond what you can get from XML itself, in twice the complexity.
> (By this I refer to XHTML modularization.)
> 
>> Now, I'm not a hot shot expert with lots of fancy titles--I'm just a guy
>> down in the virtual trenches trying to figure which voice to listen to: the
>> voice that says there is a reasoned consensus about best practices;
> 
> In my opinion, you have to strike a balance between two or more
> approaches.  There is _not_ "one true way" to do things that will
> meet everyone's needs and situations.  Trying to claim that there
> is akin to claiming that one user interface can meet the needs of
> all users with or without disabilities equally.
> 
> Heh.  That's another place, of course, where I and the official
> W3C party line part our ways -- I believe very strongly that it is
> naive to assume that one set of XHTML, delivered identically to
> all user agents, will "degrade gracefully" enough to give an
> acceptable level of access to all people.  This is why I have
> spent more than a year working on the problem of adaptive systems
> which provide customized interfaces based on user needs and
> preferences.
> 
>> or the
>> voice that says it doesn't really matter because the situation is so screwed
>> up anyway--
> 
> I didn't say that.
> 
>> Bobby doesn't really work,
> 
> Bobby works for a limited definition of the word "work" -- it helps
> catch a few pretty glaring errors that can be caught automatically.
> The people at CAST make no secret of that fact; they readily mention
> that Bobby is not an absolute check for "accessibility."
> 
> However, in the context of this particular thread, I've not even
> addressed the limitations of the Bobby program; instead I have
> stated that if you are a WYSIWYG user, Bobby won't do you any good,
> because the amount of knowledge you need to understand Bobby is
> higher than the amount of knowledge you need to understand a
> WYSIWYG editor.
> 
>> validation doesn't really mean anything,
> 
> Validation means -something-, but it doesn't mean -everything-.  Note
> that valid HTML is a level 2 priority checkpoint in WCAG 1.0, not a
> priority 1 checkpoint.  Validation is useful in theory, and is
> generally a good thing to do, but it is not a guarantee of accessibility
> any more than a Bobby logo is.
> 
>> and WYSIWYG-ed pages are good enough.
> 
> Good enough in one context?  See, that's part of the problem, in
> assuming that we can talk about accessibility in a vacuum, outside of
> issues of implementation -- that accessibility can be the _only_
> issue worth considering.  A very specific case was defined:  Non-
> designer teachers with limited training resources and no software
> budget want to put content on the web -- how can you do that in the
> most accessible way?  And FrontPage plus instructions on how to use
> FP features to increase accessibility are a solution that works for
> _that_ situation, as well as any solution can work given the
> premise.
> 
> Now, sure, you can change the premise -- you can say "okay, let's
> assume that we want to teach them HTML", but that wasn't part of the
> original spec, or you can say "well, let's buy an expensive editor
> program", etc. -- but as written there is no perfect solution.  So
> a solution that partially works is necessary.
> 
>> The later is what I hear you saying and it puts me in a heck of a bind.
>> You're one of the experts, right?
> 
> I don't know if I'm an expert or not.  I've examined the issues and I
> have my own opinions on them.
> 
> --Kynn

-- 
"Keep your monkey up!"
Davey Leslie 
davey@inx-jp.org

Received on Saturday, 20 January 2001 10:04:29 UTC