Why You Should Use XHTML 657
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."
File this in the Irony category (Score:3, Insightful)
on slashdot? (Score:5, Insightful)
W3C useless (Score:1, Insightful)
Mozilla composer (Score:4, Insightful)
Standards work now (Score:3, Insightful)
Now, Safari, Mozilla and Opera support about 98% of CSS-1 and parts of CSS-2, so it becomes possible to actually develop a working web site without spending 10 hours of testing and debugging (yes, debugging HTML) for every one hour of actual development.
Re:on slashdot? (Score:5, Insightful)
Grr.
Ugh (Score:2, Insightful)
Now you have to figure out what Doctype to set, learn CSS, enter some sort of weird workaround for IE, etc... Worse, HTML used to be fairly forgiving for the author so Newbies could get a decent page without spending hours and hours trying to figure out why their page is coming up blank or trying to figure out why the validator is complaining at them. (I really hate when it says stuff like: Illegal use of <B>. And I'm left scratching my head as to why it is illegal.). It's no wonder newbies choose instead to write their webpage in Word and use the horrible "export to HTML" feature.
But can it resist commercialization? (Score:5, Insightful)
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?
Re:Ugh (Score:3, Insightful)
Not to mention accessibility. The vast majority of sites out there are all but completely useless to the blind, or those who require very large print, or who are browsing on PDAs, cellphones, or other small devices.
The new standards are a Good Thing, and if that means gramma can't hand-code her photo gallery page (and you know, there are a lot of grammas out there that do that know) I'm not going to lose any sleep over it.
Re:XML on web sites sucks (Score:4, Insightful)
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?
Re:Ugh (Score:4, Insightful)
Do remember that web development these days cannot rely on simple static text?
Do you realize that with HTML/XHTML editing tools around these days, it doesn't matter?
Right tool for the job, my friend. A text editor is for writing static text. HTML/XHTML tools are used for making web pages and interfaces.
Just because there's "doc types and CSS" out there doesn't mean you have to use them - go ahead and write crappy looking pages in notepad, just becasue you can. But if you are going to do proper, standard, stylish web development that is a good experience for the user, you may need to know some of this stuff.
Clearly you aren't a web developer.
Re:Ugh (Score:3, Insightful)
HTML being forgiving is a bad thing. Sure, it's easier for the average person to crank out a homepage, but without strict standards, we ended up with a myriad of browser incompatibilities and mountains of sloppy coding that can't be parsed correctly.
XML and XHTML really are a godsend.
WYSIWYG Implementation (Score:4, Insightful)
Most web developers don't need it (Score:5, Insightful)
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.
Re:W3C useless (Score:2, Insightful)
Re:on slashdot? (Score:1, Insightful)
What's to prevent lather/rinse/repeat? Nothing. (Score:3, Insightful)
"Structured documents" for public distribution usually don't work. The problem is that the costs of tagging are incurred by different people than those who benefit from it. Unless you have some enforcement agency that makes people tag their data, it doesn't happen. Even then, the data quality tends to be terrible. The SEC used to require financial statements in a rigid SGML form, in the EX.27 schedule of 10K and 10Q filings. Companies hated that. Not only did they get the numbers wrong, they hated having to express their numbers "uncreatively".
There are ways it might happen. If Google said that "You must tag all "buyable things" in this format, or you don't get into our index", we'd see it happen. That's how a few big retailers forced manufacturers to bar code, two decades ago.
Re:Ugh (Score:3, Insightful)
I know the pages won't be very accessable, but the kind of people who need this are the kind of people for whom accessability is not a huge issue (these people never set ALT tags for instance). Unfortunatly, is is also these people who really made the web explode in the early days by filling the WWW with an enormous assortment of information and services. Nowadays it seems that far fewer people are creating novel services or information stores. Unusual webpages are getting harder and harder to find, and most of the content added is in the form of Blogs, which are annoyingly transitory.
I guess I've ranted enough on this for now.
Re:I dont know... (Score:2, Insightful)
I've given people introductory "crash courses" in HTML before, and they often go something like this: "A tag is used to format content. Except for the img tag. That one IS content. And you should always close your tags. Except the img tag. It stands alone because it's an object not a formatting tag."
Not terribly confusing, but it is inconsistent that tags in HTML represent formatting in some cases and content in others. This new method makes more sense to me, especially coming from a CSS-heavy background.
Re:No, XHMTL is broken (Score:2, Insightful)
Perhaps I am just being negative, but I really don't see many average users opening up a page in Vi, Emacs, or TextEdit. If you can get Frontpage, Dreamweaver, and the various blogging applications and services to use valid XHTML, you are going to take care of most of your "average" users.
Beyond those "average" users, you probably have people who can grok XHTML.
Re:on slashdot? (Score:3, Insightful)
Sure, that's a lot of bandwidth, but not in dollar terms.
Large sites pay less than a dollar per gigabyte xfer'd. So, /. would save less than 5 grand per year. That's a lot of money to me and you, but maybe not to the guy(s) who don't want to overhaul a big site that's "not broken".
--
Re:Why You Should Use XHTML 2.0 ???? (Score:4, Insightful)
Since they use practically identical tags and are structured in the same way, a well written (ie compliant) HTML 4 page will comply to XHTML with a change of doctype and a few minor tweaks (<br> to <br
Anyone who is in any way competent with HTML can switch to XHTML with no problem. In fact, for less technical people, XHTML will be easier to understand as the reams of presentation code will have been shifted to the CSS file, making the underlying (X)HTML easier to read and understand document structure.
If I'm completely off base about where you're coming from, please enlighten me.
Stuart
Re:on slashdot? (Score:4, Insightful)
However, It sounds like are working on getting slashdot to be more standards compliant. [slashdot.org]
Re:on slashdot? (Score:5, Insightful)
A Case for the use of XHTML (Score:4, Insightful)
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.
Oh, pu-lease! (Score:3, Insightful)
-
Do you remember that web pages in 1996 look like shit?
Oh please.Do remember that web development these days cannot rely on simple static text?
Do you realize that with HTML/XHTML editing tools around these days, it doesn't matter?
Right tool for the job, my friend. A text editor is for writing static text. HTML/XHTML tools are used for making web pages and interfaces.
Do I remember? Yeah, I've been coding HTML by hand since 1995, and my pages looked pretty messy back then. But it wasn't the HTML - it was my poor grasp of what looks good and works well for other users.
"Cannot rely on simple static text"? It's been said here before, and apparently you don't believe it. If your pages rely on flashy formatting and movement and pixel-level formatting, you're letting the formatting get in the way of content.
Right tools? Heh. Sorry, I've tried PageMill, and FrontPage, and Netscape and Mozilla built-in editors, and even MS Office's HTML editing. Don't like them. They all generate bulky, messy code, hard to tweak, impossible to really control. I've hand-coded everything from day one, and will always do it. And if you think hand-coded HTML is unpretty, somehow, visit http://www.worship-live.com [worship-live.com] for what you can do without an editor. Looks nice in any browser, lightweight and therefore bandwidth-friendly, and has yet to generate complaints of any significance. Maybe it won't parse out as perfectly W3 compliant - maybe I put the italics tag on the wrong side of my paragraph tag - but it works.
Sorry, but I just disagree with your basic premise. Frankly, the biggest problem facing the web today is people who somehow think that PageMill or Frontpage make them better web designers. Sorry - that's exactly the wrong answer.
Re:Why You Should Use XHTML 2.0 ???? (Score:2, Insightful)
XHTML 2.0 almost forces you to seperate "content" from "presentation". Which is a good thing.
In theory, but not in practice. What happens is that more often than not, you end up with encoded XML in a database, which means that your data is no longer separate from presentation; access to your data now requires an XML parser as well.
Furthermore, you are forced to hardcode the relationships between elements. If your data is XML based, the only possible view is heirarchical; IMS was heirarchical, and look how long it lasted.
XML (and XHTML by extension) is the new COBOL. It isn't a smart idea by any standard:
I'd like to hear from someone who is actually using XHTML to store content. My guess is that XHTML is being used more as a presentation kludge than as a content storage system.
Re:XHTML and XML?? (Score:2, Insightful)
Re:Ugh (Score:4, Insightful)
Clearly you aren't a web developer.
Most of the web developers I know (and I know a lot) started out using tools like Dreamweaver and GoLive etc, which now output decent XHTML, but now they are starting to move toward XHTML and CSS in their designs (which are some [csszengarden.com] of [stopdesign.com] the [hicksdesign.co.uk] best [mikeindustries.com] on the net, might I add), and they're switching to using text editors exclusively for writing the code, plus your standard graphics programs for the images. I do the same.
The great thing about XHTML is that is separates the content from the design, which in turn makes your code beautiful and easy to write and maintain. I was looking at an XHTML page I had written the other day, and I thought, gee, I could just put this up as plain text and people would still understand it. It was free of all that contextual crap (tables, font tags, one-pixel spacer images) that heavily-designed HTML pages of two years ago were full of. So no, a text editor is not just for writing static text. I use mine for every aspect of the design process, though, admittedly ConTEXT [context.cx] is not notepad, it's pretty close. And I would contest that the sites I develop aren't crappy looking.
You may be able to design sites with a tailored WYSIWYG HTML editor, but you usally have little control over how everything fits together, and it results in messy code that is hard to understand. If that works for you, then fine, great. All I can say is that you better "know some of this stuff" and how to do it without your XHTML editor -- learn it in notepad -- and then, once you see what was output by your editor, and if you have any respect for the XHTML standard and the ideals that the W3C had in mind when they thought of it, I have a feeling you won't go back.
Boo-Hoo, Poor Newbies (Score:3, Insightful)
We also have C, Perl, Fortran, Lisp, and so on and so on and so on... and they are all difficult to use. You actually have to sit down, open a book, read, learn, and think. Can somebody tell me why XHTML should be anything different?
First of all, XHTML is easily recognizable to anyone who knows HTML. I don't know where you get off saying it's harder than HTML. As for CSS, it's a hell of a lot easier than messing with tens if not hundreds of nested font tags and other legacy presentational markup crap.
Second, why do development tools and languages have to be simple and easy to use by the masses? So the tools can be a little less popular? Is that even bad? I for one would be quite happy if more people out there who are too dumb to figure out how to use relatively simple tools like XHTML correctly weren't producing material for the web. Even then, there is now lots of software out there that produce valid, semantic XHTML (modern incarnations of Dreamweaver, for example, are capable of this). So where is the problem?
We as developers should definitely be interested in making end-user products easy and functional. But when it comes to the languages and tools, fuck that. Let's make them good for developers, not our grandparents.
Re:XHTML and XML?? (Score:2, Insightful)
Seriously, XHTML is not much different than plain old HTML for basic usage. For advanced usage XHTML is more powerful with CSS, and if you want more power, you have to expect it to be more advanced to use.
And on a side note, what ever happened to the slashdot xhtml/css retooling? anyone?
Re:on slashdot? (Score:2, Insightful)
Now, the RSS version is extremely lean, and the alternative is hitting the home page, which is not. Why don't they ban people who hit the home page too frequently? I can hit it a hundred times in 10 minutes and they won't care, but the RSS page twice in 30 minutes? Banned for 72 hours.
Clearly Slashdot is not concerned whatsoever (not even a tiny bit) about their bandwidth consumption, unless it's not earning them ad impressions.
Tranesterification (Score:4, Insightful)
Since many sites are using crappy HTML they want to spice up they tend to use equally crappy JavaScript to add little stylistic features. I think many people are surprised when they hit up a CSS tutorial and figure out they can replace their stylistic JavaScript with CSS and have much better performing web pages.
I'd love to see more sites using XHTML, even transitional XHTML, with CSS for styling and layout purposes. Documents end up much more flexible and quite a bit smaller. It is also easier for end users to override the page's CSS with their own to either make elements more legible or friendlier for their output device (PDA, cell phone, screen reader).
Coders of CMS engines: Please use sane template systems so it is easier for your poor end users to make their pages better comply with web standards. Also don't wrap stuff in tables, not everyone uses tables to lay out their pages! Presentation logic is fine and dandy but don't hard code layout elements, let the users decide! Thank You.
Re:No, XHMTL is broken... Or is it something else? (Score:2, Insightful)
If you wrote HTML, you had all the browsers effectively working against you. You still do today. They are slow to incorporate W3 standards, and even when they claim to do so- the engines still interpret the meaning of the markup slightly differently. The DOM support has gotten way better, but there are still differences between browsers and even within versions of the same browser. Take IE for example. Simply adding the DOCTYPE tag causes all three versions to behave different from themselves! Even if you use XHTML 1.0 Transitional, you're still going to face rendering problems. They can all be gotten around, but it takes patience and experience.
Not just anybody can sit down and author HTML for a complex page that looks and behaves the same across platforms and browsers. Clearly, not EVERY browser, but it can be done. I regularly build sites that support IE 5 >, NS 6.2 >, Mozilla 1.8 > on PC and Mac and Safari on Mac. But, I have the experience of doing it for years, and the time to make sure it gets done right. The moment most authors are faced with writing code that works outside their favorite browser most give up and slap a "Best viewed in..." disclaimer on their site. This isn't really their fault, they may not always have the time or resources to do it. Others are driven by project requirements that say it should only work in such and such browser.
Really good front end developers are frustrated because there is STILL this mentality that any idiot can write HTML. Sure, but only a few of us can craft it and weild it like a blade. I would argue that authoring markup to be cross browser/cross platform requires the same level of understanding markup (HTML/XHTML) CSS and JavaScript that a C++, Java or other compiled language author must know about that language. There isn't an IDE in the world that can generate x-browser/x-platform code involving those three things (markup, JS and CSS). Some come close or do certain things really well but it's just a fact that the browsers behave too differently to do it. Unless YOU KNOW how to make it work, it likely won't using an HTML generator. Products like Dreamweaver are fine, and they have their place. But they are not a substitute for someone who knows what they are doing.
If you still think the problem is in the spec though, that's fine. I would recommend using a looser one and giving it another shot. I mentioned XHTML 1.0 Transitional earlier. This is, in my op, the best one to start with and use if you are really wanting to adhere to XHTML but don't want to give up some of the things you know and love (or hate, but need to use anyway) like table cell attributes that would otherwise be deprecated. If you're producing pages that should work in PC and Mac browsers with equal functionality and appearance, this is the one you want.
Re:on slashdot? (Score:1, Insightful)
Re:XHTML and XML?? (Score:5, Insightful)
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??
Re:XHTML and XML?? (Score:3, Insightful)
This is 2004, not 1996. Most amateur web "designers" today and even many (more than you would imagine) professionals (those who are paid) never look at the HTML. "Ma and pa" are using FrontPage or some other WYSIWYG application to create web pages. It is the job of Microsoft and other software companies to make their web page-creating apps generate markup that complies with the new rules.
Re:XHTML and XML?? (Score:5, Insightful)
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 :-)
Re:Time Stands Still for W3C (Score:1, Insightful)
Re:Has anyone tried coding a site in pure XHTML/CS (Score:3, Insightful)
No they don't, they can throw off screen readers which (rightly so) expect tabular data to be in tables.
Every site I've done in the past few months has been completely xhtml and css based. Sure, the first few times took a bit longer than before, but what I find now is that it takes me less time than it used to for a table based layout! Plus, if the client comes back a few months later wanting a redesign it's much easier because my content is separate from the visual display, so all I do is reorder some divs, update the stylesheet and bam, it's much quicker and thus cheaper for my clients.
one of your main goals is to make it look good.
No, the main goal is to make it as accessible as possible, then make it look good. What good is a flashy site if you cut out several % of viewers?
Re:...in fact, you have to wonder... (Score:3, Insightful)
Hopefully, we will do what we're already doing in many places: let them use a markup generation tool; let them use templates; let them use a content-management system.
Re:Has anyone tried coding a site in pure XHTML/CS (Score:3, Insightful)
Get Firefox and install the Web Developer extension. It has a feature called View Style Information. Turn it on and your mouse becomes a crosshair. Click on an element and you can see exactly which CSS rules apply to that element.
Re:XHTML and XML?? (Score:2, Insightful)
Let me put a different perspective on your arguments:
You can edit XHTML just as easily as HTML by hand. In fact, XHTML is probably 2x less code, because you don't have FONT tags everywhere. It's much easier to see the information you are trying to convey.
It depends on how one approches it. If you think "This text needs to be bold and red," then XHTML is harder. On the other hand if you think "This text is important," and then later decide it should be bold and red, XHTML become easier.
I am not sure what you mean by "at run time". Run time of what? A web application? A script? It is possible to put styles into a "style" attribute rather than a stylesheet. The scrip can also set the "class" attribute of the P tag, and the stylesheet can specify that that text should be centered.
People always avoid new things; it is our nature to resist change. People have complained about GUI programming, the "new" taskbar in Windows 95, you name it. Just because the majority is not quick enough to accept something does not mean it's bad.
Do you even know what the box model is? It has little to do with deprecated tag attributes. The attributes were deprecated for other reasons.
There are many reasons [olemiss.edu] why the FONT tag and it's attributes were deprecated. Same goes for most of the other tags like B and I.
I am not were you are getting this information from. The way I see it, Microsoft and other companies that make WYSIWYG editors are interested in the code being too complicated for the M and P to write it out by hand. HTML pages are more complicated, than XHTML (just take a look at cnn.com), so I would think MS is interested in using old relaxed HTML (why do you think IE is so relaxed?)
Just my two cents (well, maybe four) :)