Re: more CSS and tables

Vadim Plessky wrote:

> |   Because the span indicates that the use of the greeen colour is
> |   just a designer's whim, and is complete noise in terms of the
> |   meaning, whereas em indidcates the colour is being used to stress
> |   the word, and, a good house style will always use the same way of
> 
> frankly speaking, I do not understand why you want to "stress" this word.
> I prefer to avoid stresses as much as possible :-)


Changing the color to green *does* stress this word for visual users. 
The question is, why do you want only visual users to receive this stress?

David's point is that there must be a reason for applying different 
styles to spans of inline text. Usually there is an HTML element (such 
as EM) that fulfills this function better than SPAN. That so many people 
use SPAN instead implies that they do not really know why they are 
applying a different style to that text.

A much better use of SPAN (IMO) is to label specific items in your text 
(as I mentioned to you off-list). For example, I might like to label the 
  titles of books and the names of authors on my pages (especially if I 
were designing a publishing site):

Last summer I read <span class="BookTitle">Gravity's Rainbow</span> by 
<span class="BookAuthor">Thomas Pynchon</span>.

Now that I've labeled these items, I can choose whether to apply styles 
to them now (or later), and if I do apply styles, then I can do so based 
on the function of the text in my document. So I might decide to make 
all book titles bold italic and all authors' names italic. And I can 
change them anytime.

Using <span style="color: green">some text</span> is pointless. I have 
no idea why this is green, and no way to distinguish it from any other 
green text. If I decide later that I want this text red, I must find 
every instance of it in my code and change them individually (or risk a 
global search and replace on not-very-unusual data).

Also, I have no central source of information about this style. I have 
to find this individual text in the page to note that it is green. If I 
use class="BookTitle" instead, then all I have to do is look for 
.BookTitle in my stylesheet and I can see what properties every book 
title on the site has.

Better still, if I have green book titles and green magazine titles and 
green CD titles (and they are appropriately labeled) I can later decide 
to make book titles red, magazine titles blue, and CD titles black and 
do it all with three simple edits to one file.

Put another way, the color:green example above is simply a FONT element 
in sheeps clothing. Why bother switching?

(And as you pointed out in your reply, <span class="BookTitle"> is just 
XHTML for <BookTitle> in XML. With XSLT, I can easily shift my page back 
and forth between XHTML and some other XML dialect.)

I regularly use SPAN and DIV to encode meta-information that would have 
been encoded had I been using XML. If I choose to convert these sites 
later, all that information will already be present.

Also, in the above example, I would probably use SPAN for the author's 
name, but EM for the book title, since book titles are typically 
emphasized (using italics). That way the emphasis is preserved even on 
non-CSS browsers.


> 
> |   stressing, at least in that sort of division, so it can put in the
> |   house style rules.  Even if you don't explicitly think of speech
> |   browsers, a speech browser can emphasise the em case.  Even if you
> |   don't think of monochrome displays, the monochrome browser can
> |   bold or italic it.
> 
> ok, now we should recall teletype for compatibility issues?
> My recent study of web statistics shows that majority of web users (>80%) has 
> high-color displays (either 24-bit, 32-bit or at least 16-bit)
> So even supporting 8-bit displays doesn't make much sense nowdays...
> And you are speaking about monochrome...


I am surprised that you would make this argument, Vadim. Aren't you the 
same developer who just reminded us that bandwidth is important? Why 
should people care about those with bad phone lines but not those with 
monochrome monitors?

There are people throughout the world who can only access the web 
through slow connections and old equipment. If you are using a 286 with 
a monochrome monitor and Windows 3.1, you can't run IE 6, and even if 
you could, you can't see the fancy pages that most developers seem to 
insist on. It is important to use HTML properly -- that means using the 
right element. If text is to be emphasized, put it in an EM element. If 
it is strongly emphasized, put it in a STRONG element. If it is a 
heading, use the appropriate Hn element. If it is not a heading, *don't* 
use a heading element.

If you use the code properly, your pages will display properly on older 
browsers without any extra effort on your part. All the complaints about 
how much time it takes to make pages cross-browser compatible come from 
people who are trying to force HTML to do things it was never meant to 
do. Keep it simple and you can serve everyone -- even users in Russia 
with slow connections.


> |   Also, and possibly more importantly, the user knows about em, and
> |   can define their own rule, to provide them (or their clients) with
> |   a predictable result.  (You could also provide user style sheets that
> |   people could use on this and other pages.
> 
> excuse me, but I do not know about <em>.


Sure you do. When you see italicized text, your mind reads it as 
emphasized. When you see bold text, your mind reads it as emphasized. 
When you use EM, older browsers (and newer ones, too) use italics or 
bold weight to convey that emphasis to you. It's quite effective, and 
virtually universal.


> And all people around me (both web developers and web users) do not know 
> about <em>.


They may not know the HTML element EM, but they do understand emphasis. 
And that was David's point.


> I do not think that using <b></b> is better than <em></em> as I can also 
> argue that not all systems support Bold font.
> I think that you can use just <a></a> and define 
> a { color: green }
> or whatever you want for speach browser.
> Than you at least do not forget to add aureal section to stylesheet, and this 
> wil work even in browsers not supporting <em>


And the browsers that do not support EM are?


> I personally do not care about loosing <em>
> DIV and SPAN do all the tasks for legacy HTML, for XML ... well, you do not 
> have pre-defined tags at all :-))


Div and span might be enough for newer browsers, but for legacy browsers 
you might as well just use plain text. Div means only a block element to 
them, and span might as well not exist.


> than this "ISO HTML"  just sucks.
> I am for the web standards, but you should not adopt everything "as is"
> Head is given to the human to *think*, not to follow some Nation Leaders 
> (recent experience and a whole 20th century shows that people still tend to 
> follow leaders...)


Actually, these standards are based on the work of a great many people, 
not one of which (to my knowledge) qualifies as a "Nation Leader." There 
is significant consensus around issues like proper nesting of heading 
elements, at least among those who care about accessibility and 
well-structured documents.

Of course, print publishers also care about proper nesting of headings. 
Show me the commercial newspaper or magazine that does not nest headings 
properly. The question is whether you are willing to reflect that 
nesting in your code, or use hacks to create the visual impression of 
nesting while violating it at the code level. It is only possible to 
justify the latter method if one believes that visually-abled users 
count, but that visually-impaired users don't.


> |   I'd point out that use of such markup is a requirement of at least
> |   one of the WCAG levels.
> 
> It's ok with me. :-)
> WCAG should achieve some market penetration first in order to be valueable 
> argument.
> Postings on this list show that even people interested in WAI have a lot of 
> confusion with WCAG.


The point of WCAG is to improve accessibility for users. Accessibility 
first, market penetration second. If we wait for market penetration to 
adopt accessibility practices, we'll never see market penetration. After 
all, market penetration is simply the sum of those developers using 
accessible practices. No developers = no market penetration.

Sincerely,
Charles F. Munat
Seattle, Washington

Received on Wednesday, 9 January 2002 01:52:53 UTC