Forum Moderators: open
There is a residue taste of condescending snobbery left from reading both (some of) the commentary on this thread and the Hickson article which implies that all but an elite band of standards-cogniscenti (sp?) are basically light-weight "fools" who really shouldn't be playing with XHTML at all.
Indeed, I'm left wondering who the members of this standards-cogniscenti actually are? Probably the same people that forged them no doubt!
I'm angry 'cos XHTML was meant to be simpler, cleaner, more accessible and more efficient. Instead, at every step of the way, we've had browser-makers and code-writers alike struggle to understand and implement the darned thing!
Encyclo says it's 'flawed, or even broken': After reading this, I couldn't agree more... but what annoys me more is why the hell this is only now hitting the radar?!
I know I've invested a lot of time studying this area and would even assert that I know more than the average person. There is a limit however, to how deep one goes before pledging one's life over completely to the altar of every frickin standard going ('cos they tend to interconnect at some juncture or another don't they!).
How long has the XHTML standard been with us? 7yrs or so? If it were a commercial venture it'd long been abandoned and bankrupt... and whose fault is it? The W3C themselves!
They can't explain things clearly; Can't say things loud enough (How old is Hickson's article?... 2002 FFS!) and don't get out into the web community enough.
Web-tech these days is split into many disciplines: A web designer shouldn't have to go into the dark depths of the RFC specs and server config to do his job!
Those that are fortunate (or not) to devote their lives to the Cause would be better serving us all if they remember that and allow the rest of us who have to straddle many disciplines to use an infrastructure that works and is understandable.
Apart from that, good find DrDoc and interesting posts Encyclo too.
Encyclo says it's 'flawed, or even broken': After reading this, I couldn't agree more... but what annoys me more is why the hell this is only now hitting the radar?!
This is a gripe also. Found this on a website: "in the near future all browsers should be fully compatible with the current W3C XHTML standards"
--- That was written in 1999, and we ain't there yet.
And apparently some of the glitches in the actual W3C standards have been documented for some time - they just never hit the front page until recently. That might be one reason why browsers are behind.
IMO, there are two real questions here - why the hype in the first place about XHTML, and why have browsers been so slow to get compatible. The first one I can kind of understand - what I don't understand is why the hype continues when it is becoming obvious that some (most?) browsers will never really be compatible.
In fact, I have read a couple of rumors that FireFox may implement some of what is being called HTML 5.0, even though it has not even hit W3C yet for finals. So it is quite possible that XHTML in its present form will not go much further - it might be replace by a new standard.
And apparently even Microsoft does not know what it is doing. Someone mentioned in this thread that IE7 would not be XHTML compatible, yet MS is saying that the new replacement for FrontPage WILL be..(well sort, of they said it would produce XHTML compliant code).
So, for us at least for now, we are back to the old 4.01/ISO. When (if) W3C and the browser folks actually get their act together we will look again.
There is a residue taste of condescending snobbery left from reading both (some of) the commentary on this thread and the Hickson article which implies that all but an elite band of standards-cogniscenti (sp?) are basically light-weight "fools" who really shouldn't be playing with XHTML at all.
The adoption of XHTML to date is imho characterised by an element of foolishness. It's snobby and condescending to say so, but there's no other way to say it: many people invested time and effort in XHTML for no apparent reason. They did so because they were told to by self-appointed "experts" (or perhaps more accurately: famous, light-weight fools ;)).
The W3c and standards-cogniscenti said everyone should use XHTML because it's the future, then tried to come up with some reasons why:
The problem with these benefits is they're completely bogus. Utter bobbins. Then the first xhtml2 draft appeared and even Zeldman lost his faith [zeldman.com] in the W3C's direction.
See also WASP asks the W3C: Which should we use, HTML or XHTML, and why?, 2003 [webstandards.org]
It should be noted that WaSP were still recommending XHTML as the one and only "web standard" structural markup language up until their re-design last month, when (unannounced) HTML4.01 quietly became a "web standard" again:
Before March 2006 redesign:
"When we speak about “standards” for the Web, we mean: XHTML 1.0, XHTML1.1, XML1.0" (edited for brevity)
After:
"When we speak about “standards” for the Web, we mean: HTML 4.01, XHTML 1.0, XHTML1.1, XML1.0" (edited for brevity)
Is it any wonder that normal web authors are confused when even the standards-cogniscenti have taken this long to work it out?
Knighty:
[...] the leap to XHTML will happen at some time[...]
The W3C say it will, but that's not exactly the most convincing argument I've ever heard. How will we handle the backwards compatibility problem introduced by XHTML2?
A quote from the developerworks article Allan linked to on his blog helps throw light on this situation:
"Embedded devices such as phones and digital TVs have no need to support the Web's legacy of messy HTML, and are free to take unburdened advantage of XHTML 2.0 as a pure XML vocabulary"
The need to browse any of the millions of existing websites is simply dismissed, in favour of the (unspecified) advantages conferred by XML's purity. It's breathtaking.
[edited by: encyclo at 12:13 pm (utc) on April 4, 2006]
No one seems to answer the one key question - why is producing XHTML a bad thing?I'm producing sites that look great in all browsers, are cleanly coded and easy to maintain. As long as I continue to serve XHTML as text what is the big deal?
It all comes back to standards. Sending GIF images as
image/jpeg is bad. Sending PDF as text/plain is bad. With XHTML ... the fact that it works is slightly besides the point. XHTML was explicitly designed to be XML based. When you read the XHTML specification you hear things over and over again about how the pages "must be wellformed" and how this error checking functionality would ensure that it renders the same in all browsers. While that is true, it is only true as long as you really send the page as XML. Sending it as HTML nullifies all of that. While the XHTML standard clearly states that all the benefits only exist when the document is sent as XML, few really realize that. Even fewer will realize the implications. What happens when IE eventually supports
application/xhtml+xml? I can assure you that a large percentage of current XHTML implementations will break. Who will the developers blame? The standard! This is what Ian says in his article as well (which, for everyone's knowledge, was updated as late as 2004). He's not saying that XHTML is bad. XHTML is great! Poorly implemented XHTML, however, is misleading and takes your website in the wrong direction. Instead of gaining anything, you have started a dangerous cycle which eventually can lead to unexpected results.
I'm not saying XHTML is bad either. Please don't take it that way. I, too, think that XHTML is great. I believe it is the future. I use it.
But I also realize that it takes a conscious effort to implement it correctly, as the current "compatibility mode" (which is required for IE support) is quite the tricky thing to get right. It takes more than just being able to write the markup. It requires knowing how it changes your stylesheets and scripts. It requires careful setup of server headers. But if you can handle that, hey, go for it! More power to you. If you can't, or if you have no clue why those changes would be required ... HTML 4.01 is truly for you, as it is what you can handle (and it is what the browsers would see anyway), but without any of the drawbacks or dangers stemming from incorrect XHTML implementations.
but what annoys me more is why the hell this is only now hitting the radar?!
Actually, I remember reading about this years ago. I had forgotten where I read this... I think it may have been in the W3 mailing lists. But if you notice, Ian's document states:
This was originally written in September 2002
Are we forgeting the difference between strict and transitional? Transitional CAN be served as text according to the W3C - you only need to change if you are using strict.
Both XHTML 1.0 Strict and Transitional may be served as
text/html - it is only XHTML 1.1 which cannot according to the specifications.
What happens when IE eventually supports application/xhtml+xml? I can assure you that a large percentage of current XHTML implementations will break. Who will the developers blame? The standard!
So this could be the real "Damocles sword"
Before starting to run like rats in a cage
do we have or do we foresee a schedule for the above to happen?
What happens when IE eventually supports application/xhtml+xml? I can assure you that a large percentage of current XHTML implementations will break.
This brings a question
any SEO "cost" related for changing a XHTML trans DTD? to a strict one or even from XHTML to strict HTML 4.01?
I do not think so but....
Mainly most of my sites are "strict" ready
but I have one that uses once target _blank
so I guess for the time being I will make them strict
and kill the _blank
This brings a question
any SEO "cost" related for changing a XHTML trans DTD? to a strict one or even from XHTML to strict HTML 4.01?
I do not think so but....
A Bridge To The Future - Information week, May 2000
Well here it is 6 years later, and even xhtml 1.0 is still in the "recommendation" stage. 1.1 seems to be still in the draft stage (after 5+ years), and the status of 2.0 seems to be doubtful at best - from all appearances 2.0 will not be backwards compatible with much existing content, which makes it essentially a dead horse.
I see a lot of blame being placed on the browser makers, but I wonder how much of that is actually due to basically nothing being done for 6 years to make it a true standard?
When XHTML first was proposed, there were about 1/20th as many websites as there are now I would guess. It is starting to look like events will bypass w3c...
Well here it is 6 years later, and even xhtml 1.0 is still in the "recommendation" stage. 1.1 seems to be still in the draft stage (after 5+ years)...
Yup, and in 2006 we're still stuck with (X)HTML1997. That's 9 years of wasted development time we'll never see again. 9 years FFS!
...and the status of 2.0 seems to be doubtful at best - from all appearances 2.0 will not be backwards compatible with much existing content, which makes it essentially a dead horse.
And, by implication, xhtml1 too. xhtml1 was always seen as an intermediate step towards xhtml1.1/xhtml2:
xhtml1.1 is a "pain in the ass with no demonstrable benefit...Now that I’ve had a taste of what it's [xhtml1.0] allegedly a stepping stone towards, I just can’t see the point." , Mark Pilgrim, 2003 [diveintomark.org]
"The [xhtml2] spec may have tremendous benefits, but I’ve been doing this work for a while and I can’t see any."Jeffrey Zeldman, 2003 [zeldman.com]
"I think there needs to be a serious reconsideration of XHTML2 as an effort at all." Tantek Celik, 2003 [lists.w3.org]
"I do believe the whole thing should be, as it stands now, dropped and started again almost from scratch... I think that XHTML 2.0 is going to drastically increase the TCO of web sites... sorry to say, but XHTML 2.0 seems to me the live proof that something is going wrong at W3C", Daniel Glazman, 2003 [lists.w3.org]
To help repair the damage XHTML-advocacy has inflicted on the "web standards" movement (which I broadly support), the w3c may have to revise its entire approach to web page markup, or follow xhtml into irrelevance. That would be a disaster. I see no sign of the w3c recognising this.
</rant> :)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<tITLe>Suckiness test</TitlE>
</HEaD>
<boDy>
<P>Which language sucks? Here comes the answer:
<tAbLE><TR><td><!-- -- -->XHTML<!-- -- -->HTML<!-- -->!</TABLe>
<p>Undisputable. ©
</HtmL> ...be valid in XHTML? No it wouldn't!
The adoption of XHTML to date is imho characterised by an element of foolishness. It's snobby and condescending to say so, but there's no other way to say it: many people invested time and effort in XHTML for no apparent reason. They did so because they were told to by self-appointed "experts" (or perhaps more accurately: famous, light-weight fools ;)).
As usual, you hit the nail on the head. I've done real xhtml strict sites, with header checking and all that nonsense, I've even fixed the javascript document.write issues on one site. The only reason to do that I can see is to show that I can do that.
I did along the way find a use for serving real xhtml pages with accept header checking, it's actually pretty slick, when you build a site or new page, you can run it through firefox or opera and get a line error number on each error in the html or content.
Commercially I've pretty much given up on xhtml. If I will be the only person ever working on the site I'll use xhtml 1.0 transitional once in a while. But if anyone else will touch the code, it's going to be 4.01 strict or loose, nothing is more stupid that serving error filled xhtml, that completely defeats the entire purpose of using xhtml.
Objectively, xhtml violated every single promise of html, which is and was a beautifully flexible and forgiving markup language. The browsers handled it fine, the error engines were perfected years ago, anyone who wants to can put up the most absurdly convoluted code in the world and still expect to see it render more or less correctly.
I think one of the biggest sources of confusion in the early pro-xhtml days, 2000-2002, was confusing full css with xhtml. Likewise with css/p. How these things came to be linked in younger developer's minds was never clear to me, since there is nothing in xhtml that you can't do in html with css, realistically speaking anyway.
If you look at what really happened with html, it was developed very organically, innovations flowed into it from the market, and it spread like wildfire. It was only when the w3c decided to try to take back control that xhtml was really born. So what do we have now? A totally useless specification, and a frozen feature set in html 4. Not to mention that xhtml 1.0 offers less, not more, control and features.
I remember the first time I took a look at the xhtml 2.0 proposals, I immediately knew that I would never use it, it was so ridiculous it was hard to understand how something so utterly clueless could ever have been put forward, user friendliness was totally thrown out the door in favor of some pointless 'code purity' of interest to few humans on the planet.
Another confusion came from the idea that data itself would sit in xhtml pages, and so of course those pages had to have strict data layout. As if the world wide web would actually be built up out of static flat files. It should be obvious to even the most cluess person out there today that what has in fact happened is that html has become what it was supposed to be, a markup language used to mark up the output of dynamic database driven systems.
blogs, wikis, forums, cms systems, that is. It's totally irrelevant how you output that data, xhtml, html, whatever you want to do, just tweak the template and that's it. So why use something that is harder to work with, less tolerant of errors, etc?
The elimination of document.write as an option was I think the single most stupid thing in that proposal. I spent a few months playing around with the options, which massively violated the principle of KISS [keep it simple stupid].
The new html should have been more flexible, not less, it should have offered developers more options and tags, not fewer, it should have been even more forgiving of error, not less. It should have had new form elements, and so on. And it should have been easier to use, not less.
While I don't regret having spent the time to really look into all the practical xhtmls, as a learning experience it was and is useful, I just don't see any real point to all that effort.
Anyway, as we can see from this thread, common sense has returned to the topic, which is a relief to see.
Will I keep using xhtml on my own stuff? Yes, but only because I like the rigour of it, that's a personal thing, it has no real meaning, it's just liking clean consistent code. Any xhtml site I do can be changed to html 4 strict with 2 sitewide search and replaces, or template modifications, ' />' -> '>' and the doctype stuff.
Same to convert a html 4.01 strict to xhtml, a few regular expression search and replaces takes care of it.
Also keep in mind, for the times that data actually would be stored in flat files of some type, those would be xml, which would then be transformed by something like xsl or whatever into whatever markup language you wanted.
As primarily a content creator using the web as a vehicle to distribute this content, the proprietary tag soup was problematic to me, which I hoped web standard XHTML/CSS was going to take care of. But getting my head around it after so many years of tables with Wilbur ....
I have 3 "guru" tomes on my bookshelf on web standards/XHTML/CSS, for teaching myself the blasted stuff, and every one of them uses different unit types/methods for the same function, for example - font size display.
So I now am comfortable with idea that I set my standard and use it consistently. As long as it's well formed, validates and doesn't break in 90% of my user base.
Well, that's my rule and I'm sticking to it. ;)
All hail 4.x HTML Baby!
(OT: I see HTML 5.x is in the wind. Can we all just stop for a while, so everyone can catch up?)
So, is it worth it? Definitely! The pages are smaller in size, they load faster, and they still don't look too crappy in older browsers (and they look better in newer ones!). It is also way easier to update them and avoid nesting errors.
There is quite a contrast between the thread containing the above quote with the current thread.
A main point from the current topic in this thread is that pages can break in XHTML (browser wars again) and that some webmasters who do not understand the underlying principles should avoid XHTML.
I use Dreamweaver MX to create my pages.
I'm good at writing original content but I've noticed that some sections of my sites don't appear consistently as intended across various browsers.
Some of my html pages need to be updated to a DHTML standard; some of my pages are made with CSS but are not uniformly standard to give the site a "total look"; and then some of my content needs to be extracted and put into a new format altogether. I thought I would create some designs with XHTML to create a standard and pulled together look.
I have a book published by SYBEX, Mastering XHTML.
The book was written in 2001.
I'm in the process of creating a few master designs with XHTML for my sites but now this thread has alerted me to the potentional problem that my XHTML sites might break in browsers (IE, Safari)?
I plan to "go by the book" so is it okay for me to start my pages with:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
etc...
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
Thank you :)
I would recommend the HTML 4.01 Transitional route of the two you've mentioned, for two reasons. The first is that, as this thread has discussed, using XHTML correctly is much harder than simply swapping the doctype - and there are precious few advantages to moving to XHTML anyway.
The second reason is that the example syntax you gave has an XML prolog before the doctype, which has for effect to switch IE6 into "quirks mode", making cross-browser rendering much more complicated. See Quirks Mode vs. Standards Mode [webmasterworld.com] for more information. The HTML 4.01 doctype you mention ensures standards-compliance mode across all modern browsers.
If they do not validate as zero error then there is zero reason to call them xhtml.
You should have the quality of your code match the doctype, if your xhtml has many errors, then there is literally no reason to be using that.