(mod: split from this [new user link]. Debating xhtml has nothing to do with how to set mimetype headers)

XHTML isn't going away. html5 was a pretty stupid idea as it offers no real advantages unless you're the sort who picks your programming languages on the basis of whether it uses curly braces or significant whitespace. People see shiny features and jump on the bandwagon HTML5 is mostly about DOM changes and additions which didn't necessitate ditching XHTML. HTML isn't different or special enough to warrant/deserve inventing it's own syntax and throwing out the perfectly fine more powerful one used by everybody else due to the few minor and fixable annoyances of XML.

Well-formedness is a bare minimum basic requirement which should never occur in generated XML unless something went really wrong in which case it's probably a worthwhile parity check that you'll want to at least be warned about. The only thing I'll agree with is that the original intention of that rule wasn't to prevent users from getting at data/services and shouldn't be too tough to fix in either the specifications or implementations.

The more serious problem IMO had to do with making declaring a doctype a hard requirement (or any schema for that matter), and also the assumption that modularization would actually make extensibility easy (it is so long as you stick to the modules - modifying the modules could be tough for non-experts). If you don't actually want to use DTD you're stuck maintaining two schema implementations, though I believe that requirement has been lifted in the newest XHTML+RDFa 1.1 working drafts.

XML in (X)HTML5 might eventually be a workable solution since it forbids text/html entirely, requires no doctype, and guarantees standards-mode rendering. My only hope is that html5 doesn't make it even harder to kill html 10 years down the line when it turns out we need namespaces after all, people get tired of hacking SVG and other vocabularies into html, microformats dies due to it's inferior centralized incompatible nature, etc.

BTW, IE9 fully supports XHTML mimetypes (finally) and treats them "correctly". Previous versions of IE parse it as html even with an xhtml mimetype by falling back to the .html file extension in the url (requires using example.com/index.html for instance). Probably not a good thing to rely upon but it works, which I don't think is widely known.
Back to top

This is one of the less coherent views I've seen so far re HTML 5. Equating a wide range of new tags, such as <audio> <video> as well as advanced form handling tags with curly braces vs white space indicates you have some lack of objectivity, probably I assume having wasted your time with xhtml over the last few years, that would make further discussion problematic at best.

I'm sure there are valid applications for using real XHTML, I've never seen one personally in 10 years of doing web development, but I wouldn't argue it has zero function, just none that really matters for most users or developers, except in some very specific circumstances, where it might actually be the best tool for the job. Again, I've never come across one, not as a core member of webmasterworld, and not out in the real world. But I won't say it doesn't exist.

I suggest you start adapting to reality, all the big players are now pushing HTML 5, it's here, and it's going live, so you can either cling to such confused and mistaken views as what I quoted from you, or just learn to use HTML the way it was intended to be used, a simple easy to learn, fault tolerating, user friendly, markup language that browsers handle with exceptional flexibility (in other words, it doesn't matter that much if your code is perfect).

It is PRECISELY the type of anal programmatic technical 'correctness' that was and is the primary problem with XHTML, that is, exactly what you note falsely above about html 5: worrying about closing /, worrying about perfectly structured and output character entities, all for nothing, since the browsers all render xhtml as html tag soup because no browser can truly trust any xhtml labeled page's code.

HTML 5 is the long delayed correct future path, XHTML was and is a geek's attempt to make complicated the simple, classic computer programmer attempt to break what works fine. I'm actually happy that MSIE never parsed XHTML properly, until MSIE 9, that helped us avoid a future run by geeks.

By the way, I am NOT an HTML 5 fanboy, it's not ready for primetime, it will be, but it's not now, it's being rushed in prior to the full specifications being completed, but given the decade of total inactivity in the HTML arena, better too fast than never, at least all the main browsers will offer support, finally. HTML 5 has all the new problems, just like CSS did, irregular support, needing to do browser detection to deliver proper formats for browser x or y, all that mess that seems to be the eternal fate of web development, but at least we finally are moving again.

The strength, not the weakness, of HTML was always how forgiving it is of user error in the page code. This was never a failing, it was a core reason it took off. The geeks at W3 sadly could only see technical code perfection as the next step, not new advanced features and even more robust specs, but luckily the world ignored the entire xhtml nonsense, all browsers ignored it, and now we're left with a lot of projects churning out various blends of bad XHTML, or now and then, decent XTHML, served as mimetype text/html, in other words, tag soup, like it's always been.

All those stupid doctype things ever did was introduce more error, more areas for sloppy clueless script kiddies to do things wrong. My favorite was always seeing incompetent web developers assign xhtml 1.1 strict to their sites, which of course didn't even begin to approach validation, thinking that using that was somehow more 'advanced' than 1.0 strict or loose.

Anyway, thank god your views didn't prevail, that's all I have to say, though of course you have the right to hold them, as we all do. There's a reason HTML 5 is being pushed so aggressively, it's been over 10 years since we've had any forward progress in the features of HTML. XHTML was a step back, not forward, for almost all web developers outside of a tiny niche of uber geeks, in my opinion, fewer, not more, usable features, less, not more, user friendly. Typical geek pattern, by the way, I do extensive Free Software development in Linux area, and it's the same pattern there.

I also am one of the few people out there who actually have built and maintain sites that are true xhtml, both 1.0 loose, strict, and, just for kicks, to see how technically near impossible it was, xhtml 1.1. That's mimetype detecting, header setting, validating as true xhtml mimetype xml/xhtml sites, that is. Not something I waste any time with now, of course, since I finally grew up and stopped wasting my time and my web client's money with stuff like XHTML, now I focus on delivering results to them in a timely productive manner, with fully validating html 4 code, strict, loose, depends on the job. As HTML 5 ripens and gains wider support, I'll move to that for future jobs.

Ignoring XHTML, the real problem I see and am experiencing as a developer is the ongoing failure of browsers, text/code editors, to properly and automatically identify/display the file's character encoding. This can be a very significant issue, from databases to simply updating pages with non default characters. Why this problem still exists in general in today's day and age is beyond me.

If I need something to be grateful for, I am so thankful that the nightmarish geek wet dream of XHTML was stopped in its tracks, and sanity was allowed to return somewhat. I was absolutely stunned by the horrible syntaxes of the 2.0 specification when I read it back in the early 2000s, and I knew it would never come, because it was a total violation of all good programming rules: harder, geekier, less usable, more pointless, solving no real problems.

The problem with things like XHTML was that it massively confused programming language and syntax with simple markup code. There was never any need that XHTML met for the vast majority of users, developers, and humans. Data storage doesn't occur in static files, it is what generates the pages, and those pages should be as usable and flexible as possible, and that's why all the big sites refused to play along, even though the fanboys did, something I always noticed when reading code of most of the big sites.

XML on the other hand makes fine sense, and is a fine way to store data etc, to be parsed by some programming language and output into the markup language of choice.

For the record, I write clean, generally error free code, and where errors exist, it's because I know it doesn't matter, and the client or me does not benefit materially by working around the error, things like using <embed> in <object> tags for example, and other meaningless errors.

But glad to see the world moving on.

Complex decisions and code generation happens server side, not client side, and confusing that simple fact was always the primary problem with the entire XHTML nonsense, from the very beginning. It makes no, and has never made any, difference, to end users what markup language was served to their browsers. Mobile devices generally require server side work to deliver the stripped down pages, again, the delivered html never mattered very much, nor will it ever matter very much, unless the world decides to make another wrong turn, guided by misguided souls who I am sure are quite well intentioned, but still misguided.
Back to top

No no, other way around. The syntax and serialization has nothing to do with the addition of tags and features. It's eXtensible! Those could (and can be) just as easily encoded in XML/XHTML. The point is that there is zero reason to use a different parser in order to achieve that.


I hope the rest of your code isn't so sloppy. And anyway anal strictness is entirely missing the point. Nobody writes cr#p tagsoup anymore and that everyone seems to think that the central reason for using XHTML is to enforce some kind of strictness tells me that most people don't understand the issue or do any server-side programming involving XML. Granted in the end it doesn't really matter since it's easy enough to feed HTML to browsers after doing XSLT, XIncludes, XQuery, XPointery things on the server. None of what you're telling me I consider a valid advantage over XHTML with the possible exception of strict draconian error handling, which I already conceded in my first post...


Though if I had a choice about throwing an exception versus guessing about how to interpret some mangled bits of possibly important data in a completely transparent way to the user I'll take the former. This is such a trivial issue... don't invent your own language and throw away something else that's widely implemented over it. IMO the correct approach would be to put the user in control of error handling but for some reason nobody wants that.

No, all browsers followed it and have had this working for years. Only one browser ignored it. Don't confuse the the quality of a language with the quality of it's worst implementation, regardless of it's ubiquity.

HTML5 is absolutely not more robust or advanced. There are two separate issues at play here, I'm mainly talking about parsers and consistency with existing XML specifications and languages which we're only going to see more of in the future - particularly mixed namespace documents. Adding additional features to the browser DOM doesn't require throwing that away, and there's actually a much better way to specify it via XBL2. The HTML5 spec is generally vague and rambling by comparison.


Ah so you don't know the difference then? There's really no reason not to use 1.1. To a web programmer not concerned with DTD implementation they are virtually identical, just 1.1 happens to be much better organized... hence "modularization". You can still use text/html either way so to the browser it makes no difference whatsoever - even if the spec did strictly disallow it. You know browsers neither perform validation nor look at external entities right (with some rare exceptions in firefox with XUL)? That's why <!DOCTYPE html> works as it does.



I do agree and blame W3C for being slow to respond to the needs of UA implementors and web programmers. Whether that's more the fault of W3C or others to work with them I don't know. However I blame whatwg for totally bypassing the work of W3 rather than building from and using it as a starting point. W3 things aren't perfect, but they are standard and well-defined with many robust compliant interoperable implementations (same can't be said about SGML). XHTML certainly isn't broken in some fundamental way that can't be salvaged with a bit of cooperation.

I actually came here for Liquorix kernel stuff rather than debate about this, but it's an interesting topic. I'll probably never understand this point of view though. :/
Back to top

The fact you will never understand the point of view confirms largely what I said initially in my first response. My focus in both Linux and web work has always been heavily guided by the end user, not geek things that make no, or should make no, difference at all. I fell for the geek stuff too in XHTML, that's why I have implemented it more aggressively than most people who put it out on the web in my dev/test sites. Then I got older and more experienced, just like, apparently, Apple, Google, Opera, etc, all also have as they promote heavily HTML 5 as the way forward, and started seeing the problems.

The fact that the largest groups out there are aggressively moving to full HTML 5 support is interesting as it was unexpected. My days of wasting endless months learning new fads are happily behind me, so I don't care at all about some things, all I care about now is what is required to get the stuff out to the end user.

Basically, while I admire people who are at least able to construct coherent arguments to support their views, the bottom line is that what you are arguing has never and I believe will never matter to most web sites or web developers or end users.

This is the precise reason google, ebay, amazon, etc, never fell for the xhtml stuff, and it's the exact reason that apple, google, and all the big media type players are agressively pushing html 5. Not to mention all the browser builders. Sure they will support xhtml, why not? They have to, and it does have uses.

The extensibility of the markup languages, which while obviously you spent the time learning, was and never has been a feature used by I would guess at a very minimum 99% of all websites and pages on the internet. Sure it's nice to offer extensible markup for things like inhouse applications served over controlled networks, sort of like the idea of MS's IIS <--> MSIE hooks that almost killed the modern internet before it was stopped by opera/mozilla breaking the monopoly, but the bottom line is that such extensibility was and always will be something of such limited utility that forcing an entire markup structure onto ignorant and unsuspecting developers, ie, 99+% of all web people, the ones who put out the real pages you read, that is, as a standard or desirable default was and always will be a stupid thing to do.

I'm not arguing that there are hyper specific circumstances where such extensibility is not useful or desirable, I am pointing the real pages, the real sites, the real developers, in the real world, where such things have zero value or benefit, quite the contrary in fact. If you look at a site like facebook, or bing, you should be able to realize that exactly zero difference would occur on the page display / useragent processing if they switched their doctypes to html 4.01 strict, and updated their templating engines for that small change. It's really just a style/fashion thing, something young devs tend to like doing because it's a bit cleaner/anally precise in their minds, but for the end user, makes zero difference.

Pointing to hypothetical (for almost all users/developers) advantages indicates a clear lack of perspective on your part, and it's not a perspective shared by of the core groups involved in the current HTML 5 work. Thank god for that too I might add.

Since the output to html is largely trivial, with the single valid case, almost never used by normal sites, of extensibility, I'm not really clear on what you believe you are demonstrating in this posting. Clearly today's real internet does not at all agree with your views, Jobs didn't force xhtml 5 down our throats by not allowing flash on iPxxx devices, he forced HTML 5, and that's what he is pushing. So is Chrome, Opera, MSIE 9+, and all the rest.

So you have a valuable niche skill, that's good to have, it pays the bills, but it's not related to the actual internet most of us use, nor was it ever.

Saying browsers 'follow xhtml' is largely meaningless, since you can take any xhtml code, remove the xhtml specific components, leave the doctype, and it will display, I believe, the same, exactly, since the browser truly does not care how you declared it, it cannot do so, since to care would create errors all over the displays of almost every so called xhtml page on the internet.

The vagueness of the html 5 spec is I believe because it's being hurried out the door, but we needed to hurry it, we've simply lost too much time as it is. Why do you think HTML 5 is being so aggressively pushed? It's because it's needed now, and that is needed precisely because XHTML was far too complicated for most people/developers to actually implement.

The differences re 1.1 xhtml are found if I remember right in the way it handles DOM events, but again, I don't waste my current time or life following this cr#p, it helps nobody, it wastes my finite dev time, which is far better spent learning things that are actually useful, DB, programming languages, CSS, which unlike XHTML is a truly valuable and incredibly useful addition to our palettes as web devs. Then various JS methods, implementing HTML 5 stuff so it actually works. This is where my dev time goes this year and last, give or take, plus learning the pain of working with CMS solutions, which are largely making this entire discussion pointless for almost all web users and content generators in the world.

While your faith and I sincerely hope profitable, ie paying, interest in XHTML is nice to see in a certain sense, I think you've lost a definite perspective, which, as I noted, is thankfully not shared by the actual groups out there who are pushing where the web is actually going to go. XHTML had its time as a default, and that time I hope is now ending, but it is nice for guys like you who as I noted, I hope get paid for your learning time, are focused on the niches that xhtml serves.

Niches are profitable areas to focus on with web work, I wouldn't suggest you change your focus since it can be a good living, but your focus is not the focus of the developing web, no matter how narrowly you try to view this question. You can also focus on a tree all you want, I'm interested in the forest, and this forest is being blown by the HTML 5 winds, I'm happy to say.

I'd already figured this out a few years ago, which is when I stopped using xhtml at all in my own projects, it felt to be honest like a big weight being lifted off my shoulders, like a breath of fresh air, and I like the directions, user focused, not hardcore dev, HTML 5 is going. I'd say the real developers of the real web have spoken, and are speaking, and that is why HTML 5 is being so aggressively promoted.

So to close this verbose comment, I would just note that while you can point to whatever technically correct statements you want, which is like examining the bark of a tree in great detail rather than seeing the actual forest and ecosystem the tree is in, I stopped caring about such abstractions long ago, and now focus on the end result, the end user, browsing the page, the real world web dev, who doesn't care at all about any of the points you have raised for the vast majority of cases, and for myself, I can promise you, I would never spend any more time of my finite life tracking intellectually fascinating but in the end hopelessly pointless dead ends re the goals and time frames involved.

I am somewhat gratified to find my long held views validated not by an online debate such as this one, but out in the real world, where HTML 5 is what is now moving the web forward, finally. It's this real world that pays my bills, just as the XHTML gunk is what cost me endless hours of lost dev time, for zero gain, to either me or my end users.

Sometimes you get too close to something to see what it is, I think that has happened to you, fine if you get paid to maintain this close connection, not so fine if you are just arguing this point just to argue something the way geeks like us like to do. Should I ever need such features implemented I'll drop you a line, by the way, but I can fairly safely say that day will never come.

Just to close this so I can move on with actually productive work today, my bottom line is that while I was annoyed by the pointless geekiness of xhtml as delivered as a guideline, once i figured out that for my purposes, and all my end user's purposes, it literally does not matter how I serve the pages to them, I pick the easiest cleanest way to do that, and I certainly don't spend any of my time now following these arcane debates, though I did once upon a time find it interesting, but it was more because I simply could not figure out what the point of this more demanding and complicated system was.

And now it really doesn't matter, if I use a cms type backend and if it runs naturally in xhtml, then I don't fight it, if I have a choice, ie, if I am authoring the templates, then I make it html, who cares? Life isn't about this topic, nor has it ever been. Confusing ones production choices with meaning or real life is a bad way to spend our time, at least it's a bad way for me to spend my time...
Back to top

I just wanted to post this verbatim summary from W3.org, the web standards body, since some innocent readers of the above exchange might believe that there was actually something more to the points raised re XHTML / HTML5, or that this is somehow a gray area, or hard to understand, or unclear. As the following quote shows, there is nothing at all hard to understand or unclear about the future of the new web, which is in fact HTML5. I'm actually impressed by the honesty of this statement, since it essentially admits that XHTML 1 extensibility was for all practical purposes a total failure and an evolutionary dead end, which we are only now recovering from.

Overview/summary of HTML 5 by w3.org


And so it goes. I always knew, because only geeks could ever have dreamed up a mess like xhtml, that geeks had taken over the internal w3c standards processes, and it was only because real world users and devs represented via the main browser makers pushed for truly usable/user friendly additions to html that we finally got out of that quicksand and are now headed, belatedly, towards the promise of user friendly, usable, easy to run, easy to mess up with no real negatives, markup language.

I have to really give the w3 group credit though for admitting they were wrong, I know they really had their hearts set on things like forcing users to create object classes just to create a simple image, which already had a simple <img..> tag that is perfect for the job (that was the threat of xhtml 2.0, which thank god is now basically dead and buried, and hopefully has had a stake driven through it's disgusting heart, and garlands of garlic hung around its grave to make sure it doesn't come back to pollute the world again...)

So I really want to thank the W3C group for finally allowing HTML to once again proceed on its forward path, and allowing the web to grow. Keep in mind, Flash etc grew massive precisely because as you can read above, XHTML not only failed to advance the methods of html, it actually shrank them a bit. So we lost TWELVE years here. 12. think about that. That's worse than microsoft, or netscape before them, ever managed with their poor browsers. If xhtml had never been thought of or implemented, and if html had continued to be expanded, we would have fantastic native audio, video, wonderful forms, all fully supported in all browsers users would be running today, instead of once again having to resort to browser testing, dual logics for pages to support browsers that don't handle the stuff, etc.

So while I do want to thank w3c guys for letting the world go on, I would like to really give them a hard kick in the a#s for not realizing the total dev/user usability failure that xhtml always was, and for allowing what was almost certainly an internal cabal of geeks to take over what had been a user driven standard and promoted a geek oriented one. And for admitting that xml type syntax only has relevance for things like rss etc, ie not the main real pages, just little side features.

So now we can move on....
Back to top

I think you're still confusing a few things. The message you posted deals with abandoning efforts to replace HTML with XHTML. That's something I think everybody is happy about and everyone living in reality is aware of. The important thing to understand is what is dead is the flavor of XHTML on track towards XHTML2. That's old news. It had a number of problems and actually it's biggest problems IMO had to do with the restrictions it added for the sake of backwards compatibility (like always requiring a doctype be used) which limited it's extensibility. XHTML (that is, HTML5 in XML) is evolving to live alongside HTML, where essentially their vocabulary is shared and the only difference is one uses an XML parser. The XML flavor is still being heavily developed if you pay attention to the mailing lists. XHTML+RDFa 1.1, the HTML+RDFa variant, and RDFa core 1.1 (lets you stick metadata into arbitrary XML languages) are in their final stages and is currently the fastest growing data markup language on the web. SVG is also moving along pretty rapidly (yet another XML language) at last has good implementations in all current browsers. They also released a RELAX NG implementation of XHTML 1.1 just a few months ago.

I'm confused why you're so upset about this. I'm actually quite happy about how things have evolved in the last year or so. It's now much more realistic for the languages to interoperate, and with IE9 out all browsers are about on par. I don't buy the idea that XHTML has held back the web. IMO the "old" (xhtml 1.0/1.1 variety) hasn't done much of anything besides help improve the general quality of websites. If anything it's been IE holding things back along with ECMAScript5 and CSS3 implementation and prevalence, not the HTML parts of the specs. IE would have been stagnating regardless of what language we used, and even though new additions have been added to the various specs, nobody could use them because of IE. The truth is that the specs are miles ahead of the browsers. No browser even today comes close to implementing everything there is to implement. Believe me, the bottleneck has never been browser developers sitting around waiting for specs to complete so they could implement them. Not even close.

The main nice thing about HTML now is that everybody uses HTML5 parsers for all HTML versions so you get standardized predictable interpretation of broken or legacy documents.

In a nutshell, just relax, everything is fine. Use whatever you want. To say the need for extensibility on the web doesn't exist or isn't being worked towards is just wrong. I KNOW there are many at w3c who disagree. The way things are going work out nicely because if you need that extensibility, you can get it, and if not, use HTML. In all likelihood you can use both via a web framework which does proper content negotiation with browsers (as it should, you can't expect every UA to support every feature of every language). Either way the feature set of the HTML part is about the same and both will be developed for the foreseeable future. Even if you did choose to stick with the old XHTML from the browser's point of view you're essentially just using a subset of HTML5 and should be perfectly safe. Same goes for HTML4. The compromises that have been made between XML and HTML haven't turned out to be as painful as I first thought they would be.

I still think the need for HTML will decrease in the long run for many reasons, but as it stands it's not something the average web developer should worry about.

< Edited by ormaaj :: Apr 4, 11, 22:43 >
Back to top

I am relaxed, I stopped caring about these questions years ago, unless someone comes along, like you did, and pokes at the question, I haven't used xhtml for a client project now for quite a few years, it's mean to do that, and totally pointless, but I will use html5 as it gains a bit more support.

It's going to be, however, about 5 years or more before MSIE 9 makes these things actually relevant, but the steps are good to take.

You don't seem that up on some parts of this history, I want to think you're quite young, but on the net you never know.

XHTML 2 and 1 etc are what stopped HMTL development, and it's only now, with html 5, that the rapid progress we saw until 2000 is actually starting again. Had we not gone down this route, we would have had HTML 5 somewhere around 2005, or even earlier, but there was all this script kiddie excitement about XHTML and valid programmer perfect code, which never has mattered in the real world, and never will I believe, unless humans stop generating HTML totally, that is, ie, all websites, without exception, are created using some type of program that handles all parsing and characters.

However, since I lost interest in wasting my time on fads years ago, what I'm now waiting for is that market share thing to happen, re MSIE 9, which means XP market share has to drop to about 5% or less ideally before it's really relevant. Of course, we can return to the old dual page or dyamically generated page html, using browser detections, etc, to feed visitors html5 stuff, something I've already started doing, if the client cares and will pay for the extra work.

Same old same old, maybe it's exciting if it's the first goround of the HTML standards wagon you've been on, to me it's not exciting, let alone even worth paying attention to compared to pretty much another other real matter out here in the real world.

But I guess someone has to be excited by this stuff or nobody would care enough to spend their time learning it and creating the next set of standards, lol, so I guess it's good you care. Ok I guess if you get paid for caring about it, otherwise, just more wasted years of our lives....
Back to top

I am, I've really only been interested in web development for a year or so so I suppose I'm just seeing a snapshot of things. Currently in working on a way to organize my own pages (mostly for homework and notes and such) by writing a simple framework using WSGI, having to serialize HTML is actually an extra lossy step that would be nice to avoid and eventually will probably involve some middleware. I guess I should look at how Django or Genshi do it.
Back to top

Yes, I suspected strongly that you were very new to this, it's the 'fanboy' thing. Don't worry, you'll get past this stage soon enough, after the stuff stops being cute and just becomes a pain to deal with in the real world.

If you look at the initial development of HTML, it was feature after feature, release after release, then a huge regression with XHTML, which we are only finally now freed from. That's literally 1 decade of total stop, all caused by those idiots who tried to cram xhtml 1 then 2 down our throats. As you note, it's a tool that has utility for some instances, but properly formed html 4 strict is essentially identical minus a few /> endings on some tags, so as a markup language, there was really zero gain for developers in the real world for about 10 years. Personally, I'm long past caring, but I did once care, until I realized if I waited for svg and things like that to be implemented I'd be waiting a long time and just wasting all that learning time, which turned out sadly to be precisely right, it will be about 10 years since I first looked at svg to the time you can actually use it cross browser.

Those are long time spans, caused by geek engineers being allowed to make decisions they had no business making. Engineers should do what wiser people tell them, and they should do it well, as well as they can, but they should not set directions, just follow them.

The only thing that actually saved the day was the ongoing development of CSS, that's what actually made the difference, the HTML/XHTML never made any real difference in the web except for being yet another painful bump we have to get over on our way to learning that a markup language matters far less than the content that is being marked up.

this is something all real web sites and companies learned over 10 years ago, that's why they are here now.

You may also be missing just how good these browsers have gotten at constructing the meaning of the code generator, MSIE used to be quite spectacular in this regard, I would experiment to see how badly I would have to maul code before it would fail to get my meaning, pretty badly was the answer.

That robust bad code handling was actually what saved XHTML from itself, and from its script kiddie fanboys, ie, no matter how much junk pseudo xhtml tag soup you threw at the browsers, they still know what you mean, and just ignore all the garbage and extra /> things and just display what you wanted. Even really bad postnuke type CMS code (now rebranded as zikula or something, as if a new name makes something better....) is treated as intended, and that's saying a lot.
Back to top