Judging by the latest SitePoint Tech Times, it seems Stuart Langridge has won the argument (my emphasis):
The case for avoiding XHTML was pointed out to me by the author of SitePoint’s upcoming DHTML book, as I tut-tutted his use of HTML (as opposed to XHTML) for the book’s sample code.
SitePoint’s DHTML book will be published with HTML.
Stuart’s argument is simple. In order to benefit from the extensibility of XHTML – the XMLness that allows you include other languages like MathML – the document needs to be served with a MIME type of application/xhtml+xml. But the most popular browser on Earth, Internet Explorer 6, can only render web pages served with a MIME type of text/html, so you might as well just use HTML as most of the time you won’t get any of the benefits of XHTML anyway.
Sure you can configure your servers to send IE6 a MIME type of text/html while everyone else gets application/xhtml+xml, but what’s the point of writing XHTML in the first place? It’s an argument that’s been doing the rounds for some time and I think there’s some valid reasoning there. That said I’m not about to recast Clagnut or Multimap back to HTML.
And why are they insisting on calling it a DHTML book? I am assured the subtitle will include a nod to DOM Scripting, but still. I’m concerned about the stigma attached to the term DHTML – all that browser-specific code branching, falling snowflakes and flying gifs, which is not what this book will be about at all (my understanding is that it will be much more practical). I suppose the thinking is that the general site building public, professional or otherwise, will have a better idea of what DHTML means than DOM Scripting. Shame though.
DOM | JavaScript · Mark-up techniques
Anup wrote:
One advantage of XHTML being XML is that you can use XSL to transform it if you need to.
If you are using server side technology to produce HTML (maybe also from XML/XSL) then that might not be a big issue. But if you are producing (or generating) static HTML files, which you may want to repackage or change later XSL can be useful on an XHTML doc.
Sure, some changes to (X)HTML like this might sound like bad initial design, but then, there is also the real world to consider ;)
I found creating Eric Meyer’s slide show thing in XHTML was very useful. With XSL I could extract some of my slides for different purposes by simply adding extra classes in the class attribute and have an XSL pick out the slides I need. This was a valid way of doing things, because the slides can be packaged and deployed to people who run it locally and don’t have a web server at hand.
James wrote:
Granted we can’t really reap XHTML’s benefits such as the ones you mentioned on a large scale because IE doesn’t support it when served as XML.
But if we all gave up and went back to using HTML 4 then Microsoft would definitely not bother to add proper XHTML support to IE.
If, however, we carry on promoting XHTML and making people aware of its potential benefits we may just create enough demand for MS to notice and take action.
It’s not like using XHTML causes us any inconvenience in the mean time. I certainly can’t see any good reason not to use it. I don’t think anyone can argue that adding a closing tag here and there is somehow more complicated than old-skool HTML. Personally, I actually find XHTML easier to read because you have clear indication of where elements begin and end.
Just my 2
Stuart Langridge wrote:
I never have a problem with knowing where my elements end in HTML 4.01, because I close them. Just because it isn’t obligatory to close elements like <p> doesn’t mean that you can’t vlose them if you want to. The only elements that don’t get a close tag are empty elements, and most people don’t “close” them in XHTML either: they put <element /> rather than <element></element>.
As regards the “transform with XSL” thing, I’ll solve that pretty easily the day I decide to move to XHTML by throwing all my HTML code through HTML Tidy; since it’s all valid HTML 4.01 Strict, Tidy will find it easy to tidy it into XHTML.
Just say no to XHTML!
Chris wrote:
>But if we all gave up and went back to using HTML
>4 then Microsoft would definitely not bother to
>add proper XHTML support to IE.
Exactly!
paul haine wrote:
“I never have a problem with knowing where my elements end in HTML 4.01, because I close them. Just because it isn’t obligatory to close elements like <p> doesn’t mean that you can’t close them if you want to.”
Sure, but writing xhtml and validating against an xhtml doctype makes it easier, because the validator then helpfully points out your unclosed elements for you, and the same goes for unquoted attributes. There’s a difference between “closing them if I want to” and “closing them because I have to” – I personally prefer the latter. That said, I don’t really care either way whether people are writing xhtml or html, so long as it’s valid and well-written.
Anup wrote:
Re: “As regards the transform with XSL thing, Ill solve that pretty easily the day I decide to move to XHTML by throwing all my HTML code through HTML Tidy; since its all valid HTML 4.01 Strict, Tidy will find it easy to tidy it into XHTML.
Just say no to XHTML!”
No, you missed my point – I was simply saying that in such situations where you needed to change the XHTML or HTML to be different throughout the site, and you only had static (X)HTML pages, it is easier to use XML-based tools and technologies to convert one XML document to another XML document than to write stuff to parse HTML. Unless you mean to use HTML Tidy to convert to XHTML and then convert that using XSL? That would seem like extra effort to me if you can get it up front, though would still work.
FInally, another point is that for XHTML 1.0, the application/xhtml+xml mime type is optional according to the standards. It is admittedly unfortunate that it is optional for we do miss out on the benefits of being the xhtml+xml mime type, but that is what the spec says at this point…
Michael Havard wrote:
Look, it’s the same with any new technology/standard. The EARLY EARLY adopters are going to overhype it and talk about how it’s the best thing since the discovery of gravity. That’s going to set some other people, the early adopters, to looking into the technology. Those early adopters will then become the reasonable advocates for the practical benefits of the technology and encourage average people to get into the mix.
Then you’ll have a group of people who hate the hype that the EARLY EARLY adopters created and they’ll partner with the group of people who don’t understand why anyone would want to replace the 8-track. Then it just turns into a shouting match between the advocates and the anti-advocates.
One of the points of XHTML is to be a jumping off point to get people into XML. Not only that but it’s also meant to spur companies into action, getting them to produce tools that will not only handle XHTML but also handle XML (why build two tools when you can build one) while still supporting the older standards like HTML 4.01.
Without someone using the technology (without a lot of someone’s) companies will simply dismiss it as a fad and continue to do little or nothing (IE 7 – security patches). If there is no pressure from consumers/developers then there are no market forces for the companies to react to.
There is a place for XHTML regardless of the petty mime-type argument. If you find a place for it in your site GREAT! If you think other people might be able to make the same use then by all means be an advocate. If you can’t find a use for XHTML, GREAT! Don’t be an advocate. But don’t yell at the masses and name call and tell everyone how XHTML is considered harmful or “you’re not really using XHTML because… ” blah blah blah blah. Don’t be an anti-advocate.
I know “but HTML 4.01 can do all the things that XHTML claims to do” Can it be sent as mime-type XML? Use it or don’t. Listen to your 8-track, or hop on the next Sony proprietary music format, or find a nice middle ground.
Another James wrote:
I see this:
And this:
And I can’t help wondering: have you guys never heard of SGML tools? You can do validation, transforms, anything you want basically, using existing and well-known tools. I do this all the time with DocBook documents, for example.
Michael Havard wrote:
When people think of “easy” they don’t typically think of SGML. It might be that SGML tools are just as easy to use as XML tools. Unfortunately most of the commentary around XML describes XML as essentially “SGML extra light” and talk about the learning curve involved in learning SGML. The goal of XHTML/XML is to be human readable and reduce complexity so that average authors can create/manage content and data. There’s been no discussion that I’ve seen regarding average users learning how to use SGML tools. Even with “knowledgeable” developers if the XML parser/validator isn’t built into an IDE they’re unlikely to know what to do (i.e. using SAXON/XALAN/MSXML from the command line). It’s as much a matter of effort as it is a matter of knowledge.
zedzdead wrote:
Just do your best. That’s what my mum told me. That’s what I tell my kids – Just do your best.
Eric Meyer wrote:
“I found creating Eric Meyers slide show thing in XHTML was very useful.”
Well, it starts life as XHTML, so that’s cool. However, my experience is that there’s almost no difference between XHTML and HTML when you pour them through XSLT. If the document is well-formed, the transform will succeed; if not, then it will fail. Nothing about XHTML makes it more amenable to transformation than HTML- again, assuming well-formed documents.
Olly wrote:
You know why I prefer XHMTL? Its not for some religious technobollocks reason.
Its because its tidier. Its all lower case. All of the tags are closed. This adds up to making it easier on my eye (and easier to sopt whenI’ve forgotten to close something!).
And its the latest and greatest thing, obviously ;-)
Jeff Croft wrote:
I prefer to write XHTML because it’s a bit cleaner and nearer of a language overall. That, and the simple fact that i expect one day we <em>will</em> be serving up XHTMl documents as application/xhtml+xml and at that point, I’ll have less “conversion” to do because my documents will already be well-formed XHTML.
At this point, it really doesn’t matter. Unless you’re a stickler for doing things “right” (Hello, Anne! :), or you are going to serve as application/xhtml+xml and say “screw you” to IE, then it really doesn’t matter. There’s really not a great benefit to either one.
John wrote:
Eric Meyer wrote: “Nothing about XHTML makes it more amenable to transformation than HTMLagain, assuming well-formed documents.”
Actually, because with HTML you can have non-well formed elements (in an XML sense) and still be valid, then that does make XHTML slightly more amenable to transformation.
XHTML is meant to be strictly XML-based (although you have funny things like some tags cannot be closed using short hand notation) so it is therefore a tiny bit more amenable to XSL. Especially if you extend that XHTML to include other xml documents using namespaces etc, then XSL can be used with more options and flexibility.
This is all going a bit round about though. The first guy to comment had an interesting use for XHTML, although HTML is also still a valid standard. Eric seems right that if you do have well formed html, then his slides can be written in either.
Not sure why everyone still gets hung up on this. You can use both, according to the specs, today.
Someone else had interesting point that one reason to use it may not be technical: it just gets everyone thinking about and pushing towards XML. Adding vocabulary from other namespaces is going to be quite powerful once (if???) all the major browsers support it properly.
David wrote:
If we avoid using xhtml because IE doesnt “support” it then we’re giving in to Microsoft and IE. I say we design using xhtml and let IE catch up.
Faruk Ates wrote:
It’s very simple to me: HTML is forgiving and gives you no incentive to be a good programmer nor to know what you are doing, XHTML is not forgiving and demands that you do your job properly.
Human laziness is not to be underestimated, especially since whatever YOU write will likely be used as an example to 20 to 2000 other webdevelopers, and if they all work off of a mediocre example, well.. you can do the maths. :)
P.S. you still need to fix your form field CSS. I can’t read my own comment unless I highlight it, because you forgot to specify color:#000; on the input, textarea, select { ... } :)
Rich wrote:
What rot! HTML is no less forgiving than XHTML, it just has a slightly different set off rules. HTML is a not XHTML for lazy people – HTML takes as much time and care to write and validate as does XHTML.
Hayo Bethlehem wrote:
HTML doesn’t require you to close elements. Thus it is more forgiving.
Faruk Ates wrote:
bq.What rot! HTML is no less forgiving than XHTML, it just has a slightly different set off rules. HTML is a not XHTML for lazy people HTML takes as much time and care to write and validate as does XHTML.
Utter and complete nonsense. HTML most definitely is more forgiving (and less strict) than XHTML. You can omit head, body and html tags in HTML, which you cannot do in XHTML. You can omit ending tags in HTML, which you cannot in XHTML. You can use poorly encoded characters and entities in HTML, which you cannot in XHTML.
HTML is very much NOT strict; it’s not just “a different set of rules”. HTML allows one to be a completely horrible webdeveloper and get away with it, and no one can blame you for it, because HTML is that forgiving. But with XHTML, if you’re a horrible webdeveloper, you will get your ass kicked by a) proper browsers, b) the good webdevelopers, and c) yourself (eventually).
It’s complete bullshit (pardon my language) to say that HTML is no less forgiving than XHTML, and you should’ve known that.
Rich wrote:
Everything you have written there is incorrect, with one exception: ‘you can omit ending tags in HTML’.
Try validating an HTML document with a
headelement missing. Try validating an HTML document with incorrectly encoded entities. You can’t. Just because a browser will still try to render it does not make HTML more forgiving. Invalid HTML is not HTML by definition. Incidentally, anyone who thinks that browsers choking on badly formed XHTML is a good thing can think again.And just because XHTML requires you to close all it tags does not in someway make it superior. There is absolutely nothing wrong with coding valid HTML, nor will there ever be.
Faruk Ates wrote:
I’m sorry Rich, but you will have to eat your words and acknowledge the fact that you don’t know the first thing about HTML, really:
http://validator.w3.org/check?outline=1&uri=http://limpid.nl/
No HTML tags, no HEAD tags, no BODY tags, yet perfectly valid HTML 4.01 STRICT. Please stop embarrassing yourself any further. :)
Ooh, but I see you fixed your CSS for form fields, great, thanks :)
Rich wrote:
Nothing like a bit of insult, hyperbole and slander to endear oneself, is there?
Astonishingly you are correct. In HTML 4 the
head,bodyandhtmlelements are indeed all optional.Faruk Ates wrote:
Sorry for the insult, but I get a bit rough when people say I’m lying when I’m looking at the proof of my claims at the very same moment…
Also, I was really shocked to see someone who blogs on web standards not know how lenient HTML was. In my state of shock I was more insulting than I’d meant to, for which I apologize.
Rich wrote:
Not as shocked as I was to see that
bodytags, etc are optional. I guess I’d forgotten that because I’d never consider not using one.It’s wise not to forget that the low barrier to entry of HTML is what made the Web take off in the way it did. That’s not to excuse invalid code though,
bodytags or nobodytags.Faruk Ates wrote:
Yeah, but as much as HTML’s lenience made the web great, it also made it crap. HTML isn’t going to change that, but XHTML (combined with CSS) has the power to do exactly that.
HTML’s lenience allowed Joe Clueless to make websites, and that’s a big shame in several ways, because that is why most the web is so unsemantic and ‘filthy’ as it is. Web Standards help clean it up, and XHTML helps make Web Standards be used across the globe; HTML has not, and will not, aid in that.
Rich wrote:
There’s a fundamental point here on we’ll have to agree to disagree. HTML is a Web Standard and as such, you will never convince me that valid HTML should ever be considered ‘filthy’. And XHTML (Strict or otherwise) does not guarantee or even imply that code will be semantic, structured or meaningful in any way. In fact, combining mark-up with CSS makes it all to easy to write
<div class="mainheading">.This is a matter that only education can correct, not choice of mark-up language.
Faruk Ates wrote:
HTML’s problem is that it almost invites you to make ‘filthy’ markup, and as a result (as evidenced by the current internet) people have chosen to be ‘filthy’ because it’s easier.
I agree that neither XHTML nor HTML are more semantic than the other, what I’m saying, however, is that XHTML has made thousands upon thousands of people look into semantics and educate themselves in webstandards, whereas HTML simply has not done that at all.
Dougal Campbell wrote:
Ahhhh, screw it all.
I’m going back to tag soup and <blink> tags. I miss the old days.
Rich wrote:
Ah, you can try Dougal but I’ll just do this to you:
blink {text-decoration:none}Yo wrote:
Obviously the fact that you are burying yourself and the rest of us in the year 1995 for the next half decade doesn’t bother you.
You are the only pressure these companies have to produce quality products. Or do you have something against quality products?
Rich wrote:
Yo – enough with the flaming. Please keep your comments civil and constructive.
And while you’re at it you might like to explain how proposing use of valid HTML is somehow stuck in 1995.
Faruk Ates wrote:
Rich: because it is. See also JeroenMulder.com or my articles / posts on XHTML.
Using XHTML is currently the only one (of HTML and XHTML) that aids the process of spreading web standards, whereas HTML is making the opposite happen. Every new HTML site is a thorn in the Web Standards Supporter’s eye.
p.s. your CSS file seems to be reverted or something; the form fields CSS is without color: again :/
Rich wrote:
A calm voice makes the point that I believe Faruk et al are driving at:
The argument seems to be that newbies should learn to write their web pages using XHTML because that way they learn to code to more rigid rules. That’s fine and entirely commendable – it forces folks to learn to close tags and so on. Of course it goes nowhere to ensuring what I’d call good mark-up: meaningful and structured; semantic if you must.
But for people who already code well, I still say that XHTML does not really represent any great advantages over HTML as things stand. That’s not a reason not to use XHTML (after all this entire site is written in XHTML) but neither is it a reason to castigate those who use HTML in preference to XHTML (you might like ask Eric Meyer why Meyerweb is written in HTML).
Faruk Ates wrote:
I know why Eric Meyer made meyerweb in HTML, but he’s one of the few who actually uses HTML 4 for his own weblog, by choice.
“Of course it goes nowhere to ensuring what Id call good mark-up: meaningful and structured; semantic if you must.”
That’s a mistake to assume, though. People who learn XHTML are far more likely to also learn about semantics and the like than people who learn HTML. This isn’t some “assumption” or “theory” I have here, it’s an analysis from seeing it happen time and time again. The moment people start getting into XHTML and looking up stuff about it online is the moment they also invariably get introduced to the Semantic Web. People who learn HTML are unlikely to have that happen to them, because 99.9% of all websites that talk about and teach HTML are living in 1996.
I’ve never had anyone come up to me and go “hey, I’m learning HTML, but I saw this guy talk about …semantics? and what’s this CSS layout stuff about?”
I can’t even begin to count the amount of people that came up to me (and still do) going “hey, I was looking into XHTML and it’s pretty neat.. what’s that semantics stuff about that all those bloggers are talking about, though? and where can I find some good CSS tutorials for making layouts?”
Plus, as you said, it’s good when people become proper, strict coders. Not only on its own, but also because such people are more likely to actually CARE about semantics once they’re introduced to them, rather than go “eh, semantics.. shrug whatever” – which is exactly the thing I’ve seen HTML-people say. (and yes, that did infuriate me, and yes, they learned not to say such things around me again ;))
DarkCryst wrote:
the think most people forget is that valid XHTML 1.0 is also valid HTML 4!
There is no reason NOT to code in XHTML unless you have an huge need to code tag soup. So what if it is served as HTML? It doesn’t matter – you are making your life easier by coding to XHTML as it is more transferable.
there is a fundemental difference between how content is served and how it is written… Stuart seems to misunderstand this relationship.
Rich wrote:
This is a complete fallacy (assuming your definition of ‘tag soup’ is font tags and tables for layout, or even heaps of divs and classes). HTML does not imply tag soup any more than XHTML implies a lack of tag soup. How can it possibly, when XHTML 1.0 is simply a reformulation of HTML 4.01 in XML? You said it yourself: “valid XHTML 1.0 is also valid HTML 4”.
If you believe that learning and coding in XHTML engenders a philosophy of meaningful, structured mark-up then fine, you may well be right, but that is an entirely different argument. It remains untrue to say that coding as XHTML inherently means your code will be ‘semantic’ and it is equally untrue to say that coding as HTML forces tag soup upon the author.
Consider this non-semantic yet valid XHTML Strict document (I refrained from demonstrating a true tag soupy XHTML Transitional document complete with font tags):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<title>XHTML tag soup</title>
</head>
<body>
<div class="bigheading">This is the page heading</div>
<div>This is supposed to be the first paragraph.
<br /><br />
And this is the second paragraph.</div>
</body>
</html>
And compare with this semantic HTML document:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"><html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<title>Semantic HTML</title>
</head>
<body>
<h1>This is the page heading</h1>
<p>This is supposed to be the first paragraph.</p>
<p>And this is the second paragraph.</p>
</body>
</html>
Jeroen Mulder wrote:
An important part of XHTML (as opposed to HTML) shares the same essence with the way we build websites nowadays. Seperating presentation from structure. I truly believe this is a key element everyone needs to get in his head, if we wish for them to write semantic markup and build CSS based layouts.
This seperation is tangible, whereas semantic markup is far less tangible and for new people they can’t even begin to imagine how a CSS baed layout looks like (code-wise). The seperation on the other hand is the most tangible aspect, considering it starts right at markup-level – a level they are already familiar with (HTML4). The transition from HTML to XHTML might be meaningless for us, but for them it will be the start of learning aspects such as semantic markup, accessibility and CSS. Why? Well, simply because the current ‘standard’ when writing about these aspects is to include XHTML, if needed, not HTML4. Furthermore, we have a validator to slap your wrists if needed. Even though this is not on the same level of semantics we discuss, it starts at banning the B and I elements. In my experience, the example of the B and I elements is a perfect example to illustrate what today’s web design is about.
Rich, people like you, Dan from Simplebits, Stuart, Doug from Stopdesign, Zeldman and many more fullfill an example role. Some weeks ago Molly Holzschlag published an article ( http://www.informit.com/articles/printerfriendly.asp?p=369225 ) where she mentions the quote: “Do what I say, not what I do.” Perhaps it’s deceiving, but what else can we do?
I think it’s safe to say XHTML plays an important role in advocating web standards, as well as semantic, accessibility and all those other aspects that have been neglected for so long. At the very least we might build our personal sites using XHTML, yet build our projects using HTML. Newbies (if you like that word) need a low level of entry to enter this whole new side of webdesign and I truly believe XHTML is that door for them. It’s the door that allows them to suck up a whole ton of information allowing them to form their own opinion.
Mind you, XHTML is only a part of a wide range of aspects. CSS is becoming a hot item as well, but fairly complex for the new user. Semantics is a buzz-word for designers who are with one foot on our side, but semantics on its own is still a tough subject, as Dan Cederholm’s SimpleQuiz sometimes shows.
To shortly respond to the original entry, writing XHTML and serving it as text/html now is a whole lot more forward-compatible than writing HTML, when the time arrives when we want to switch to application/xhtml+xml. Sure, we can use Tidy, but not everyone has access to it. Furthermore, the extremely ancient, crappy, draconian (whatever you like to call it), XML error handling requires authors to be familiar with XHTML when the switch arrives. Serving XHTML as text/html could serve as a sandbox for them.
Perhaps not everything is right in detail, but looking at the bigger picture, we’re advancing in terms of the use of web standards. XHTML is adding a great deal to that.
(wow, this got long).
Michael Havard wrote:
Let’s just point out a fact that we here, debating this issue, are not the “average” web developers. The average web developer is oblivious to the standards and best practices for that matter. They’re creating web pages using some tool like Frontpage/Websphere/Word/Dreamweaver/etc. They may also be using some template system based on JSP/Struts/PHP. In any case the web content that they create adheres to the standards only as much as the tools they used to create the content.
Trying to explain the differences between HTML 2.0/3.2/4.01 and XHTML 1.0, well formedness, tag soup, presentation and structure, etc. to the average web developer will get you nothing but a glassy eyed stare. They don’t care, they don’t even care to care. What they know is that the content they create appears in the browser the way they want it to.
These tool oriented developers are hard to turn towards using standards while new developers might be slightly easier because they aren’t yet set in their ways. If knowledgeable and careful web developers promote a standard that integrates important best practices and well formedness and promotes that standard to new developers it may generate enough influence on the tool manufacturers to update the tools. If the tools are updated content won’t be perfect but it may be significantly less imperfect and more easily cleaned up in later stages of development.
Here’s an apples to apples comparison of the type of real content that’s being created out there right now:
You very often get something like this – (which is supposedly <!doctype html public “-//W3C//DTD HTML 3.2//EN”> invalid, no semantics)
<title>Product Descriptions</title>
<i><font size=”7” face=”tahoma” color=”purple”>Product Descriptions</i><p><b><b>
<p><span lang=”en-us”><font size=”2” color=”black”>This page contains descriptions of all of our current products.
<!- some more crap here //->
While you’d love to get this (valid and semantic):
<?xml version=”1.0”?>
<head> <title> Product Descriptions </title> <link rel=”stylesheet” type=”text/css” src=”css/general.css” /> </head> <body> <h1>Product Descriptions</h1> <p class=”summary”> This page contains descriptions of all of our current products. <!- some more crap here //-> </p> </body><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
</html>
Wouldn’t it be okay if you at least got this (valid):
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”><html xmlns=”http://www.w3.org/1999/xhtml”> <head> <title> Product Descriptions </title>
<style type=”text/css”> p.c1 {font-style: italic; font-size: 300%; font-weight: bold; color: purple; font-family: tahoma;} p.c2 {font-weight: bold; font-family: tahoma;font-size: 80%;}
</style> </head> <body> <p class=”c1”> <i>Product Descriptions</i> </p> <p class=”c2”> <span lang=”en-us”>This page contains descriptions of all of our current products.</span> <!- some more crap here //-> </p> </body>
</html>
I’m happy if there are developers out there that can create well formed semantic HTML 4.01 standard code. It’s not their content I worry about.
Ben wrote:
Myths about web standards and valid code
This article summarises quite nicely why you should use xhtml – to satisfy trolls on forums.
There are very few advantages other than being able to dwell peacefully on a forum without having a mob trying to hang you from a street post.