Slashdot Mirror
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
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...
(Before I'm completely slaughtered for complaining about performance, a disclaimer: I haven't done strict benchmarks)
Is it my imagination or are XSLT transforms very slow. I know this will depend on what engine you use to transform, but during the course of designing a website for a friend I tried several Java based transforms to go from XML to an XHTML page.
Why are these operations so slow - I thought XML (and therefore XHTML) was supposed to be straight forward and easy to parse.
In my limited experience XHTMLs benefits seem to be "weakened" by parsers/transformers that are still a bit away from maturity (speed-wise).
(Hint: if anyone knows a lean, mean transformer nows the time...)
[ Monday is a terrible way to spend one seventh of your life. ]
I dif XML and all, but things like replacing tags with stuff like:
<p src="map.png"><span src="map.gif">Exit from station...</span></p>
seems a bit too... anal? or purist/academic at best.
I suppose it's a moot point if MS/Macromedia/Adobe comes out with a great XHTML2.0 WYSIWYG editor, then 95% of the developers out there wouldn't even care...
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
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
No, that would be very much worse. The whole point of a publically specified XML application like XHTML is that everybody understand what the element types mean. If you go around inventing your own element types, nobody will no what you mean. Google understands <h1> as being more important than normal text. It won't understand <my-fancy-heading> in the same way.
You forget the original purpose of HTML. HTML's purpose, and the reason it grew so quikly, was to be an easily understood markup language that could be used by less technical people. The reason so many people were able to make their own homepages and grow the web like they did was that HTML could be easily learned.
Now we have XHTML and CSS. Neither of these are easy to learn. Neither of them is easy to use. Less technical people are incapable of using either. This is great for job security for webmasters, but for the growtrh of the next and for the internet as a medium of free and easy communication its horrible. XHTML is broken as an HTML replacesment because it does not meet the original purpose of HTML- to be something that anyone can easily learn and use.
I still have more fans than freaks. WTF is wrong with you people?
I would argue learning XHTML is easier than HTML since the rules are a LOT more straightforward.
There's really not much to it:
Firefox's WebDeveloper extension makes XHTML/CSS validation (among other funcs) so easy that there's no excuse to be lazy about it.
--
Power to the Peaceful
How do you know that? Did you actually write both an HTML and an XHTML parser? While I didn't, I would also instinctively think that parsing a stricter language would be easier; but David Hyatt, however, who worked on Mozilla and now works on Safari, seems to think otherwise:
doing their preferred geeky thing in the most efficient way possible
Now maybe your preferred geeky thing is minimizing bandwidth over the short term.
And maybe others' geeky things include minimizing over a longer term.
I could spend $10K in time to save $5K/year in expenses, or $10K on some other effort that will have a better long term payoff.
The "editors" here ARE in fact geeks, and they know what they are doing behind the scenes, which you do not. Maybe you should assume they have some idea of what they are doing, and that as you have said, since they have little actual editing to do, maybe, just maybe, they actually do some geeky things that you know nothing of.
Infuriate left and right
Does anyone know if this revision will specify more precisely how it should be displayed by a web browser?
The problem I've found with fully using XHTML+CSS for web pages is that it is not possible to layout pages that will scale accurately as the font size is increased. So much for accessibility!
I wonder why it was decided that it would be useful for text that doesn't fit, to run-over other text and elements on the same page.
It would be better if we could tell the browser that when elements expand the other parts of the page must move out of the way.
- Brian.
I will be checking out the new specs.
One of my greatest dislikes of all of the new X-Style languages is that they all seem aimed to cutting human beings out of the web equation. The original HTML is sloppy, but most people can get a decent looking page by typing out code in a text editor or in a little tiny textarea box on a forum.
The different HTML-Strict DTDs are nit-picking to the point that they preclude humans from writing code. For example, you have to replace all of the ampersands in a URL with an ampersand followed by "amp;". They've eleminated monoid tags; so you have to end img, meta and br tags with a "/". Each nit-picking details decrases the ability for ma and pa kettle to pound out their own web page.
To a large extent it appears that the primary goal of the W3C is to force the market into the position where people have to buy expensive programming languages to write HTML.
Personally, I like humans more than machines. I agree with the majority of web pages on the net that we should resist the W3C.
Gee, am I the only one who has been writing xhtml in vim for a while now?
It's not that hard to do.
1: add the doctype at the top.
2: always close your tags.
3: check you work with a validator.
html tidy will also identify and clean up any mistakes.
Know any other programming languages that can do a completely understandable and arguably human readable 'hello world' like that? Yeah, I know there are probably a few. But that's not hard, man, I'm sorry. The doctype tag is the hardest part. Try searching for 'xhtml doctype' on google and copy-paste. Not hard.
If you know anything about software development, you'll no doubt be familiar with the idea of abstraction. You know, splitting a complex or redundant thing into parts to better understand it and make it simpler (loosely defined, anyway). XHTML does exactly the same thing. It abstracts the Content away from the Structure away from the Design. It takes away all the crap that existed in HTML4 pages from all those being mashed together, making XHTML far more readable and easier to code. If you can't see that, then you've never actually tried coding a bit of XHTML.
"Writing out XHTML by hand is going to be a pain, even for very simple content." -- I responded to something like this earlier, but I'll say it again -- people coding XHTML are throwing away the old WYSIWYG editors in favor of a better program -- a simple text editor. XHTML is so easy to code by hand that you don't even need a program to help you do it. Any old text editor will do. Just shows again, you've never actually had experience coding XHTML. The web is moving in this direction. If you're not going with it, then stop holding it back by saying unfounded things like this.
"!"
You're kidding right?
First off, Ma and Pa Kettle haven't cranked out their own web page in notepad since about '97 or so. Nowadays they use FrontPage for that which produces something akin to code soup.
Secondly I don't understand why new syntax precludes anyone. Learning new things is not difficult. I write valid XHTML 1 code by hand, it isn't very hard, in fact its much easier to control the elements than it used to be, and produce nice looking sites that downgrade nicely for people using broken (IE) browsers.
It makes everyone's life easier if there is a standard that is followed. You don't expect a programming language to know what to do with invalid syntax do you? Why should your data language be any different?
The Anti-Blog
It's horribly painful to create a decent layout using strict XHTML and CSS. You can make some nice-looking things after a bit of work, such as the samples at CSS Zen Garden. However, try looking at the CSS file for any of the nicer designs. They appear to be completely hacked together! Separating the CSS stylesheets from the XHTML source makes them even harder to understand, since you can't figure out which element has which id/class and what order the elements come in.
For 99% of site designs, tables work perfectly well. You want some header accross the top, a sidebar with links on the left, perhaps another sidebar on the right, then some content and a footer that spans the bottom. It's very natural to perform a layout using rectangular blocks. If you look at any print publication, it's probably also laid out using blocks.
When you're making a website, one of your main goals is to make it look good. If you just wanted to give the user annotated data, you could just give them a plain XML file.
As much as I like the work of W3C, it's as if they are stuck in a time warp where they could actually effect development patterns. It's not 1994 any more, and there's so much existing infrastructure in HTML 4.0 (or similar) code and horrible Ineternet Explorer interpretation of that code that little will happen for YEARS. The lead time on their final specifications are probably at 5 or 6 years now.
Don't get me wrong-- they're doing the right thing, but it's as if they could shout at the top of their lungs that MathML and SVG should be standard and no one will care. Oh wait, nobody does. How many browsers support either "out of the box?" If you were to add up their market share it would be in the single digits.
It's time we just realize, as web developers and designers, that we are stuck with a horribly inefficient means to share information that is worsened by the lackluster industry movement required for change in the way we get at that information.
I'd say this is a new thing, but it's not. Look at any industry and the same thing always occurs.
"Politicians find new names for institutions which under old names have become odious to the people."
First of all, I'm of the very-supportable impression that standards are a good thing. Few things in web design are quite as annoying as having to detect and code for different browsers.
;.
Second, I think we can all agree that--despite the "L" in XML and XHTML that these are not programming languages but markup languages. While there are clever things that can be done to markup, especially with XSLT and XSL:FO, markup languages are not procedural--and therefore not programming lanuguages--the way C++, Basic, or JavaScript (to name a few) are.
Third, XML and XHTML, especially when used in conjunction with XSLT and XSL:FO, are vastly more versatile than HTML without being much harder to write. Not being programming languages, you can even create XML/XSL/XHTML documents in any text editor and validate them for free at W3C.
Fourth, every markup language--and every programming language--I've ever encountered has reserved characters that have to be replaced by escapes. Maybe it's just me, but I've seen more than a few instances of & n b s p
The whole point is to make web pages more friendly to their audiences and, at the end of the day, you're only going to the trouble to even create a web page so that you can reach an audience.
Karma
Both you and the parent poster are wrong.
It's 2004, and we still need to look at the (X)HTML source as much as ever. Sure, if you're creating some simple static webpage, a WYSIWYG editor is fine. But for any reasonably complex, dynamic website, FrontPage/Dreamweaver/etc just aren't useful.
However XHTML makes things better for these kinds of sites. By increasing the up-front complexity mentioned by the parent poster, you greatly reduce the effort necessary to debug a problem when things go wrong. For instance, a major headache for websites that pull html from many templates is mismatched table tags. Tracking down a missing closing table tag in code you didn't write when it could be in a dozen different template files can take forever. But with XML, you're more likely to get a meaningful error message which will point you toward the real problem.
HTML is easy to write, hard to read. XHTML adds more structure which becomes incredibly useful as the complexity of the task increases.
So you say that website with tables used for design are more easy to read ? Are you sure ?
d io.asp and listen what a blind person can ear when a website use unecessary tables.
:)
Have you ever work on the website of another person, company, project using table for design ? It sis totally impossible to maintain it without losing much time.
Now about the goal of a website, it is not to look good but to provide information. Now if it look beautiful too it is better. But information is the main point and accessibility - I mean information for everybody (blind persons, persons using their mobile phone,...) With tables for design accessibiliy is not possible
Foolow this link http://www.humanfactors.com/downloads/chocolateau
Moreover XHTML is more easily readable than XHTML for web-engine. With the separation of content and design you win lot's of bandwidth. Etc.
All my websites now use XHTML and CSS and I am very happy with this. It work perfectly and I win so much time than bfore using tables. I can change the look of all my website by changing one file. Do this with table and without server languages (PHP,ASP,...).
XHTML rox ! CSS rox ! HTML will die slowly
...there are many languages out there which follow these rules, and humans always tend to hate them.
Why should we need a semi-colon to end a statement. The line feed should be enough. Well, that's the way it was in assembly language and shell scripting, but people bitched and moaned, and statement-separators have been a part of both kinds of language ever since.
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? And yet, whenever Python is suggested as a language, the usual response is some language bigotry about "the indentation nazis taking over." Heck, even Stroustrup tried a variation of C++ where the try/catch blocks didn't have to be enclosed in braces, because the "try" and the "catch" made everything redundant. The compiler was just fine with it, but the people using the language clamored for the braces to be put back.
I'll stick to Python, but I'll let the sloppy Perl coders share the same air as me. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Now that every browser anyone would dream of using supports IMG in some form, even if it's just replacing the element with the contents of the ALT element, it's easy to forget about its heritage and not correctly shame the creators of this, one-broken-always-broken element.
IMG was added to Mosaic back in the day, and after it was implemented it was submitted for peer review. The "peers" correctly noted that the use of an 'alt' attribute to handle browsers which cannot display the image is inadequate because pre-IMG browsers will not render it at all. In addition, it can only accept plain text and not full markup, so it is impossible to provide proper fallbacks in non-trivial cases. Sadly, the Mosaic developer responsible for IMG decided that since it had already been implemented as submitted, and Mosaic was the browser of the time, it wasn't worth the trouble to rewrite the support for this element in their tag-soup parser.
Today we have OBJECT which works as suggested by the peer review of IMG back in the day, but IMG has become so ingrained that no-one can feasibly use it. OBJECT is clearly a superior solution, supporting all kinds of object and providing multi-tiered fallback simply by nesting OBJECT elements within each other and finally nesting other elements such as IMG.
I'm not so sure that I agree with this new "everything is potentially an image" idea, though. It seems nice in theory, but just that example of a SPAN element inside a P element shows that it's all just an awful hack. It's a good start, but it seems like they didn't really think it through properly.