- From: Vadim Plessky <lucy-ples@mtu-net.ru>
- Date: Fri, 11 Jan 2002 01:42:23 +0000
- To: w3c-wai-ig@w3.org
On Wednesday 09 January 2002 06:54, Charles F. Munat wrote:
| 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?
well, I understand that we discuss this problem on WAI ML - but here is my
*personal* reason.
I exactly use <SPAN> to highlight (or *stress*, if you like this word more)
text in my CV.
I know that it's somewhat funky to have CV in HTML - as most people use MS
Word .doc for this task, few people use PDF, and almost none uses HTML (and
those last people using HTML - put it on web, but without any intention to be
hired or whatever)
Frankly speaking, I do not think that I can be hired by some blind person -
so there is no reason at all to include aureal CSS rules into styleheet
inside my CV.
Anyway, aureal rendering can be easily added to that CSS - if it's really
necessary.
|
| 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.
In my understanding of this problem: you are talking about semantics here.
I think that both CSS and HTML are at *grammar* (syntax) level, not at
semantics parsing.
Browser should not know *what this HTML file is about*.
(otherwise, we will get Judgement Day soon!.. And have to struggle with
Terminators :-)
|
| 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.
you are very right here.
I also prefer to name CSS class first, than apply formatting on it.
Naming some element / class "BookTitle", you open a way to convert your
markup to XML later.
so it will be just
<BookTitle>Gravity's Rainbow</BookTitle>
which is much better than using *any* kind of legacy HTML.
|
| 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?
well, most web masters do not bother at all.
|
| (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.
|
| > 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 was dicussion on this list about "minimal browser requirements"
I guess it's very close to the point of "minimal system requirements"
I understand that you may want to use aureal browser when you can't see the
screen. But if you can see your screen: why, for the heaven's sake, we should
use monochrome?
IIRC, "color increases readability by 78%"
As about bandwidth - yes, it's absolutely important.
I guess people (and companies) still not recognized *how* important bandwidth
is.
I think that issues of mono/color, high-res images/low-res should be solved
under "customization" menu of the web site.
And, returning back to my mail:
My research shows that (potential visitors I am interested in) have
high-color (>8-bit) displays. So guess what color depth I should use on the
site?
|
| 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
I see your point, but want to add to it:
you can't satisfy *all* users. Marketing wisdom says that 5% of auditory
(visitors, users, etc.) will be always _unsatisfied_ with your product,
service, etc.
So, you should focus your efforts on the rest (95%), which is still A LOT,
IMO.
| 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.
to tell you the truth: English teacher in the school (and in University when
I was studing after) forgot to teach me word "emphasize". :-)
I know that this can sound strange to native English speaker, but people
using English around me do not use this word at all. Pls believe me!
Your arguments are wuite good for native English speaker. But <em> will say
nothing to the people in Easter Europe. I believe people in Germany also use
different word for this task.
| 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.
ok, I guess I explained it with more details above.
|
| > 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?
ha-ha... I haven't tested browsers for this :-)
But if I found some time to code minimalist browser in the future, it can be
that I will get rid of <em> together with Tables.
Probbaly, it's so simple to add support for <em> using pre-defined
stylesheet - but may be it's better to make <em> available as an option.
|
| > 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.
Legacy browsers? What they are?
MS IE has 92%-95% marker share, Netscape/Mozilla - 4%, the rest is in 1%-4%.
AFAIK, NS6 based on Mozilla M18 has good support for SPAN and DIV.
MS IE also support it. So, what's the point with remaining 1%?..
|
| > 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.
well, if you speak about consensus in HTML - yes, it explains its uglyness
and brokeness.
CSS is *better defined*, but ... you may want to take a look on thread "How
is it possible to devise such a feeble system?" on www-style mailing list.
Tjis, and many other threads show that people are *not happy* how some W3C
standards defined, and do not accpet these standards "as is" just because
it's W3C standard.
Software development practice and research in Computer Science (I refer here
to 1970-2000 period, 30 years) shows that consortiums were always *failing*
to bring out good, reliable, understandable standards.
Compare Pascal and Cobol. Than, one generation later - Modula-2 and Ada.
There are some people from Microsoft participating in W3C consortium.
Do you seriously say that Microsft is not pretending "Nation Leader"?
As far as I know, they are somewhat "World-dominated Leader", to be precise:
monopolist, pushing their products down the throat.
And yes, history (and business practice) shows that people follow Microsoft
course. That's reality. And the fact that MS doesn't care about accessibility
of their sites is so well known that I even don't want to repeat it here.
|
| 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
My experience shows that commercial newspaper or magazine care only about
money from advertisings.
Same is valid for online press.
| 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.
yes, that's exactly the point were we stand at a moment :-((
|
| Sincerely,
| Charles F. Munat
| Seattle, Washington
--
Vadim Plessky
Moscow, Russia
Received on Thursday, 10 January 2002 17:40:55 UTC