Why You Should Use XHTML
Da_Slayer writes "The w3's HTML group has released the 6th public working draft for XHTML 2.0. XHTML 2 is a general-purpose markup language designed for representing documents for a wide range of purposes across the Web. Meaning it is to be used for document structuring which is why it does not have presentation elements. The draft is located at w3's website. Also they have a FAQ about why you should use XHTML over HTML. It goes into specifics about embedding MathML, SVG, etc... and has links to tools and resources to help convert existing html documents to xhtml. One of those resources is a document on XML events and its advantages over the onclick style of event handling."
You have to wonder if Microsoft will be implimenting this new standard in IE. I have done some webdevelopment and have really noticed that they rarely impliment any of the standards in there browser. Not to mention that they are on the board that approves these standards :P
anyone else amused that this article was posted on slashdot? a site who's HTML is so bad they've blocked validator? I'm amused.
I post links to stuff here
Which browsers accept the media type application/xhtml+xml? Browsers known to us include all Mozilla-based browsers, such as Mozilla, Netscape 5 and higher, Galeon and Firefox, as well as Opera, Amaya, Camino, Chimera, DocZilla, iCab, Safari, and all browsers on mobile phones that accept WAP2. In fact, any modern browser. Most accept XHTML documents as application/xml as well. See the XHTML Media-type test for details. Does Microsoft Internet Explorer accept the media type application/xhtml+xml? No.
M$ Lawyer: But `gcc
I've been using XHTML for some time, but only in the modes that safely fall back to HTML for browsers that don't "speak" XHTML.
I have to wonder if 2.0 is going to catch on. Internet Explorer isn't likely to support it any time soon, and nobody wants to code two versions of every web application.
Still, good FAQ on that site. I learned some details that had been hazy.
With all the time we spend hearing about alternatives to IE around here, you would think that slashdot would be compliant to at least some W3C standard. If /. were some tiny hobby weblog this would be forgivable, but /. could use the size of it's audience to actually lead. Why not do it?
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
XHTML 2.0 almost forces you to seperate "content" from "presentation". Which is a good thing.
Something better would be to use pure XML for creating content and then let the browser apply a CSS to present the content.
See Mozilla + CSS + XML = Structured + Formatted Content for more info.
Consensus is good, but informed dictatorship is better
XML is a metalanguage; that is, it's a mark-up language for writing other mark-up languages. XHTML is one such language. It's basically plain old HTML but with XML's stricter rules. I like it because it discourages sloppy coding (sort of like preferring Java over Perl).
Other XML languages include SVG (for vector graphics), WML (for simple web pages designed for cell phones; never really took off), and RSS (for news feeds).
XML is a pretty generic set of format rules. There are LOTS of various formats that are implemented in XML (SVG, XHTML, XSLT for some popular examples).
:)).
XHTML applies the rules of XML to HTML. For instance you can have one root node, you have to close all tags, attributes have to have single or double quotes around their values, etc.
Writing something that parses XHTML is a LOT simpler than writing something that parses HTML. It's also easier to confirm you've written it properly (using schemas for instance, which are also written in XML
Get your own free personal location tracker
Good answer ;-)
The grandparent might also interested in the following:
XHTML is implemented in XML. So XHTML is to XML as OpenOffice.org's writer format is to XML. (Or as HTML is to SGML, or as this post is to English.)
People often say somthing is XML when it is really implemented in XML. Using that (misleading) terminology XHTML is XML.
-Peter
Meaning it is to be used for document structuring which is why it does not have presentation elements.
That's what they said about HTML in 1992. Look what happened to it when it got popular: bastardized so badly with presentation elements that it lost almost all of its structuring features. Remember <fig>? It was obsoleted before it even made it out of draft status because commercial browser vendors (*cough* Netscape *cough*) pushed <img align> on everyone instead, because it was quick and easy. That's just one example. Who's to say this new XHTML won't be spoiled the same way? We could say "Use HTML if precise control over layout is needed" but back in the HTML days, we were saying "use PDF if precise control is needed" and we were ignored, and HTML was destroyed so badly that XHTML is now needed to fill the role HTML had to abandon.
What's to prevent lather/rinse/repeat?
Edith Keeler Must Die
You guys are both essentially complaining about the speed of XSLT transforms. While XHTML makes "HTML" a valid XSLT target target document (in other words, it makes HTML XML compliant), nobody is forcing you to use XSLT.
XHTML is still completely valid on its own. It's a HELL of a lot easier to validate for one thing. Ever looked at the sourcecode to HTML validators?
I think that so long as the WYSIWYG community keeps implementing these standards into their applications, web developers will follow suit. The latest version of Dreamweaver codes excellent XHTML and almost forces designers/developers to use CSS to incorperate presentation elements out of the box. For those who code 100% manually XHTML is an easy thing to tackle. The big issue it seems is that, like many web developers out there, I am getting quite sick of the frustration in multiple browser support. While it may be the most popular browser, IE is quite possibly one of the worst for supporting standards. I don't mind Microsoft trying to develop their own web standards so long as they are 'implementable' in other browsers/systems, but that never happens.
-- Bored? Check out my Portfolio
The only version of XHTML that is suitable for transmission as text/html is XHTML 1.0 following Appendix C. XHTML transmitted in this fashion doesn't have any of the benefits of mixed namespaces, stricter parsing, etc.
You get these benefits when you serve XHTML as application/xhtml+xml, and your visitors use browsers that support those features (such visitors are extremely rare - SVG isn't even in main Mozilla builds yet). But many legacy user-agents require text/html. Search engines would probably be the most important ones.
So unless you are willing to set up content-negotiation, sending different document types to different browsers, and unless you have a niche market that use browsers that understand these new features, you really aren't going to get anything from XHTML. Not for a few years, anyway.
I would argue learning XHTML is easier than HTML since the rules are a LOT more straightforward.
Also they have a FAQ about why you should use XHTML over HTML.
Meaning it is to be used for document structuring which is why it does not have presentation elements.
What! No <blink> tag?? No
No way I using it!11!1 I'm a serious web designer!
(This comment looks best at 717x913 resolution, using Internet Explorer for the security holes and that essential <marquee> tag. Page designed in Microsoft Word, because that HTML stuff makes my head swim. Enhanced with buggy JavaScript we stole off some Russian porn site, to resize your browser window, make its controls inaccessible, ensure the "security" of our images by disabling right-click, and to reject any browsers other than Netscape 4.72 and IE 5.5. Please bookmark this comment and come back when we've made the entire comment one big Flash animation completely inaccessible to anyone not running Flash or running Flash but on dial-up. PS: we appreciate your business.)
Opinions on the Twiddler2 hand-held keyboard?
HTML versus XML and the related set of schemas, including XHTML, can be compared to building with Lego versus real construction materials. HTML comes out of the realm of the old web where everyone and their uncle can be a so-called "web designer", a title anyone in the industry knows to actually refer to a graphic artist who draws buttons and banners. Coding in HTML revolves around nudging table cells by a few pixels this way or that way and hoping that all falls in place on that old piece of crap browser that half of the customers of your company are still using for some reason. HTML can be written by a 5-year-old. Some see this as an advantage, those who use it professionally can't see it as anything but a shame. I've known my fair share of web developers, being one myself, and the number of them who know anyhing about actual software development is probably less than one percent of the total.
XML, and all the web-related schemas and standards like XHTML, on the other hand, provide you with an ability to present very complex business domains over the internet. Anyone wno knows anything about programming will say that jumbling all your data, along with it's structure, along with it's presentation is a terrible way to write software. The new standards allow one to keep data separate (XML), structure separate (XHTML), and presentation separate (CSS). While it's admittedly more complex than the regular HTML it lets you do so much more with your data. Switch stylesheets and bam, your site looks completely different. Switch XSL stylesheets and you can serve the same data in completely different ways on a PC, a PDA, or a mobile phone.
Lastly I want to bring up that web clients are often used as front ends for company intranets and while it's going to be a while until web developers (and consumers!!!) will be able to enjoy the benefits of the move to XML on www those benefits can already be reaped in the controlled environment of your company intranet.
I don't know about you guys, but my pages are already written in XHTML 1.0 and, thanks to CGI.pm, all I need to get my pages up to the XHTML 2.0 spec is a newer version of CGI.pm which would be provided through a newer Perl distribution.
Ah portability..
The different HTML-Strict DTDs are nit-picking to the point that they preclude humans from writing code.
YES.
We should get ALL langauge compilers to ignore simple little syntax errors.
Why should we need a semi-colon to end a statement. The line feed should be enough.
Why should we need a closing brace. Cannot the compier SEE that it is the end of a block simply because the indenting is different?
!
The real problem is that people have been getting away with sloppy HTML. No closing TD, TR, TABLE tags because, hey, the browser allows it, and it works. Don't close italics in a TD cell? No problem!
MS started this mess when they had IE ignore HTML syntax errors. Netscape (at the time) was still strict. Suddenly many pages would not work in Netscape that worked in IE. This was perceived to be a Netscape problem, where in reality it was the coders problem.
Would YOU blame a compiler for trapping syntax errors? Of course not. So why should we allow sloppy HTML??
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
Pardon me, but I feel you're not being didactic enough in your answer (even though I totally agree with you), and since this issue is a pet peeve of mine, and I really want the message to be heard, I'll take the liberty on expanding on your arguments. I hope you'll forgive my rudeness :-)
So, why do we need a strict language that will barf at the first syntax error ? Well, it's simple : the current situation is a huge mess. No, wait, it's a *HUGE* mess. Currently, anyone can cobble up some shoddy webpages with some lame software (hint : it starts with "Front" and ends with "page") and slap them up on his Web space. Few will test their pages with more than one browser (namely, Internet Exploder), and even less will think of the implications of their design outside browser-land. What about search engines ? Speech synthesizers ? Intelligent agents who would like to quickly get a summary of the site to syndicate it ? All these systems have to be geared towards correcting user and software-generated mistakes to provide useful results. This demands more sophisticated engineering, render the software more complex, and is an incredible waste of resources. It also ensures that no two User Agents (be them browsers or something else) will have the same idea of a given HTML document. Thus, it renders the job of Web programmers (like yours truly) more difficult, and sometimes just insane (think Netscape 4.x). Another waste of resource, induced by the necessity to circumvent problems in UAs, themselves induced by their necessity to circumvent mistakes in the original code. It's a vicious circle that cannot be stopped, but for a shift to a more sound model. That's exactly what the W3C is promoting.
Also, I would like to debunk one persistent myth, viz. the idea that laymen would no longer be able to write Web pages when everybody will have switched to send data with a application/xhtml+xml MIME type. Let's be serious one moment : Joe Sixpack doesn't type HTML. Period. Good ol' Joe uses a WYSIWYG authoring tool (like the aforementioned abysmal failure from Seattle). I'm totally confident that these authoring tool will be updated to include support for XHTML, and even for semantic markup. So, Joe will be all of a sudden writing valid pages, without even noticing it. As for the people who write HTML in Vi, I assume they're knowledgeable enough to go read the documentation (I was, and I sure am not the sharpest knife in the drawer[*]), so there's still no problem.
That's it. I hope you'll see there are indeed reasons to move over to a more rational way of creating Web documents, and I encourage you to try out XHTML, CSS styling, and to validate your pages. Have fun !
[*] No, I'm totally unrelated to Ken Brown or AdTI :-)
Xenu brings order!