Professionally I make sure that I devote a certain amount of time every week to reading articles, whitepapers and blogs related to every aspect of web development. The subjects range from web design, to programming, SEO, and those that I spend a considerable amount of time reading about: web standards, accessibility, and pretty much anything related to the W3C. The communities based around those "W3C"-centric subjects are host to some extrordinarily well-research articles, posts and comments which is largely in part to the time afforded from the relatively slow pace in which major changes occur in respect to the major areas of HTML, XHTML and CSS.
Lack Of Support
One topic of controversy in this area has been Internet Explorer 7 not supporting the application/xhtml+xml MIME type, which essentially means not supporting true XHTML as specified by the W3C. Of course with this being related to Microsoft there is the expected amount of flak coming from the anti-Microsoft camp. That said, even once you've filtered out the extremes from the discourse, there are still a lot of people who think Internet Explorer 7 killed/is killing XHTML.
The support of Internet Explorer is certainly an important factor in the mainstream adoption of a web specification, considering that all versions of IE account for over 50% of web browsers used on the net. It seems reasonable that people would think that not supporting true XHTML would be a devastating blow to a specification that has been continually rising in popularity. In a time when IE is still recovering from the frustration of web developers everywhere about IE6's poor handling of CSS it's not hard to see why a lot of people think that the IE development team has a grudge against the W3C.
Tough But Fair
The IE development team is not stupid. They are also faced with the task of creating the browser that is used by millions of people every day. It is important to remember this because the decisions made regarding the development of IE are hardly made lightly. In a post on the IE Blog Chris Wilson, the lead program manager for the Internet Explorer platform and incendently a member of the XHTML 1.0 W3C working group, explained why IE7 does not support XHTML served as application/xhtml+xml.
The reasoning was that implementing support would involve hacking in XML constructs to the existing HTML parser in IE7. The existing parser is based on compatibility, and even if the support for properly served XHTML was implemented it would still have to accommodate invalid documents, which is exactly what shouldn't happen with an XHTML document (example of what happens when attempting to view an invalid XHTML document served as application/xhtml+xml). If support involves the same silent support for invalid documents, there is really no point.
In fact, had IE7 implemented support in this fashion it would have been worse for XHTML. Take a look at how many HTML documents on the web even come close to validating against their DOCTYPE. Now think about how many of those documents use XHTML (usually as a matter of the developer trying to look like they are on the cutting edge of the internet!. )If all of these non-valid XHTML documents stopped working in Internet Explorer the average IE user, discovering that a significant portion of the websites they visit don't display in their browser, would have reverted to IE6 (shudder), which would certainly have been counter-productive to the goal of increasing the adoption of XHTML.
All in all, it is natural to get impatient waiting for proper widespread support of XHTML. Just don't let the impatience make you lose sight of the big picture.
I have combed through thousands upon thousands of client's HTML documents since I began working in web development, and even more in my career as an SEO. Much of this time is spent fixing invalid markup, shaving off unneeded code, and generally doing what the original developer should have done in the first place. One thing that I quickly realized was that a disturbingly large majority of the sites I came across that were created by "professional" developers and firms seem to have absolutely no idea what a Doctype really is. This is especially true when I see these developers slapping an XHTML Doctype on their pages, somehow thinking that since it is newer it will make them (the developers) look better. As a developer who has actually taken the time to pore through the W3C specifications for the different revisions of HTML and XHTML, I find that practice rather irritating.
That being said, as a developer who actually knows the difference between the various doctypes it is easy to spot markup from lazy and/or ignorant developers. I should clarify that I don't expect all markup out there to pass the W3C validator 100%, nor do I expect perfect seperation of markup and structure. However, when you place that doctype declaration at the top of your document, you are essentially saying "these are the rules that this document is going to abide by", and when those rules are obviously ignored I believe that says a lot about the developer who created the page.
Those tell-tale signs are easy to spot. Self-closing ("/>") elements under an HTML doctype, or lack thereof in an XHTML document. Capitalized elements and attributes in an XHTML document (xml is case-sensitive remember!). Undefined elements such as <font> which has a cockroach-like ability of staying around, or attributes that aren't defined for the element they are declared on. All indicators that the developer doesn't really understand the language they are working with.
HTML really isn't that complicated. Someone who had never seen a piece of code in their life could pick it up within a week and have a working knowledge of the language. Unfortunately that seems to be the average professional understanding of it as well, because it is apparantly too much to expect someone who makes a living using a markup language to take a few hours and actually learn how to use it properly.
It's an exciting time to be an ASP.NET developer. As the ASP.NET community continues to grow we find ourselves with an ever-increasing aresenal of tools, controls and frameworks at our disposal. Unfortunately this can make the decision on a component a little more difficult, as very few of the components out there have reached that point where they are largely considered the "standard". ASP.NET blogging engines certainly fall in to this category, as many of you have probably noticed.
When I decided to create this blog I had some definite requirements in mind when it came to choosing a blog engine. First and foremost it had to render completely valid XHTML because I practice what I preach in respect to W3C compliance. Control over SEO-important aspects such as canonical URLs and meta descrition elements were a necessity. It also had to have a URL strategy that didn't rely on a "/page.aspx?id=123456789"-style mess of a querystring. Finally, the underlying code had to be well-organized and lean. Without a de-facto "standard" for ASP.NET blog engines I started hunting around and researching the options that were out there.
I tried some different ASP.NET blog engines such as dasBlog and subText, but found the markup that was rendered was not acceptable. Then I came across BlogEngine.NET, which, I was thrilled to discover, met all of my requirements. It's light weight, very easy to set up, and is very well-designed and organized under the hood. A nice feature is that, by default, it doesn't require a SQL database to run, instead storing all posts, comments and settings in local XML files. Of course SQL database integration is available, and is also easy to get up and running. Aesthetically it comes with a nice collection of themes, which are quite easy to modify, and creating your own themes is a straightforward process.
The above factors have led me to believe that BlogEngine.NET is in a position to become to ASP.NET what WordPress is for PHP. If any of you are currently trying to decide on a solid ASP.NET blog system you should definitely try BlogEngine.NET. You won't be disappointed.