Re: [WSG] Styling Text...

[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. 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. 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. 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. 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.) IIRC, it was felt that b and i had some semantic value. I disagree. <snip/> <b> and <i> are purely visual, they have no semantic meaning when rendered into speech of braille, etc. So then we're in agreement here.