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.