List of Technologies

Thanks, Sean, for fleshing out this list!

At 05:54 AM 1/2/2001 , Sean B. Palmer wrote:
>FWIW, here is my attempt at a more definitive list of techniques documents
>than the one Kynn gave:-

I'm going to go through the list and offer opinions on how high of
priority I think these should be.

>Techniques for:-
>- XHTML
>   - CSS Style for XHTML
>   - XHTML m12n

Yes, this is good.  This could potentially be combined together, but
leaving them separate allows for a possibly more "generic" CSS
document.  In other words, write a "pure CSS" techniques document
which assumes, but isn't limited to, CSS working with XHTML.  This
allows it to work with HTML, with XML, etc.

>   - XHTML for XML Pure UIs?

Not sure about this one yet (I see you're not either by the question
mark) -- so maybe put this down as a future project but not in the
first wave of stuff.

>- {XML (DTDs)
>- XML Schemas}
>   - CSS Styling for XML

As noted, we handed off XML issues PF -- but the CSS styling
described here could be included in the CSS techniques document
as mentioned under XHTML.

>- SVG

Yes -- and we should draft Chaalz to write this. :)

>- SMIL

Definitely.

>- MathML?
>- WML?

Hmmm.  I'd say hold off on both of these until next time.

>- Scripting langauges (ASP/PHP/CGI)?

I'm thinking that a server-side techniques document could lay the
framework for these -- including other techniques such as server-side
XSLT processing and the like.  Maybe call it 'generated content'
techniques.  Cynthia's thought a lot about these (draft her!)...

>- ECMAScript???

Definitely an ECMAscript/Javascript/Jscript document.

>In regards to XHTML, maybe it can be split up according to priority levels
>(if any) for WCAG 2.0. In other words, a Techniques document for "priority
>1", one for "priority 2" etc.

I'd rather avoid that because I think many people will want to set
their own compliance levels (e.g. section 508) based on their own
values, and building priorities too strongly into the techniques
document would be unhelpful to those people.  I do think that XHTML
should be broken up into logical "chapters" and not one huge file.

One more thing to add, which Sean probably won't like:

- HTML

I think we -have- to have a module for HTML if we want to be relevant
for the next couple of years.  To many people, learning a new
technology (XHTML for example) is scary and threatening and they
worry about backwards compatibility, about browser support for
new technologies, and about bureaucratic restrictions.  The vast
majority of web designers are coding in HTML (or think they are
writing HTML at least) -- if we say "thou shalt only use XHTML to
be accessible" then we will have lost them.

(I've seen this before -- early versions of WCAG 1.0 had a -very-
strong emphasis on CSS, which was, at the time, very untested, not
reliable, without good browser support, and generally unknown to
web designers.  The WCAG 1.0 draft made it seem like 'in order to
create accessible web pages, even single-A, you _must_ learn CSS'
and if someone didn't know CSS, that was as far as they read.  We
have to remember that many people who use HTML [sic] will look at
a list as above, and not seeing anything they recognize, decide
'accessibility is not for me, I have to learn XML in order to do
it!')

--Kynn

-- 
Kynn Bartlett  <kynn@idyllmtn.com>                    http://kynn.com/
Sr. Engineering Project Leader, Reef-Edapta       http://www.reef.com/
Chief Technologist, Idyll Mountain Internet   http://www.idyllmtn.com/
Contributor, Special Edition Using XHTML     http://kynn.com/+seuxhtml
Unofficial Section 508 Checklist           http://kynn.com/+section508

Received on Tuesday, 2 January 2001 12:10:52 UTC