Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry


August 23, 2003

I’m slowly plodding along to XHTML 1.0 Strict sitewide, in a happy little idealistic attempt to later move to 1.1 and join the growing list of X-Philes. Evan Goer and Jacques Distler are fantastic resources on this stuff by the way (update: and I can’t believe I missed Anne Van Kesteren), but this is all background for you.

In my process I’ve dropped XHTML formatting from my comments and added auto-links for URIs since I can’t be bothered messing around with comment validation and the like. But this is still background.

The problem is, or was, this: auto-links to long URIs would break my layout. In Firebird they would run into the right-hand column, in IE they would do the same and they would push the right-hand sidebar down below my content area.

So the other day I’d had enough of feeling helpless about this problem, and luckily CSS offers a few ways out. After some experimenting with the CSS-2 property overflow: auto; on each comment block (.comments-body) I finally ended up using overflow: hidden; Any URIs longer than so get chopped at the right of the comment block, the magic number being around 60 characters. Why hidden instead of auto? After all, the latter would add scrollbars, ensuring truncation doesn’t occur.

But the more I thought about it, the more I realized that truncation was exactly what I wanted. URIs are the only bits of text within .comments-body that could possibly be affected, so why not truncate? It’s cleaner looking, enough of the link shows up for the user to get the idea, and they’ll still get the full URI in the status bar. Otherwise I’d have to live with ugly vertical and horizontal scroll bars in any comment block that needed them, and that just looked odd.

Which just goes to show that there’s always more than one way to tackle a problem.

Reader Comments

patricia says:
August 23, 08h

i’m glad i’m not the only who doesn’t like those ugly scrollbars.

Tom says:
August 23, 09h

I’ve been thinking of going to strict compliance as well on a website I’ve been working on (no shameless plug), but I have a question about your post. I’ve seen references to URIs on the w3c validation pages - in their tips of the day - and I don’t know what a URI is. I’ve yet to find a definition online that really explains the difference between a URI and a URL. Can anyone help?

August 23, 09h

I have to live with the scrollbars until I figure out how to display long lines of code without overflowing. Even so, I’ve found that it doesn’t always work nicely in all browsers. In IE and, reportedly, Safari, long one-liners are reduced to super mini-size scrollable area that barely works.

If someone knows of a good way to do this, let me know!

Dave S. says:
August 23, 09h

Tom - URL, URI, it’s more or less the same thing. I’ve only recently switched to calling them URIs, prompted by this:

MikeyC says:
August 23, 10h

What about using Fahrner Image Replacement (or one of its variants) on the <a> tag? You could create an appropriate “external link” symbol that would replace auto-linked URIs. Visitors would still get the address in the status bar, but would not be misled by a truncated address on screen.

Darin says:
August 24, 01h

Exactly what benefits does upgrading from XHTML 1.0 to XHTML 1.1 provide?

After reading Mark Pilgrim’s thoughts on the matter, I’ve decided to hold off myself. It seems to me that XHTML 1.1 is a whole lot of trouble for no real gain. Perhaps I’ll change my mind and upgrade to XHTML 1.1 for its own sake, as an exercise in standards-compliance, once MSIE can support the proper MIME type. However, as things stand, I refuse to intentionally break the standard by sending XHTML 1.1 served as text/html to legacy browsers when XHTML 1.1 offers zero real-world benefits over the perfectly functionable XHTML 1.0.

Evan says:
August 24, 01h

I agree, it is a whole lot of trouble. But actually, XHTML 1.1 is the one version of XHTML that does provide interesting functionality over its predecessors. XHTML1.1 is modular, and that means you can use it to embed other XML fragments (MathML, SVG, …) directly inside your page. (Assuming that your pages are well-formed and that you’re serving up a MIME-type that will trigger XML parsers.)

I think that’s pretty nifty, and it’s definitely something you can’t legally do with plain old XHTML 1.0 or HTML 4.01. On the other hand, not too many “regular folks” need to be embedding MathML in their weblogs, so… your question still stands.

August 24, 02h

Hi Dave. My solution wasn’t scripting, but I am using Brad Choate’s MT Regex plugin to search for URLs and replace them with [link] where the word “link” is, well, a link. I’m also putting the URL into the title tag so users can mouseover the text to see where it will take them. Besides the overflow problem, I think the [link] text looks cleaner. See:

You didn’t mention this, but the overflow solution is also great for long strings of text (such as source code).

Oh, and I totally dig plain-text in comments. Some commenters just aren’t as particular about their markup as the rest of us. ;-)

MikeyC says:
August 24, 02h

“Exactly what benefits does upgrading from XHTML 1.0 to XHTML 1.1 provide?”

For that matter, exactly what benefits does upgrading from HTML 4.01 to XHTML 1.0 provide? Mark Pilgrim’s rant made me re-think XHTML altogether. XHTML 1.0 & 1.1 are really just excuses to get designers used to the XML syntax for the coming age of XHTML 2.0 (if it ever actually materializes…big IF).

XHTML 1.0 (& 1.1) is really just a “bridge” technology with very little practical, real-world benefits and a few, serious drawbacks like the whole MIME-type headache (remember, if you are serving your XHTML as text/html you are really just serving up malformed HTML as far as the browser is concerned).

True “XHTML” will not become viable until around the end of the decade (remember: it doesn’t matter that Mozilla can handle it now–MathML and the rest is near-useless if it only works in 1% of the browsers–not trying to be cruel just trying to be pragmatic), so I really don’t buy the argument made by many that its a good idea to get used to the syntax now, as if the syntax differences between SGML and XML are so great that it’s gonna take several years to get used to them and not merely one afternoon in 2009.

Before jumping on the XHTML bandwagon every designer really should read:

Mark Pilgrim’s rant is also a good read you just have to see past the hyperbole.

“Standards are bulls*it. XHTML is a crock. The W3C is irrelevant.”
-Mark Pilgrim

August 24, 03h

“only works in 1% of the browsers”

How many browser are out there? I think you meant the public’s browser of choice ;).

And why is it so evil to use XHTML? It is getting you used to the syntax which will be used later (and now). It can be transformed, it is flexible and it will be (is) te replacement for HTML.

The differences between XHTML1.0 and XHTML1.1 are listed here:

And there is one change not listed, which you can find here: (not meant as spam, it’s the only reference around)

Dave S. says:
August 24, 03h

Ken - RegEx is precisely what I’ll be looking into. Not only will it help the link thing, but it’s the last piece of the puzzle in making sure these comments don’t break validation. However, I don’t have the foggiest when it comes to using regular expressions, so I’ve still got some learning to do.

MikeyC - see Jacques Distler’s weblog linked in the original post for a very real-world reason to use XHTML 1.1. As well, when inline SVG comes into play I’ll be very glad to have made the switch. Really, there’s no benefit for me to make the switch right now. But I’m still moving in that direction anyway.

Dave S. says:
August 24, 03h

MikeyC - somehow I managed to miss your link to Ian’s rant the first go-around. I’ve read it four times now. I agree, everyone working with XHTML needs to be aware of it.

I don’t, however, agree with the conclusions. Like Anne, I don’t think there’s any harm at all in getting used to the syntax now, for the eventual and inevitable shift to XHTML later.

Besides: if we weren’t supposed to be using XHTML now, why would the W3C have aimed for backwards-compatibility with shorthand and the option of serving Transitional as text/html?

ala_747 says:
August 24, 03h

A little more “comprehensible” info about URIs/URLs:

MikeyC says:
August 24, 04h

Anne: “And why is it so evil to use XHTML?”

For the record I never claimed that it was evil, but simply that it’s premature to be using it.

Dave: “when inline SVG comes into play Iíll be very glad to have made the switch.”

No disagreement here, Dave. Just saying it’s premature to be using XHTML 1.1 (mime-type problem) and that XHTML 1.0 offers no advantage.

Assuming IE7 comes out in early 2005 (and it’s not a big disappointment) and supports application/xhtml+xml and inline SVG/MathML etc… and has a rapid adoption rate (despite the fact that standalone downloads will no longer be offered) then we are still looking at a target date no sooner than around 2007-08 before true XHTML/SVG/MathML become viable.

Dave: “see Jacques Distlerís weblog linked in the original post for a very real-world reason to use XHTML 1.1”

Jacques use of MathML is very cool and I’ve admired his weblog for some time, however, weblogs can get away with stuff that other sites really can’t (for reasons that could be debated forever). I honestly don’t think pointing to a weblog’s use of technology X can really be used as an example of a “real-world reason to use XHTML 1.1”.

What I am really frustrated with is the hold-up of including SVG support in release versions of Mozilla. Every day that goes by is one more day that flash becomes even more entrenched and ubiquitous. For crying out loud, I’ve even read about including SVG within Flash at this point?!?

August 24, 04h

What if you had the server retrieve the title of the link? Just use wget or something on the link, check to see if you got something with <title>something</title>, and strip it out. Then you can build a real-looking link, but it’s more likely that it’d be wrap-able text. (But you’d be better off keeping overflow:hidden regardless.)

August 24, 05h

Why is inline SVG so exciting?

I’ve started using SVG on my blog, but included via the <object> tag. Why? Not just because that’s what Adobe’s plugin supports (in other words, what people can actually see in their browsers), but because:

1) I author SVG in a drawing program (Adobe Illustrator). That produces a self-contained SVG file. Am I supposed to open it up in a text editor and cut and paste the SVG code into my XHTML? That would be daft.

2) Included files can be cached. Just like external CSS stylesheets cut down on page bloat, so do external SVG files.

3) Fallback. If your browser doesn’t do SVG, you get a GIF image instead.

I don’t understand the “We’ve gotta wait till Mozilla supports inline SVG.”

“weblogs can get away with stuff that other sites really canít”

Of course. But you’ve gotta *start* somewhere. Weblogs are the perfect place for trying out new technology. They’re the off-off-Broadway of the Web.

That’s why Dave’s swimming towards XHTML 1.1 on his weblog, not on one of his commercial sites.

In my case, MathML is a technology people in my line of work really need (though most of them don’t know it yet). If we wait around for it to “go mainstream”, we will wait forever.

My motto is “If you use it, they will come (and switch browsers if they have to).”

MikeyC says:
August 24, 05h

Jacques: “Why is inline SVG so exciting?”

SVG support, of any kind, natively in Mozilla would be exciting to me.

Jacques: “Iíve started using SVG on my blog, but included via the tag…Fallback. If your browser doesnít do SVG, you get a GIF image instead.”

Out of curiousity how well does that work in real-world browsers? Does IE cascade/fallback properly to the gif image if the adobe plugin isn’t present?

August 24, 06h

Native support is great. But a plugin (espcially one that works as well as Adobe’s seems to in my limited testing) ain’t chopped liver.

Does it fallback correctly in IE? Check it out and see:

MikeyC says:
August 24, 06h

Jacques: “Does it fallback correctly in IE? Check it out and see”

Shockingly, the result was as expected ;)

Browser support aside, you made a good point about including SVG through the object tag as opposed to inline. Including SVG inline is simply going to bloat XHTML files unnecessarily for those users’ who don’t have SVG support. At the same time, it goes to show that plain ol’ HTML 4.01 is not an obstacle to SVG support as the object tag is part of the spec. MathML, Ruby, etc… are another matter I suppose.

MikeyC says:
August 24, 06h

MikeyC: “MathML, Ruby, etcÖ are another matter I suppose.”

Why did I write that, I don’t know? Couldn’t MathML *also* be included through the object tag?

August 24, 07h

“Couldn’t MathML *also* be included through the object tag?”

Only if you want a separate file for every single damned equation on your page. And then Mozilla wouldn’t be able to read it. (MathML is supported in Mozilla only when the document is served with an XML doctype – such as application/xhtml+xml).

My authoring software takes inline LaTeX input (the lingua franca for this sort of thing in the scientific community) and converts it to inline MathML. See

There is, by contrast, no authoring software which naturally creates inline SVG. And I’m not sure what such a piece of software might look like.

August 24, 07h

Canīt you make a script to shorten the displayed URI/URL like some bulletin board software do?

When the text is over X characters long, it gets shorthened in this fashion: http://beginning/../ending.html , but the status bar still shows the full link, of course.

August 24, 07h

You would be the first designer on that list :). Every site is ugly there (including mine, although I’m about to change that).

Maybe you could refer to any hyperlink as [link] ? And the actual address is in the statusbar of course.

Dave S. says:
August 24, 09h

groan. Why does everyone always suggest scripting? Sometimes to be good at one thing, you have to purposely choose to not be good at other things.

Alex says:
August 24, 12h

I feel your pain, Dave. Whenever someone mentions “server-side,” it’s off to bed for me ;)

Actually, I don’t have a problem with the current “overflow: hidden.” Sure, it might look nicer if it was replaced by a pretty little icon or some text, but I’m not too nitpicky about those things.

Hank Marquardt says:
August 25, 04h

Quote – groan. Why does everyone always suggest scripting? Sometimes to be good at one thing, you have to purposely choose to not be good at other things.

I agree with you generally, however, you sometimes have to delve into those other areas to achieve your effect … case in point, I’m a server side guy; but guess what, without some design, layout and markup all the snazzy scripting I can do is pretty worthless … that’s why I read this site, Zeldman and others … graphics in particular are painful for me, but layout isn’t far behind, yet I do it anyway and strive to get better at it.

Just my $0.02 … besides a few RegEx problems are fun (if you have a sick, twisted, scripting mind) …

… and hi Minz!

GaryF says:
August 25, 05h

To go back up to the top of the comments:
Using [Link] for all links is an awful idea for accessibility for the same reasons that “click here” shouldn’t be used for link text.

August 25, 05h

@GaryF, you could still differentiate them by putting the link location in the title. That way you’ll still pass level 2.

@Jacques: Are you 100% sure it is impossible to import mathml into html4.0 with the object element? Maybe it’s time for a little test…

August 25, 06h

Gary, I’ve actually been wrestling over the accesibility problem that “same link phrases” pose. The Bobby validator has been failing me on my “n Comments” links on my homepage. It’s entirely obvious that any comments link on my homepage goes to the comments section of that particular post (just as it is with the “reply” links on Dave’s homepage)–especially because the title attributes clearly indicate where the links go.

There does seem to be some contention over whether or not the title attribute deals effectively with this accessibility problem. When I wrote about this recently, I found an interesting debate on the topic here:

The “Cynthia Says” validator at just lets me of with a warning about these link phrases, but doesn’t fail me for WAI Priority 2. Because of this, I think I qualify for Priority 2 accessibility (even the W3C uses same link phrases that point to different places on their homepage), but I can’t link back to a validator that will claim this like I can with XHTML validation.

As far as the true accessibility issue goes (because that’s really the point, right?), there’s really no way for me to know how this affects a blind person using a screen user without being able to test it.

August 25, 09h

[..]You would be the first designer on that list :). Every site is ugly there.[..]

Thanks for the hint ;))

Michael says:
August 26, 01h

Hi Michael,

Michael here, too!

Re this:

“So the argument that some sites like make hinge on the fact that the developer of the content will not concern himself with following the spec because the content wonít break when it reaches the user agent and therefore the developer will spit out spaghetti code.”

I don’t agree. Hixie is saying that XHTML sent as text/html will be parsed as “tag soup” by an HTML parser. That would hold *even if it were valid*. So he concludes there is no real advantage in sending it to such agents.

MikeyC says:
August 26, 03h

What it comes down to, for me, is that the browser is going to see it as invalid/malformed HTML if sent as text/html and not Valid XHTML 1.1 (even though it might be valid). XHTML sent as text/html punishes browsers that correctly interpret HTML because XHTML relies on the fact that most User Agents inerpret closing slashes incorrectly.


<p> Hello <br /> World </p>
…is, if interpreted as HTML, exactly equivalent to:
<p> Hello <br>&gt; World </p>
…and should really be rendered as:
> World

XHTML 1/1.1 backwards compatibility is a big fat lie that simply relies on that fact that most User Agents interpret HTML wrong.

Andrew says:
August 26, 05h

I like regular expressions… does that mean I have a sick, twisted, scripting mind? I s’pose that’s a reasonable reflection.

And I’m sure there’s more than just me that likes to think themselves as having a foot in each camp (coding and design, that is). Having said that, I probably don’t qualify to be in either!

Strange how these comments have evolved into something entirely unrelated to the original context!

Zen garden flower bed somewhere in the ether; “employed” as a .Net programmer

Michael says:
August 26, 07h

The arguments against XHTML thus far have been pretty petty. Essentially it comes down to mime-type discrpencies which keep the user agent from properly validating the content. So the argument that some sites like make hinge on the fact that the developer of the content will not concern himself with following the spec because the content won’t break when it reaches the user agent and therefore the developer will spit out spaghetti code. So since SOME developers refuse to use the tools available to validate their content then ALL developers should NOT USE XHTML. It’s poor logic.

I also take issue with the use of the word “advocacy” when referencing, which is exaclty the opposite of advocacy since all the points he writes on seem to be negatives NO to XHTML, NO to XSLT, NO to XSL:FO, how is that advocacy?

There’s nothing dangerous or wrong with coding to the XHTML 1.0/1.1 standard. As with all previous W3 standards you have early adoptors and hold outs. The hold outs are probably the same holdouts that said that HTML 3.2 was fine, why do we need HTML4. Or the same hold outs that continued to develop on Netscape 4 despite it’s lack of standards support.

I personally think that there are a lot of web developers fighting against the “hype” of XHTML that they think is happening and using as an excuse to jump on a different kind of bandwagon, but that’s just my opinion, I don’t have an article to back it up.

Use what you like. Use it because you’re comfortable with it, because it makes sense to you, because you like the way it works. DON’T use it because someone else tells the other technology is bad, DON’T assume that those people writing the articles MUST be smarter than you, DON’T assume that because it’s been quoted a million times that it’s fact.

August 26, 07h

“XHTML sent as text/html punishes browsers that correctly interpret HTML because XHTML relies on the fact that most User Agents inerpret closing slashes incorrectly.”

In principle correct, but in fact, silly.

We can divide browsers into three classes:

1) Browsers which can’t handle the correct XHTML MIME type but which interpret trailing slashes in HTML “incorrectly”.

These browsers can be sent XHTML as text/html and will not screw up on Hixie’s example.

2) Browsers which understand the correct XHTML MIME type.

These browsers can be sent XHTML with the correct MIME type, and will parse it as XML. They won’t screw up either.

3) Browsers which cannot handle the correct XHTML MIME type, but which interpret trailing slashes “correctly” in HTML.

It is only this latter class of browsers which will screw up Hixie’s example.

Unfortunately, there are no *existing* examples of browsers of type 3). And it is *very unlikely* that there will be any written in the future. Almost all future browsers will be of type 2). There will continue to be “legacy” browsers of type 1). But type 3)? You’re joking.

I refuse to get worked into a lather arguing about the empty set.

MikeyC says:
August 26, 09h

“In principle correct, but in fact, silly.”

Some people might say the same thing about using the W3C box-model when the IE-box model works just fine in +95% of the browsers in use today. Just because 100% of the *known* browsers in use inerpret HTML incorrectly is no excuse to feed all browsers knowingly malformed HTML. Perhaps the reason there are no browsers out there that correctly interpret the closing slash is because XHTML pages *would* break in them and so the developers have decided to forego compliance for convenience. What if faced with the overwhelming installed base of IE5 users no browser had ever dared to use the W3C-box model for fear that it would cause incompatibility? I just find it funny that the W3C, who pretty much defines these standards/recommendations, would put forth a solution which knowingly relies on a ‘browser-bug’ that goes against an earlier standard/recommendation. In effect, browser-makers that adhere closest to the recommendation are penalized. Lovely.

August 26, 11h

I’m sorry, maybe you missed “class 2)”. I’m perfectly willing to entertain the possibility that some future browsers will interpret trailing slashes in HTML “correctly” AND handle the correct XHTML MIME type.

There are *no* browsers in class 3) today, and I cannot imagine a reason why anyone would ever write one.

This has nothing to do with fear of breaking anything.

When you send out “XHTML” as text/html, it is parsed by the browser’s HTML parser. It *is* HTML, whatever DOCTYPE you happen to slap on it.

Only when you send out XHTML as application/xhtml+xml (or similar MIME type) does it get parsed using the browser’s XML parser. Only then is it “really” XHTML.

I don’t see why you’re complaining that the W3C has provided a *migration path* to “real” XHTML by sanctioning sending out “XHTML” with a MIME type of text/html (relying on the “broken” behaviour of all existing browsers).

It would be a much harder slog to convert to XHTML were they to forbid that.

It seems to me that they’ve found a very nice compromise – a migration path that does not break in any browsers, but allows one to, at some point down the road, simply flip a switch and start doing “real” XHTML.

August 27, 12h

if using PHP just use wordwrap (with some regexping maybe) and u are there.

Michael says:
August 27, 12h

I refuse to get worked into a lather arguing about the empty set.”

Quite - there is something unrealistic about his argument. And in any case, to paraphrase, the W3 says what he doesn’t want “may” be done. And in fact its own authoring tool Amaya only writes XHTML.

OTOH, it seems to me it is probably true to say there is no real advantage in not using HTML 4.01 …

for most of us. :-)