Web Devout tidings

Yes, I know. I’ll be testing its standards support, too. Firefox 3 will be released this coming Tuesday, the 17th. I won’t have the standards support information done yet for either browser, but I hope to finish the CSS sections this weekend and put that up by Tuesday.

It’s browser testing season again. Since the first Firefox 3 release candidate has been released, I will begin testing its standards support and adding it to the site. As usual, I’m going to start with the CSS section and post an update when the initial test data is complete.

Rather than using a standard test suite, I prefer to write custom tests as I go. This allows me to get into the nooks and crannies of standards support, but it does take longer. Starting now, I’m going to save all of the test cases of bugs that I find, and at some point I’ll make those test cases publicly available.

My testing process usually works like this: I initially assume that everything with a “Y” in the last version also has a “Y” in the new version, so I’m not testing for regressions in my initial test data. This saves a lot of time, and I can add regression information later as it is found. Next, I go through each “I” and “N” and retest the browser’s support. Features that still have “N” support go by quickly, so it’s the “I” features that take the bulk of my time. The time it takes to complete a section depends on a number of factors, such as the demands by my day job, how scorching hot the weather is, and whether or not the pizza has arrived yet.

In regard to Safari 3 information, that will not be part of this test session. Adding information for a new browser from scratch is a ton more work than updating for a new version, and I want to get the Firefox information out there quickly. At some point, though, I’m going to bite the bullet and do the Safari 3 testing, even if the information isn’t very thorough at first (the IE, Firefox, and Opera information started off very rough as well). Until then, here are some sites you can check out for Safari (WebKit) support information: SitePoint Reference, Wikipedia, Quirksmode.

I haven’t really added anything to the Web Devout site in a while. In fact, I’ve even fallen behind on the security summary updates for all three browsers. A lot of it is due to my very busy work week, trying to fulfill the “guy who solves all our problems” role for several different projects. But I have been committing my weekends to Web Devout.

So why haven’t there been any changes on the site? Well, changes are happening, but they’re happening somewhere else. A couple of weeks ago, I was given a powerful new server, all to myself, with tons of bandwidth to spare. Because this is the first time I actually have full administrative control over the server, and I can actually use recent versions of PHP and whatnot, I’ve decided it’s time to give several sections of the site some much-needed backend love (nmiaow). And while I was at it, I went ahead and started rewriting the entire site from scratch, based around a new modular homegrown infrastructure that will make future development a lot cleaner. I’m designing it with the idea that I’ll eventually open source it for other people to use. This rewrite will also give me a chance to implement an OpenID-based user account system seamlessly with all services on this site, and I hope to develop an early working version of my long-planned public bug tracking system by the time the new site goes public.

For those of you just tuning in, I want to make a single public bug reporting and tracking system for all versions of all web browsers, with focus on simplicity and ease of use (as opposed to, well, Bugzilla). Well-confirmed bugs will be automatically put into a table structure similar to the current web browser standards support resource. I hope it to be entirely user-driven, with little to no editorial oversight needed. We’ll see how well that goes. ;)

I’m still a long way off before I have something to show you, but hopefully it will be worth it.

When you send XHTML to a browser using the common text/html content type, all major browsers will respond by using their regular HTML parsers on your page, regardless of the doctype. For some reason, the W3C HTML Validator doesn’t follow this widely-accepted convention. Instead, if you’re using an XHTML doctype, the W3C Validator will use an XML parser on your page. Obviously, that will give different results than what your browser is seeing. And unfortunately, there was no easy way to force the W3C Validator to parse your page with an HTML parser like everyone else did.

That is, until now. I’ve just released the new Validate XHTML Parsed as HTML tool. It works very much like the HTML Good Practice Checker: you submit the URL you want to test, it makes a few minimal changes to the beginning of your markup in order to modify how the W3C Validator sees your code, you click the button to validate it, and the results appear below.

The purpose of this tool is to illustrate how the compatibility issues between XHTML and HTML are not as simple as whether or not you follow the HTML Compatibility Guidelines. A fully-compliant HTML parser following widely-accepted conventions for parsing mode selection would encounter all of these errors when attempting to parse your page. Popular web browsers don’t support the Null End Tag construct, so they would see it slightly differently, but they would still see errors in each instance of /> on the page. I thought one of the selling qualities of XHTML was that it was supposed to put an end to lax error handling. I guess not.

I apologize for the lack of updates here lately. I’ve been swamped at work with projects of biblical proportions (you know, getting colleges to actually talk to each other), all due at the end of August or September. Hopefully after that I can get back full-swing into some of the stuff I’m developing for Web Devout.

In the meantime, you can read some of my latest posts at Tech Center Current or my random non-serious blog Nanobits.