View Full Version : Deprecating Toward Validation
drewprops
2006-03-26, 23:45
I spent awhile tonight chasing down problems on a new website I'm doing to make it validate as XHTML 1.0 Transitional and along the way I realized how confused I am about what will be considered valid XHTML and what is going to be (or may already be) deprecated. For instance, am I still supposed to be wrapping items that I want in bold with <b>bold</b> tags?
I know that a lot of people just walk away from this swamp knowing that they're "compliant enough" for their own needs but I've started enjoying writing compliant code.
The short version: No. You probably want to use <strong> or <em>.
The long answer: you should distinguish between well-formed, valid and semantically correct.
Markup is well-formed when it follows XML's rules. An XML parser is not allowed to accept non-well-formed markup, and, at best, can display it until the first error occurs. Well-formedness is easily machine-verifiable.
Markup is valid when it follows the DTD (in this case, XHTML 1.0 Transitional's DTD). It is fairly common for HTML parsers to accept certain errors, but for XHTML parsers, this behaviour has become generally significantly stricter. Validness, too, is easily machine-checkable.
Finally, there's semantics. The specifications usually explain a lot about this, but then, most authors don't read them. Worse, they're described in a human-readable context, so a machine cannot verify them. This is very important: your markup may be well-formed and valid but semantical nonsense. The beauty of a markup language is that it describes the content and its meaning, rather than the content and its presentation (i.e., the way it looks). For presentation, there's CSS. For functionality/behaviour, there's ECMAscript (aka JavaScript aka JScript) and DOM.
See, in the case of <b>, it's rather simple. <b> is exclusively presentational and should never be used in XHTML. The only reason it existed to begin with is that, during early days of HTML, there simply was no CSS and, as such, no way to manually define the "looks".
<strong>, per default, is set in CSS to appear bold. Ergo, you achieve the same effect, but in addition, you also give the text meaning: you're not making it bold just because; you're making it bold because it's important. You're emphasizing.
Another tag that emphasizes/stresses is <em> (short for, er, emphasis), which is usually set in CSS to appear italic, instead. Same here: don't use <i>.
If you want something to appear bold because it's a headline, don't use <strong>. Use <h*> and go to CSS to declare the specific looks. If you want something to appear bold, however, because it's an important point, within a paragraph, i.e. inline, do use <strong>.
Not that you probably want to go back through and redo a bunch of stuff as you've spent a lot of time massaging your CSS, but you may want to make more use of contextual selectors next time around. I found once I quit using so many classes I began enjoying CSS more.
All the <em> <strong> tags etc made more sense semantically when I defined them contextually as "here's what emphasized text looks like when it *happens* to be in the main body, here's what it looks like when it *happens* to be in the sidebar." That way you're defining your content by assigning unique ids to your structural <div> tags (as you've done), leaving the markup to be styled "automatically" just virtue of where it resides. The only time I really uses classes anymore is if I have a special case where a tag has to serve dual purposes (i.e. make the last <li> appear differently than the rest of them).
rollercoaster375
2006-03-27, 10:44
Not that you probably want to go back through and redo a bunch of stuff as you've spent a lot of time massaging your CSS, but you may want to make more use of contextual selectors next time around. I found once I quit using so many classes I began enjoying CSS more.
All the <em> <strong> tags etc made more sense semantically when I defined them contextually as "here's what emphasized text looks like when it *happens* to be in the main body, here's what it looks like when it *happens* to be in the sidebar." That way you're defining your content by assigning unique ids to your structural <div> tags (as you've done), leaving the markup to be styled "automatically" just virtue of where it resides. The only time I really uses classes anymore is if I have a special case where a tag has to serve dual purposes (i.e. make the last <li> appear differently than the rest of them).
Can't wait for CSS3... nth-child selector (Or rather, Pseudo class)=D
At the risk of derailing the the thread... what does the nth-child selector do? Add pseudo-classes to other tags besides <a> ? Something like an li:first and li:last would be useful. Too bad I won't realistically be able to use it for quite a while on commercial sites. :(
Pseudo-classes aren't exclusive to <a>. Maybe some *cough* browsers only implement them there, but nowhere in CSS's spec does it limit it in such a way (why would it, anyway? CSS is designed to be agnostic of the markup language it's being used on).
w3.org has a preliminary description of n-th child, including examples (http://www.w3.org/TR/css3-selectors/#nth-child-pseudo).
Looks interesting. Also I guess there are more than just <a> pseudo-classes in CSS 2, but not much (http://www.w3schools.com/css/css_pseudo_classes.asp).
To try and veer this back towards topic, do you guys (Chucker and Rollercoaster) use contextual selectors or classes more? Any other comments/best-practices on trying to use more semantically-correct markup? What would you use for copyright and disclaimer statements? I've been using <small> tags for those if it doesn't warrant it's own <div> (i.e. a footer with copyright in it). <small> and <big> have kind of turned into my catch-all tags when others don't seem semantically correct.
Oh and by the way. Mac IE 5 recently gave me headaches. Our client wasn't concerned with testing for that browser, but I did anyway on principal. Has quite a few odd bugs, and CSS2 support was incomplete when development stopped. Some very illogical display bugs that are hard to chase down.
Long story short, Mac IE 5 doesn't like left: positioning in certain situations. Use margin-left: instead. ;)
rollercoaster375
2006-03-28, 14:04
I generally prefer to use IDs, in combination with contextual selectors. My main reason for doing this is to give some sort of semantic meaning to my <div>s and <span>s.
I don't see why <b> is any different to <strong>. They both make text bold as standard, they both can be made to do something else in a CSS.
Because <b> has no semantic meaning whatsoever. It's purely an inline means of making text bold, something that's deprecated and discouraged.
<strong>, on the other hand, is inline as well, but means "stress this piece of markup (e.g. text)".
Uh, no. See here (http://mpt.net.nz/archive/2004/05/09/semantic), <b> and <i> are alive and kicking in HTML 4.0, XHTML 1.0 (except XHTML Basic) and XHTML 1.1.
Uh, no. See here (http://mpt.net.nz/archive/2004/05/09/semantic), <b> and <i> are alive and kicking in HTML 4.0, XHTML 1.0 (except XHTML Basic) and XHTML 1.1.
http://www.w3.org/TR/xhtml2/introduction.html#presentation
The very first version of HTML was designed to represent the structure of a document, not its presentation. Even though presentation-oriented elements were later added to the language by browser manufacturers, HTML is at heart a document structuring language. XHTML 2 takes HTML back to these roots, by removing all presentation elements, and subordinating all presentation to style sheets. This gives greater flexibility, greater accessibility, more device independence, and more powerful presentation possibilities, since style sheets can do more than the presentational elements of HTML ever did.
Are <b> and <i> presentation elements? Well, I suppose they are. Why else would they be in XHTML 1.1s presentation module?
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_presentationmodule
Uh, no. See here (http://mpt.net.nz/archive/2004/05/09/semantic), <b> and <i> are alive and kicking in HTML 4.0, XHTML 1.0 (except XHTML Basic) and XHTML 1.1.
Just because they are allowed doesn't mean they are good semantically.
I had the practically the exact same response as chucker's first reply, but I didn't see the thread until much later.
drewprops
2006-03-29, 14:52
Thanks for all the replies you guys, this has helped me gather my understanding together a bit better. The sad thing is that I bought a book on XHTML and simply haven't had time to dig into it yet. The markup for XHTML is far richer than I imagined and even though I'm not quite up to following along with those at the bleeding edge of markup theory it is all quite interesting. So much to learn~
JayReding
2006-03-29, 18:08
It can be a difficult transition - I started developing using standards all the way back in 2001, and I'm still learning things all the time.
Then again, when you start really caring about your markup and using semantics to your advantage, you get much better rankings with search engines and a better experience for your users - it's brilliant that you're willing to learn the semantic way of doing things, that is sometimes too uncommon in this industry.
drewprops
2006-03-29, 23:25
That's interesting about the better rankings with search engines... finally, an excuse for my new obsession!!
Some friends of mine design sites for a living and they're starting to make squeaking noises about having to "learn CSS" (they've sensed that they're about to be left behind). Wait until they tug on the innocuous looking little thread that is CSS.
For the record, I hate this thread. Every time I see it pop up in the recent thread list, I think it says:
"Deprecating Toward Vandalism"
wtf. :)
drewprops
2006-03-29, 23:50
I just sprayed "Trekkie" on your front door :p
For the record, I hate this thread. Every time I see it pop up in the recent thread list, I think it says:
"Deprecating Toward Vandalism"
wtf. :)
Hm... I go the other way. "Defecating Toward Validation"
It's not a pretty image :p
Wait until they tug on the innocuous looking little thread that is CSS. I hear that. This time last year I was only using CSS for general font styling. We'd at least been doing that(for a few years), but man...once I got into using table-less layouts and all the browser quirks you need to be aware of... that's a whole new ballgame. I was a bit spoiled at how well all the browsers supported the old table/spacer.gif method. But I'd say it's all worth it. The amount of control you have with XHTML/CSS is great, and once I got over the initial learning curve I don't want to ever go back to tables for layout (though we still do it for HTML email). CSS gets us so much closer to the control we have in page layout programs, and you gotta love the "automagical" nature of contextual styling.
JayReding
2006-03-30, 15:29
Things will get much better with IE7 - which supports CSS much better than IE 6 does. Right now getting things to work correctly with IE's horrendously broken CSS implementation is a major pain. IE7 makes a decent attempt to get things right, and while it isn't perfect, it's better than it was by leaps and bounds.
If you think CSS is bad, wait until you delve into the deep, dark world of DOM scripting... :)
Things will get much better with IE7 - which supports CSS much better than IE 6 does. Right now getting things to work correctly with IE's horrendously broken CSS implementation is a major pain. IE7 makes a decent attempt to get things right, and while it isn't perfect, it's better than it was by leaps and bounds.
If you think CSS is bad, wait until you delve into the deep, dark world of DOM scripting... :)
Yeah, I'm just worried that IE7 will fix all the CSS parse errors... but not fix the functionality. That would completely destroy many hacks designed to get around the bugs.
And, yes, JS and DOM crud is teh worst. I'm thinking about trying Ruby on Rails 1.1 to get some AJAX-y goodness without needing to overly worry about JS.
vBulletin® v3.6.4, Copyright ©2000-2024, Jelsoft Enterprises Ltd.