The HTML 5 Test is a really cool site that tells you how much HTML 5 support is built into your browser. With Apple screaming “We have the best HTML 5 support” I thought it would be logical to visit The HTML 5 Test and see who’s the real winner.

I went on Monday, June 7, the day Safari 5 was released. I went back on Tuesday and discovered that the test had been revised. The original test had 160 possible points, while the current test (released on Wednesday) has 300. I’ve broken the tests down by New (300 point scale) and Old (160 point scale). The score does not include bonus points

Google can claim they beat Apple and offer better HTML 5 support, but that’s if you’re using the 6.0 developer version, which most of you shouldn’t be using.

Apple can claim they beat Google and offer better HTML 5 support with the current stable releases, which is probably a more accurate claim.

The truth is support is still pretty crappy. Speaking of crap, Microsoft’s IE 7 and 8 are POS when it comes to HTML 5. Yeah, yeah, yeah, I know IE 9 is so much better, but nobody in their right mind would test it on their production machine. That’s assuming their production machine isn’t running XP because IE 9 won’t work on XP.

I’m too curious. I installed the IE 9 Platform Preview on my Vista laptop. IE 9 isn’t really a browser, but more of an HTML viewer. For one thing, you can install it alongside another version of IE. That’s really, really difficult to do in the real world.

As you see in the scores above, IE 9′s HTML 5 support is less than IE 8, but greater than IE 7. I’m not impressed. Here’s a screenshot showing the new, still limited support.

Post from: Web Pages That Suck -- Daily Sucker

Google Beats Apple And Apple Beats Google in Supporting HTML 5. IE Still Sucks.

I hate forms. In fact, if I’m not mistaken, WPTS is a form-free zone. However, they’re insanely important for most sites and here’s “Best Practices in Form Design,” a free, downloadable, 133-page PDF (4.37Mb) from the guy who wrote the book on forms.

Download the PDF

Post from: Web Pages That Suck -- Daily Sucker

Something that doesn’t suck about a topic that does.

An old high school buddy, Terry Schill, came up with a brilliant take about recent Twitter events: “Not bragging, but all of my Tweets are going into the Library of Congress….who would have known?”

Definitely NOT The Daily Sucker.

The best part of the Twitter deal is that everyone can now legitimately tell people, “I’m an author. My works are in the Library of Congress.”

Post from: Web Pages That Suck -- Daily Sucker

Wish I Said This First

Speaking of testing your site’s performance (and I have been talking about it), try Zoompf’s Free Web Performance Assessment, created by Billy Zoompf (not really, he’s Billy Hoffman but I like calling him Billy Zoompf because it reminds me of Billy Zoom from the great LA band X). Billy is one of those fricking genius kids that we all wish we were. You can see a sample report of Porn.com “with extremely tiny pixelated nakedness,” which may make it NSFW.

Post from: Web Pages That Suck -- Daily Sucker

Free Web Site Performance Test

Not the Daily Sucker – Information Architecture TV: Wireframes

Check out the site. Content doesn’t suck.

Website Wireframe Lecture from Chrissy Kimball on Vimeo.

Post from: Web Pages That Suck -- Daily Sucker

Not the Daily Sucker – Information Architecture TV: Wireframes

I’m spending a lot of time working with web page speed. I discovered an interesting factoid: if you throw all your HTML, Javascript, CSS and graphic files in the same directory (and modify your files to account for this), your pages will load 20-30% faster. Of course, I wasn’t a math major.

Post from: Web Pages That Suck -- Daily Sucker

I’m getting better

Submitter’s comments: Now this is nice! It has a beautiful horizontal navigation, which you can control by keyboard, too. Needless to say that it breaks my favorite hotkeys Alt-left and Alt-right to navigate backward and forward in my browser.

Just tried to click some post called “Rethink. Redefine. Redesign.” Would be a great idea. When you’re at the utmost left or right position, which you cannot tell as there’s no horizontal scrollbar visible, you automatically jump to the next/previous article. And as you can see at the upper right corner, you can also press the letter ‘s.’ No idea where that brings me, but at least it does something. You can even point with your mouse at the letter ‘s’ and my browser says that I can click on it. I do not dare, as no url shows up on my status bar, so I don’t know what happens.

Oh wait! The ‘s’ was the last letter of ‘Issues’. I just had to make my browser window a bit wider. Lucky me that I have a screen capable of 1280 pixels horizontally. But everybody has wide screens, nowadays, don’t they? (And lucky me I know how to turn off Javascript, which disables this crap and results in a normal, vertical page.)

Vincent Flanders’ comments: This site conveniently classifies itself as “experimental,” which disqualifies it from being a WPTS Daily Sucker — no matter how much the site sucks. And the site sucks much.

The site’s content consists of articles. Articles are composed of words. Words need to be presented in a linear fashion and that means top-to-bottom — not horizontally, which necessitates scrolling (or, in this case, clicking). The navigation goes batshit crazy on the feature pages. This is an information site and people expect to see content presented conventionally. Remember: it’s experimental; it sucks; and it isn’t the Daily Sucker.

There are a lot of contrast problems, as this screen capture by the Juicy Studio Contrast Analyzer demonstrates. Remember: it’s experimental; it sucks; and it isn’t the Daily Sucker.

I hate writing that looks like it came out of dack.com’s Web Economy Bullshit Generator. The modus operandi page of today’s not-the-Daily-Sucker has the following phrase:

We tried to think ahead and create a site that was a paradigm shift in interactivity and turn the traditional blog format on its head – or in this case, on its side.

Paradigm shift? Bullshit. If I want a paradigm shift, I’ll stand in front of the San Andreas Fault and wait for the big one. (Yes, I’ve used the phrase twice on WPTS, but it’s used sarcastically). Remember: it’s experimental; it sucks; and it isn’t the Daily Sucker.

Thinking for a Living

Post from: Web Pages That Suck -- Daily Sucker

Thinking for a Living – Not the Daily Sucker for Monday, March 1, 2010

I ran into two articles about problems in using a CSS file for printing:

1. Browser Performance Problem with CSS “print” Media Type (December 2009)
2. 5c media=print stylesheets (February 2010)

It turns out that if you’re using a print stylesheet (shows up in the format <link href=”print.css” type=”text/css” rel=”stylesheet” media=”print” />), every other file has to wait to load until print.css finishes loading.

To get the full effect of the delay, I created a 583Kb print.css file — which may be the world’s largest print.css file — and placed it in the head of this HTML file. Notice how long the page takes to display (I’ve turned off caching and file compression.).

The following picture shows what happens (click graph for larger example):

The page took 7.42 seconds to load. Page Speed gave the page a score of 81. Yslow gave it a “B,” with a score of 84. These two tools are extremely important and should be in your arsenal.

Optimizing the page. I removed the CSS from the <HEAD> of the document and inserted the Javascript code from Article 1 just before the </BODY> statement.

<script>
window.onload = function() {
var cssNode = document.createElement(‘link’);
cssNode.type = ‘text/css’;
cssNode.rel = ‘stylesheet’;
cssNode.href = ‘print.css’;
cssNode.media = ‘print’;
document.getElementsByTagName(“head”)[0].appendChild(cssNode);
}
</script>

</body>
</html>

As you can see in the graph below, the document loads much faster (click on the graph for larger example). All files load in 5.97 seconds, but the whole page (everything but the print stylesheet) loads in 2.11 seconds — the visitor quickly sees the page and doesn’t care that the print stylesheet loads last because s/he may never want to print the page and if s/he wants to print the page, it won’t happen immediately.

Page Speed gave this version of the page a score of 85. Yslow gave it a “B,” with a score of 83. Page Speed liked the page 4 points more, but Yslow liked the page 1 point less.

Since nobody on Planet Earth is going to print a document immediately after it loads, it’s safe to use Javascript to load the print stylesheet. What if they don’t have Javascript enabled? See Article 1 for the answer.

Yes, it’s true that nobody is going to have a print stylesheet that’s this large (it’s composed mostly of comments) and the improvements aren’t as important as caching and compressing your site’s files, but it’s good to be aware of what causes roadblocks in displaying your web pages.

Post from: Web Pages That Suck -- Daily Sucker

Not The Daily Sucker – Your print.css file is hurting you

Customers Increasingly Intolerant With Slow Web Sites

Post from: Web Pages That Suck -- Daily Sucker

Not The Daily Sucker