On Aug 17, 2005, at 10:02 AM, Edward Clarke wrote:

I see your point about backward compatibility but B and I aren't
technically, semantically empty. (If that makes sense).

<span style="font-weight: normal;">Harry Potter</span>

makes sense...

<b style="font-weight: normal;">Harry Potter</b>

does not.

Both of your examples make the same amount of sense, semantically. Bold text does not mean anything different than non-bold text, and therefore boldness has no semantic meaning. Consider the semantics of these (fictional) tags:

    <compass>North</compass>
    <surname>North</surname>
    <dictionary-entry>North</dictionary-entry>

Those are three different meanings that "North" can have. In your example, the span'd Harry Potter is the same as the b'd Harry Potter, and that would be true regardless of what content you wanted to span or b. That's why I say b is semantically empty.

What you are saying though, is that it doesn't make sense to declare that the b tag not render as bold. To which I reply, in a CSS browser, none of the presentation properties should be derived from the tag, and all should be derived from the CSS. Why single out a specific, meaningless tag? All presentation must be in the CSS, regardless of the tag.


B and I being visual tags should be removed from the markup and styled via
<SPAN> or inherited from its parent element, the styled using CSS.

img is also a visual tag. This is likely the reason that img was going to be removed (like b and i) in XHTML2, until a developer outcry insisted it remain for backwards compatibility (nonsense, I say -- if you're moving to XHTML2, the img tag is the easiest thing to transform). I wholeheartedly agree with removing presentation from the markup. This is why in my original post I stated that using b gains you backwards compatibility, but you *must* style it appropriately, as if it were a span; otherwise, you fail to separate.

Allow me to reiterate:
- b and i are not deprecated (i.e., valid but marked for future removal)
    - they are semantically empty, and must be thoroughly styled
    - they achieve a semblance of backwards compatibility

Some point out that b and i are deprecated because they are not in XHTML2. This argument is soft at best; for example, the very document pointing out that b and i are deprecated requires a use of the label element that is incompatible with XHTML2.

http://www.w3.org/TR/WCAG20-HTML-TECHS/#label
http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod- list.html#edef_list_label

Those trying to code their XHTML1.0 Strict to be forward-compatible with XHTML2 have their work cut out for them.


It's a
fundamental aspect of removing presentation from content; something I
believe should fail (but doesn't) the validator on any STRICT DTD check.

Don't confuse "valid" with "preferred technique." The Strict DTD is a different DTD than the Transitional or Frameset DTDs, and it is not better or worse, nor are the other DTDs less strict (as in "rigidly applied"), they just include more options. What you are proposing is that the Strict DTD should not include b and i; it's a valid argument, but it does not reflect the approved Recommendation of the W3C.

--

    Ben Curtis : webwright
    bivia : a personal web studio
    http://www.bivia.com
    v: (818) 507-6613




******************************************************
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
******************************************************

Reply via email to