Fog Creek Software
Discussion Board




XHTML, CSS and valid web pages

Not to start a religious debate...

But I understood that the reason to use xhtml and css was to insure that your websites would be compatible for future versions of compliant browsers.

do most people agree with this, or do they think xhtml is more of a waste of time.

Charles Reich
Friday, April 11, 2003

XHTML's big advantage is that it's completely regular form of HTML that you can feed into an XML parser.

In theory, they might make an XHTML-only browser, but I suspect that as long as you stick to the HTML standard, you will be fine.  I've been moving over to XHTML because I've moved my static web content generation to XML+XSLT.

Flamebait Sr.
Friday, April 11, 2003

I don't worry too much about valid HTML. No company would dare make a web browser which will not reneder older style HTML correctly, it would break too many pages.

Matthew Lock
Friday, April 11, 2003

You can have strict interpretation of HTML without requiring that it be turned into XML. The SOLE purpose for making XHTML is so it can be consumed by an XML parser. This doesn't do jack for browsers or end users, because browsers have to support HTML as tag soup.

So emitting XHTML is a rather pointless task.

Now, observing HTML 4.01 Strict, the HTML DOM, and CSS... those are very good ideas. Nailing down the interpretation is a very sizeable leap forward in browser independent presentation and code. It's even doubly valuable to remove layout from data, no only for maintenance, but also because it opens up whole classes of non-traditional browsers that old style HTML was mostly terrible with (mobile devices, aural browsers for blind people, etc.).

Brad (dotnetguy.techieswithcats.com)
Friday, April 11, 2003

Oh, and XSL-T transforms can output traditional HTML. They don't have to emit XHTML.

Brad (dotnetguy.techieswithcats.com)
Friday, April 11, 2003

I second Brad's remarks. See also  http://www.hixie.ch/advocacy/xhtml , which discusses the issue at some length.

Chris
Friday, April 11, 2003

FWIW, Ian Hickson is wrong when he says that the <br /> syntax would produce an extra &gt; in HTML. I use it regularly (for XML compatibility), and the W3C validation service (*) says it's perfectly valid HTML 4.01 Transitional, as per my document declaration. I've also never seen a browser produce that extra ">" character claimed by Hickson.

I seem to recall that the empty tag syntax was made legal in the HTML 4 or 4.01 standard, so as to allow valid XML content. Really old browsers might have a problem with it.

Otherwise I agree with Hickson, browsers that understand correctly declared XHTML are too rare to bother with this format right now. Just use XML to create content, and XSLTs to create HTML 4.01 from that. Then it's easy to make the switch when XHTML does become common.

(*) http://validator.w3.org/

Chris Nahr
Sunday, April 13, 2003

Just because the browsers render it as you expect, doesn't mean it's legal. He does even make the point that it's exploiting a bug in the browsers wherein their shouldn't render it.

Besides, it's showing that browsers can't handle real XML, wherein [br/] would be legal, but browsers are only buggy enough to accept [br /]. You can see it's obviously exploiting a common parsing bug.

Brad (dotnetguy.techieswithcats.com)
Sunday, April 13, 2003

Okay, I just checked the HTML 4.01 specification and it does indeed specify that <BR> cannot have an end tag.

However, the W3C validation service continues to accept both <BR /> and <BR/> (no space) as valid HTML 4.01 Transitional...

Clearly something's not quite right here. But as long as this "bug" is common enough that both the W3C validator and virtually all browsers support it, I think I'll happily continue using it. <shrug />

Chris Nahr
Monday, April 14, 2003

Forgot to add that the no-space variant of <BR/> is also rendered as expected by IE6. Which browsers exactly only accept the space variant?

Chris Nahr
Monday, April 14, 2003

Earlier versions of Netscape and IE, as I recall, both had problems with this, although I don't know what the exact matrix is.

Brad (dotnetguy.techieswithcats.com)
Monday, April 14, 2003

The reason that I code with XHTML is because it helps ensure that I'll get the page that I want.  With XHTML's rulesets you are forced to write more highly structured code.  While one can write very well structured HTML, it is not required.  Quite often in the past I would lose a TD or a TR somewhere and end up with an IE only bug or a Gecko only bug.

As for CSS, its is simply a more convenient and less time consuming way to code - it strips out all the unnecessary information from the page and stores that presentational material elsewhere.  And of course there's the whole - it results in a smaller page, and CSS documents are usually cached, and updates are faster and easier.

One can continue to code in HTML- that's not a problem as far as I'm concerned, but CSS is a must for future development.  Static text pages with many KB of wasted markup are not exciting and cost companies money.

Lou
Monday, April 14, 2003

Lou,

You would only get the benefits you hope for with some form of validation, which browsers are not doing. They treat XHTML as tag soup. So the validation is a manual process, either locally or using a service like the W3 validator (which works just fine for HTML, and catches problems like missing closing tags).

Also, when you write code instead of writing HTML directly, you eliminate those types of bugs, because the code all takes care of it. I'm not sure why people would still write HTML by hand when code can do it much more regularly and reliably.

Brad (dotnetguy.techieswithcats.com)
Monday, April 14, 2003

The browser will do proper validation for you - if you server your page as an XML document and your doctype is XHTML 1.1 strict - any small error will kill the site in a Gecko browser and kick out XML errors.  That's not cool.

But its the structure of XHTML that I appreciate - that's what I was trying to convey.  Being well formed is just the start - using non-proprietary code is next.  By using XHTML I've been able to significantly drop development time because a validator will identify any errors more accurately than they could in HTML (ever hunt for a bug caused by a deep nesting in a poorly formed document?). 

That drop in development time could possibly be achieved with the right programming tools, but I've yet to see a tool that can achieve the compact code with the long term maintainability that I seek.  If I can't read my code in 3 months or a year its not good code - not that its non-functional and should be scrapped, but it should have been written better.  XHTML is a tool that helps that happen for me.

Lou
Monday, April 14, 2003

You should actually read that link. Serving HTML as text/xml is a dangerous thing, at least as dangerous as serving it as text/html. There's no win.

And I just don't see what you're talking about for nesting. HTML 4.01 Strict took away the same set of "presentation" tags as XHTML 1.0 Strict did. Using CSS is an orthogonal task from deciding on HTML vs. XHTML.

Brad (dotnetguy.techieswithcats.com)
Monday, April 14, 2003

If I'm writing something new, I'll use XHTML. I mean, why not? It's a tiny bit more typing, but as many people have pointed out, there are some potential benefits.

But do I have plans to go back and change existing HTML? No, not worth the bother.

Bill Tomlinson
Tuesday, April 15, 2003

XHTML allows some neat tricks like embedding other XML types in-line using namespaces.

Remember, it's not just browsers that are going to be parsing your page.  Imagine a search engine that was intelligent enough to read the structure from your page.  Being able to parse it as XML would be a huge help.

Sure, you say.  But there's so much tag soup out there that any such search engine would have to read that too.  Not so!  Because it might be *you*  writing this search engine for a corporate intranet and wouldn't life be easier for the coder if he could assume everything was valid XML?

Remember folks, it's not just about the browser anymore.  XHTML is a good thing.  It doesn't provied so much of an immediate benefit, but if we all used XHTML, more things would be possible in the future.

Richard Ponton
Wednesday, April 16, 2003

Doesn't the W3C say that XHTML is eventually going to replace HTML?

Charles Reich
Thursday, April 17, 2003

The W3C hopes that it will, sure, but how do you suppose they'd force you to do it?

What will make XHTML standard will be browsers that only consume XHTML and throw errors on bad pages. But browsers will almost assuredly never do that. It's chicken-and-egg, and it's the maxim of "being liberal in what you accept" at work.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, April 17, 2003

*  Recent Topics

*  Fog Creek Home