What I want to touch with this post is how errors are handled when XHTML is served the way it should be. Let’s, for the sake of argument, say that we want to write and deliver XHTML (not wanting to turn this into a discussion whether we should write HTML or XHTML).
First, some general background information about how to send documents to the requesting web browser. It’s all about the media type type, described in XHTML Media Types:
Should be sent with the text/html MIME type.
All flavors of XHTML 1.0, strict, transitional and frameset, should be sent with the application/xhtml+xml MIME type, but may be sent as text/html when it conforms to Appendix C of the XHTML specification.
Should be sent with the application/xhtml+xml MIME type; Should not be sent with the text/html MIME type.
So, what’s the difference? It’s that web pages sent as text/html is interpreted as HTML while those sent as application/xhtml+xml is received as a form of XML. However, this does not apply to IE, because it doesn’t even understand the application/xhtml+xml MIME type to begin with, but instead tries do download it as a file. So, no application/xhtml+xml for IE.
Aside from IE‘s lack of support for it, and for what you need to consider described by Mark Pilgrim in his The Road to XHTML 2.0: MIME Types article, it means that when a web page is sent as application/xhtml+xml while containing an well-formedness error, the page won’t render at all.
My thoughts about this started partly by seeing many web developers writing XHTML 1.1 web pages and then send them as text/html, and they were only using it because it was the latest thing, not for any features that XHTML 1.1 offers (this also goes for some CMS companies that have invalid XHTML 1.1 sent as text/html as default in their page templates for customers to take after). Sigh…
It is also partly inspired by an e-mail that I got a couple of months ago, when Anne was kind enough to bring an error on my web site to my attention, with the hilarious subject line:
dude, someone fucked up your XHTML
What had happened was that Faruk Ates had a entered a comment to one of my posts where his XHTML had been messed up (probably because of some misinterpretation by my WordPress system), hence ending up breaking the well-formedness of my web site so it didn’t render at all.
Because of that, and when using it for major public web sites, I really wonder if that’s the optimal way to handle an error. Such a small thing as an unencoded ampersand (example: & instead of &) in a link’s href attribute will result in the page not being well-formed, thus not rendered. Given the low quality of the CMSs out there, terrible output from many WYSIWYG editors, the “risk” (read:chance) of the code being valid and well-formed is smaller than of the code being incorrect. Many, many web sites out there don’t deliver well-formed code.
Personally, I agree with what Ben de Groot writes in his Markup in the Real World post. I prefer the advantages of XHTML when it comes to its syntax and what will be correct within it. However, Tommy once said to me that if you can’t guarantee valid XHTML you shouldn’t use. Generally, I see his point and think he’s right, but to strike the note Ben does, I can guarantee my part of it but there will always be factors like third party content providers, such as ad providers, sub-par tools for the web site’s administrator and so on. And for the reasons Ben mention, I’d still go for XHTML.
So, conclusively, I have to ask: do you think XHTML sent as text/html is ok, when it follows the Appendix C of the XHTML specification? Do you agree with me that having a web site break and show nothing but an error if something’s not well-formed isn’t good business practice?
I reacted in two ways when I heard about his presentation and the crowd reaction:
It’s very good and about time that this is being focused on.
This belief is based on an old era, the so-called browser wars days, when IE 4/5 and Netscape 4 were fighting for domination. And we all know how that went…
Nowadays, if you write proper scripts according to the standardized DOM, also known as DOM scripting, you will target virtually every web browser in the market. For a comparison, you will even get more widespread support than CSS 2 has!
The problem we had was to get the scripts to work in all web browsers
If Microsoft only had taken the proper time and decision to implement proper DOM scripting, which is supported in any major web browser, as well as from IE 5 and up on PCs, things would’ve been fine. So, let’s kill this misunderstanding once and for all that has flourished for a long time. Correct written scripts will work in any web browser.
Trust me, it’s a whole new level that will give you a big smile when you realize what you can accomplish! 🙂
An old colleauge of mine, Oscar Berg, has started blogging. Oscar is well-experienced as a Business Analayst and Usability Designer, and I have to admire him for finding the time to start blogging with having two kids (and a third on the way).
He is one of the people behind the initial launch of the hugely successful hitta.se, and I actually wrote the very first HTML prototype of it. But unfortunately the company that owned the technical part of the project decided that they knew enough to code the interface themselves. If you look at the web site’s code, apparently they didn’t…
Anyway, for those of you interested in the business perspective on things, I strongly recommend a visit to his blog.
A common problem is that the Web Forms and Web Controls in ASP.NET generate invalid XHTML. Amongst these errors are invalid attributes and inline elements without a correct block element container, as well as good ol’ HTML comments in a script block, which prevents you from sending your XHTML with the application/xhtml+xml MIME type.
All these errors are automatically created when the page in question is being rendered in the web browser, meaning that even if you write flawless code you will still fail to get it valid.
To the rescue, some solutions to take care of this:
(for the vast IE 4 support required?) and still HTML comments in scripts block.
My advice to you: some way or another, make the extra effort to make sure your XHTML from .NET is valid. It’s not that big of a deal, and it’s totally reusable in your next .NET-based project.
Do you have experience of above techniques to make it valid, or some other way to accomplish it? Please feel free to share!
Seems like a pretty easy question to answer, doesn’t it? Well, it isn’t. If you look further than the obvious standpoint, that of course one wants every web site to be accessible and usable by everyone. From a perspective based on respecting and catering to people with different needs, accessibility is a given.
However, let me give you some background first by pointing you to two good articles Roger has written:
About people jumping the bandwagon stating that they create accessible web sites to get PR and make money, and then ignorant journalists that don’t do proper fact-checking support their claims.
With that as our canvas, enter the business factor. Sure, WAI is the hype word for the moment for IT sales men, but I’m sorry to say this: I still haven’t had the opportunity to work in a project that offers an accessible web site, or even a project that has had that set as a goal. For instance, take the project I work in right now: It’s a web site based on a Microsoft .NET-based CMS product from one company, with the addition of extensions from yet another company.
To start, we all know that Microsoft .NET generates code that can’t be validated as strict XHTML or HTML.
The CMS product generates some invalid code on top of .NET’s plus the fact that it has a WYSIWYG tool based on Microsoft’s contenteditable property, which, to say the least, generates terrible code.
To top it off, the extensions mentioned above use span tags as the ultimate block level element, encompassing everything (span tags are inline elements, you morons).
There’s too little time and money (as always) in the project, so there simply isn’t any window of opportunity or incentive for any system developer to fix the .NET errors. And even if that had been taken care of, we would still have the WYSIWYG and extension problems. So, with that in mind, accessibility isn’t even on the agenda. And we’re talking about a web site that has roughly 60 000 – 70 000 visitors per day!
And, from my experience, this is not an uncommon situation at all. Generally, when you present the accessibility factor to a company, they want it “in the package”, but they’re not ready to pay anything more for it nor allow for any extra testing. Most companies (and visitors that don’t need the accessibility enhancements) are happy if the web site in question displays somewhat correctly. They don’t give a damn if it follows web standards, uses correct semantics or is accessible to people with other needs. The companies normally seem to think that the percentage of visitors they lose in not being accessible doesn’t make up for the time and testing it takes to go that extra mile (no notice taken to the bad will this will create, however).
Take note that the site do not follow web standards, is using frames, do not validate, have a lot of accessibility problems.
I have no doubt that Jens will do his best to push things in the right direction in the future, he seems like a knowledgeable person, but the fact still stands that its current state didn’t keep it from getting first place. Another example that seems to come up is Google. Do a search for Robert Nyman, and it returns a page with 437(!) warnings/errors (Ironically, a MSN search, of all web sites, returns a valid XHTML Strict page, although not sent with the application/xhtml+xml doctype, but that’s a discussion for another day). This gives people the argument that:
Well, Google seem to do pretty good. And if they don’t care about web standards or accessibility, why should we?
I don’t really know how to argue with that. Even if every web interface developer in the whole world would know how to create accessible web sites, we still need to convince businesses, customers and decision makers to take it into consideration, to sell the idea of accessibility to the ones that ultimately make the call!
I’m back! Feels good to be home again. Actually, I’ve been home a little bit over a week, but that week has been spent going to a party with my new employer, attending a wedding and also starting at my new job. During that week, I have also been building and setting up our Rome trip web site, optimized for IE 4 and later (just kidding, ok?). We had a great time and you can find travel stories, pictures and video clips in the web site!
Since people found out that I had come home again, they started asking me when I was going to start blogging and write my next post. This makes me really happy, to see that people appreciate my writings!
A friend of mine, Per at Gamepepper , pointed out to me that I have at least reached #3 in the Lifecycle of Bloggers. 🙂
However, I must confess that I’ve flirted with a lot of the other points as well…
I have come to the conclusion that I won’t be writing a new post every day, Monday – Friday, but maybe somewhere around 2-4 posts per week. This is not due to not having enough topics to cover or lack of motivation, rather just that I have to spend more time with my family and doing other things than just sitting in front of the computer (no, this is not a faux “retire”).
Also, writing every day has lead to some people missing a few of my posts, since they just don’t have the time to visit my web site/read the RSS feed every day (however, what would be more important than that, I have no idea… ;-)).
So, with this move I hope my posts will become better and I aim to write really interesting pieces in the future!
I would be very happy if you were to write a comment what you think about the Rome trip web site, or my move to writing fewer (and hopefully better) posts!
Update! For you web developers out there: Resize your web browser window in the Rome trip web site and look at the dynamically sized masthead image. Also, take notice of the fixed navigation bar that even works in IE 5!