Re: Minutes from 16 November 2000 WCAG WG telecon

> Sean, this is one of the guidelines that remains somewhat incomprehensible
> to me. [...] I don't typically work from outlines but start working with
the
> first word or graphic for a page...

It seems to me that your main question is "why should we separate
presentation from content?".
A fairly rigid answer, but one that provides no explanation is the following
(I'll provide an explanation as well):

     It is a violation of SGML to specify markup for presentation: end of
story.

"SGML purists would assert that HTML, in particular early HTML, does not
rigorously implement all the SGML principles for example, hierarchical
structure and elimination of presentation-specific markup from a
ocument"  -
http://www.ncu.edu.tw/~center5/book/quebooks/netscap3/netch33.htm

"When writing an SGML document, the author identifies the document part
(title, procedure list, footnote) and provides its content. They don't say
what that part will look like; that is defined separately, and typically by
someone else. The writer doesn't waste time in what the text looks like." -
http://www.mulberrytech.com/papers/whatsgml.html

Why do people think it is so hard to write a structural XHTML document and
then apply the style afterwards. Hey, if I can learn to do it, I'm pretty
sure that anyone can!

Here is another good quote that I found:-
[[[
"With Styles, your sites load faster. You work faster, too. Styles shave
grueling hours of grunt-work off your design workload: one brief CSS
document can style an entire domain; and when it's time to redesign, you can
execute site-wide changes in minutes instead of days. Style Sheets bring
genuine leading and sophisticated margination to the web, easing our
readers' eyestrain while bringing us the control of negative space we take
for granted in other media. They offer exciting new possibilities, from
absolute positioning, to interactive manipulation of text and images. And
they allow us to create sophisticated layouts while doing no harm to the
underlying structure of our documents - ensuring that search engines (as
well as hand-held devices, web phones, and other futuristic browser morphs)
can "understand" our pages as easily as readers do. Plus, unlike
cross-browser DHTML, JavaScript, and other advanced technologies, CSS is
bone-simple to learn and use."
]]] - http://www.alistapart.com/stories/fear/
Other evidence why presentational markup is bad, and separate style is good,
is presented (pun intended) at:
http://www.mcsr.olemiss.edu/~mudws/font.html
http://tech.irt.org/articles/js135/

But we need to look at it from an accessibility viewpoint as well. What
better way than to give an example:-

Example: A user needs to specify their own style sheet that makes document
backgrounds dark. In fact, I often require this. If you put presentation
information in the document it then becomes very hard for me to override it
with my style sheet.

> As Kynn pointed out, this isn't a religious affiliation, and true
believers
> are tempered by practical voices.

I am a practical voice. I use CSS on 99.99% of my sites, and to good effect.
Take a look at http://www.mysterylights.com/

> CSS may be practical someday, but today isn't that day.
> Before CSS is widely supported, something better may come
> along ..

I sincerely doubt that.

> Something that combines coding for "visual aides" however they are used,
so
> that hearing readers know what's going on. At present, by using a graphic
> as a line instead of <hr>, I can apply an alt tag, a Title, and a long
> description. What more is offered in CSS?

All of that and much much, more! My gripe was with hr itself, but I used img
as a means of getting round the fact that most people use title as an alt
attribute. I'm not opposed to the correct usage of images in HTML.

Winess my example again:-

     <p dc:author="Robin">This bit was written by Robin</p>
     <hr />
     <p dc:author="Sean">This bit was written by Sean</p>

What does the <hr /> stand for if a blind user was looking at it? It is in
fact a border between one author of the document and another. But having
<hr /> doesn't imply that, it's just a visual horizontal rule: and *that* is
one of the greatest problems with HTML. You could write:

     <p dc:author="Robin">This bit was written by Robin</p>
     <hr title="Division between content implying different authors" />
     <p dc:author="Sean">This bit was written by Sean</p>

But that still doesn't mean much; it is still *incorrect*.
In reality, because <hr /> is presentational and only for screen media, you
should scrap <hr /> altogether, i.e.

     <p dc:author="Robin">This bit was written by Robin</p>
     <p dc:author="Sean">This bit was written by Sean</p>

And use the following CSS style sheet:

@media all {
*[dc\:author="Robin"]:before { content: "The following section was written
by Robin: "; }
*[dc\:author="Sean"]:before { content: "The following section was written by
Sean: "; }
}
@media screen {
p[dc\:author="Robin"] { border-bottom: 1px solid #000000; }
p[dc\:author="Sean"] { border-bottom: 1px solid #000000; }
/* Really this should apply to all block level elements,
but I just used p as an example */
}

Fair enough that it doesn't work in NS3 etc., but then it is only a pointer,
and not essential to the document structure. The essential part is that it
has been marked up with the authors included: which all goes to prove that
you should attempt to find a correct semantic equivalent.

Does this make any more sense now?
> >      Guideline 2. Separate content and structure from
> >      presentation and explicitly define significant structural
> >      or semantic distinctions in markup or in a data model.
> >    - http://www.w3.org/WAI/GL/WCAG20/

I certainly hope so!

Kindest Regards,
Sean B. Palmer
http://xhtml.waptechinfo.com/swr/
http://www.w3.org/WAI/ER/
http://www.w3.org/WAI/GL/
"Perhaps, but let's not get bogged down in semantics."
   - Homer J. Simpson, BABF07.

Received on Saturday, 18 November 2000 15:57:15 UTC