over 2% still seems a little high to me seeing that web pages written in XHTML are offered for download because the browser can’t display them. It’s starting to get close though.
It would be interesting to know where those 2% are located.
Anyhow, who really cares about the X anyway? It has dropped out of my field of vision altogether.
Not necessarily stop pushing the web forward, but more appreciation for all it’s forms. For many messages, simple works well.
I worthy topic. There are so many choices, no one can do all.
I think we should teach wordprocessing with HTML structure and CSS dressup in middle school as complementary to super-duper desktop publishing as in Word.
Three tiers - plain text, HTML and CSS, and desktop publishing ala some CMS.
To me, digital document creation, not necessarily graphics, photos, or video, are driven by different motives.
With so many choices, I no longer feel “the media is the message” applies.
Yes, with the exponentially growing number of choices, frequent shifts in the “foundation” and still only 24 hours in a day, it is often an over-whelming.endeavor trying to keep up.
Some days I feel as though “yeah, I got this” but most days I feel as though it’s like my todo list. i.e. even If I lived 3 more lifetimes there still wouldn’t be enough time. It grows faster than I can shrink it or even keep it same size.
READ:
It’s out of control
So what to do? Let it run or try to slow it down?
Well I have been waiting for 16 years to be able to use XHTML properly instead of that horrid mess called HTML so as soon as I can ignore IE8 I will start converting to use XHTML properly.
At least with XHTML if you have errors in the markup the browser doesn’t try to fix them so you can fix them yourself before the page goes live and gets interpreted differently by different browsers that fix the errors in different ways.
Also now that all browsers more modern that IE8 support XHTML somebody ought to use it or XHTML 1 and XHTML 5 and all that effort adding support for XHTML into browsers will have been a waste of time.
I too like XHTML.
Sure. it’s more “strict”, But I like lo think that putting more control into the hands of devs is better than the “write sloppy and let browsers fix it” approach that HTML5 seems to have.
It might be different it browser support could be relied upon, but it can’t
But if no one wants to use it, it was as waste of time.
Easy solution: don’t have errors. 
No one is really promoting obvious reasons for using XHTML that I can find. I don’t see coding errors as that big a deal. Certainly not a reason not to serve anything to and end user. Seems better to me that the browsers at least make an attempt to deliver the content, even if the code around it isn’t the best.
1 Like
It certainly isn’t the biggest benefit of XHTML. A far bigger benefit is much simpler parsing rules - as all tags must be closed it is much simpler to parse XHTML than it is to parse HTML.
Also with XHTML being based on XML you can have one single source of information that can be converted not only to web pages but to a whole range of different types of document that are all based on XML.
I would think that there will be far more XHTML pages generated as one form of document from the same source as all sorts of other type of document than will be manually coded just as XHTML.
Interesting. Still, for the most part I think I follow the rules for XHTML. So I’d think if your aim were to be XML compatible, you could just write your HTML that way, without having to have a different doctype for it, but meh. On balance, I still prefer the idea of a more forgiving environment that made the best of things, rather than just fail because of a misplaced tag etc.
I think in most cases most mistakes are “corrected” fairly well.
But not always, and when they are not they can sometimes cause CSS problems, go unnoticed for a while and be a real bugger to troubleshoot.
Admittedly contrived example.
<body>
<h1>Malformed Table</h1>
<table>
<tr>
<td>row one cell one</td>
<td>row one cell two</td>
<td>row one cell three</td>
</tr>
<tr>
<td>row two cell one</td>
<td>row two cell two<td>
<td>row teo cell three</td>
</tr>
<tr>
<td>row three cell one</td>
<td>row three cell two</td>
<td>row three cell three</td>
</tr>
</table>
</body>
Instead of replacing the <td> with </td>, Firefox “corrected” the mark-up as though that tag was intended and added two “missing” </td> tags
There isn’t a different doctype for XHTML 5. You can either ise the same short one HTML 5 uses or leave it out completely since the only purpose that tag serves in HTML is to turn off quirks mode and XHTML only has standards mode.
There’s almost no good reason to use XHTML anymore. To quote a WHATWG blog post:
“I would say that the main advantage of using XHTML5 would be the ability to extend HTML5 to XML-based technologies such as SVG and MathML. The disadvantage is the lack of Internet Explorer support, more verbose code, and error handling. Unless we need that extensibility, HTML5 is the way to go.”
And that’s a 5-year old post. I think today that advice would be out of date and it would be better to just use regular HTML5.
The thing is, these aren’t really hard errors. And the fact that the browser fixes them is a huge benefit, not a drawback. That being said, it is true that in the past, due to lack of interoperability, browsers had different results with some kinds of broken markup. But 99% of the time, they handled it basically the same. Also, a validator is just a few clicks away, so I don’t know why it’s necessary to have explicit error messages. You can fix the markup and still have the advantage of the browser trying to make corrections.
So my advice is: Forget about XHTML (in any form) unless you have some really rare edge-case scenario that absolutely requires it. But I can’t, for the life of me, think of any such scenario.
2 Likes
So you didn’t actually read my earlier post where I suggested what I think will be the most popular use of XHTML.
The source of most future documents will be XML where they can be easily converted to a variety of different XML based languages depending on where they are to be displayed. For display on the web they will be converted to XHTML as that will be a trivial conversion compared to the much harder task of converting them to the illogical HTML.
Also an error is an error. If you want to fix all the errors so they don’t cause problems later (as errors tend to do) then anything that makes finding them is a bonus. Obviously you are not a programmer as no programmer would use HTML if they could use a far more logical language like XHTML.
I did, but…
According to who? Or what evidence is there to suggest this? I’m not sure if you’re making a sweeping opinionated statement about the future of the web here or if you’ve seen some kind of trend that I haven’t seen…?
Yes, you give what you think is a good reason, but nobody that’s working on the web platform specs agrees with you. So I tend to side with them (more on this in a moment…)
Well, the fact that I humored you and called them “errors” is just that, me humoring you. But they’re not errors. That’s why the HTML5 validator (for example) doesn’t care if you close paragraphs or list items, etc. And again, you’re making a really sweeping generalization there by basically saying that nobody who prefers HTML over XHTML is a programmer. That’s absolutely not true and provably so.
You mention that XHTML documents are easier to parse when in XHTML or XML format. As mentioned, AFAIK, the engineers working on the web platform don’t seem to see this benefit. But besides that, keep in mind that every web page renders a live DOM, after which it is quite trivial to parse. So if you want to parse HTML and convert the contents to another format, go ahead. You can actually use a modern up-to-date browser to render a live DOM, from which you can grab and convert whatever you want, universally, without any problems. Cross-browser compatibility and interoperability are non-issues if you’re talking about parsing and/or converting the contents of web pages.
The W3C and WHATWG moved on from XHTML because, in a nutshell, XHTML is an awful solution for the web. It makes no sense on a platform that relies heavily on backwards compatibility and progressive enhancement. There’s no indication whatsoever that anyone working on the specifications for the web platform are promoting some future use of XHTML5 (ie. HTML5 as XML), and until I see evidence of that, I strongly suggest nobody tries to write a page or app using XHTML in any form.
1 Like
I wasn’t referring to people working on web platform specs - XML and therefore XHTML are far more global than that small section of the computer world.
Microsoft have already swapped all their office document formats to an XML based markup which makes converting any office document to XHTML trivial.
Also why did Internet Explorer recently introduce support for XHTML if XHTML is dead.
Also the latest XHTML standard was released less than a year ago - why bother with it if XHTML is dead. The only decision that was made is that XHTML will not replace HTML and so it is worth keeping both standards in sync rather than assuming that everyone will transfer across.
Anyway HTML is going backwards - HTML 5 should have been called HTML 3.1 or even HTML 1.1 given how much of what was introduced in HTML 2 and HTML 4 that it has undone - even though those changes were made for good reasons that still apply.
Of course one thing with the web is that people can write in whatever (X)HTML version that they prefer since the browsers have completely ignored the entire concept of “deprecated” tags and attributes and have continued to support them long after they should have been deleted (and would have been deleted if HTML was a programming language).
With JavaScript there are so many web sites still adding scripts designed to work on Netscape 2 that a whole new command needed to be added just to allow browsers to distinguish between that language and the almost totally different language that JavaScript is when written for modern browsers.
The whole thing with the web is about choice and you are denying that others have a right to choose to run a different version of the various languages to what you think they should run.
Anyway, your saying that something that I think will happen is not what you or someone else thinks doesn’t change anything unless you provide me with evidence to convince me to change my opinion - since it is my opinion and no one elses. There is plenty of evidence that there are lots of people who think XHTML 5 (released less than a year ago as a new standard) is not dead - in fact XHTML as a proper markup language will only be born once IE8 users are a small enough percentage of web users to ignore.
If you’re going to insinuate that others need to provide proof for their arguments, perhaps you should do likewise.
I’d also encourage you to stay away from obviously derogatory/inflammatory remarks like
As that’s not constructive at all, is obviously not true, and serves no useful purpose here.
Incidentally, guys, this conversation has caused me to read up quite a bit on the HTML5 specification and related issues, and it’s been informative. Thanks!
2 Likes
I agree - I was expressing my opinion and louislazaris attacked that opinion dictating that I was wrong to hold that opinion as that wasn’t what was going to happen - no facts were presented to refute my right to hold that opinion.
You don’t agree, clearly, as that’s not what I said.
No one is interested in stripping away your right to hold opinions. Unless you happen to reside in a country where the government is trying to do so. I am pretty confident from memory that this is not the case.
You were not just expressing an opinion, but expressing it as though it were factual and unassailable. That’s not the same thing as offering an opinion. As I was saying, if you wish other individuals’ arguments to be backed by proof or citations, perhaps you need to justify your own with citations or proof as well if you intend your opinions to be taken seriously.
Finally, the only attack I’ve seen here is yours. I’m simply advising you to be careful of the tone of your posts and not create an environment in which civil discussion and debate on an issue cannot be had without personal attacks. I’m sure that’s not asking too much.
1 Like
Hey guys, sorry if this got out of hand.
Felgall, I apologize if I came across as attacking. That was not my intended tone. I was merely expressing an opposing view based on my understanding of the subject.
The fact that you brought up the recently edited spec on XHTML(5) is certainly a valid point, but I don’t think that changes the crux of my argument here. I’m not attacking anyone, but I do think that it’s not very constructive to advise people that XHTML is the markup of the future. I still think there is little, if any, evidence that XHTML is the recommended way to go. My guess is that they keep the spec updated because it’s still used (though rarely) and is still a valid way to write markup. If they invalidated XHTML, that would go against the very principles they’re trying to defend when deprecating it in the first place (backwards compatibility).
So my feeling is: I appreciate your opinion, I do acknowledge that there is an updated spec, but I haven’t seen any evidence that the W3C or WHATWG or any of the big vendors are gearing towards a future in XHTML. It’s simply not there, and so I strongly advise anyone to not use XHTML in any form unless that changes in the future.
Of course, that being said, are your documents going to suffer from being written in XHTML? No, not at all. But, in my opinion it would be a waste of time to spend all that effort to get valid XHTML pages since it will accomplish very little and will produce much more code than is necessary.
I think we both misinterpreted what the other was trying to say.I wasn’t trying to suggest that XHTML 5 was for everyone or even recommended.
(X)HTML 5 gives a freedom of choice - those who prefer the HTML 3.2 markup (the majority) can continue to use the tags that HTML 4 deprecated as HTML 5 did not obey that and remove them but instead downgraded their status to obsolete (or even reinstated them in some cases), those who prefer the HTML 4 way can do so now that IE7 is dead, and those who prefer the XHTML way can also do so once they consider IE8 to be dead.
I can’t see that there is really any difference between the effort to get valid XHTML pages and the effort to write valid HTML (the editor I use adds the closing tags automatically either way) - it is just easier to spot the errors with XHTML as the browser helps you find them rather than assuming the missing tags are there.
There is also more room for misunderstanding JavaScript code referencing HTML than there is with XHTML. For example with HTML the <tbody> tag is always added by the browser if you leave it out of your table and so you need to take that into account when referencing the table from JavaScript whereas if you leave it out in XHTML then it is not added by the browser. Similarly with other optional tags that the browser will assume are there if you leave them out in HTML - as far as JavaScript is concerned all those tags are there.