There is at least one tool I am aware of (common tool found on a lot of
desktops) that does exactly what Charles describes - putting arbitrary chunks
of information into an HTML source and then relying on CSS to provide logical
flow.
Charles McCN
On Wed, 17 Jan 2001, Charles F. Munat wrote:
Ben Morris wrote:
The following would become unreadable without css:
.colHeader
{background: black; color: white;}
...
<td bgcolor="black" class="colHeader">Header</td>
Reply:
Yes, but the real problem here is that CSS is being mixed with deprecated
HTML formatting attributes - exactly the danger I was talking about a month
or so ago and the reason I'm in favor of avoiding all HTML-based formatting.
A more interesting question is, How can one make a document unreadable
without CSS using CSS alone? And the obvious answer is that the HTML
structure of the document must be broken and CSS used to fix it. Then, when
CSS is turned off, the user would be left with the broken HTML structure.
The simplest example of this would be to use absolute positioning. Suppose
that I listed the elements of a page in random order (maybe they're
paragraphs), then used CSS to reorder them:
<style type="text/css">
#e1 { position: absolute; top: 10em; }
#e2 { position: absolute; top: 1em; }
#e3 { position: absolute; top: 7em; }
#e4 { position: absolute; top: 4em; }
</style>
<span id="e1">Fourth element</span>
<span id="e2">First element</span>
<span id="e3">Third element</span>
<span id="e4">Second element</span>
To add to the confusion, I've used SPAN instead of P. This is a very simple
example (and you'd ask, Why bother?), but consider a much more complicated
page and you could see how someone might be thinking entirely in absolute
positioning terms and then just randomly add the items to the bottom of the
page as he went.
Without absolute positioning, it's a little more difficult to do something
stupid, but how about this:
<style type="text/css">
p { font-size: 2em; padding: 0.3em; }
p.Col1 { float: left; }
</style>
<p class="Col1">A</p>
<p>D</p>
<p class="Col1">B</p>
<p>E</p>
<p class="Col1">C</p>
<p>F</p>
I could also have used SPAN elements (or EM or STRONG) and set display:
block. What a mess that would be.
Add Javascript to the mix and you can really go to town! Here is an example
that will work in Internet Explorer (but could easily be extended to other
browsers):
<head>
<style type="text/css">
.ItemData { display: none; }
</style>
</head>
<body onload="showData();">
<p>
<span id="i1" class="ItemData">Hats</span>
<span id="i2" class="ItemData">Coats</span>
<span id="i3" class="ItemData">Boots</span>
<span id="q1" class="ItemData">4</span>
<span id="q2" class="ItemData">7</span>
<span id="q3" class="ItemData">10 pair</span>
</p>
<script type="text/javascript">
var item = new Array();
var qtty = new Array();
item[1] = document.all.i1.style;
item[2] = document.all.i2.style;
item[3] = document.all.i3.style;
qtty[1] = document.all.q1.style;
qtty[2] = document.all.q2.style;
qtty[3] = document.all.q3.style;
var x = 1;
function showData() {
for (i = 1; i <= 3; i++) {
item[i].display = 'none';
qtty[i].display = 'none';
}
item[x].display = 'inline';
qtty[x].display = 'inline';
x++;
if (x > 3) x = 1;
setTimeout(showData, 1500);
}
</script>
</body>
This will change the display every 1.5 seconds. First you'll see Hats 4,
then Coats 7, then Boots 10 pair. But without the JavaScript you'll see
nothing, and without the CSS you'll see Hats Coats Boots 4 7 10 pair. Make
the list ten times as long and you'll see how confusing this could be. And
it wouldn't surprise me to find a page like this being generated dynamically
with the lists of items and quantities being generated separately and then
just dumped on the page.
Of course all this can be avoided if one uses this method for coding pages:
1. Build the structure of the document in XHTML strict. Do no formatting
whatsoever. (I use DIV elements to group items in a logical manner, and
sensible class names to identify function beyond P or H1, etc.)
2. Check to ensure the page is readable in the browser (should work in all
if your XHTML is correct).
3. Add CSS to make the page look the way you want it to look, checking it in
a variety of CSS browsers. Use a separate stylesheet and avoid as much as
possible applying styles to individual elements (either via the style
attribute or via an ID).
4. If AND ONLY IF you absolutely cannot get the page to work properly
without a deprecated attribute, change the doctype declaration to
Transitional and add in the deprecated item. There are very few instances
where this is really necessary:
a) name attribute on A elements for linking to fragments
b) type and start attributes on nested lists (older browsers)
c) align on IMG elements (older browsers)
d) border on IMG elements enclosed in A (Netscape 4)
But maybe you should just rethink the page.
The improvements gained in accessibility by using the above deprecated
attributes is, IMO, minimal. I generally avoid them unless I feel that the
usability of the page will be seriously harmed by their absence.
If you design from the structure out rather than from the "look" in, you'll
find that you're less tempted to do things on your page that can't really be
done yet. You'll be more inclined (at least I am) to work within the
limitations of the medium. And you'll find that this system is much, much
faster than starting with a page designed in say PhotoShop and then trying
to hack the code to force it to work in multiple browsers (especially when
Netscape 4 is in the mix).
I've accepted that my pages will be rather plain looking in legacy browsers,
and will occasionally look a bit strange in Netscape 4 (though I never
sacrifice readability or usability). On the plus side, they look great in
Lynx, seem to work well in screen readers and self-voicing browsers, and
look and work great in the newest CSS browsers (Opera 5, IE 5.5, Netscape
6... I don't have access to a Mac).
Hope this answers both the question and suggests a workable solution.
Sincerely,
Charles F. Munat,
Seattle, Washington
--
Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
until 6 January 2001 at:
W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France