Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- HTML vs XHTML
- Timothy Larson
April 11, 2006, 9:49 am
rate this thread
A couple years ago it seemed like XHTML was the direction of most web
markup, a foregone conclusion. Now I return to the scene and I see many
here recommending that authors stick to HTML, albeit in strict mode.
What happened? Why the shift? What's the problem with XHTML that has
everyone saying it be avoided in most cases? Can I take it that this
group seems to think HTML5 is going to be the future direction of the
web rather than XHTML2?
I've been happily going along marking stuff up as XHTML 1.0 Strict for a
couple years now, so I was just looking for some feedback on this issue.
Re: HTML vs XHTML
Please spare us yet another HTML vs XHTML thread, this issue has been
discussed ad nauseum here. Use the archives to find the arguments and
No-one knows. Safari, Opera and Mozilla are supporting the WhatWG
projects and have started to implement bits of the Web forms 2.0 and Web
Applications 1.0 aka (X)HTML5 proposals. I'm not aware of any current
support for XHTML2 in UAs.
OT (Re: HTML vs XHTML)
I've been on Usenet since 1992. I don't need your opinion to inform me
what a newsgroup is or is not, or how it should or shouldn't be used to
realize its potential. Maybe you weren't around back in those days, or
maybe years of the "new" internet have made you jaded.
It was commonly accepted then that technical NGs such as this one were
places that people could use as a resource to get solutions. This isn't
alt.fan.ricky-martin or something, where we can "discuss" back and forth
with no goal or objective in mind other than the discussion itself.
We're not here solely to discuss the vagaries and philosophies of markup
design without any practical application. Most of us are here because
at one time or another we've run into real-life problems and need
practical solutions. We ask for advice at those times, and those who
have been around a little longer and gotten help in the past themselves
try to offer suggestions. Ofttimes those suggestions amount to "educate
yourself, resources at <url>" but that's OK.
So trying to tell me that I shouldn't be able to expect a constructive
answer to a question is a joke. If you can't further a discussion by
adding to it constructively, don't say anything at all. _That's_ what a
discussion group is - people having meaningful and relevant discourse.
If all you can add is "go search the archives" then close this group
down and replace it with a pointer to Google. News hosts don't maintain
an unlimited history of groups' postings, so it's not always easy to go
back. Maybe a group has an archive, or maybe not. Even now that Google
seems to be fulfilling that role nigh-universally, it's still not a
panacea because searching doesn't guarantee you'll necessarily find the
best resource - in a group like this, there are probably thousands of
posts that mention "html" and "xhtml". I was duly diligent in searching
recent discussions, as appropriate for NG netiquette - my original
question itself alluded to the fact that I'd heard of the issue (which I
couldn't have if I hadn't been) but not the reasoning behind it.
With this in mind, I hardly thinks it's inappropriate to ask the NG at
large to point me in the right direction. If you don't want to help me,
fine, no one's forcing you to spend your valuable time on me. I
certainly don't have the expectation that I'll get an answer, though I
am hopeful. But why spend your time to give a non-answer? That only
wastes everyone's time. If you don't have an answer, don't reply!
Yeah, I could take the time to wade through thousands of posts - I know
how to search, and can certainly use those skills here. Pointing me to
a particular thread (or answering any question from anyone) doesn't do
you any immediate good, that is true. But at some point I may have a
suggestion to contribute toward a dilemma of yours, and that's what
makes NGs like this work. It's a community of knowledgable people
willing to contribute for mutual benefit and edification.
Given that searching can be difficult and NG histories are often
limited, and given that our time is precious and no one likes to have it
wasted in rehashing material, I am more than happy to accept a pointer
to a reference - specifications, documentation, past threads - as an
answer. However, archiving your non-answer is a waste of resources and
contributes absolutely nothing to the collection of knowledge.
Archiving a pointer to existing information results in more people
finding what they need more quickly when they do searches in the future.
Apologies for the long OT rant.
Re: OT (Re: HTML vs XHTML)
You'd long have the answers you are looking for had you spent that time
looking at the archives.
But apparently you can't be arsed to check out the first link from
So here ya go you lazy sod:
April 14, 2006, 2:53 am
Re: HTML vs XHTML
Timothy Larson wrote:
Bad, inappropriately done XHTML.
We learned how to do XHTML correctly. Then many people (although not
myself) decided to reject XHTML completely.
I use almost entirely XHTML for my internal processing, totally for my
mobile device output, and sometimes (as Appendix C) for general web
work. XHTML (C) _does_ work on the widespread web, but you have to
know what you're doing.
We realised that "XHTML-not-in-XML" wasn't really much use until there
are XML-aware consumers that can actually benefit from it.
XHTML is problematic and still premature for general publishing.
HTML 5 however is totally bogus and an exercise in one person and their
acolytes throwing their toys out of the pram. Hixie is up on my
dartboard next to the photo of Winer.
I predict (and quote me embarassingly on this in a year or two) that
XHTML is just about set for widespread adoption. It won't be as
"pages", but it will be as page fragments delivered to AJAX clients.
These are finally the widespread clients that really understand XML,
even if their parent pages aren't doing it as XML.
We'll also see a return to browser sniffing. AJAX-based "thickish"
clients for the browsers that can, restricted function compatibility
pages in plain HTML for those that can't.
I'd like to see a move towards Flash rather than XHTML 2! Now _that_
really is a bogosity.
Re: HTML vs XHTML
Gazing into my crystal ball I observed David Stone
Hey, I still have Netscape 3.0 - It's kind of refreshing to what an old war
horse does with new stuff.
Please respond to the group so others can share
Re: HTML vs XHTML
I still have Netscape 1.0 on original floppy for Mac, although I am sure
bitrot has destroyed it. I even paid for it and have the goofy 'Netscape
Navigator Reference Guide' which came with it, all in a silver tri-fold
Netscape jacket. I also have 'A Brief Guide to Mosaic Macintosh Edition'
by Michael Fraase, but I have no idea why I have that; although I did
use Mosaic, I didn't buy it. I just put the Mosaic stuff in the silver
jacket with Netscape for safekeeping and enlightenment for future
Thanks for reminding me of what I have and to search for and find it
again. I generally tend to throw stuff away. I also have an invoice for
NS3 for 49 bucks and a one year Navigator license for $17 dated in
August 1996. By golly, that's going in the silver folder too.
Re: HTML vs XHTML
I like the reality-based approach of providing an update path for tag
soupers without boiling the ocean.
It is ugly and uncool, but specs that aim for success in the real world
cannot ignore network economics and the effect of legacy systems.
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Re: HTML vs XHTML
Henri Sivonen wrote:
It's as bogus as RSS 2.0, and for much the same reason. It's
prioritising a personal dislike of some aspect of the existing spec
(which might even be a valid complaint) over the benefits of having a
widely accepted standard.
Standardisation is itself valuable, at least when it comes to web
As to why HTML 5 is bogus, rather than Hixie's attitude being bogus...
We don't need "HTML 4+1" to improve the rendering of web pages. HTML 5
doesn't even attempt to offer much here anyway.
In fact what we _really_ need is HTML 4 + CSS. 1997 is _long_ overdue!
I certainly have sympathy for the view that "HTML 4.01 is all you need,
not XHTML". However this doesn't justify HTML 5, nor is it a long-term
viewpoint. XHTML is currently problematic because of transitory issues
about browser support, not because XHTML is itself flawed. Long-term
there's also a developing value to taking the XML path.
What we do need new is something akin to XForms. "Web applications" are
the interesting part of web development at present - for static
presentation we're still barely scratching what CSS has done for years.
AJAX is hot, as are all manner of "sophisticated but still thin"
client technologies. What these happen to have in common is the use of
XmlHttpRequest or similar as a component and these _simple_,
_lightweight_ components are all based around XML, not SGML.
So if we move towards "Web 2.0" at all, it'll be through XML, not SGML,
parsing models. Yes, we're not there yet.
As to sheer unbridled bogosity, then look at the dichotomy between
HTML5 and XHTML5. If HTML5 is a "solution" to the non-problem of XHTML
being in XML, then the very last thing we need is to split the format
XHTML works. It works today, barring the trivia of SHORTTAG, and
assuming a level of developer competence that's sadly unknown outside
this newsgroup. What's broken and needs fixing is the level of
training, skill and competence out at large, not the spec itself.
If you need a way to indicate HTML/SGML or purist XML processing being
appropriate, then use content-type. That's what it's for. We don't need
a HTML5 that looks either big-endian or little-endian depending on
which way up you hold it. Yes, that's very _clever_, but it's no damn
use for anything.
Remember what happened in 2000 when XHTML Appendix-Bogus started to
appear. Now imagine what a stinking mess HTML 5 would look like, when
passed through the hands of a pack of fashion-victim clowns with
Re: HTML vs XHTML
On Thu, 13 Apr 2006, Andy Dingley wrote:
AIUI, now that SGML has the "web SGML Adaptations Annex", it is
technically feasible to write a buttoned-down DTD for something
closely resembling HTML4, which essentially permits the things which
current browsers do with valid HTML, but disallows the things which
SGML didn't previously have the ability to disallow via DTD. I'm
talking primarily about the unbundling of the various features of
SHORTTAG. (Just to be specific, I found this with google:
However, I don't expect to see such a cleaned-up HTML DTD coming from
the W3C, seeing that they put their shirts on XML.
Unfortunatly, (and on this point I think Hixie's dire warning is
correct, no matter what one's reaction to the rest of his arguments),
by the time that there will be sufficiently widespread *real* support
for XHTML, there will be a vast legacy of XHTML-flavoured tag soup to
be coped with out there, and no browser developer will be able to
resist the demands for tag soup slurpers for rendering it. Thus,
we'll be right back where we were before - with whole menageries of
heuristic fixups, and no developer *daring* to report "hey, this
so-called XHTML is preposterous, no way could one expect to render
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — The site's Newest Thread. Posted in » Secure Shell Forum