This is as days pass by, by Stuart Langridge

As overly hyped as it may be, I see XHTML as an effort to get the major browsers to return to some form of standards. The difference in feature sets between two browsers should not include differences in the way it processes the markup of a page. Every page should look the same in every browser. Ideally, every page should look the same regardless of resolution, as well. Anyway, I believe that the fear of breaking half the web because pages are coded badly is the main reason why newer browsers haven’t gone on to limiting support to XHTML only. Eventually, I see that barrier being overcome and designers/programmers being forced to get off their tail ends and code things right, which is what they should have done in the first place.

Sorry to admit that I don’t read SitePoint enough, but I have been impressed with it’s content on those occassions that I have done.

That said, this is the first I’ve heard of a DHTML book being published.

Is there a page discussing this?

My ideal of a JS/DHTML book would start with an introduction to JS’s features (such as first class functions, objs as associative arrays, and closures), and continue on to using JS to enhance pages unobtrusively, highlighting where the features of JS play especially well to this need.

Can I expect this from the mentioned book? grin

You’ve gotten really good at imagining forthcoming complaints and fending the off preemptively, haven’t you?

:)

I suggested closures because I’ve just recently seen the light on them; they can be insanely useful for allowing integrations and context where an API (which you don’t control, like the DOM eventing model) otherwise does not allow.

... So, no page for the book yet, then?

I just don’t get the whole ‘XHTML backlash’ thing. Yes, much about XHTML is over-hyped, but using HTML 4.01 introduces unnecessary inconsistencies with XML syntax, and doesn’t tie in as logically with DOM scripting.

Surely XHTML Transitional was created precisely to allow the benefits of a more modern syntax without having to face the current limitations of ‘true’ XHTML? Getting developers to modernise their skills is hugely important for quality and morale, it’s not all about purity of markup.

Using HTML harms the spread and effectiveness of web standards; using XHTML increases web standards awareness and makes for more skilled webdevelopers.

Using XHTML at the moment rarely is a case of benefitting from the increased functionality, rather, it’s about idealism and wanting Web Standards to be fully implemented in every browser, not just a few.

As long as people choose HTML over XHTML, there won’t be enough reason for Microsoft to make their next version of IE support true XHTML and have proper CSS support.

I thought that the cool webdevelopers in the blogosphere were about progress. Reverting back to and/or recommending HTML is the opposite of progress. Hell, it’s a slap in the face of true web standards enthousiasts.

Yes, you can make just as semantic a page in HTML and XHTML. But HTML has never made anyone learn about semantics in the long run, whereas XHTML does that on a daily basis.

Sil, it’s a lot more likely to happen this way, than it is when everybody still uses HTML and tables for layout.

XHTML is currently by far the best way to get web standards spread throughout the ENTIRE webdevelopment world, and not just ‘the elite’ (bloggers and enthousiasts). Until web standards get spread everywhere, Microsoft won’t have enough reason to make such radical changes to IE.

My point is mostly, HTML does absolutely nothing to spread awareness, yet XHTML does that job perfectly. CSS does a good job as well, esp. sites such as the CSS Zen Garden, but CSS won’t do it on its own (nor would XHTML, but together they’re very solid).

Additionally, XHTML forces people to improve their coding habits, something HTML does not. Web standards have a good amount of strictness to them, which require good coding habits.

First of all, I never said HTML wasn’t a web standard. I said HTML has never given people the proper incentive to educate themselves on Web Standards, unlike XHTML, which constantly makes people educate themselves.

Secondly, the only mainstream browser at the moment that doesn’t support XHTML is IE; Mozilla/Firefox, Safari, Opera, they all support it just fine, and have for quite a while.

Thirdly, the idealism-aspect isn’t the sole reason I promote XHTML. Browsers that do support XHTML will render pages much faster when it’s XHTML, compared to HTML, unless it’s a gigantic page (or unless the user is on a tragically slow dialup), and like I said, XHTML makes for better coders/webdevelopers. This aspect is highly underrated; in our company, interns don’t get a permanent job here if they’re not good (and strict) coders by the end of their internship. The ones that do have learnt most of their good coding practices from XHTML; the ones that don’t are too stuck in HTML, and, simply put, lazy about being strict. That’s something we can’t have in our high quality environment.

“The best example of real proper XHTML, done like it should be, that I know of is MozillaQuestQuest.”

That is definitely a horrible example: that page uses text/xml headers, which should not be used at all!!

Better examples:

Snelsite CMS
My own blog, the KuraFire Network
Or any other given Snelsite powered website.

Those are all true-XHTML websites, but with a text/html header for Internet Explorer. However, the sites generally work just fine on Mozilla, Opera, Safari, Konqueror, and so forth.

Your example is a site that isn’t doing XHTML properly, and is thus a rather poor example.

Faruk: I’m not sure XHTML really prompts people to learn how to build good web pages. Some people get the whole separation of content/formatting concept (whether using HTML or XHTML), but some just slap on an XHTML dtd and use global replace to stick in some extra space-slashes. Using compatible-XHTML syntax in HTML for no apparent reason seems to be gaining traction in the wider community – a sign of the confusion caused by “a little” learning imho.

I don’t buy the “XHTML will be faster” idea. As a user agent doesn’t know whether a document is well-formed until it’s rec’d the whole document, surely the loss of incremental rendering negates any marginal speed advantage gained through using a strict, potentially-simplified parser?

I understand your point about XHTML being seen as “cool” and hence helping to spread the web standards meme. However, imho people who buy in to the XHTML hype, then come to understand and dismiss the hype, face the prospect of becoming deeply disillusioned. Look at Zeldman. He was so disheartened when he realised how pointless xhtml1.x is, he started having children...

text/xml isn’t wrong, but it’s a bad idea to use it:

2 quotes from Anne, who has looked into all this much more than I have:

1) “@text/xml@ has issues and will be deprecated eventually.”

2) “It just is that text/xml has a default charset of US-ASCII and application/xml does not. (Default is UTF-8.)”

The risk with text/xml is that there is a certain ‘freedom’ in character encoding, which may end up making documents not well-formed. That risk does not exist with application/xml nor with application/xhtml+xml, hence why there is no sensible use for text/xml really.

mattur: I’m aware that there are plenty of people which basically write HTML and just stick an XHTML doctype on top, but going by 2 years of personal experience now, I can honestly say that XHTML still helps people get educated on proper webdevelopment whereas HTML simply does not. I’ve seen countless people be introduced to XHTML and wonder what was so special about it, and eventually learned all about semantics and CSS design and what not. I’ve never seen anyone go “ooh, HTML.. what’s that all about?” and proceed to learn about semantics, webstandards or any such thing.

As for speedy rendering: I can only speak from experience, but my experience is that all of our sites, which send true XHTML to browsers that accept it, render noticeably faster when sent as true XHTML, than when they get sent with a text/html header to all browsers, regardless of their Accept Header.

“I’ve never seen anyone go “ooh, HTML.. what’s that all about?””

You should have been here 10 years ago… ;)

I was here ten years ago. What I heard was “Ooooh what’s Frontpage thing… cooooool!”

10 years ago I went “ooh, HTML, making websites, cool”

10 years ago, I started on websites.

But 10 years ago, the concept of “web standards” was alien to everyone I ever asked about web-related stuff. :D

ps. the CSS of this comment field makes the text hardly legible. ‘course, the preview on the right is handy, but you may want to ‘complete’ the CSS by specifying a background color along with a text color—my background color is black, not white.

Michael: Frontpage was first released in 1997 – as you would know if you were here in 1995, you cheeky monkey.

Faruk: Unsurprising, really. The w3c wasn’t set-up until 1996, and it wasn’t really until after html4 rec. (Dec 1997) that anyone paid any attention to w3c recommendations because they were so far behind the browsers as to be irrelevant (though one of my colleagues back in 1997 did put “HTML 2” tick logos on his pages for some bizarre reason – “future compatibility” IIRC…).

I admire your enthusiasm for web standards. However, the idea that using xhtml somehow transforms a “just-make-it-work” web author into an expert in “semantic markup” is just wishful thinking.

Taking a randomly selected xhtml website as an example (cough), using div’s like #gs_container, #container, #stylewrap, #cssbuttons, #boxborder is not “semantic markup“. It’s the 2005 equivalent of tag soup – presentational divitis.

Mattur:

sure, it’s not a “definitive conclusion” or a “given fact” that using XHTML will turn anyone into a semantics-focused web expert, I’ve seen tons of people jump onboard the XHTML bandwagon and end up with something that validates as XHTML transitional, but still has no semantics.

My point is… these people are now ready and willing to learn about semantics. I see people go from XHTML Trans. with no semantics to learning why people are still complaining about their markup; lack of semantics. And I see them get into semantics and, a lot of the time, they end up becoming pretty web-savvy developers.
People that stick to HTML4 are much more likely to remain stuck with HTML4 and don’t even hear the word “semantics” anywhere. And a lot of the time, when they do hear about it, they seem to just not care about it. That’s something I don’t see nearly as much with the people using XHTML.

So that’s why I favor XHTML. People who start with it are (apparently) much more eager to get into semantics as well. In general, of course.

HTML 4.01, possibly the final version, and XHTML 1.0 both come from the origins of SGML, and the old and current browsers accept some of these language standards.

However, in the near future, the newer version of XHTML 1.1 means with newer browsers, application developers will be inclined to write code in this way because newer browsers will slowly be dropping the old standards of HTML and locking in the new standards of XHTML (although I don't believe that happening anytime soon).

Since HTML 4 and XHTML 1.0 both come from the same origins, both really are essentially the same thing, but have some differences. HTML was designed for the limited hardware and platforms of the past, whereas XHTML is simply an upgrade of HTML 4 that provides access to the latest of hardwares and platforms such as PDAs and cell phones.

There are some differences in syntax of the two. For instance, when encoding markup languages, they begin with tags and end with tags. This works well when identifying simple HTML because it is HTML. XHTML, however, depending on the version you are using, must be identified as strict, transitional, or frame set in conjunction with the beginning and ending of HTML tags. But that makes sense. Everyone is given a name to identify who they are, and we can even associate them with their interests.

There are some do's and don'ts with XHTML and HTML. XHML language tags require a beginning tag and an ending tag. However, HTML authors can get away without writing a few ending tags. HTML line break tags such as don't require an end tag of , and in the old browsers, authors of HTML can leave out the paragraph end tags such as , but not in the new browsers. Therefore, it is probably a good idea to stay in the habit of writing codes with beginning and end tags to prepare for XHTML; since the W3C also advocates good form, placing beginning and end tags makes for better organization, reading, and relocating a particular area later and prepares for getting used to XHTML code.

Although XHTML is far stricter than HTML when encoding, in the end, XHTML will be far easier to remember and code because XHTML is written systematically. For example, nested tags within each other are written in chronological order. If you have you must end with , writers cannot do I have something to emphasize in italics . Rather, it must be I have something to emphasize in italics (O'Reilly, 2002).