So, as I let the dust settle from the most controversial changes I made in the redesign (and tweak some things and watch my stats in response to the constructive feedback I’ve gotten), I’d like to address the other big change that people have been asking about: why I switched (switched back, actually) from XHTML 1.0 to HTML 4.01.
The short and sweet reason is simply this: XHTML offers no compelling advantage — to me — over HTML, but even if it did it would also offer increased complexity and uncertainty that make it unappealing to me.
Bear with me and I’ll explain why.
XHTML really only offers two major advantages — to a document author — which aren’t available in HTML: the ability to mix in content from other markup languages more or less seamlessly (via XML namespaces), and the ability to use standard XML tools to work with your documents.
Note that I’ve left out the big “advantage” (or disadvantage, depending on your point of view) that generates most of the noise in typical HTML-vs.-XHTML debates: XML’s draconian error-handling policy, which promotes nearly all errors to fatal errors. I don’t see any real advantage in applying that model to the Web, and I see a host of potential disadvantages, but the arguments have been so well-trod at this point that I don’t honestly think I’d convince anybody one way or another by bringing them all up again.
Meanwhile, I don’t have any need for namespaced content; I’m not displaying any complex mathematical notation here and don’t plan to, and I don’t use SVG for any images. So that’s one advantage of XHTML out the window. I also don’t have any need for XML tools; all the processing I need to do can be handled by HTML-parsing libraries like BeautifulSoup. That’s the other advantage gone.
So there’s no concrete advantage to be gained, for me, here on this site, by using XHTML.
Once again, I don’t want to argue for or against XML’s draconian error-handling model, but I do think the consequences of that draconian error handling, combined with some odd quirks of XML and its intersection with HTML in the form of XHTML, result in some significant disadvantages.
First off, let me point out that if you have a need for the features XHTML offers, the other big traditional HTML-vs.-XHTML debate — concerning which media type should be used for XHTML documents — becomes moot. If you want the behavior of XHTML, you have no choice but to handle it as XHTML, using either the recommended XTHML media type of application/xhtml+xml (vastly preferable) or a more general XML media type like application/xml. The reasoning for this is simple: sending a document as text/html, even if its DOCTYPE indicates that it’s XHTML, won’t get you any XML or XHTML behaviors. So if you’re going to do XHTML, you have to actually do XHTML.
But the moment you do that, your job as a document creator gets a lot more complicated. First off are the (relatively) well-known changes to the way CSS and the DOM work in XHTML documents which are actually being handled as such: the rules for applying styles are subtly different (you need to apply your document-wide styles to the html element instead of the body element), and any DOM methods intended to work with or manipulate the XHTML portions of the document must be changed to namespaced versions and fed the XHTML namespace as an argument (since a true XHTML document may well have content from multiple XML namespaces).
If you have to support Internet Explorer, this is a nightmare; IE has a long history of lackluster support for handling XHTML-as-XHTML, and so you typically have to fall back to text/html. Now your document has to work under either of two different style and object models, and that’s even less fun.
Now, on top of this add the consequences of XML. You don’t just have to ensure your XHTML is well-formed, you also have to be aware of some quirks which can cause a document to be well-formed and properly interpreted in one context, but non-well-formed or misinterpreted in another.
For example, many browsers use non-validating XML parsers, which means they are not required to recognize or correctly handle any named character entities other than the five predefined by XML itself: amp, quo, apos, lt and gt. These days the browsers mostly do some special-case processing to ensure they properly recognize and handle entities from XHTML’s externally-defined entity set, but there was a time when, for example, Firefox would toss an “unrecognized entity” error at you if you used any externally-defined named entities (such as nbsp or copy or other commonly-used entities) in an XHTML document (arguably a bug for any document which was not declared to be standalone).
Although popular web browsers can now handle this situation correctly (from the point of view of a Web author), there’s no guarantee that other tools which use non-validating parsers (which includes a vast swathe of popular XML libraries across most mainstream languages) will do the same. This raises a very real risk that an XHTML document, when fed to arbitrary XML tools, will not be interpreted or handled as intended.
Similarly, the Byzantine set of rules which govern the handling of character-encoding information when XHTML documents are sent over HTTP opens up ample opportunities for “quirky” behavior. It’s quite easy, for example, to produce an XHTML document which is well-formed when read from a local disk but not well-formed when served over HTTP using common default settings for web servers. Worse: some XML tools will correctly recognize the well-formedness (or lack thereof) of such a document, while others will not, introducing uncertainty as to how your documents will be handled.
And this is really just the tip of the iceberg; the intersection of HTML, XML, HTTP, CSS and the DOM is a pedant’s paradise, and successfully navigating those waters involves a lot more work than I’m willing to do just to publish a blog.
Since XHTML doesn’t offer any advantages over HTML for what I’m doing here, and that using XHTML brings up a whole host of potential issues, It’s a less than desirable solution. Meanwhile, HTML does everything I need, and it does not fall victim to any of XHTML’s potential problems: it has one style model and one document model, its semantics are not selectively applied according to the type of parser in use and serving HTML over HTTP involves fewer specifications and thus fewer opportunities for frustrating “quirks”.
So here I am, publishing valid HTML 4.01 Strict. As HTML5 — both the specifications and implementations — come to maturity over the next couple of years, I’ll probably migrate in that direction. For now, though, I have HTML 4.01 and I’m happy with it.
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
I agree. There is really no need for XHTML.
Even the W3C admits that documents containing pure XHTML do not really have any advantages over HTML:
http://www.w3.org/MarkUp/2004/xhtml-faq#advantages
I totally agree. I wrote about HTML and XHTML last year and found references by all major browser vendors either advocating HTML 4, or pointing out the fact that serving XHMTL with the wrong mime type is just the same as sending invalid HTML.
As it currently stands, you’re more likely to get consistent cross-browser rendering using 4.01 Strict than using any form of XHTML.
@tangerine: Funny you should mention consistent cross-browser rendering … I use XHTML 1.0 Strict, as it get’s me the most consistent rendering across browsers.
It’d be intersting to see what rendering differences there are between the two different strict modes, and what developers really expect to happen. Leave it long enough, and I am sure that PPK will do a complete investigation ;)
I think there’s a definite case for sticking with HTML if that’s what you prefer. I personally use XHTML and have never had problems with it.
You mention that XHTML must use a MIME type of application/xhtml+xml. That’s true for XHTML 1.1 (which few people use for that very reason). However, XHTML 1.0 can be served as text/html.
I think the well-formed nature of XHTML is also an advantage since your code can be validated against a schema. That in itself helps reduce CSS and DOM scripting problems. Yes, developers can get pedantic - I certainly do - but that attention to detail pays off when you’re creating a large Ajax-driven application that works in every browser, new and old.
I don’t really agree that XHTML is any more complex than HTML. If anything, there are fewer tags/attributes. Most of the rules still apply to HTML, but browsers are generally more forgiving of mistakes in your code.
I think the real problem (certainly in my case) is that the XHTML I tend to argue in favour of is not the XHTML that actually exists.
The differences between implementation in terms of actual coding work are negligible - an average XHTML document will look almost identical to the same content rendered in HTML, which leads us to this discussion (partisans aside): what does XHTML actually win us, bragging rights aside?
The honest answer is invariably “not a lot, and even though I’m writing XHTML, I may not be serving it, and even if I am then I’m serving it into a world that expects an HTML-like soup anyway”. XHTML is a noble effort, but the reality is that most of the wins we think we’re getting are equally available through plain old HTML too.
Most of the developers I speak to (myself included much of the time) think of XHTML as a sort of “Finishing school for HTML” - it’s the regular, ordered HTML that puts aside all the tag-soupness of unclosed paragraphs etc. Of course, there’s nothing stopping us closing our HTML tags, but somehow using XHTML “feels” more standard.
What we forget is that this “finishing school” will actually SHOOT ANYONE THAT DOESN’T FOLLOW THE RULES. The implementation of XHTML is so (as you put it) draconian that any wins we get are immediately lost in the quagmire of actually doing it right.
So what do we do? We just don’t do it right. We write XHTML, but we serve it up incorrectly, or we don’t worry about anything as long as we get the little green tick in Firebug.
At which point I ask - What the hell was the point? HTML is just as good at that level, and with HTML5 we have a future that is about standards-driven INNOVATION, not just more rigid structures.
XHTML has an X in it. It must be better. Right?
Perhaps the basic vocabulary of XHTML and HTML isn’t any more complex but an XHTML web page is an XML document… as such there are differences in the DOM, XML Namespaces to worry about and there are lot of other uncommon gotchas about XML. For instance most Unicode control characters aren’t allowed in XML and element and attribute names in your CSS rules are case sensitive in XHTML.
If you use a proper XML editor that serializes your work correctly, hopefully the nitty-gritty XML well-formedness is taken care of for you. Common CMS tools like Wordpress/MovableType/Blogger do not invoke an XML serilazier and stack to properly normalize and store your input into the data-store… nor does it render your templates+content as XML either. These tools do all of their XHTML construction using string concatenation and then slap an XHTML doctype on at the beginning… in which case you might as well just use HTML 4.01 strict.
I always author in XHTML because I prefer the syntax. The fact that HTML allows certain tags to go unclosed clashes with my sensibilities. However, I always serve it as
text/htmlbecause, like you, I don’t get much utility out of the advantages related to serving it as XML. I’ve never seen a compelling argument against XHTML served astext/htmlexcept that you don’t get those XML advantages. Since that doesn’t concern me it all comes down to syntax, and XHTML is my preference. Different strokes for different folks. :)Something left out of the picture imho is the compliance with disability standards which usualy imply stricter checking / xhtml compliance.
I have read your article and I have found your opinion very valid and well supported. However, I have also found good advantages of using XHTML 1.0 strict over HTML 4.1 strict, especially in search engine optimization techniques. As you said, it is a matter of taste or liking, basically.
Another disadvantage of XHTML-as-XHTML is you lose incremental rendering in Firefox (this is fixed in 3.0 so less of an issue going forward).
@Scott Nelle: Browsers have two parsers, a HTML parser and an XML parser, XHTML as text/html causes your XML to be parsed by the browsers HTML parser, XHTML is not HTML so you’re effectively sending the browser malformed markup. For me personally that makes it a non-option, even if it “works” OK in practice.
To the people above stating they use XHTML served as text/html, do you realise this is not actually XHTML? It is HTML pretending to be XHTML.
I have used true XHTML, XHTML as text/html and HTMl 4.01. And out of them all I would say HTML 4.01 Strict is by far the best option.
To quote Anne Van Kesteren
Viva la evolution.
I can understand you opinion but I do not totally agree with you. I think with the rise of the semantic web (and yes this rise has already begun) technologies like XSLT, RDFa and SVG will become much more important. So if you want to use the true power of that languages you have to take XML as your ground layer and therefore you absolutly need true XHTML.
At the moment maybe HTML 4.01 is still good enough but it’s only a matter of time.
via: http://webkit.org/blog/68/understanding-html-xml-and-xhtml/
So you are saying, stick to old standards until the big market share browser (IE) supports the new standards.
That’s a typical pragmatic argument.
You don’t really read the article did you.
Without IE in the equation XHTML isn’t the better option for most sites, with IE in the equation it’s just pointless.
Currently, I’d agree that there’s nothing you cannot do in XHTML that cannot be achieved using HTML. Even for the semantic web, strict HTML can be read just as easily as XHTML.
However, XML (which XHTML is) does have uses that go beyond standard HTML: transformations, XPath, web services, etc. If you’re doing any page manipulation on a server, then XHTML is a good choice. XHTML has benefits on the client too, especially if you’re doing DOM scripting or Ajax calls.
Whatever your opinion and coding preference, an understanding of XML/XHTML will give you an insight into other techniques and possibilities.
Finally, I can understand why this article refers to pro-XHTML coders as pendants. However, to then state that you’re not really using XHTML unless you serve “application/xhtml+xml” is pedantic too!
Please use XHTML. It’s so much easier to scrape your data with.
Ian Bicking made a similar argument at PyCon 2008.
I don’t know whether you saw it or not: the room was pretty full, and I can’t recall if you were in there. A member of the audience insisted passionately that (valid) HTML trails (valid) XHTML on accessibility issues. I’m mentioning this because I think accessibility is important, although I don’t know enough about the relative accessibility of the two technologies (yet) to be able to comment further.
I’m partial to XHTML over HTML, but I agree that the draconian error-handling can be irritating in cases where validity doesn’t significantly affect parsability. Rather than having two technology families for the same job (marking up web pages), I would prefer if there were only one, but one with a greater flexibility in succinctly and explicitly signalling to browsers when to be light- or heavy-handed with errors. Ah, dreams…
Wow, tough crowd! I thought the XHTML fad had been and gone. I’d be more interested in hearing a similar analysis on why you haven’t jumped straight to HTML5.
Anyone who claims XHTML has greater accessibility benefits is either misinformed or lying. XHTML 1.0 and HTML 4.01 are, by definition, tag-for-tag and attribute-for-attribute identical to each other. The only difference is SGML rules in HTML 4.01 versus XML rules in XHTML 1.0, and so far as I know there are no accessibility benefits inherent in draconian parsing.
I agree completely. Dont let others that say you are wrong confuse you.
I dont write XHTML by hand, I autogenerate it. But IF i would write it by hand I would go crazy.
It doesn’t seem to make a difference (so long as you are serving it all as text/html.) I tend to call it XHTML because it just gets my guys, and myself, into a good habit of closing tags, lowercase consistency and such. Social engineering or whatever you want to call it. By now though I’d say you could go back to calling it HTML 4.01 and the good habits would persist. 4/5 years ago that wasn’t the case.
XHTML made me write better HTML.
The difference between XHTML and HTML is that for XHTML to be implemented properly it takes the skill of a software developer. Many of the arguments above are thin at best. Using XSL XHTML can be queried natively. Which is bad news for SQL developers and those that hammer away in languages like Python Perl and others.
“The future is here. It’s just not widely distributed yet.” - William Gibson
Here’s one for you. You don’t have a single image on this page - so, since you don’t need the
<img>tag, should you make your page unable to support<img>tags? What if a commenter wants to post an image in their comment?Or, let’s say you’re not working with dynamic contents, and you remove all comments (as I have long since). What if you want to post an image in one of your posts, later? A screenshot of a new design with two tweaks, to illustrate your point? You’re screwed, because your design, your layout, your widgets, your entire site is setup in a way that doesn’t allow images. No, but wait - you’ve got it! You can use
<pre>tags and ascii art to simulate it, right? Awesome, no longer a problem.That was sarcasm, incase you couldn’t tell.
Replace every ‘image’ above with ‘mathematical equation’ or ‘vector diagram’, or any of a host of other things that you can do in a true XML document. What if one of use commenters wants to show a diagram of what we’re talking about? Do we resort to creating an external document and link to it from our post? How old school. What about later on down the road, when you want to describe the mathematical relation of visible negative space to reading speed and comprehension? Yeah, just create a PNG and upload it - because that’s totally championing the openness that I’m going to assume you champion as a fellow designer. What if somebody wants to take that equation and modify it to show their take? Take the PNG and photoshop it a tad? How about they view source, copy the MathML, and add a
/2in there?I’m not refuting your entire argument, I have no desire to force which one I choose on others - nor, even, to justify that choice to said others - but I do believe that your first argument, “So that’s one advantage of XHTML out the window.”, is total and complete bollocks.
In any case, however, wonderful article! Linked from stoneship. And thanks for choosing Markdown for your comments - if I have to type one more awkward Textile link… shudders.
I really don’t understand the comments stating that XHTML is hard? I hand-code XHTML1.0, adhere to XHTML1.1 standards, and have never had a problem. Yes, you need to learn structure rules and close tags, but you should be doing that in HTML too. HTML is more forgiving of bad code - but that does not necessarily make it a good choice. In fact, it’s the very reason web coding was so awful 10 years ago.
The hardest thing about web development is cross-browser compatibility. Many HTML pages also use a transitional (or no) DOCTYPE, which makes CSS coding an absolute nightmare. At the very least, XHTML forces you to think about code validity and standards.
Why haven’t I gone for HTML5? Well, maybe I will … eventually. However, the specification is not complete, no browser fully implements it, and validators are not widely available. I don’t use XHTML 2.0 for the same reason.
If you prefer HTML, then use it. This page could have been coded in plain text and it wouldn’t have made much of a difference. But I’d urge you not to reject XHTML on the basis of this article.
@Craig
True it’s not hard, I used to code with true XHTML and loved the error handling at the time. But when you start building large sites with input from multiple sources (people, the public, other websites, other machines etc) you simply can’t risk having a page or a whole site fail because someone forgot to close a tag or encode a character properly. HTML’s error handling solves this problem and is designed for the real world, just because it has been abused in the past does not mean it is bad.
That doesn’t make sense, most XHTML pages use transitional and XHTML (the text/html form) does not force anyone to think about valid code. Validity is simply a choice you make whether you’re using faux XHTML or HTML.
It would have made huge difference, lack of any semantic mark-up for one, and if you can’t see this then I’d be worried.
So far I’ve not seen one solid reason not to drop XHTML, where as this article gives some pretty good reasons.
If you’re capable of coding well formed semantic markup in XHTML then I’d suggest moving to HTML 4.01, it’s purer than faux XHTML and better suited to real world use.
@Ryan What error handling in HTML? That is a myth. A malformed HTML doc will render broken HTML with the mistakes intact. An the rendered page broken. XHTML renders a fatal error before I publish allowing me to correct broken tags or what ever before it goes public.
The real world is people being able to render your page properly with broken HTML. Not relying on the kindness of strangers or applications.
XHTML is a useful, robust platform for transmitting content over the web. Begin to think like a software developer instead of a “web designer”.
@Ryan correction: The real world is people being able to render your page properly. Not relying on the kindness of strangers or applications.
» Ryan- Why so sure that everybody uses ‘faux’ XHTML?
Not everybody has to submit to the tyranny that is IE’s market share, thank god.
I have to agree with Ryan, otherwise… if you’re too scared to stand against the IE monster, if you’re using mis-declared XHTML… you’re better off using plain old HTML. Go, run home to your mommy - that’s right. Wouldn’t she be proud?
@Ryan
Bad markup is bad markup: using HTML won’t save you from that. Closing a div could still break your page design. But that’s really an argument for validating and formatting input - XHTML can be a positive benefit in that respect.
Come on, really? Anyone taking the time to learn XHTML is likely to have at least a basic understanding of W3C standards, semantics, and the need for validation.
But surely plain text would save you from the worry of ANY markup issues? You could take data from anywhere, publish it, and it could be read by anything! Now obviously, I’m being extreme here - but your arguments for HTML over XHTML could easily be applied to plain text over HTML.
No one’s disagreeing with your point that - for your site - XHTML offers you no benefits. But to give the impression that XHTML is quirky and unusable in the real world is misleading.
@elliotcable: hmm, couldn’t HTML documents be extended via the CONCUR feature of SGML? I haven’t tried it myself. Still, CONCUR works a lot like XML namespacing.
That said, extending XML docs would still be much less work :)
If ppl only read the w3c spec they could understand how robust (X)HTML is. Most only use a fraction of its resources. We have created many a false social meme about markup.
Hmm no not really, if you only used plain text all the machine would see is a meaningless group of characters. This is why we have SGML, HTML, XML etc.
True XHTML is unrealistic in the real world for the reasons I outlined previously. In theory it’s fantastic but if you try and build a large site that allows input from multiple sources such as a user community, non-technical staff or even external sites it can easily fall apart. If there is so much as one error or malformed piece of markup then the entire site (or just a page depending on a design) can be brought down due to the error handling. You need absolute control which just isn’t practical or necessary. If someone forgets to close a strong tag is it really helpful to block the entire page until the error is resolved? I don’t think so. Of course XHTML served as text/html doesn’t have this problem, but it’s not really XHTML.
Don’t get me wrong I don’t hate true XHTML (as I’m calling it), it’s useful for teaching people how to code mark-up correctly and for small absolutely controllable projects.
Bad markup is also not the end of the world, and as stated above a non-closed strong or p tag should not bring down the entire site/page, but use true XHTML and it will do. It simply isn’t realistic or practical to have such harsh draconian error handling. I’ve already stated why.
Most XHTML is still transition text/html and not XHTML though. And anyone taking the time to learn HTML properly should have at least a basic understanding of W3C standards, semantics, and the need for validation.
Not everyone, but certainly most.
The real world is not having absolute control over everything 100% of the time, which you need with true XHTML and its error handling.
Which is all well and good if you don’t factor in any external input or influences. As I’ve said already throw in user communities, general users, machines or software (such as external sites) as just three examples and you open yourself up to a whole load of possible issues. Sure it’s helpful know of errors before going public, but then you should be validating and checking your code as you build it and QA testing at the end (HTML validator extension for Firefox is perfect for this).
When the choice is between showing customers a visually and functionally perfect site with a few mark-up errors that I can find and fix later. Or an XML error page causing customers to go elsewhere, I know which option I’m going to choose. I’m experienced enough to know you can not and will not catch every error before the client sees the page.
Also HTML does not equal invalid, malformed, unsemantic mark-up or hinder SEO/Accessibility. So anyone talking about XHTML being more valid, semantic mark-up or better for SEO/Accessibility purposes needs to go do some research.
But you know what, this is entirely pointless. I’m confident in what I’m doing and unless we end up working together it doesn’t make the slightest difference what either of us think. Until that day comes, feel free to continue creating sites in a way that suits you best.
I just stumbled this. Even though I’m on the opposite side of the fence, I must say that this was a great article. At the very least, XHTML supporters could use this as yet another article to explain why XHTML should be served as XHTML or at least as XML. :P
I’m liking XHTML 2.0. (X)HTML5, on the other hand, seems to have far too much redundancy, and I don’t like the fact that elements like B, SMALL and I were redefined using a semantic definition while stating that they should still be rendered exactly the same way. I thought people understood that CSS and markup should be separate…
Totally agree with this article. Thanks for this writeup…
i never really hated XHTML, it was just so expensive to call it.
@Ryan I work alot (10years) with XSL,XML, and XHTML and hear the same uninformed arguments everyday. So to clean up a few bad memes: 1)Draconian Error Handling: I used to write alot of C based languages and in any other language including PHP a fatal error is a fatel error. Why then in HTML is this frowned upon? Source errors are generlly syntax errors and are easily corrected.
2)User Generated Content: To store data simply store it in a CData tag within XHTML. Call it using XSL and set to disable-output-escaping=”yes” and output it to HTML. Another meme bites the dust. XSL is a native programming language for anything XML.
3)I Serve XHTML as…: If you are thinking as a programmer and not a designer then serving it as HTML or XHTML is out. XML is the only to go as of this date. This also eliminates the need for a doctype as the XMLNS is now doing that job. BTW @ Ryan XHTML is not any more semantic but by serving XML and the XHTML ns it now has the ability to be read by humans and also parsed by XSL. !NO DATA BASE RULES! XSL does that work for you.
4)M$ does not support XHTML namespaces: FALSE if need be I can show proof of concept. Any M$ OS supports namespaces. XHTML ns is no different. The thing is that IE will not itnialize XHTML + XML but yeah the bastards support it.
I can go on and on the point is this: Design types have replaced the science of programming markup and replaced it with memes misinformation and lies about markup. It is time programmers take up the slack and call BS when we see it.
And lastly XHTML is an application. Where HTML is markup. XML has constraints and parameters as does any language. Use XML as intended it will serve you well. Anyone can find things wrong with any language but learning to work within the language is the mark of a developer. Developers design applications web designers literally hang curtains .
I was mostly behind you until you said this. Why would you expect designers to respect our work when you show such a deep misunderstanding of their work?
Yup, once you consider the abysmal support for XHTML in IE it is just not worth it.
@Brandan Lennox
Actually Don Ulrich’s statement (while possibly slanted) isn’t completely a misunderstanding. Actually a web “designer” would better be defined as someone who would be focusing mainly on the look and feel of a page. A web “developer” on the other hand is someone who would better understand the underlying structure of the web likely knows at least one if not a couple of coding languages (JavaScript, PHP, Ruby, etc.) and may or may not have some talent for design in addition to this. Saying “designers” just “hang curtains” isn’t really a stretch if you look at it this way … taking the example further you don’t ever hear of anyone hiring an “interior developer” to come up with ways to liven up their home, some of which could require some structural development (demolition and/or construction).
This is highly anecdotal, but many “web designers” I run across (though maybe they were just calling themselves that) tend to be very visual, artistic-type people and think more in style than the abstract yet defined structure that most programmers tend to think in. I haven’t run across many individuals that are both artistic in nature yet have a firm grasp of certain concepts found throughout programming (i.e. the need for the syntax and semantics of a language (markup, script, or otherwise) to be well defined so that it can be processed consistently, using data structures appropriate to a task, etc.)
Some designers will go as far to completely avoid hand coding (even if it would be simpler and quicker) and instead use the WYSIWYG editor almost exclusively in whatever web-development software (i.e. Dreamweaver) they happen to use. While many things are more easily changed in a WYSIWYG, you also introduce the possibility things getting “lost in translation”. While the software probably won’t leave open tags (at least if you’re using something other than an early version of FrontPage :-P), there’s still the chance for something to “break” as the software goes to translate your visual changes into the related markup and/or code changes.
Again, this is mostly anecdotal. It could be the term “web designer” or even “web developer” gets used by people who technically don’t really qualify as such by most standards. Nonetheless, there are those “designers” (and perhaps some “developers”) who would not really understand/appreciate the possible benefits of an XHTML standard and would only see that they now either have to rewrite any residual tag soup by hand (given their web development suite is several years old and doesn’t do validation) or they have to convince their boss to buy the latest and greatest web development suite that automatically does validation/correction … even though, as far as the big boss can tell, “everything works fine (in IE)”.