> -----Original Message----- > From: Mordechai Peller > > Geoff Deering wrote: > > It is better practice to stop using such elements, especially when > > there are other elements that serve the same purpose, but are more > > semantically correct and accessible > > I agree with the exception of sub and sup which I agree with the draft > in that they have semantic value. >
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". Yes, I agree they have semantic meaning and value. > > You can code your XHTML1.x to be compatible with XHTML2, which when it > > becomes a recommendation and supported, will mean minimum maintenance > > by oneself and reap the benefits of future and backward compatibility. > > 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. If it references a DTD and it is not valid, when it hits the first invalid declaration it jumps back to quirks mode, once it does that, it back to best guess (which many do amazingly well, all considered... just goes to show they can do better). 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. This is also good discipline if you have to start working with generating structure and presentation from XML and XSLT based tools. It also aids you so you don't have to code different front ends for different devices. > > I often have trouble dealing with the inconsistency of the various W3C > > specifications, as the W3C does itself. I tend to focus more on the > > WAI specifications because they (to me) are more refined in this area, > > and teach on better practices. > > 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, and others parsers. <b> and <i> have no meaning in a screen reader. So the ROI of all your efforts, kind of falls short when you consider you have put in this much great effort to get this far. 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. > > It amazes me that this type of thing has been kept in when there is > > there is such a strong movement towards semantic and separating > > structure and presentation. > > IIRC, it was felt that b and i had some semantic value. I disagree. A > similar discussion is now taking place in regards to br and hn. > Personally, as I see it, the difference between l and br is one of > focus: What's important, that the preceding and following text should be > viewed as distinct lines, or gut not the same line. It's a subtle > difference, but a difference none the less. <b> and <i> are purely visual, they have no semantic meaning when rendered into speech of braille, etc. Geoff ***************************************************** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *****************************************************
