benbob — 2012-08-08T09:18:20-04:00 — #1
After finally reaching the stage where I have accumalted enough programming knowledge ( hopefully ) to re-design my site using CSS3, I am left with only 1 challenge: Xhtml 1 or html 5.
From all I have read, I think I understand that xhtml gives better options to optimise for Android/Iphone/small screen platforms, but can have some compatibility problems for various browsers/systems.
Is there a concrete downside to using Xhtml? If so, what is it?
ralphm — 2012-08-08T09:20:13-04:00 — #2
No, there isn't. HTML5 is not really ready for use, either, as it's still in development, so best to stick with what works for now. (Mind you, there's not much advantage using XHTML over HTML4, but it's up to you.)
By the way, CSS3 is also in development, and the few bits of it that are supported now don't work in older browsers, so use it wisely and with caution.
logic_earth — 2012-08-08T09:25:49-04:00 — #3
Just don't bother with XHTML, it is dead in the water. Has been for the longest time.
ralphm — 2012-08-08T09:29:23-04:00 — #4
XHTML2 is dead in the water, but not XHTML, which is perfectly fine to use and will presumably be usable for many years to come. These days, even the latest version of IE upports it (wow!), but it's worth noting that it was never supported by IE8 and under, meaning that it has to be served as text/html, which means you might as well have used HTML4 all along.
benbob — 2012-08-08T09:38:08-04:00 — #5
As there is no "real" (if there is such a thing as real) downside, I'll take the plunge and use Xhtml as the platform. I may not really use the difference, but if I do find something useful that is specifically "X", it will save me redoing the site again. This is the second time I have to do a complete overhaul, and I am getting fed up with patching up.
I know CSS3 is not "finished", but at the speed things are developing in the web world, I doubt any platform will ever be finished and stay unchanged for more than a year.
With regards to this, I am mainly concerned with avoiding application of coding that creates display incompatibility problems between brosers like [text decoration - blink] not being recognised by IE because people may find it irritating. (No, the irony of MS taking action to avoid people getting irritated, is not lost on me)
ralphm — 2012-08-08T09:43:55-04:00 — #6
Things seem to last longer than that on the web. Anyhow, I guess the point is to use only what you really need, as you can do pretty much anything you need to with HTML4 and CSS2.
benbob — 2012-08-08T09:57:12-04:00 — #7
That is good to know. As you know, I am far from being able to call myself an expert ( at least without lying ) and I often get the feeling things change faster than I can learn the laterst updates.
I fully agree with your remark to only use what you need. I subsribe to the theory that "less is more" and aim to keep my site as simple as possible without looking cheap/simplistic. Apart from the actual amount of useful information given, I try to keep it as small as possible. My basic premise being that the less code there is, the lower the chance of faults/problems/poor rendering.
system — 2012-08-08T10:34:06-04:00 — #8
Many of us use HTML5 semantics today. I use HTML5 semantics. It's viable, with the same notable exception as with XHTML: legacy IE. I'd go as far as to say XHTML is worse about that.
The thing is, all of us will use HTML5 semantics tomorrow.
Even more, HTML5 semantics gives you the opportunity to keep coding XHTML or just plain old HTML. It's your choice.
But XHTML is an application of XML. And XML is long dead now.
logic_earth — 2012-08-08T11:12:33-04:00 — #9
I don't know where you got that idea from, but XML is far from being any where near dead.
system — 2012-08-08T11:27:13-04:00 — #10
XML may be kept on life support for now because of the compatibility issues.
But everybody agrees XML is too verbose and it's on its way out.
logic_earth — 2012-08-08T11:31:15-04:00 — #11
Who is everybody? Where is this group of everybody you speak of? I'm going to assume you mis-understand what XML is because like I said. It is far from dead, not on life support and there are no compatibility issues keeping it alive. XML is quite alive on its own.
benbob — 2012-08-08T11:38:45-04:00 — #12
In your previous post, you said it was dead; now you say it is not.
Which one is it? Dead or not?
And who are these "everybody" that know this?
system — 2012-08-08T11:47:47-04:00 — #13
Nitpicking are we...
XML, as technology, is quite dead.
XML, as use, has a few breaths left. Mostly for backward compatibility in app settings, manifests. Just because some few stubborn cling on it in their newest release, doesn't make XML livelier.
logic_earth — 2012-08-08T11:50:08-04:00 — #14
system — 2012-08-08T11:56:52-04:00 — #15
For ME, at least, XML is dead. As in no longer a prospect. No longer relevant.
In database world, I don't want data that can break with a little missing >. In HTML world I don't markup that can break with a little missing >. In app settings world, I don't want settings that can break with a little missing >.
It's not that I'm not for strict and rigorous, I am. But for substance, not for structure. Much less for a superfluous verbose structure.
jeff_mott — 2012-08-08T12:55:36-04:00 — #16
I agree with this. Even pages that claim to be XHTML are nonetheless served as text/html, which means as far as the browser is concerned, it's just plain old HTML, which means there's zero benefit.
system — 2012-08-08T14:05:05-04:00 — #17
You should use the XHTML syntax only if you're using the XHTML features too, otherwise it just shows a poor understanding of what XHTML stands for
You're just presenting the browser with a wrong syntax each and every time it receives your page, which means extra work for it and it opens the door to potentially odd and buggy behavior from its part
And this is true for HTML5 semantics also. Even though the DTD is common for both features, you should choose one and stick with it, you shouldn't create hybrids. Clarity on intent, consistency on code.
benbob — 2012-08-08T15:54:33-04:00 — #18
From what I understand so far reading through loads of browser discussions, most browsers contain up to 50% "error-patch-coding" to be able to read sloppy coding. As smart phones are grabbing the web market by storm, it is well advisable to make sure your code is spot on, as phone software is more limited than computer software and thus more prone to display problems.
Writing clean code is really not that big a chore as long as you pay attention and test it. I handwrite it using wordpad and Notepad++, which makes it easy to spot typos. After that, I run it through a validator on "strict", which will pick up the remaining bit of static.
To chose a system because it allows for sloppy coding, is a strange way to go about imho.
system — 2012-08-08T16:12:14-04:00 — #19
As you stated yourself, a code is only as sloppy (or as clean) as you ... code it. It has nothing to do with a system.
I'm not sure how you handwrite code in Wordpad though. For hand-coding HTML, you need a plain text editor, which Wordpad is not.
And HTML has a strict DTD too, not just XHTML.
Finally, you should use XHTML only if you really use it, not as a catching net for coding errors. That's wrong. And strange. And it has the reverse effect on the browser, since you obviously won't be serving it as application/xhtml+xml or application/xml.
jeff_mott — 2012-08-08T16:14:52-04:00 — #20
I don't think anyone here suggested HTML "because it allows for sloppy coding." We suggested HTML because, even if you use an XHTML doctype and the self-closing slashes, browsers are nonetheless parsing your code as if it were plain HTML. The XHTML is just a facade.
next page →