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."
You have to wonder... (Score:5, Interesting)
Is this really going to happen? (Score:5, Interesting)
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.
/. should lead the way (Score:5, Interesting)
So Slow ... (Score:3, Interesting)
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...)
I dont know... (Score:3, Interesting)
<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...
Re:XHTML and XML?? (Score:5, Interesting)
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
Re:Why You Should Use XHTML 2.0 ???? (Score:4, Interesting)
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.
No, XHMTL is broken (Score:3, Interesting)
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.
Re:Ugh (Score:4, Interesting)
XHTML/CSS is picking up steam... (Score:4, Interesting)
There's really not much to it:
Firefox's WebDeveloper extension [mozdev.org] makes XHTML/CSS validation (among other funcs) so easy that there's no excuse to be lazy about it.
--
Re:You have to wonder... (Score:2, Interesting)
Now, the question is will Microsoft's various tools that generate HTML be able to generate valid XHTML. Considering the quality of HTML that Microsoft Word generates, I suspect it will have trouble meeting *any* standard.
Re:No, XHMTL is broken (Score:3, Interesting)
Re:XHTML and XML?? (Score:2, Interesting)
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 [mozillazine.org], however, who worked on Mozilla and now works on Safari, seems to think otherwise [mozillazine.org]:
Re:No, XHMTL is broken (Score:4, Interesting)
HTML is NOT easy. Writing a valid HTML documenta 20-30 lines long by hand is possible, but for any non-trivial page it is near impossible. (that there are no good HTML editors is besides the point). Any website containing more then 1 page should use some kind of automation to create HTML, be that continiously generated dynamic pages, or generating the HTML once per change. Spreading the rumor that HTML is easy to learn and that anyone can, and should, use HTML is a disservice to humanity.
If you are a non-technical person, or even a technical person whose job is not specificly HTML creation software writing, then you should not generate HTML by hand. Use some kind of CMS. Use some HTML editor. Use Docbook and "compile" HTML.
Why are Wiki's popular? Because they use a markup language that actually is easy, one that is hard to screw up.
Please, pleae, please, dont continue to spread the lie that HTML is easy enough for anyone to learn.
Efficiencies (Score:3, Interesting)
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.
Displaying XHTML (Score:3, Interesting)
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.
Re:XHTML and XML?? (Score:1, Interesting)
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.
Re:Ugh (Score:4, Interesting)
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.
Re:why you should NOT use XHTML (Score:3, Interesting)
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.
Re:No, XHMTL is broken (Score:2, Interesting)
Far more complicated? I don't agree. The benefits you gain from a tighter spec are well worth the trouble of adapting to the new technology.
For instance, changing a style within a single file and watching those changes cascade effortlessly through the site is much more elegant than the old ways. This makes updating your site easier and may actually increase adoption by mom and pop.
I think if people see the benefits, they will invest a little energy in learning new tech.
Re:XHTML and XML?? (Score:4, Interesting)
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?
Has anyone tried coding a site in pure XHTML/CSS? (Score:1, Interesting)
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.
Time Stands Still for W3C (Score:3, Interesting)
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.
Re:XHTML and XML?? (Score:3, Interesting)
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.
Re:XHTML and XML?? (Score:1, Interesting)
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.
Re:Has anyone tried coding a site in pure XHTML/CS (Score:3, Interesting)
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
The funny thing is... (Score:3, Interesting)
...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. :-)
The history of IMG (Score:3, Interesting)
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.