|
-----Original Message-----
From:
Mordechai Peller
Geoff
Deering wrote:
They are not part of the "Font Style Elements", they are part of the
"Special Inline Elements". But this shows how even the W3C specs can be
misleading, cause FONT is part of the Special Inline Elements", yet B, I, U
etc are "Font Style Elements".
I've done some digging, and I think I've found the source
of some of our confusion; in part we're both right and in part we're both
wrong.
For starters, the HTML4.01 Font
style elements include the TT, I, B, BIG, SMALL, STRIKE, S, and U
elements, of which only U, S, and STRIKE are deprecated. (FWIW, I partly
disagree with deprecating STRIKE, since it's a way of conveying negation.) For
the rest: "The following HTML elements specify font information. Although they
are not all deprecated, their use is discouraged in favor of style
sheets."
Now lets skip ahead to XHTML1.0 Modularization and
XHTML1.1. Here you have the Presentation
Module, which includes the b, big, hr, i, small, sub, sup, and tt
elements, which aren't deprecated, and the Legacy
Module, which includes some various attributes and the basefont, center,
dir, font, isindex, menu, s, strike, and u elements, all of which have been
deprecated. As of XHTML1.1, the Legacy Module has been dropped.
Moving
ahead still further to the future XHTML2, most of the Presentation Module
elements have thus far been dropped except for sub, sup, and hr. The newly
formed Inline
Text Module includes both sub and sup, as well as a bunch of other
elements. The hr element has been added to the Block
Text Module, but is under consideration for either removing
or renaming.
Agreed, but I not sure why you would need to switch. As I see it, the
worst that will happen is that a future browser won't have a default
style for b and i.
For a number of reasons. User-agents that render to a valid DTD render
faster and more accurately if the document is valid.
Both b and i are in, and will forever be in, the DTD for XHTML1.1. If
that's your DOCTYPE, then they are valid.
I
have no disagreement with this at all. What I am saying is if you
develop a large site, that is very well designed and engineered, then, when
XHTML2 comes out there are found to be HUGE benefits for using it (this is
just hypothetical), then what is the cost justification for then bringing the
site up to date, when there were techniques and strategies for future
proofing? What I am saying is it is better right now to drop tags like
<b> and <i> because they are useless to screen readers and a waste
of time for future compatibility, when other tags are more appropriate
<strong> and <em>. That's my point.
The more you can follow the STRICT philosophy, of separating structure from
presentation the more you flexibility in your design and deployment methods,
and you get the above advantages.
If you mean "STRICT" as a proper noun, I disagree because it's part of
the XHTML1.0 STRICT DTD. If, on the other hand, you mean "STRICT" as an
adjective, then I totally agree. One problem with all caps is that there is a
loss of semantic meaning; a common problem with presentational mark-up.
What
I am saying is the basic philosophy behind the STRICT DTD is separation of
structure and presentation, and that that approach has a ROI in content
management and deployment, especially when sites have to be redesigned and
regenerated.
This is also good discipline if you have to start working with generating
structure and presentation from XML and XSLT based tools.
You can do that even with XHTML1.0 Transitional.
On
large projects, Strict will always be more efficient and have a better ROI
over a number of SDLCs.
Except the main topic is validity; accessibility is only secondary.
If you take that approach then the structure of you markup may be valid, but
semantically meaningless to people using other devices,
If I "take that approach" then I'm staying consistent with the topic of
this thread. If you go back ant look at various comments I injected into my
replies, you will see that I don't support the use of b and i, despite that
they are valid.
And
all I said was as far as their semantic value, and their future deprecation,
they are not worth using.
If you read the accessibility material, those people really know the
semantic power of markup better than the average developer. There's a huge
knowledge base there.
Depends on which material you're talking about; they're not all of equal
quality. I have a suggestion, go take Andy
Budd's Quick Accessibility Quiz and we'll see who scores better. I will
admit, after reading the WAI guideline I would have rephrased some of my
answers, but Andy was prohibiting that when I took it. I don't know if I got
all five correct, but I'm sure I got at least four right. (However, I've been
certain and wrong before, so we'll see.)
That
is a very very poor quiz, and shows the author does not understand WCAG1
very well at all. Actually,
it shows more that he does not know how to form the proper
questions.
Geoff
|
