Category: XHTML/HTML

About XHTML/HTML

Categories
XHTML/HTML

IE8: Not supporting XHTML?

Recovered from the Wayback Machine.

Continuing from previous post

Following are the web log entries that contain the new MSIE 8.0 user agent string, with the specific MS IP address blocked out:

—-.microsoft.com – – [04/Mar/2008:01:55:29 +0000] “GET /favicon.ico HTTP/1.1” 200 1406 “-” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022; MS-RTC LM 8; OfficeLiveConnector.1.0)”

—-.microsoft.com – – [04/Mar/2008:01:55:29 +0000] “GET /standards/ie8-standards-mode-by-default/ HTTP/1.1” 200 29177 “http://www.techmeme.com/” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022; MS-RTC LM 8; OfficeLiveConnector.1.0)”

Typically, IE access to this site results in only one log entry: the entry for the specific page. There are no log entries for CSS files, JS files, and so on, because IE doesn’t support the XHTML MIME type, and therefore doesn’t parse the page and pull these resources. This is what I’m seeing in my web log for these log entries.

These two log entries also reflect the new Office Live functionality, just released. The Office Live functionality could impact on what’s picked up from a page–hard to say, because I don’t have any Office Live accesses for my sites that aren’t strict XHTML. However, if these log entries do reflect access of the post directly with IE8, based on the fact that none of the CSS or image files were also pulled, and based on the pattern of access of pages at this site by previous versions of IE, IE8 does not support the XHTML mime type.

To repeat what I said in the last post, this statement isn’t based on a confirmation from the company. It’s a guess based on current web log entries reflecting the new user agent string for IE8, an IP address that resolves to inside Microsoft, and matching a pattern I’ve seen with previous IE versions that cannot access this site because of the MIME type I use. With the continued silence from the IE team and Microsoft, guesswork is all I have to go on. I sincerely hope I’m proven wrong.

Categories
XHTML/HTML

IE8: Standards mode by default

Recovered from the Wayback Machine.

Others might talk about Microsoft’s move to the clouds, but one decision MS made shows its feet are firmly planted on solid ground: IE8 will be standards mode by default.

This was a good decision, but it’s also an ominous decision. Not a word on support for the XHTML mime type. With no clear idea of exactly what MS has planned for this release, I am forced to hold my huzzahs until we see what IE8 actually delivers. According to the ieblog report, IE8 will be one of the topics covered at MIX08. Perhaps we’ll see the first beta release of IE8 this week.

To put this in perspective, Microsoft has just agreed to deliver what Opera, Firefox, and Safari have always delivered.

update One interesting thing about this announcement–the IE program manager announced the move on the ieblog, and Ray Ozzie announced it in the press release. Where’s Chris Wilson?

second update Jeffrey Zeldman sounds like a man who put himself on a line that just disappeared.

third update I just sent an email off asking the opinion of someone who knows this stuff better than me what he thinks, but from web log entries for this site, based on the new MSIE 8.0 user agent string, IE8 does not support the XHTML mime type. I repeat: IE8 does not support pages served up with application/xhtml+xml.

Again, this statement isn’t based on a confirmation from the company. It’s a guess based on current web log entries reflecting the new user agent string for IE8, and matching a pattern I’ve seen with previous IE versions that cannot access this site because of the MIME type I use. I sincerely hope I’m proven wrong.

Categories
SVG XHTML/HTML

If you’re pushing the grapefruit, make sure the apples don’t stink

Though RealTech is a weblog, it’s also the place where I do much of my experimentation with technology. It’s the site I use to test out the plug-ins, graphics applications, and what not I’m eventually planning on using in the rest of my web sites. Normally you don’t use a ‘live’ site to test changes, but I happen to think a live technology weblog is one of the better places to try something out. All those juicy testers.

However, one of the downsides to such effort is that the page may be challenging to access at times. Or a challenge to access at all times for IE7 and lower if it comes to that.

Another downside is that when I’m pushing one type of technology, my uses of other technologies may make it seem like the one I’m pushing is causing problems, when the reality is it could be any number of other tweaks and tricks.

As an example, I’m a big fan of SVG and XHTML. I serve my pages up as XHTML, and I use SVG inline. I write quite a bit on XHTML and SVG because I’m trying to encourage the use of both. If you access this page and it loads slowly, or seems to have other problems, you might think ithe problems are generated by my use of SVG, because it’s the technology I write about the most. However, it could also just as likely be any of a number of other tweaks I’m currently trying out.

In my post WordPress at the Top: Not, a couple of folks (Seth and Daniel) mentioned they had problems loading the page and scrolling and both thought it might be the inline SVG. It’s true that in their client environments, the inline SVG could be causing the problems–especially with my use of gradients, which are quite CPU intensive.

However, a little experimentation of my own shows that problems with the scrolling could also be caused by two older technologies: the first being the use of the CSS fixed background, which no browser seems to handle efficiently; the second being the use of the JavaScript-collapsed posts.

I also use rather large images in the header, and load them as background for elements, which turns off image caching. The lack of caching and the larger image sizes, combined with the derived CSS could slow load times. However, my experiments for sampling images and deriving CSS elements rather depends on my use of the CSS background attributes for adding the images, rather than just loading them using IMG.

To determine whether it is the SVG causing problems, or my other tweaks, I’ve removed the fixed CSS positioning, for now, as well as the collapsed posts and optimized the images and slimmed down the code deriving the CSS. If you’ve noticed performance problems in the past, can you access the pages now and see if the problems you had have been eliminated?

In the meantime, in addition to the other changes I’m making to support XHTML (BTW, you’ll notice that my XHTML validation of comments is too strict at this time, and will more or less give you invalid errors for any use of element attributes), I’m going to look more closely at my use of photo sampling, photo as CSS background, and what I can do to improve this type of functionality.

Then I’ll probably corrupt all that hard work by experimenting around with something else new, and causing my site performance to tank. Again.

Categories
XHTML/HTML

Speaking of tanking

Recovered from the Wayback Machine.

Speaking of tanking, the comment thread to the WaSP post on the round table on IE8 versioning took an interesting turn.

A real consensus is that Microsoft should be supporting XHTML (not to mention SVG), and that XHTML strict should trigger standards mode. I think there’s considerably more people supporting XHTML than people assume. I also think this could be a way for MS to save its bacon.

If Microsoft doesn’t follow this advice–doesn’t support the XHTML MIME type, doesn’t turn on standards mode for XHTML strict–the company is sending a message that transcends issues of browser versioning.

Categories
XHTML/HTML

XHTMLating feeds

Jeff has been adding SVG annotation, as well as objects to his weblog design. When using SVG, the first issue that arises is serving up XHTML in order for the SVG to be processed correctly. This also means serving up your Atom feeds, accordingly.

In Jeff’s case, he’s using the object element to incorporate SVG annotating the post type. If he inlined his SVG, and wanted it processed correctly in feed readers (both big ‘ifs’–stripping out the SVG is also an acceptable response), two things need to be modified.

First, there’s an html_type option value that needs to be adjusted. The only want to do this at this time is to manually update it in the database. I had thought there was a modification made to WordPress to add this as an Administration option, but I couldn’t find it in the checked in code.

I hard coded my feed for this weblog to XHTML, and made the appropriate adjustments, removing the CDATA section and adding a wrapping DIV element (source for feed and comments feed).

To ensure the two feed files don’t get overwritten, I have a plug-in that I use to override the location of the atom feed files, pointing the location to files in my theme directory.

This is only a temporary fix, though. The real fix would be to provide an option to set the html_type in the admin page, which then serves the weblog pages up accordingly, as well as being used to set the type in the feeds. The value should also be used to determine the output of the content in the feeds.

All of this could be done in plug-ins. What can’t, is handling input from readers when serving up XHTML pages. Input from readers enters WordPress in several different places in the code, most of which do not have hooks allowing us to override the code to provide our own. The only way WordPress will be able to effectively do XHTML is through a commitment to make this a change in the underlying base code.

Since the WordPress developers have not shown any interest in supporting XHTML, and since I haven’t seen a lot of interest in XHTML support in WordPress from my own explorations and published posts, this is just not a challenge I’ve been eager to take on.

The real question is will Microsoft support the XHTML MIME type in IE8? Not having support for XHTML is one of the major browsers is probably the biggest hold up on more widespread support for XHTML. Otherwise, I would think that the increasing interest in SVG would start generating enough movement towards XHTML to finally trickle it’s way into the WordPress community, regardless of the aversion to XHTML of the development team.

PS I would appreciate help testing my current XHTML validation in my comments. You can’t hurt anything with the way the comments are now currently moderated.