Can't agree more in general, I HATE uppercase tags, I especially hate randomly assigned uppercase/lower case tags. Font tags are stupid. I know of no case where using a font tag is a good solution.

"that it forces other people who work with me to code better". This reason is almost good enough to add to the primary list of actual real reasons to use XHTML. But it applies just as well to HTML 4.01 strict, which is actually cleaner than XHTML, after years of making xhtml sites, the first site I did in HTML 4.01` felt like a breath of fresh air, code looked nice, seemed less rigid, hard to say what caused the feeling, but I liked it.

The semantic web - fact versus fiction
You might want to read up more on semantic coding, that is not implemented, it's actually a complete misunderstanding of what the semantic in 'the semantic web' is, it doesn't exist, it's a proposal, it's being tested, nobody likes it, nobody is using it.

Reading:
W3C semantic web site



HTML is a markup language, it's not a semantic thing really. That's getting into the technical definitions though. There is decent document structure, reasonably correct use of tags, etc. But that's just a markup thing, browsers and search engines don't treat your page semantically, because HTML isn't really a semantic system, except in a very loose way, like saying something is a heading, but that's not actually a semantic statement, it's a markup statement.

Is the table tag evil, or is it just misunderstood?
The W3C itself says that tables are fine for markup, as long as the data flow is linear and logical. That particular quote is one that tend to annoy CSS/P fanatics, since it's such a clear statement, in black and white. The W3C said that for the simple reason that in fact tables are fine for markup, just not massively bloated, nested table, layouts.


The visual formatting here is referring to things like using tables to hold sliced headers, etc.

Linear, logical page content data flow is the only way data can flow in a table, as long as it's a basic, clean table, header, left bar, content column, possible right bar, possible footer. This will be linear. However, what is not linear, oddly enough, is right floats. Or source ordered HTML. In other words, CSS/P can violate some pretty basic rules set by the W3C, whereas a basic clean table really can't.

Re: real versus pseudo XHTML
You're still thinking that you are creating an XHTML page by saying the doctype is xhtml. That's only partly correct. Real XHTML is what I'm talking about when I talk about document.write. When and if you ever create a real XHTML page you will instantly see what I'm talking about here. And you will get very very depressed, I promise you. The way a browser handles any document it receives is determined primariy by the header the server sends it. Your supposedly XHTML pages are not in fact XHTML, they are being served as text/html. Not application/xhtml+xml.

Since IE does not support XHTML in the real sense, XHTML is actually pretty much dead in the water as a real mimetype.
Back to top

i got ya on the semantic thing.

all i'm saying with the xhtml is that i think it looks cleaner. if having not having it served as application/xhtml+xml really bothers you, you can simply just change the doctype to html and it will still be valid code.

i agree as far as application/xhtml+xml being dead in the water until msie supports it. unless you have it setup to serve the file as application/xhtml+xml for mozilla/netscape/firefox and text/html to msie
Back to top

It's not that it bothers or doesn't bother me, it's that xhtml is not actually supposed to be html, or served as html, it's the specifications, and for 1.1 it's not even supposed to be an option, the specs specifically state that 1.1 must be served as application/xhtml+xml

So anytime you see a webpage that claims to be the lastest and best, using XHTML 1.1, and you validate it, and it is text/html, that is not actually a valid page, even though the w3c and browsers tend to ignore that, as they do all bad html code.

However, my point is only a technical one, your basic point that putting out clean code that is of a certain type, and error free, is a desirable thing to do is something I completely agree with. I know the source of your pain, it's very annoying to have to deal with junky code, it's downright painful at times, so any standard you can apply to your projects, as long as it's consistently applied, whether HTML 4.01 loose or strict, XHTML 1.0 loose or strict, is good. You need to work to standards with code or stuff will decay into chaos, that is I think your basic point, and it's one I absolutely agree with.
Back to top

Nice informative blog here, guys. I think everyone on here, though (including Microsoft's developers at present), have completely missed the argument FOR using XHTML in web applications today, despite the browser issues.

XHTML is XML. And you want your web site designed that way so its data/content can be accessed later and repurposed and reused by all types of applications. Thats it! Its not JUST about look-and-feel. That means your web pages, no matter how "pretty" or "ugly" they become because of browser differences, now have the ability to perform as data pages. That means your web content can be easily managed and repurosed for say, mobile phone browsers, print, screen readers, text readers, RSS, etc. It also opens up web content repurposing using XSLT.

Also, where we are heading with XHTML and CSS is a world where you build your own tags ("<wildranger_rocks></wildranger_rocks>") and then attach id's for data access purposes and connecting styles and events using those id's and classes. As far as HOW to create good clean XHTML-based web sites, you CAN use XHTML without the xml prologue, but with the standards-based doctype to avoid switching to quirks in IE, with the metatag for the xhtml/xml MIME, but without the actual server page header (send as plain text/html) and still get the benefits of designing with XHTML and CSS, and attack your browser look and feel using CSS style hacks today.

When IE 7 and Safari developers clean up their acts, get some real markup training under their belts, and rebuild their browsers to meet standards like MOZILLA has done, the next year or so, and get with "Web Standards", you sites will be supporting the standard, and make your web sites really easy to manage and repurpose as XML for all types of devices and agents.

In the mean time, by all means abandon the HTML, table-based mess and move forward with XHTML people!

<mod edit: no promo url's please>
Back to top

wildranger, some decent points, we'll see how IE 7, Safari, and the rest actually do with this in the future.

In most cases, especially where it's a question of delivering different markup etc to different user agents, the data would be stored as XML or be dynamically generated, into whatever HTML type you want.

I tend to make my sites either XHTML compliant or HTML 4 strict compliant, doesn't really matter to me, although technically delivering any XHTML without application/xml+xhtml headers is just wrong, it's tag soup to the browser.

My experience has shown that unless I'm in full control of the site HTML, errors will creep in to the code at some point somewhere, and XHTML with errors will simply not function in the context you mention, which means that unless all the generated content and HTML is run through an automated system, the pages would literally not display or run through any type of XHTML conversion, 100% perfection is required for this, I do it on some sites, but it's very hard to maintain.

One of the beautiful things about HTML is that it is incredibly sloppy, that's for example why an XHTML 1 strict page with errors delivered as application/text+html will display on almost all browsers out there.

However, having error free code is another matter, that's the best thing you can do for any web page as a developer, allows meaningful debugging and much easier maintainance long term.
Back to top