Check this out!

webdeveloper.com/forum/showthread.php?p=755345&posted=1#post755345

In a word...wow.

Maybe LNR should register there and open up a can of her proverbial whoopass. It's always kinda sexy when she does that.

Seriously, this looks like a case where playground logic kicked in: the facts are correct, but they're used in such a way as to cloud the much deeper issue. In particular, that Charles guy is one of those guys most of us just want to smack in the head with a large blunt object; he knows so much that he understands nothing. "I must be the only person who has read Appendix C of XHTML 1.0". WHO GIVES A ****?

Appendix C is a series of guidelines, and they bold the phrase "This appendix is informative." at least 3 times. Informative = instructional, and as anyone with any experience has seen a thousand times or more on here, a set of instructions provided online is almost never the correct way to get to an answer. Yes, those instructions are provided by members of the W3C, but that doesn't mean they're any less likely to screw something up. So why is he making such a big deal out of it? I don't know where he's going with it either.

The best argument in favour of XHTML 1.0 Strict is the simplest: it's the strictest coding standard presently available. While it doesn't guarantee that your code will work across all browsers (no coding standard will ever do that), it provides the best opportunity.

The second best argument is future-proofing. Let's say 3, 4, maybe 5 years down the road Firefox v. 3.0 comes out. And for whatever reason, Firefox "in the interest of promoting web standards" or some other scenario decides to drop support for "past coding standards". Which one is going to drop first in that scenario? HTML 4.01? XHTML 1.0? Either HTML 4.01 will, or the slight possibility exists that they both will at once.

Now...this isn't to suggest this will occur. In all likelihood, it won't. But why take a chance?

Now, they could be trying to say that XHTML alone won't solve the problem of bad coding and that future versions of XHTML will create layout issues. They're right if they are, but that's not a problem with the standard; just the implementation.

They did, however, manage to draw one point out of you that I would suggest could be improved: don't just follow trends. Don't "stay on the front edge of the curve" for the sheer sake of being cutting edge. Do what works...for you. And do what works...for your customers (if you have any...I'm not sure if you do or you don't). And if you're going to listen to advice and get caught up in debates with people, figure out who the people who have been there, done that are (they're usually not that hard to determine).

Thanks for the reply.

Just so it's not taken out of context, the reasons behind following the latest ideals for me is an attempt to ensure:

a. My customers are getting the best bang for their buck I can deliver.

b. Even more importantly I deal with less and less cross browser issues which in turn lowers time spent fixing bugs and troubleshooting errors. There was a reason behind my comment.

I also try to keep an open mind, although these guys sound like they know what their talking about, I (for obvious reasons) always remain a bit skeptical of things I read.

I find it kind of ironic that this guy claims XHTML is used improperly and more prone to errors than HTML 4.0 yet his signature displays Tim Berners-Lee, W3C Director and inventor of the World Wide Web .

If XHTML is not reliable or erroneous by nature... wouldn't the directer of W3C put a stop to validating it on W3C?

Is it just me? LOL?

I think you just answered your own question there, friend.

Wow. I'm really amazed that that you got flack over using xhtml. Let Charles and his friends ignore it if they want. I've been using it for years with great success and will continue to use it.

Wow, Sydpixel. This is a great topic. Even though I currently code in XHTML, I have to point out...Charles has a point. XHTML isn't truely XHTML unless the MIME type is changed from text/html. In essence, I feel as though it has never truely been implemented to it's intended purpose.

My vague memory about why XHTML became so popular and so many books were written about it...XML was the new 'it' back then. There was a point that we all thought HTML was dead and that XHTML was the way forward. The books on XHTML started coming out and the W3C even announced there would be no more HTML versions. But the web has a way of twisting and turning in unexpected ways.

I'm not convinced that XHTML is necessarily related to future-proofing. I think clean, strict markup and thoughtful layout is the best approach to future-proofing. Honestly, the future is a guessing game at best.

I'm wondering if, at some point, there will be a decision made on either HTML or XHTML. There is a draft for XHTML 2.0 and HTML 5 is currently under development (see below).

My understanding of the general consensus...use strict no matter what you choose.

I may find myself going back to HTML, especially since I just noticed document.write() and a few other things I'm starting to do more are supposedly not supported in XHTML.

Why do I currently use XHTML strict? I like the syntax, it has seemed to be good practice and it's something I now know very well. But perhaps it's time to review...this conversation has prompted me to do some research.

Thanks for the post.

Resources:
----------------------
HTML5 - http://www.whatwg.org/specs/web-apps/current-work/
HTML vs. XHTML - http://www.sitepoint.com/forums/showthread.php?t=393445
http://www.456bereastreet.com/archiv...iant_websites/
Why XHTML? - http://www.elementary-group-standard...why-xhtml.html

The thing that still confuses me is, If XHTML isn't truely XHTML unless the MIME type is changed from text/html, what (outside a few advantages) was the purpose of writing in XHTML. It almost seems like it makes it more difficult to implement in to design as apposed to HTML?

Things You Can Do in XHTML But Not In HTML

• Use CDATA sections (<![CDATA[ … ]]>). That's useful if you have content with lots of literal characters that otherwise need to be escaped.
• Use PIs (processing instructions), e.g., to link to a style sheet:
  <?xml-stylesheet type="text/css" href="style.css" media="screen"?>
• Include elements from other XML namespaces (see below).
• Use the &apos; character entity.

Things You Can Do in HTML But Cannot Do in XHTML

• 'Hide' the contents of style or script elements with SGML comments (<!--…-->).
• Create parts of the page dynamically with JavaScript while the document is still loading (e.g., using document.write()).
• Use named character entities (e.g., &nbsp;) other than the four predefined ones: &lt;, &gt;, &amp; and &quot;.
• Use the .innerHTML property with JavaScript (technically this is non-standard even in HTML).

It looks like coding should be presented as a "pick your poison" approach as apposed to "use XHTML because it would reduce cross browser compatibility issues"?

Maybe it's like windows VISTA. I wouldn't dare use it because of it's newness. I would rather wait a few years and let them work the bugs and patches out, then buy.
(even if I was considering a new PC *next one will be Mac )

I have noticed along the way in my XHTML journeys, several instances were I validated pages and had a client informed me there was something that just wasn't right... at first I was like ... but... but... I validated the page ..??? But I'm painfully realizing there really is no one sure fire way to avoid issues like this here and there.

The first company that nails these issues and develops software that creates web pages with fool proof code, will certainly make a gazillion dollars!

Well... for now I'll just take it at face value and continue my reading, worse case scenario, It will make the transition from XHTML 1.0 to XHTML 2.0 a little easier... maybe?

Your first point sticks with me. Why are we coding XHTML? The advantage of XML is that you can define your own elements, but we don't do this in XHTML because it's not valid.

Some of the things mentioned in the Site Point post that you're not supposed to do with XHTML, I've in fact done in XHTML. It is a little confusing.

I'm actually leaning towards HTML 5. Check out this article on Digital Web Magazine...

http://www.digital-web.com/articles/...re_of_the_web/

Hey,

Did you notice the answer to your question in the information you copy+pasted? The example posted on the other thread included processing instructions...

Not sure those would ever be read properly...but they may be handled by the bug processing in browsers.

I am right with "Charles" on this point.

XHTML is not HTML and should not be used in place of HTML. It is designed to be used with XML and XSLT. The fact that designers have picked it up and are using it a kind of snobbery does NOT make it the right thing to do.

Unless you are using XML/XSLT as part of a page you should be validating to HTML 4.01 Strict.

The thing that still confuses me is, If XHTML isn't truely XHTML unless the MIME type is changed from text/html, what (outside a few advantages) was the purpose of writing in XHTML. It almost seems like it makes it more difficult to implement in to design as apposed to HTML?

What are the advantage of writing in XHTML 1.n?? There are many disadvantages especially when you have to code pages for complete crossbrowser compatibility

As above; the purpose of XHTML is for it to work with XML.

That's my point exactly. As a relatively new guy in the field, I picked up XHTML because it seems every book and web site I've come across uses and endorses the use of XHTML?

If it's intended to be used with xml, then why are so many people using it as of late? Why are people like Jefrey Zeldman selling books based around writing in XHTML? It's almost a big slap in the face so to speak. I have spent allot of time practicing this way of coding along with tons of others. Doesn't this whole issue kind of put a monkey wrench into up and coming web designers who have also spent hours and well... years learning the ups and downs of XHTML ?

Let's say you have a web site that's coded in XHTML. The facts are, because older browsers may in fact not recognize XHTML at all, I may be creating less cross browser compatibility?

Sheesh this is ridiculous! I want my money back Jefrey Zeldman!

According to some further reading, this is what makes XHTML html?

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

That goes back to the second-biggest advantage, Chris: future-proofing. Any web designer with any level of experience has dealt with a scenario whereby a client comes up with something completely out of left field. Anyone is capable of coming up with any idea for any reason at any time.

That something may well require XML and therefore may require XHTML as well. You don't know. Why get caught with your pants down?

Sydpix, check out this one link:

http://www.w3schools.com/xhtml/xhtml_intro.asp

W3Schools is the tutorial arm of the W3C. In particular, pay attention to two lines:

XHTML is a stricter and cleaner version of HTML

W3C defines XHTML as the latest version of HTML. XHTML will gradually replace HTML.

To be perfectly fair, the W3C hasn't exactly done a great job of making that happen. Like many not-for-profit organizations, they find themselves lost in their own rhetoric and ambiguity a lot of the time. But in this case, these are pretty clear and (literally) bold statements.

The truth is, I have so much time invested in learning XHTML (call me a noob)
That I highly doubt I will go back now. Whether there are more advantages or disadvantaged, well... I guess we'll all find out in the long run.

As I mentioned earlier, it looks like it's "pick your poison" scenario rather than anything definite.

I personally like the way XHTML is clear and precise when designing. I do however think I will consider XHTML strict as my new method of attack.

Thanks for all of the input on this, it really has been beneficial in my decision making.

I code entirely in XHTML 1.0 Strict. Does that make me a snob ? Maybe, but frankly I don't care what other people think of that. There are clearly 2 camps on the subject and I"m in this one. This has been an ongoing argument for quite some time.

As for HTML 5, it's looking to be a disappointment already with too much backsliding - like putting more presentation stuff back IN rather than taking it out and not including some other things that are desirable.

http://www.456bereastreet.com/archiv...ook_at_html_5/
http://www.456bereastreet.com/archiv...ntics_in_html/

The HTML 5 WG is going to go at it's usual snails pace, so I don't expect to be moving to HTML 5 any time soon as there is apparently a lot of heel dragging going on in the browser camps. If the timeline for CSS 3 is any example, HTML 5 won't go anywhere for a few years.

LNR, I have to say I'm a tad disappointed. I wanted you to go Al Sharpton or Jesse Jackson on us. Come on, girl, get yourself to some hardcore TESTIFYIN'!

Al Sharpton ?? I despise that man

I didn't go to the discussion Sydpix linked to, but I figured there was enough preaching going on over there

There's another point that might be getting lost, about the person writing the ML. You can write horrid xhtml if you put your mind to it ... or only know enough to be dangerous. What's the difference between writing <font color=red> and <span style="color: red;">? Not really much at all.

I think the X flavor is more future proof, and the strictness forces you to be more precise, which is a good thing when you're trying to communicate.

Agree 100% Forrest !