Why You Should Use XHTML

File this in the Irony category by Anonymous Coward · 2004-07-23 06:18 · Score: 3, Insightful

Slashdot isn't even valid regular HTML, let alone XHTML, and they're running a story on why we should be using XHTML? I'd laugh if it weren't so sad.

Re:File this in the Irony category by smartalecvt · 2004-07-23 06:29 · Score: 2, Informative

There were two good articles on alistapart.com about bringing /. up to code.

one and two
Inertia is an ugly thing.
Re:File this in the Irony category by critter_hunter · 2004-07-23 06:49 · Score: 3, Informative

Rob mentionned in his journal not too long ago that he had redesigned his page using HTML+CSS and that he would like to someday do the same for Slashdot.

--
Karma: Could be worse (could be raining)
Re:File this in the Irony category by Grant_Watson · 2004-07-23 12:01 · Score: 2, Informative

"WTF? The work was already done for you!"

There's a big difference between converting a staticly-saved page to XHTML and patching up Slashcode to generate the same. The latter would have to be done to make Slashdot use XHTML, and it's a lot more work.

Still, CmdrTaco expressed interest in patches, if anyone would like to provide them.

XHTML and XML?? by ViolentGreen · 2004-07-23 06:18 · Score: 3, Funny

Can someone please explain the differences between XHTML an XML?

--
Not everything is analogous to cars. Car analogies rarely work.

Re:XHTML and XML?? by Ambrose · 2004-07-23 06:22 · Score: 2, Informative

XHTML is HTML redone in XML. So XHTML is an XML "language", like MathML, SVG, etc.
Re:XHTML and XML?? by typhoonius · 2004-07-23 06:26 · Score: 5, Informative

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).
Re:XHTML and XML?? by volteface · 2004-07-23 06:26 · Score: 3, Informative

While HTML is an implementation of SGML (Standard Generalized Markup Language), XHTML is an implementation of XML (Extensible Markup Language, which is a subset of SGML used for describing different types data).

Basically as long as HTML follows the syntax structure of SGML correctly it is considered valid, but XHTML must follow the rules of XML correctly in order to be valid.
Re:XHTML and XML?? by Kentamanos · 2004-07-23 06:28 · Score: 5, Informative

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 :)).
Re:XHTML and XML?? by pete-classic · 2004-07-23 06:32 · Score: 4, Interesting

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
Re:XHTML and XML?? by skamp · 2004-07-23 07:07 · Score: 2, Interesting

Writing something that parses XHTML is a LOT simpler than writing something that parses HTML.

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:

Every modern browser, including Mozilla and Safari, is much worse at XHTML than at HTML. People tend to foolishly gloss over the transition from one to the other, thinking that code you write for one will "just work" when you switch to XHTML. That simply isn't true. If you look at XHTML in both Mozilla and Safari and compare it to HTML, you'll see that it's slower, non-incremental, and generally buggier than HTML.
Re:XHTML and XML?? by Sciamachy · 2004-07-23 07:35 · Score: 2, Insightful

Isn't xhtml an implementation or subset of XML? After all, xhtml pages rely on an XML DTD to define the tags they can use.
Re:XHTML and XML?? by JeanPaulBob · 2004-07-23 07:37 · Score: 5, Informative

No one seems to have explained this point sufficiently, so I'll give it a go. (The other posts give correct information--but incomplete.) XML looks a lot like HTML. If you look at any XML or HTML document, you'll see a bunch of tags--a word or phrase or letter surrounded by greater than/less than symbols--perhaps with text in the middle. For example, here's basic HTML: <p>The quick brown fox said, <i>"Lorem ipsum dolor sit amet."</i></p> Your web-browser sees the <p> tag and interprets everything between it and the closing </p> tag as a paragraph. The text is formatted accordingly, with line breaks before and after. Similarly, the browser knows to show everything between the <i> and </i> tags--which are nested inside the <p> tags--using italics instead of standard formatting. Other tags include <img> for images; an image tag also has attribute inside the tag to specify the image to be shown. For example: <img src="mypic.jpg"> That's HTML. XML is structured in pretty much the same way. Tags are used to give meaning to text in a systematic way, attributes can be included, tags can be nested, etc. For instance, you might store information for an address book in the following tags: <entry> <name> <firstName>Joss</firstName> <lastName>Whedon</lastName> <title>Mr.</title> </name> <address> <streetNum>1324</streetNum> <street>Mulholland Dr.</street> etc. </address> </entry> <entry> info for another person </entry> Then you would write a program that parses the data and displays it onscreen or saves it to your PDA or whatever. The key difference between XML and HTML or XHTML is that XML tags have no inherent meaning. You can use any text you want as a tag name, with a few limitations (no spaces, for instance). There are no assigned tag names like there are in HTML, where a <p> mean paragraph, and <b> means bold, etc. In the above example, you could change "entry" to "stickyWicket" if you want. XML data is meant to be interpreted by a machine, not a person--though meaningful tag names are obviously more convienient than random junk like "xkljad". As the other posts say, XML has some stricter rules than HTML. For instance, in HTML, there's a tag <br> for a line break. It doesn't have a closing tag--you just put it anywhere you want a new line to start. In XML, every tag has to have a closing tag--though you can combine both the opening and closing tags using the / symbol. You can use that to make your XML more concise. For instance, the <name> tag above with nested <firstName> and <lastName> could be simplified to this: <name first="Joss" last="Whedon" title="Mr." /> People have used XML to define all sorts of formats, from music notation to images. All that means is that they decided on a tag structure with meaningful tag names and nesting, and published the rule set. Then anyone can write applications to deal with that data. XHTML is just the old HTML tag with the strict XML rules. So, in XHTML, a line break is <br />. To sum up, XML is just a way to structure data systematically. XHTML is an XML document with particular tags intended for a web browser.
Re:XHTML and XML?? by wampus · 2004-07-23 07:58 · Score: 2, Insightful

Yes! Viva la ! Death to the w3c infidel!

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:XHTML and XML?? by blanks · 2004-07-23 08:02 · Score: 2, Informative

I can understand your point, but the fact is it is forcing people to follow standards. One reason I test my web apps in many browsers, if it dosent look the same in all of them, I'm not doing something right! If people are not willing to use these standards, then their websites will not look right in most browsers anyways. Just because new browsers let you get away without following standards dosent mean people should be able to write sloppy code, and by this I mean most ma and pa sites dont even follow standard HTML specifications.

--
TruePunk | Games
Re:XHTML and XML?? by Christianfreak · 2004-07-23 08:26 · Score: 3, Interesting

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
Re:XHTML and XML?? by canon006 · 2004-07-23 08:30 · Score: 3, Informative

Good descriptions so far, lemme add my two cents. A professor I had put it this way, "XML is more like a set of rules than a language; XHTML, SVG, etc are languages built using those rules."

I always thought it was a good way to think of the relationship.
Re:XHTML and XML?? by Cereal+Box · 2004-07-23 08:36 · Score: 3, Informative

How do you know that? Did you actually write both an HTML and an XHTML parser?

I'll tell you why it's easier to parse XHTML than HTML: if you're sure you've got well-formed XHTML data, then ALL you need to "parse" XHTML (that is, get it in a document tree format) is an XML parser, which someone else has conveniently written. Compare this with parsing HTML, which requires hacks to compensate for HTML's looser rules (i.e., elements like <p> and <br> which don't need to be closed off, etc.).

Now rendering XHTML is another story altogether, but there is no doubt that parsing XHTML is FAR easier than parsing HTML.
Re:XHTML and XML?? by RetroGeek · 2004-07-23 08:39 · Score: 5, Insightful

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.
Re:XHTML and XML?? by elFarto+the+2nd · 2004-07-23 08:47 · Score: 3, Funny

Perl I believe
Regards
elFarto
Re:XHTML and XML?? by DeComposer · 2004-07-23 08:48 · Score: 2, Interesting

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
Re:XHTML and XML?? by superyooser · 2004-07-23 08:49 · Score: 2, Insightful

Each nit-picking details decrases the ability for ma and pa kettle to pound out their own web page.
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?? by wsapplegate · 2004-07-23 09:23 · 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 :-)

--
Xenu brings order!
Re:XHTML and XML?? by space_man51 · 2004-07-24 17:39 · Score: 2, Insightful

Let me put a different perspective on your arguments:

I work with several amateur web designers...they all make their pages by writing the HTML. If you surf through the net, you will find that there's millions of people who are writing their own code. Even those using frontpage spend a great deal of their time in the HTML edit mode.

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.

I watched a large numbers of people who had little difficulty learning HTML have tremendous difficulties with XHTML...

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.

Take something simple like centering. The decision to center a paragraph or image is often made at run time.

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.

The fact that so many real people are avoiding the new think indicates to me that there's problems with the new think. I now agree with and encourage those who resist XHTML.

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.

I agree that the box model is best for overall page layout, but the deprecated tag attributes are better for run time design decisions.

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 why the FONT tag and it's attributes were deprecated. Same goes for most of the other tags like B and I.

Although I am modded a troll for saying it. I think the W3C is still too much under the influence of Microsoft and other big firms...

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) :)

--
Anton Markov
*** Linux - May the source be with you! ***

You have to wonder... by Dozix007 · 2004-07-23 06:19 · Score: 4, Interesting

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

Re:You have to wonder... by RickL · 2004-07-23 06:56 · Score: 2, Interesting

The implementation issues primarily affect the generation of XHTML rather than displaying it. As long as IE or any other browser doesn't choke on things like ' />', they won't have any problems. Because the rules of XHTML are so strict, parsing is greatly simplified.

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:You have to wonder... by volteface · 2004-07-23 06:57 · Score: 2, Informative

Well, Microsoft seems to be pretty big on promoting the use of XML as a whole, especially with its integration with their more recent .NET technology. What this means for IE and XHTML I don't know, but it definately seems to be a standard that Microsoft is interested in.

On a somewhat related note, Longhorn's presentation subsystem (Avalon) will use an XML-based definition language called XAML (similar to XUL, I believe) to define application user interfaces.

With XML being so common in new MS technologies, I would say they will more than likely adopt XHTML soon enough.

on slashdot? by einstein · 2004-07-23 06:21 · Score: 4, Insightful

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

Re:on slashdot? by LincolnQ · 2004-07-23 06:28 · Score: 5, Insightful

Yes. It is starting to really bug me. They could save a lot of bandwidth and make their page far more viewable with stylesheets if they moved the code into proper CSS and XHTML.

Grr.
Re:on slashdot? by MP3Chuck · 2004-07-23 06:38 · Score: 5, Informative

You weren't kidding when you said "a lot" ... damn!

For those who didn't RTFA the parent post had, it restructures /. with XHTML and CSS. Bottom line:
* Savings per day without caching the CSS files: ~3.15 GB bandwidth
* Savings per day with caching the CSS files: ~14 GB bandwidth

And the traffic figure they used was from June 2000. Do the math.

--
Who doesn't like free music?
Re:on slashdot? by Saeger · 2004-07-23 07:02 · Score: 2, Insightful

* Savings per day with caching the CSS files: ~14 GB bandwidth
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".
--

--
Power to the Peaceful
Re:on slashdot? by jCaT · 2004-07-23 07:05 · Score: 3, Insightful

14gb * 30 days = 420gb, which equates to about 1.5mbit sustained per month. With what slashdot is paying for bandwidth, that SHOULD be about $150 a month. Not exactly an amazing drop for them in price. It's not hard to see why they haven't bothered.

However, It sounds like are working on getting slashdot to be more standards compliant.
Re:on slashdot? by liquidsin · 2004-07-23 07:08 · Score: 4, Insightful

The "editors" here are supposed to be geeks. Every geek I know is all about doing their preferred geeky thing in the most efficient way possible. You'd think they'd want to do it just to say "yeah, we rewrote the site and saved 14GB of transfer PER DAY". Not only does it save them money, it saves the users load times. Besides, it's not like they have any actual editing to do.

--
do not read this line twice.
Re:on slashdot? by Quixotic · 2004-07-23 07:38 · Score: 2, Informative

that's assuming those savings are if all client browsers dont support gzip compression... i'm fairly certain slashdot will gzip compress it's pages if the browser will support it.

since text compresses really well, those savings will probably be quite a bit less...

--
--
Re:on slashdot? by Fastolfe · 2004-07-23 07:59 · Score: 2, Insightful

What I find even more amusing is the lengths they've gone to identify and ban people who request the RSS version of the home page too frequently (once every half hour is the cap).

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.
Re:on slashdot? by blanks · 2004-07-23 08:27 · Score: 3, Informative

Its been done http://www.alistapart.com/articles/slashdot/ Its happening now http://www.slashcode.com/plugins/04/03/04/0229237. shtml?tid=4&tid=24&tid=28 Big update in next few months in the cvs http://www.slashcode.com/ Yes its not here now, but it sounds like slashdot will be XHTML compliant soon. If you dont like it, fix it, public CVS. Dont bitch, change it your self.

--
TruePunk | Games

Funny quote by slashdevslashtty · 2004-07-23 06:21 · Score: 5, Informative

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 /dev/random -o kernel.dll` is our trade secret!

Re:Funny quote by JamesKPolk · 2004-07-23 08:27 · Score: 3, Informative

Let's see what the MS apologists have to say about that. If their browser is so great, why can't they handle docs that use the W3C-recommended mime-type?

Of course, I'd like to see what the people who call Google a great, loving, standards-obeying company would say to the fact that Google can't handle application/xhtml+xml either?

Before I added a special-case hack to send my pages go Google as text/html (thus violating the W3C mime-type recommendation), Google would not read the content of my pages, and would offer to show an "HTML version" of my XHTML which was actually blank.

Because HTML is ancient... by gnuman99 · 2004-07-23 06:21 · Score: 2, Funny

Maybe we should use XHTML because HTML is ancient and broken? Furtheremore, CSS must be pushed to replace most of the format specifications. XHTML+CSS actually simplify the rules by which browsers format text.

Is this really going to happen? by Defiler · 2004-07-23 06:22 · Score: 4, Interesting

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.

Mozilla composer by Danathar · 2004-07-23 06:23 · Score: 3, Insightful

It would be nice if Mozilla composer could save in XHTML....I'd gladly use it if more editors would save in XHTML format.

/. should lead the way by pohl · 2004-07-23 06:24 · Score: 5, Interesting

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...

Re:/. should lead the way by CHaN_316 · 2004-07-23 06:45 · Score: 2, Informative

There was an article on slashdot a while ago about retooling slashdot with XHTML. A pretty good read that summarizes the benefits of XHTML/CSS. The cost savings pretty interesting too:

*Savings per day without caching the CSS files: ~3.15 GB bandwidth
* Savings per day with caching the CSS files: ~14 GB bandwidth

Most Slashdot visitors would have the CSS file cached, so we could ballpark the daily savings at ~10 GB bandwidth. A high volume of bandwidth from an ISP could be anywhere from $1 - $5 cost per GB of transfer, but let's calculate it at $1 per GB for an entire year. For this example, the total yearly savings for Slashdot would be: $3,650 USD!

--
"There is no spoon." - The Matrix

Why You Should Use XHTML 2.0 ???? by stonebeat.org · 2004-07-23 06:24 · Score: 4, Informative

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

Re:Why You Should Use XHTML 2.0 ???? by JimDabell · 2004-07-23 06:34 · Score: 3, Interesting

Something better would be to use pure XML for creating content and then let the browser apply a CSS to present the content.

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.
Re:Why You Should Use XHTML 2.0 ???? by Stuart+Gibson · 2004-07-23 07:04 · Score: 3, Insightful

OK, I'm sure you're trolling, but how is XHTML any harder to understand than HTML 4?

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 /> etc).

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

--
It's all fun and games until a 200' robot dinosaur shows up and trashes Neo-Tokyo... Again

So Slow ... by johnhennessy · 2004-07-23 06:24 · Score: 2, Interesting

(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 dont know... by boomgopher · 2004-07-23 06:25 · Score: 2, Interesting

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.

Re:I dont know... by renderhead · 2004-07-23 06:52 · Score: 2, Insightful

This is only a problem for pre-existing code and for people who already know HTML. If I were teaching a brand new user to write markup, this method makes just as much sense as the img tag, if not more.

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.

--
I wish that my inferiority complex were as good as yours.
-RenderHead

Standards work now by cubicledrone · 2004-07-23 06:26 · Score: 2, Insightful

The reason most HTML is not valid is because browsers have generally not supported CSS completely, which makes it necessary to replace DIVs with tables, add huge browser functions to Javascripts, etc.

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.

--
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.

It's always the way. by caluml · 2004-07-23 06:28 · Score: 5, Informative

From the FAQ:

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. However, there is a trick that allows you to serve XHTML1.0 documents to Internet Explorer as application/xml. Include at the top of your document the line in bold here: <?xml version="1.0" encoding="iso-8859-1"?> <?xml-stylesheet type="text/xsl" href="copy.xsl"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transition al.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> where copy.xsl is a file that contains the following: <stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform"> &am p;n bsp; <template match="/"> <copy-of select="."/> </template> </stylesheet> Note that this file must be on the same site as the document referring to it.

--
Get your own free personal location tracker

Ugh by jandrese · 2004-07-23 06:29 · Score: 2, Insightful

Man, do you remember when writing a webpage by hand was easy? Back in 1996 or so when just about anybody with a text editor and a link to that excellent Netscape HTML manual could write a decent page without spending hours poring over obtuse documentation?

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.

--

I read the internet for the articles.

Re:Ugh by Ambrose · 2004-07-23 06:37 · Score: 3, Insightful

It is because HTML is so lax that we have the browser support nightmare we're in today. I would trade making it harder for the average newb to make a web page for consistent (or at least predictable) rendering across browsers.

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:Ugh by JohnnyCannuk · 2004-07-23 06:40 · Score: 3, Insightful

Do you remember that web pages in 1996 look like shit?

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.

--
Never by hatred has hatred been appeased, only by kindness - the Buddha
Re:Ugh by BlaKnail · 2004-07-23 06:41 · Score: 3, Insightful

"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."

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.
Re:Ugh by Kentamanos · 2004-07-23 06:42 · Score: 4, Interesting

I would argue learning XHTML is easier than HTML since the rules are a LOT more straightforward.
Re:Ugh by jandrese · 2004-07-23 06:47 · Score: 2, Insightful

My big point was that the original web standards were pretty egalitarian, with just about anybody with a good (or not so good idea) able to toss up a halfway decent looking page. Nowadays the standards are becoming rather elitist, and unless you're already a master of XML and know the W3C's technical jargon well enough to read their documentation, you stand little chance of just picking up XHTML from reading the documentation.

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.

--

I read the internet for the articles.
Re:Ugh by trisweb · 2004-07-23 07:42 · Score: 3, 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 of the best 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 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.

--
"!"
Re:Ugh by kirkjobsluder · 2004-07-23 07:59 · Score: 3, Interesting

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.

XML vs. XHTML vs. HTML by diagnosis · 2004-07-23 06:30 · Score: 2, Informative

A quick summary of XML, and XHTML vs. HTML:

XHTML is the next iteration of HTML. It is more formal and more strict, and (hopefully) more consistent. From http://www.w3schools.com/xhtml/xhtml_html.asp:

XHTML vs. HTML:

XHTML elements must be properly nested
XHTML documents must be well-formed
Tag names must be in lowercase
All XHTML elements must be closed

XML:
XML is not really parallel to XHTML/HTML. It is more useful for defining data containers and storing data. It is another step along the path to separating content from presentation.

From from http://www.ucc.ie/xml/#acro:
"XML is actually a `metalanguage' --a language for describing other languages--which lets you design your own customized markup languages for limitless different types of documents."

---------------------
Dr. Movie Movie: DrMovieMovie.com
Tomorrow's media behemoth -- today's independent voice.

Re:XML vs. XHTML vs. HTML by volteface · 2004-07-23 06:42 · Score: 2, Informative

"XML is not really parallel to XHTML/HTML. It is more useful for defining data containers and storing data."
Not sure this is not entirely true. Technically, a strictly conforming XHTML document is an XML document. If you think of an XHTML document like a hierarchy (which is in fact what it is in the Document Object Model), it becomes clear that a website is made up of data and data containers. This is my interpretation of it at least.

You are right that HTML and XML are really not parallel, though, other than they share the same SGML syntax.

But can it resist commercialization? by kindbud · 2004-07-23 06:33 · Score: 4, Insightful

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

XML on web sites sucks by laird · 2004-07-23 06:34 · Score: 3, Informative

Nope, you're right.

I'll go out on a limb and say that using XML as the document format for web site production is a terrible idea. XML is a great data exchange language between systems, but it's insanely inefficient for use within a single system. All of XML's positive attributes (self documenting, robust, extensible, supports encodings, validation, use XSLT to do transforms between arbitrary XML representations of data, etc.) are all important between loosely coupled systems. But those issues don't occur within a single system, and the overhead of using XML is immense. It's orders of magnitude faster to query a datbase directly than to parse XML, transform, etc.

--
Enable 3D printed prosthetics!

Re:XML on web sites sucks by Kentamanos · 2004-07-23 06:39 · Score: 4, Insightful

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?

No, XHMTL is broken by AuMatar · 2004-07-23 06:35 · Score: 3, Interesting

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?

Re:No, XHMTL is broken by AuMatar · 2004-07-23 06:46 · Score: 2, Informative

For me, you, or anyone reading slashdot, it probably isn't. Remember, this is the average Joe we're talking about. Ok, perhaps the slightly above average. The XHTML spec is far more complicated than HTML was. CSS and stylesheets is something they just don't understand, they don't get the idea of separating content from presentation (in fact to many of them, the two are equivalent), and they don't understand the idea of abstraction that they represent.

HTML 4 was worse for the average guy than previous incarnations, but XHTML is terrible for them.

--
I still have more fans than freaks. WTF is wrong with you people?
Re:No, XHMTL is broken by AuMatar · 2004-07-23 07:00 · Score: 2, Interesting

He also didn't forsee the rise of blogs, forums, etc. I write more html for forum and blog posts than I do for websites. Sometimes quite complicated html for tables. I suppose I could use an editor, save the file, open it in a text editor, and paste the result in the form, but that seems like more work than just writing the html in most cases.

--
I still have more fans than freaks. WTF is wrong with you people?
Re:No, XHMTL is broken by Allistair · 2004-07-23 07:02 · Score: 2, Insightful

I don't know. It seems to me that the average Joe/Josephine is going to be using some editor (graphical would be my guess) to do the editing for him/her. So, the only people that really need to be fluent in those rules are going to be the creators of those tools.

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:No, XHMTL is broken by T-Ranger · 2004-07-23 07:09 · Score: 3, Interesting

I dont know that that was HTMLs purpose. I keep hearing people say that, and it being "easy" may be true, but I dont know that that was its goal.
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.
Re:No, XHMTL is broken by subVorkian · 2004-07-23 08:16 · Score: 2, Interesting

The XHTML spec is far more complicated than HTML was.

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.

WYSIWYG Implementation by beejay54 · 2004-07-23 06:41 · Score: 4, Insightful

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

Most web developers don't need it by JimDabell · 2004-07-23 06:42 · Score: 4, 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 by rwiseman63 · 2004-07-23 06:42 · Score: 2, Insightful

I agree that most W3C specs are horribly written, but your comment that Schema doesn't fit the needs of OOP is just stupid. First of all, XML is not Object-Oriented, so there is no need for an XML validation language (i.e. Schema) to include built-in OO capabilities. On the other hand, XML could be used to implement an Object-Oriented language, and I am 100% sure that you could write a Schema to validate this language.

What's to prevent lather/rinse/repeat? Nothing. by Animats · 2004-07-23 06:46 · Score: 2, Insightful

We've now come full circle. First there was SGML, which is a "general purpose markup language for representing documents". Then HTML. Then XML. Now, XHTML, which is a "general purpose markup language for representing documents". What's wrong with this picture.

"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.

extra quotes by hey · 2004-07-23 06:47 · Score: 2, Funny

Regular HTML:

<img src=logo.gif width=10 height=10>

XHTML:

<img src="logo.gif" width="10" height="10">

I hate those extra quotes. Why is this progress!?

XHTML/CSS is picking up steam... by Saeger · 2004-07-23 06:49 · Score: 3, Interesting

I've been "coding" to XHTML transitional for a few years now, and have noticed recently that a lot of the sites being created or redesigned now are also opting for it rather than the old HTML401.

There's really not much to it:

All tags are lowercase, which is easier to type anyway
All attributes have to be "quoted" for sanity
All tags have to be terminated, like this lists </li> which makes the browsers job of rendering much easier since it doesn't have to play the guessing game. This is especially handy on lowend devices like PDAs.
All the old bandwidth-wasting presentation elements (like <FONT>) are now CSS presentation ATTRIBUTES of any element by using id= class= and style=

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

Warning: not for real web designers! by orthogonal · 2004-07-23 06:58 · Score: 4, Funny

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?

Efficiencies by A+nonymous+Coward · 2004-07-23 07:18 · Score: 2, Interesting

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

A Case for the use of XHTML by Llevar · 2004-07-23 07:18 · 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! by Goldenhawk · 2004-07-23 07:20 · Score: 2, Insightful

Do you remember that web pages in 1996 look like shit?
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.

Oh please.

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 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.

--
--Brandon / Split Infinity Music

Displaying XHTML by Brian+Blessed · 2004-07-23 07:25 · Score: 2, Interesting

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.

Boo-Hoo, Poor Newbies by Lethyos · 2004-07-23 07:51 · Score: 2, Insightful

Now we have XHTML and CSS. Neither of these are easy to learn.

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.

--
Why bother.

CGI.pm by mishan · 2004-07-23 07:58 · Score: 4, Informative

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..

Re:why you *should* use XHTML by Laebshade · 2004-07-23 07:59 · Score: 3, Informative

Why should you encourage XHTML?

Readability: XHTML is readable as long as it is structured correctly. Note: That doesn't mean having everything on one line.
XHTML can be done with a plain text editor just like regular HTML, though as always, it's best to use a text editor that at least has syntax highlighting.

I code valid XHTML nearly everday as a freakin' hobby. There's 3 useful things I've come to know:

Make it structured and it is easily readable. Tabs, line breaks, and spaces in appropriate places.
A text editor with syntax highlighting. A must.
Ok, so I forgot what the third was.

The above is true for nearly all programming. Slashdot, home of the all-knowing arrogant beings.

Tranesterification by Graymalkin · 2004-07-23 08:07 · Score: 3, Insightful

One huge problem I've encountered trying to switch pages from HTML 4.01 to XHTML is more established engines tend to hail from the HTML 3.2 days (Slashcode) and have not evolved much since. Forum software is often the worst in my experience, everything is littered with tables and fixed size elements. A lot of people host their sites on vhosts and many of those don't support things like HTML::Template, Mason, or Smarty. As such most coders just write their own template system which may or may not handle newer web standards.

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.

--
I'm a loner Dottie, a Rebel.

Re:No, XHMTL is broken... Or is it something else? by EtherAlchemist · 2004-07-23 08:10 · Score: 2, Insightful

It's not a surprise to hear someone complain about XHTML and CSS and all that goes with it. People have become complacent with markup. When HTML was the only way you built Web pages, people thought "Cool, this is so easy, anyone can do it!" and this was true. Anyone who could, did. But then rules got involved. Browser makers went on their own paths, interpreting or altogether ignoring W3C recommendations and spec and causing a new breed of technology employees major pains in their collective ass.

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.

--
R(k)

Re:why you should NOT use XHTML by trisweb · 2004-07-23 08:12 · Score: 2, Interesting

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd "> <html><head><title>Hello World</title></head> <body> <h1>'hello world'</h1> </body> </html>

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.

--
"!"

Time Stands Still for W3C by Frobozz0 · 2004-07-23 08:31 · Score: 2, Interesting

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."

Re:Oh God, not again... by the+endless · 2004-07-23 09:45 · Score: 3, Informative

why don't they fix CSS first and try doing something GOOD, like making the id and name attributes the same or both handled in CSS and javascript

The id and name attributes aren't meant to be the same. The name attribute is used for naming form controls, and (for example) this means that all radio buttons that are meant to be part of the same set all have the same name. Since the id attribute is meant to contain a unique identifier, making them the same would mean either [a] making it impossible to group radio buttons, since their names would need to be unique, or [b] making it impossible to grab an element by it's unique identifier, since ids can't be unique if you want to group radio buttons. Which would you prefer, exactly?

Re:Has anyone tried coding a site in pure XHTML/CS by shift1978 · 2004-07-23 10:20 · Score: 3, Interesting

So you say that website with tables used for design are more easy to read ? Are you sure ?
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/chocolateaud io.asp and listen what a blind person can ear when a website use unecessary tables.

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 :)

Re:Has anyone tried coding a site in pure XHTML/CS by Phil+John · 2004-07-23 10:45 · Score: 2, Insightful

For 99% of site designs, tables work perfectly well.

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?

--
I am NaN

The funny thing is... by devphil · 2004-07-23 11:08 · Score: 2, 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. :-)

--
You cannot apply a technological solution to a sociological problem. (Edwards' Law)

The history of IMG by Nurgled · 2004-07-23 12:14 · Score: 2, 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.

Re:...in fact, you have to wonder... by Grant_Watson · 2004-07-23 13:00 · Score: 2, Insightful

"...but what are we gonna' do for those whose real contribution to the net is content -- ideas, pictures, arguments -- rather than scrupulous code."

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 by prockcore · 2004-07-23 15:09 · Score: 2, Insightful

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.

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:OK, ya got me by mrchaotica · 2004-07-23 20:50 · Score: 2, Informative

HTML is a presentation language and well, websites do present. It doesn't take a programming genious to separate the presentation from the content if that is desired.

Allow me to illustrate the important difference between HTML and XHTML: the <i> tag vs. the <em> tag. They do the same thing, right? Wrong! They only look the same on a web page, in a normal visual web browser. But that's not all that XHTML is for -- imagine an audio web browser, for the blind. How is it going to know what to do with that <i> tag? How do you speak "italicized"? Speaking with emphasis makes much more sense. Also, what if instead of a person, it's a computer program parsing the XHTML. <em> means that the phrase is more important than the other text -- but what does <i> mean? For all the program knows the author just felt like writing in italics for no apparant reason!

That's just one example; the entire point of XHTML is that the entire thing is designed with these kind of things in mind. Another example is tables; in HTML they're often used for page layout. In XHTML, they should only be used for tabular data; page layout should be handled with CSS. This is because in XHTML, <table> means "this is tabular data" rather than "this is arranged in rows and columns".

Also, navigation bars: in HTML, you'd see things like this: "home | foo | bar | links | goatse" -- just a bunch of hyperlinks, separated by pipes. This is wrong (although technically valid) in XHTML. Instead, you should think about what you're actually making -- a list of links. Therefore, use <ul> instead, and use CSS to make it look like the row of |-separated links (which can be done, fairly easily -- check A List Apart)

Anyway, the point of this is that a XHTML document isn't just a "web page" -- it's a semantic document that should be useful in things other than a web browser. It should (ideally) be usable on everything from a PDA browser to a printout to a powerpoint-style presentation to a text-to-speech browser. Most importantly, it should provide semantic markup for use with spiders and such. Normal HTML doesn't do this.

--

"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

96 of 657 comments (clear)