Kevin Yank, in the latest Sitepoint Tech Times, writes that SitePoint’s DHTML book will be published with HTML after some evangelism by the author of said book. Since said book is my book, and said author is me, I’ll note that I was really pleased that Kevin was open to discussion on this point. As he said, he tut-tutted my use of HTML 4.01 in the book rather than XHTML, and I responded (probably more forcefully than I should have) with my view that XHTML is a pointless and overhyped waste of time and energy at this point. Kevin, to his credit, took those views on board; he himself says that he’ll stick with XHTML for his own projects, but that the book will use HTML 4.01. Large kudos to him for not being taken in by the XHTML community’s hype on this!
(Cheers to Richard Rutter for alerting me to this.)
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.
Posted by Matthew Turland on February 21st, 2005.
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
Posted by Jeremy Dunck on February 21st, 2005.
Jeremy: pretty much yes you can :)
Posted by sil on February 21st, 2005.
Matthew: hm. I’d like to believe that we can encourage people to “get off their tail ends and code things right“, but it’s just not gonna happen. People won’t code things right until they have to, and they wno’t ever have to because there won’t be a browser with significant market share that only renders correct pages, and there won’t be such a browser because no-one will use a browser that only renders 1% of the web.
The key point is that XHTML isn’t “HTML that is also, usefully, XML“; it’s XML that is also mostly XHTML. A whole load of new requirements come along with XML that did not apply to HTML (because it was a lot more lax). For more on these, see Mark Pilgrim passim, particularly all the bits where he talks about the necessity for lax parsing (because people don’t get XML right).
There are a lot of complex requirements for XML —well-formedness, content-types, Unicode—which people don’t use and basically don’t understand, and I really don’t think we’re ever going to get over that hurdle.
Posted by sil on February 21st, 2005.
Jeremy: well, thinking about it, it doesn’t go into closures too much, because they are way too hard. Yes, they’re great, and yes, I use them, but you don’t have to care about them unless you’re pretty advanced. When I write “Advanced DOM scripting” then I’ll go into detail about them :)
Posted by sil on February 21st, 2005.
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?
Posted by Jeremy Dunck on February 21st, 2005.
Jeremy: the problem is seeing the light. Closures are brilliant once you’ve seen the light. Unfortunately, they’re totally bloody incomprehensible before that point, and I have not ever, not once, seen any description that enables people to see the light from that description. It’s just through a process of fiddling around until one day you reach enlightenment. Maybe there is someone out there who can write the brilliant explanation which will enable mortals to grok closures on first reading, but I don’t think I’m that person :)
Posted by sil on February 21st, 2005.
Oh, and on a page for the book: O‘Reilly have one although I wouldn’t pay too much attention to the “full description” if I were you.
Posted by sil on February 21st, 2005.
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.
Posted by Matt Round on February 22nd, 2005.
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.
Posted by Faruk Ates on February 23rd, 2005.
Faruk: if developers using XHTML will make Microsoft implement decent XHTML support for IE, then developers using CSS will make Microsoft implement decent CSS support for IE, yes? Is this likely to happen?
Posted by sil on February 23rd, 2005.
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.
Posted by Faruk Ates on February 23rd, 2005.
Faruk: allow me to applaud your enthusiasm while simultaneously deploring your idealism. If the best argument we have for XHTML is “it’ll make people use web standards“, then, well, that’s not enough of a reason. HTML 4.01 Strict is a “web standard“. It’s a documented and released W3C spec. It is just as capable of being invalid as XHTML is. More to the point, no-one else is bothering to handle XHTML properly either; as far as I’m aware, the only browser which will properly handle a properly-served XHTML document is Mozilla. Everything else will interpret it as XML and display it as such. Even then, I’m unclear that Mozilla even does the right thing on all occasions. More to the point, people in general will not shift to using XHTML just when there is frankly no benefit to them from doing so. If you want browsers to support the standards, then lobby the browser makers to do so, certainly, but suggesting that we switch to the less useful and more difficult XHTML simply as a sneaky undercover way to usher in a new world of standards compliance is cutting off one’s nose to spite one’s face, I think.
Posted by sil on February 23rd, 2005.
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.
Posted by Faruk Ates on February 23rd, 2005.
Ahem. I said XHTML served properly. Not served with type text/html, for example. The best example of real proper XHTML, done like it should be, that I know of is MozillaQuestQuest. So let’s try some screen captures, courtesy of BrowserCam’s free trial account.
As you can see from the screen captures the XHTML support in browsers isn’t particularly good. I’ve tried to pick a reasonable selection; I know IE doesn’t support it (and I threw one in to demonstrate the point, with it showing a DOM tree (!)), but you’ll notice that only Netscape 7.0 is showing that page correctly. Opera 6 and 7, Safari, all fail to render the page properly; styles are lost. Konqueror fails as well, but you’ll have to take my word for that because I forgot to grab the screenshot.
When you speak of “browsers that do support XHTML“, it’s difficult to know what “support” means in this context. Proper “support” means being an XML user agent, not an HTML user agent. Mozilla is that, sort of. The others…I don’t know.
Posted by sil on February 23rd, 2005.
“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/xmlheaders, 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/htmlheader 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.
Posted by Faruk Ates on February 23rd, 2005.
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…
Posted by mattur on February 23rd, 2005.
Ahem. Any XHTML Family document MAY be served as text/xml.
One SHOULD use application/xhtml+xml, but text/xml isn’t wrong.
Posted by sil on February 24th, 2005.
text/xmlisn’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/xmlhas a default charset of US-ASCII andapplication/xmldoes not. (Default is UTF-8.)”The risk with
text/xmlis that there is a certain ‘freedom’ in character encoding, which may end up making documents not well-formed. That risk does not exist withapplication/xmlnor withapplication/xhtml+xml, hence why there is no sensible use fortext/xmlreally.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/htmlheader to all browsers, regardless of their Accept Header.Posted by Faruk Ates on February 24th, 2005.
“I’ve never seen anyone go “ooh, HTML.. what’s that all about?””
You should have been here 10 years ago… ;)
Posted by mattur on February 24th, 2005.
I was here ten years ago. What I heard was “Ooooh what’s Frontpage thing… cooooool!”
Posted by Michael Havard on February 24th, 2005.
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.
Posted by Faruk Ates on February 26th, 2005.
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.
Posted by mattur on March 9th, 2005.
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.
Posted by Faruk Ates on March 18th, 2005.
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).
Posted by Mario on October 5th, 2006.