Dave Winer has one rule that matters and a number of other good points on making standards and protocols.
Category Archives: Web Standards
“In recent years, Apple’s strategy towards the web can most charitably be described as ‘benevolent neglect.'” Nolan Lawson throws the gauntlet down by asking Is Safari the new Internet Explorer?
Twitter API
I think the opportunity has passed for the Twitter API to become a lingua franca for the real-time web. WordPress.com, Tumblr, Typepad, SocialCast, and Status.net all added support for the API in a way to make it as easy as possible for Twitter client developers — all they had to do was change the endpoint. The clients would then become a hub for users across different services, and had the ability to flourish regardless of the direction of the service they originally built on.
However because of perceived lack of market or a rush trying to keep up with each other and new features in Twitter’s API, like geo-location, we’re now close to half a year later and support for alternative endpoints in the major clients is haphazard at best. One of examples we all used to point to, Tweetie, is now owned by Twitter Inc. and doesn’t have much motivation to support other services in the future. Neither do the other official clients they’re rolling out. (Twitter.com/downloads is now a 404 page.)
For the record I completely support Twitter creating or buying official clients for every platform, including desktops. It’s what I would do in their position. However the third-party client developers that contributed immeasurably to Twitter’s success thus far are now in the awkward position of no longer being useful to their parent. It makes no sense for Twitter to have its user or signup experience mediated by a third party. None of the third-party clients have innovated enough in the user experience (for the most part they do not look or work significantly different from when they launched) or in cross-service support and flow.
If any of the clients had added seamless third-party API support when the opportunity first arose we’d all be pointing to them and promoting them. Now we’re more in a situation where, like Twitter, it makes more sense to build and promote our own because our users are demanding a multi-modal experience.
Typekit Web Fonts
Introducing Typekit, an iTunes-for-fonts on the web that allows you to have rich typography in your designs and pages without resorting to flash or image hacks. (Old time readers will remember my yellow design which used Dante, the original WordPress logo font, and generated-image titles.) Typekit takes advantage of the current and upcoming browser support for embedded fonts and abstracts away all of the complications thereof like Feedburner did for feeds. Brought to you by my friends at Small Batch, previously of Adaptive Path, Measure Map, Start, and Wikirank fame. The people building the web have been waiting for this.
Downloadable Web Fonts
Downloadable font formats for the Web. See also: Web Font Optimizer (visit in anything except Firefox). 2009 will be an exciting year for typography on the web, particularly when Firefox 3.5 comes out this summer. Hat tip: Mark Wubben.
Standard Argument
This post from Molly about HTML5 and the W3C, and the resulting comments, illustrate very well why the process of making or improving standards is so ugly, and why I don’t participate anymore. Discussions are dominated chiefly by people who have time to dominate discussions, which over time includes fewer and fewer of the people who actually should.
Open Source has the same problem and can usually survive it through things like rapid iteration, plugin systems, benevolent dictators, and easy forking. However I don’t know if those concepts could be successfully applied to a standards process, almost by definition.
King of Web Standards
Jeffrey Zeldman: King of Web Standards. Hat tip: Niall.
Invalid Atom
“Next time someone tells you Atom 0.3 is invalid because the validator says so, point them to this page. The validator is full of it, because it doesn’t reflect reality.” If Robert had comments, I would say “I never suggested Bloglines was “best-effort software development” (though I do love it and use it myself) but merely that it has an overwhelming market share. We’ve been tracking feed stats on WordPress.com and Bloglines and Newsgator online both dominate. The Web Standards project never casts stones from an ivory tower, they’ve always advocated practical standards for pratical benefits. Ben’s comment was akin to someone saying that the site sucked because it used XHTML 1.0 instead of 1.1, or if the validator decided to instantly “deprecate” all sites using HTML 3.2, 4.0, and XHTML 1.0 when 1.1 came out.”
Spamback
About 98% of Trackbacks are spam. Obviously that can’t be addressed with a new spec without breaking backward compatibility. (For added humor, see the front page of the Trackback Development Blog.) The charter of the new trackback abandons the only thing that made Trackback interesting, and incidentally one of the things it was created for, content aggregation and category aggregation and other applications that don’t require a link at all. (Essentially a push application of what everyone uses tags for now, it was way ahead of its time.) In the meantime, they’re re-inventing Pingback with XML-RPC replaced by Atom/REST.
DTD Magic
AJAX Commenting
This AJAX commenting looks pretty neat, has anyone made this into a WP plugin yet?
AJAX Spell Checker
This AJAX spell checker seems pretty interesting and functions a lot like Gmail’s. Has anyone written a plugin using it yet?
Dynamic Textareas
Tools for Textareas, the resizing textarea has been in the WordPress Shuttle development mockups for a while.
Usable AJAX
Google Reviews
So Google has done what hReview dreams of in the future, and they’ve done it without boiling the ocean and making everyone change their markup. If we all do million dollar markup we can enable multi-million dollar search startups to compete with billion dollar giants, with the obvious economic incentive for the hoi polloi being increased traffic from placement in the content aggregators.
XHTML Friends
XHTML Friends is a site doing some very interesting visualization of XFN data across the blogosphere, though it’s dataset is pretty new. Remember adding XFN info to anyone in your blogroll is simple as a couple of checkboxes, so you have no excuses! It would be great if XHTML Friends was the first service to suppor the “me” value for aggregating disparate identities. Some may have noticed that Technorati profiles now sport the “me” XFN value. I wonder why? 🙂
Phat FAT
Fade Anything Technique gives you the smooth “yellow fade” popularized by the 37 Signals crew. Check out this technique as well. We should roll one of these into WordPress, I can think of several situations where it’d be useful.
Search Engine Markshowdown
I decided to run the web page analyzer (excellent tool) against the front pages of a few of the latest and greatest search engines and also do a little analysis of my own. Here are some of the results in one of the only tables you’ll ever see on this site:
| Feedster | Technorati | Yahoo Search | ||
|---|---|---|---|---|
| HTML | 6.11 | 3.72 | 1.18 | 7.82 |
| Ext. CSS | 11.47 | 11.63 | 0 | 1.45 |
| Other | 9.10 | 6.70 | 15.10 | 1.72 |
| Total | 26.70 | 22.05 | 16.27 | 11.00 |
| Compressed | No | No | Yes | No |
Numbers are kilobytes, and may not add up exactly due to rounding. CSS is external, linked files. “Other” includes images and javascript.
Yahoo was the surprise winner here. Their HTML was alright but I think could be reduced quite a bit without losing anything. You’ll note they have the heaviest HTML of the bunch, heavier than other sites showing quite a bit more on their front page. They should probably talk to Doug. Overall though I think Yahoo has consistently been doing great nearly-standards-compliant work in their new designs. Yahoo could save about 67% of their HTML size with compression. Interestingly, Yahoo was the only site to specify ISO-8859-1 encoding, all the others claimed UTF-8.
Google was optimized to the hilt, but it’s kind of silly that they put so much effort into their markup but couldn’t go the last inch and make it valid HTML 4. They could probably make it a bit smaller with some more intelligent CSS usage. At least they don’t have font tags anymore. I think under normal circumstances they would have won but they have an olympic logo right now that’s pretty heavy. Google was the only site that used gzip compression for their HTML, but even uncompressed they only weighed in at about 2.4 kilobytes, still the lightest of the group.
Technorati clearly had the smartest markup of the group, and was the only one that validated. (An impressive feat for any website in this day and age.) Their markup is clean as a whistle with excellent structure and logic, and their numbers aren’t bad when you consider that they have a lot of stuff on their front page. This isn’t too surprising since Tantek did it. Their CSS, however, is pretty heavy. It’s strange because it’s very optimized in some ways but bloated in others, I think they could cut a few K from it pretty easily. One smart thing they did is have the CSS named with the date, so it’s name versioned and they can update it monthly without caching issues. All that said, they’re so far ahead of everything else they don’t need to worry about much. Technorati could save about 53% of their XHTML size with compression.
Feedster has its heart in the right place, but the implementation falls far short. For example it has a XHTML 1.1 doctype but then has the needless XML declaration at the top throwing IE into quirks mode. They use CSS in places, but then they have a table with 75 non-breaking spaces in it for positioning. There’s a ton needless markup, including a full kilobyte of HTML comments. On the bright side, they have the most room to improve. Feedster could save about 61% of their XHTML size with compression.
WordPress.org Search
I’ve ripped out the guts and redone the search on the WordPress.org support forums in the hopes of making it something more people will use. Try it out! The new system searches the wiki (hosted on a different machine), thread titles, recent posts, and does a FULLTEXT post search for the most relevant posts. It has contextual search highlighting (like Google).
When I have some time to get back to this every section will have a “more of this” link to take you to more results (paged). It does this currently with the wiki search, counting the total results and linking to the wiki search directly if there are more than 5 results. Probably still a few bugs to work out. The fulltext query was taking over two seconds to run until I tweaked the JOIN type to get the MySQL optimizer to use the proper index and join order. Everything should validate as XHTML.
A new system is also in place to inject custom results at the top of the page. We’ve been logging searches for the last few months (over a 129,000 so far, about 43,000 unique searches) and I’m going to be working closely with the documentation team to identify which searches are most common and what tailored information would be best to present the user with when they search for targetted terms, be it a blog post, an external resource, someplace on WordPress.org itself, a wiki page, or a specific thread. We can watch trends and spikes in searches to identify any problems in the application itself or features that may be insufficently documented or hard to use.
The work is far from finished, but I think it’s a strong first step into fully integrating search as a support mechanism and bringing the WordPress team even closer to the pulse of the users.
Google Doesn’t Read XHTML
Google doesn’t index application/xhtml+xml pages, geez what a mess. I prefer the rigidity of XHTML syntax but I don’t want the mess that comes along with it. Hat tip: Petroglyphs. Update: See comments.