Introducing: XHTML Dev

Ben Scofield, Development Director, July 28, 2008 4

We’ve recently started reviewing our markup and CSS standards at Viget (we do this periodically to make sure that we stay up to date with recent developments and changes in the landscape). As part of that, we’re looking into the whole XHTML/HTML MIME type issue (brief summary: sending XHTML with the text/html MIME type is technically wrong, but sending it with the correct application/xhtml+xml MIME type is broken on some browsers).

After a fair amount of discussion, we’ve settled on releasing production sites written in XHTML and served as text/html (there are several reasons for this, but they’re mainly outside the scope of this post). We very much wanted to get some of the benefits of serving these pages as application/xhtml+xml in development, though, so I took a little time last week and whipped up the XHTML Dev plugin.

Basically, installing this plugin forces your Rails application to serve pages as application/xhtml+xml—but only in development. That means that our designers and developers can build out pages and easily check them for well-formedness in standards-compliant browsers (which show error pages when given malformed application/xhtml+xml markup) without having to hit an external validation service. The plugin is inactive in production, which means that third-party and user-generated content won’t break the site unexpectedly.

Of course, there’s still the issue of testing with older browsers in development, and for that the plugin provides a before_filter (handle_with_ie). With that filter in place, any requests from IE6 or earlier browsers will receive text/html responses.

It’s a simple plugin, but it’ll make things a little easier for us down the road. If you’re interested, grab it from GitHub.

Posted in Tools of the Trade on 07/28/08 4 comments

Joan Piedra said on 08/01 at 09:41 PM

Hey Ben,
I like the idea to create a filter and use the correct mime when possible.

This made me wonder, if you are validating it already why does it rollback to the text/html mime-type in production mode?

Is it because you are trying to control future updates and possible markup errors on the production site? So if you are using the application/xhtml+xml mime-type it won’t break the whole site on current browsers?

Regards,
Joan.

Ben Scofield said on 08/03 at 08:23 PM

That’s it exactly, Joan. Many of our sites rely in part on end-user-generated content, which opens the door to potentially invalid markup. Falling back to text/html in production allows these sites to render correctly even when the content is less than optimal.

Joan Piedra said on 08/07 at 01:21 AM

Hey Ben,

Right, it’s always helpful to make end-users’ life easier even if they made html “wrong”.

I don’t even think you let your users use html, so it’s more probable they could break anything using a wysiwyg editor.

Nice idea, and useful indeed.

Regards,
Joan.

J. Ryan Sobol said on 08/16 at 12:40 PM

Quite the pragmatic solution. It’s impressive that you 1) took the time to review your standards and 2) contributing your work back to the community.

Thank you!