I ran across an article by Ian Hickson in which he lays out reasons why it's bad practice to use XHTML in most cases (though not necessarily all). The Webkit blog has a post on the same thing. What's your take on this?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
HTML 4 better than XHTML?
- Thread starter memco
- Start date
- Sort by reaction score
I've been reading these articles for years. I use XHTML myself most of the time. The "problems" that article mentions are lame in comparison to other articles I've read on the subject. It seems to mention them as problems because there are so many web designers out there who don't know what they're doing and so don't make their XHTML valid. Making pages XHTML valid isn't really anymore hard than making them HTML valid, you just have to know the nuances.
I have nothing against using HTML, and do use it myself at times, but I think people should aim for X/HTML Strict and have it be valid. One of the reasons I stick with XHTML for most of my work is that I work a bit in XML and XSLT so it makes sense for me. I also like how XHTML is more formalized and strict in its syntax. Other people use those same reasons for not liking it. It's a matter of opinion really, just try to remember to validate your pages to the best of your ability, and if you have problems getting a page to validate, post to the forum.
I have nothing against using HTML, and do use it myself at times, but I think people should aim for X/HTML Strict and have it be valid. One of the reasons I stick with XHTML for most of my work is that I work a bit in XML and XSLT so it makes sense for me. I also like how XHTML is more formalized and strict in its syntax. Other people use those same reasons for not liking it. It's a matter of opinion really, just try to remember to validate your pages to the best of your ability, and if you have problems getting a page to validate, post to the forum.
All of the complaints seem pretty poor. If he had spent any amount of time doing real programming with a language such as C he would be used to the fact that things are case sensitive and that you must write correct code all the time.
Lazy development is one of my pet hates. I actually ended up writing HTML 4 code that followed the XHTML rules by accident back when HTML 4 was the next big thing. I preferred the look of the code and wanted it to be properly written.
Lazy development is one of my pet hates. I actually ended up writing HTML 4 code that followed the XHTML rules by accident back when HTML 4 was the next big thing. I preferred the look of the code and wanted it to be properly written.
You bring up a good point. It seems like many of these articles complain that web designers are just too dumb and don't care about their code, and it's left up to the browser people to gracefully handle it. It's a bad situation and I feel for the browser people who have to deal with tag soup, but really they shouldn't have let themselves get into this situation. They have a chance with XHTML and the strict doctype to start throwing people out who don't write correct code.
Compilers don't try and deal with lexical soup, why should browsers deal with tag soup?
/rant
Well, we can thank MS/IE for leading us here. Even if the other browsers were to take a stricter stance (which they do, but would break 80+% of the current web sites out there), IE would likely still be what it is and people would just end up using IE for the internet. It's a sad state for sure.
Part of me wishes for better formed code like programming forces, but web creation has been reaching much more than to the programming minded who don't want to spend hours and months learning how to do proper HTML development when all they want is to show off pictures of their kids.
What would help is if WYSIWYG editors created better code so people wouldn't have to learn the nuances of web design (unless they wanted to). iWeb, even with all of its downfalls, is a step in that direction, but hopefully it (or someone else) will pick up the slack and take us farther. What iWeb does right is having tools with names that are more generic and don't assume you know web design. Software like Dreamweaver and Kompozer assume the user knows all of the HTML tag names and their uses. So the interface will have you create a photo gallery, open dialog and pick a folder of images, set some settings like thumbnail size, number of rows or columns, and presto. Rather than saying, I want a ul, and each li will have a img, and that img will a to a full size image, then I want my CSS like so ...
Angelwatt, you seem to be speaking of the need for more advanced wizards in popular COTS or open source web development products. So making a photo gallery is template based under the hood, and a wizard walks you through alot of options and customizations and so on.
DW and other products do things like this through plugins, but they are not wizards that walk you through, step by step, and allow you to even jump around when debugging something you've already created with the wizard.
However, the topic of this thread is concerned with XHTML vs. HTML, and no matter how the wizard runs - under the hood all the templates should be XMTML strict 1.0, use an external style sheet, and validate.
Of course we, developers, would become designers in the end. But during the transition, like iWeb introduced HTML snippets and plugins to extend its WYSIWYG functionality for people above novice level, we would still be needed because the wizard makes widgets of different flavors, so it's still up to us to conjur up new widgets, not just wizards. Face it, developers are ego-maniacs, control freaks and we want it done OUR WAY with no roadblocks using as many tools as it takes so our end product is unique, customized and of course proprietary so we get called back for fixes and new features. The system sucks in terms of progressiveness and efficiency, but damned if I don't love it and it's my living, as well.
I'm not giving up my day job yet, but honestly it would be nice for all of us if we could wizard our way to site perfection, have validation and repairs be automated and we can concentrate on content, at long last.
-jim
DW and other products do things like this through plugins, but they are not wizards that walk you through, step by step, and allow you to even jump around when debugging something you've already created with the wizard.
However, the topic of this thread is concerned with XHTML vs. HTML, and no matter how the wizard runs - under the hood all the templates should be XMTML strict 1.0, use an external style sheet, and validate.
Of course we, developers, would become designers in the end. But during the transition, like iWeb introduced HTML snippets and plugins to extend its WYSIWYG functionality for people above novice level, we would still be needed because the wizard makes widgets of different flavors, so it's still up to us to conjur up new widgets, not just wizards. Face it, developers are ego-maniacs, control freaks and we want it done OUR WAY with no roadblocks using as many tools as it takes so our end product is unique, customized and of course proprietary so we get called back for fixes and new features. The system sucks in terms of progressiveness and efficiency, but damned if I don't love it and it's my living, as well.
I'm not giving up my day job yet, but honestly it would be nice for all of us if we could wizard our way to site perfection, have validation and repairs be automated and we can concentrate on content, at long last.
-jim
I'm good about validating my pages, so they come out as proper XHTML. The only reason I found this interesting was the way the MIME type affects how the page rendersin all likelihood even if it's proper XHTML, it's still being processed as HTML. If that's true, it seems like it might make more sense.
My question is what browsers wouldn't/couldn't handle the issue? It seems like there's some panic that this mythical browser that doesn't expect XHTML pages to exist the way they do will horribly maim the entire internet. That seems pretty paranoid and unrealistic.
Realistically, all this means is that I do a find and replace of all "/>"s in my pages. That seems kinda silly so I'm not likely to change.
My question is what browsers wouldn't/couldn't handle the issue? It seems like there's some panic that this mythical browser that doesn't expect XHTML pages to exist the way they do will horribly maim the entire internet. That seems pretty paranoid and unrealistic.
Realistically, all this means is that I do a find and replace of all "/>"s in my pages. That seems kinda silly so I'm not likely to change.
I would hope that web development involves more than just producing valid XHTML / CSS.
You still have PHP / Javascript / Python (possibly) / SQL of one flavour or another / shell scripts for the server side etc.
@SrWebDeveloper: I hear what you're saying. The wizard style editor to me would be for the "common man," not for the "real" web designers and developers. Though they might help us out too. I was really just saying the non-designer -developers in the world should have a way to create some web pages that are valid and cross-browser compatible without needing to know a ton about web design. Of course all the code underneath would be strict and valid, though at this point I wouldn't care if it were HTML 4 Strict or XHTML Strict. So don't worry, I don't think you're day job is going anywhere if my ideas ever come to fruition.
In one word, IE. IE can't handle a true XHTML delivered page. It doesn't understand the mime type application/xhtml+xml, which means it would choke on those pages. And since IE is still the most used (not most popular) browser, we have to deliver as text/html. So the issue is very real, no a myth.
memco said:
In one word, IE. IE can't handle a true XHTML delivered page. It doesn't understand the mime type application/xhtml+xml, which means it would choke on those pages. And since IE is still the most used (not most popular) browser, we have to deliver as text/html. So the issue is very real, no a myth.
@angelwatt
Even the hypothetical super-wizards of the future should generate XHTML strict as it has been adopted by the W3C as a standard, not just suggested as a best practice. The W3C refers to this as a "specification" in the status section of their latest revision document. Interestingly enough, the MIME type you mentioned has not yet been standardized, the W3C last visited this issue in 2002 and their own "note" oriented document states:
Microsoft is under no obligation to support it, but as we all know, this is a bad decision on their part, in a long line a bad decisions as they attempted to dominate the marketplace and did so, successfully. They won't even support it in version 8, touted to be more standards compliant - but as I noted above, that MIME type is an accepted open standard, not an official specification as outlined by the W3C.
Sorry for getting overtly technical here, but this stuff is relevant and important from a developer's perspective. Gives great insight into the crazy world of standards that drive us nuts! Well, me, at least.
-jim
Even the hypothetical super-wizards of the future should generate XHTML strict as it has been adopted by the W3C as a standard, not just suggested as a best practice. The W3C refers to this as a "specification" in the status section of their latest revision document. Interestingly enough, the MIME type you mentioned has not yet been standardized, the W3C last visited this issue in 2002 and their own "note" oriented document states:
Source
Microsoft is under no obligation to support it, but as we all know, this is a bad decision on their part, in a long line a bad decisions as they attempted to dominate the marketplace and did so, successfully. They won't even support it in version 8, touted to be more standards compliant - but as I noted above, that MIME type is an accepted open standard, not an official specification as outlined by the W3C.
Sorry for getting overtly technical here, but this stuff is relevant and important from a developer's perspective. Gives great insight into the crazy world of standards that drive us nuts! Well, me, at least.
-jim
Well, I'll go against the grain here... I've pushed all of my projects to HTML 4.01 STRICT.
IE6/7 don't support XHTML, and I write web applications where our clients are either mostly or ALL running IE6/7.
I like the idea of XHTML if for no other reason than forcing well-formed markup. As the web approaches that standard, life will get much easier for all of us developers. But until IE8 is released and widespread, I don't see the point.
XHTML is still a very long term strategy.
Yes, I agree XHTML (strict) is a long way off.
I encourage everyone to view the chart at this link:
http://www.webdevout.net/browser-support-html?uas=IE6-IE7-FX3-OP9-KN3_5-SF2#xhtml1
My interpretation of it shows basic tag oriented XHTML 1.0 support for most of the popular modern browsers including IE6 and IE7 as discussed here. If you follow the bottom line of the chart, basically that's "XHTML 1.0 Transitional" which I find is the standard useful for many of my jobs. I use the proper DTD and send the page as "text/html" as the chart notes. I feel using this standard (which involves the slightly stricter syntax on tags and a few minor changes) helps developers release more conforming code with less problems - but still retains a solid grandfathering of the basic HTML standards. It's not superior to HTML 4.01 strict in any way, of course, but this standard helps train developers by practice as to the future tag syntax which will very likely be adopted in the future as a W3C specification. And you can troubleshoot code just as easily via W3C validators that recognize and accept this transitional standard.
-jim
I encourage everyone to view the chart at this link:
http://www.webdevout.net/browser-support-html?uas=IE6-IE7-FX3-OP9-KN3_5-SF2#xhtml1
My interpretation of it shows basic tag oriented XHTML 1.0 support for most of the popular modern browsers including IE6 and IE7 as discussed here. If you follow the bottom line of the chart, basically that's "XHTML 1.0 Transitional" which I find is the standard useful for many of my jobs. I use the proper DTD and send the page as "text/html" as the chart notes. I feel using this standard (which involves the slightly stricter syntax on tags and a few minor changes) helps developers release more conforming code with less problems - but still retains a solid grandfathering of the basic HTML standards. It's not superior to HTML 4.01 strict in any way, of course, but this standard helps train developers by practice as to the future tag syntax which will very likely be adopted in the future as a W3C specification. And you can troubleshoot code just as easily via W3C validators that recognize and accept this transitional standard.
-jim
