Planet db79

Karl Dubost pulls together some references for thinking about how to handle Chinese, Japanese, & Korean (CJK) languages in the <canvas> API. Karl is constantly rocking the W3C weblog and I always consider his thoughts when he chimes in on a HTML WG issue.

Christina Wodtke suggests that one way to get people to upload meaningful avatars is to give them unrelated ones as a default. Her example shows an extremely beautiful woman (looks familiar but I am no celebrity expert) that doesn't quite sell her point IMHO. She does suggest that an image like a cro-magnon might do it. The exact motivational image probably depends on your community; William Shatner, Hilary Clinton, Charles Manson or Hello Kitty all seem capable of pacifying and provoking potential users in the right setting.

Gez Lemon and Steve Faulkner (among others) are working hard to make alt a required attribute on HTML 5 <img> elements. I'll publish my thoughts on this soon, I've got some research I need to collect still.

Dean Allen asks weblog owners (and calls out Dan Hill's cityofsound.com) to stop advertising multiple feed formats (RSS, Atom, etc) and promote only one. Dean suggests that people and software interested in other formats will know where to find them.

Update: Upon rereading Dean's post for the third time, it is not clear to me who his intended audience is. What follows is still appropriate though... whether it is the HTML author, weblog software, or Safari the solutions aren't that obvious.

Update 2: Dean follows up:

Having seen some responses to this, it’s clear I should’ve been less terse here. My point is that feed autodiscovery as it is in Safari (and Firefox, Camino, Firefox 2 on XP, Opera, iCab) is a very good thing, and I agree it’s perfect for this sort of application, allowing feeds carrying different content to be quickly tweezed out without one having to hunt for links on a page.

Cool, I think we're on the same page.

If however you argue that multiple formats are important because, say, Microsoft prefers RSS while Google prefers Atom, then it’s trivial for you, Microsoft and Google to work that out amongst yourselves (think CSS). Just please don’t require every single person who tries a feed autodiscovery popup to have to decide if they want their ice cream served in a boot, a Pontiac, or a waffle cone.

Ok, so now I picked a shitty example. :) My point was that: in the present "wild wild web" environment semantic web crawlers aren't capable of finding multiple XML formats unless you tell them where they are located. And sadly... given the completely shit state of feed formats (they are rarely valid XML) developers and content aggregators seem religiously devoted to one format or the other.

Also Jens Alfke chimed in with a similar post describing the autodiscovery legacy and the many problems with XML feeds.

One of the commentors on Alfke's post asks:

Is there a single aggregator out there that can handle RSS 2.0 but not 1.0?

It is not solely about feed aggregators. There are other platforms grabbing and parsing XML feeds. They should be doing both (well, they should be doing Atom) but it is just not that straightforward.

What follows was the original post (with some modifications):

Since John Gruber didn't call him out on this one, I've gotta throw my voice into the conversation.

Knowledgeable weblog authors have long complained about the plethora feed options displayed on the average weblog. RSS 0.91, RSS 2.0, Atom 0.3 and Atom 1.0? Who cares? Given that 88% of internet users don't even know what feeds are why complicate matters?

The problem with Dean's complaint is that in his example Dan is only actively advertising one feed. Visit Dan's website and if you read the content in his sidebar you'll see he only promotes one link to an XML feed with the text "Subscribe to this blog's feed."

Dean's web browser, Safari, is parsing the HTML page using the only "official" method authors have to alert HTML user agents to alternate content: the <link> element combined with a rel attribute and a a mime type attribute that signals if it is one of the known XML feed types. I call it unofficial because this practice has never been standardized to my knowledge. Mark Pilgrim pimped it and user agents implemented it after a couple major blogging packages started using it.

HTML authors can place references to alternate representations of their content by using the attribute+value pair of rel="alternate" (and in this case rel="feed" is a possibility, but it is not as widely supported as alternate.) There's no other way to "semantically find feeds". Options such as sniffing at common URLs and attempting to guess if you are using a common weblog system don't scale.

Safari could choose to advertise only one of the possible feed formats, right? Just pick the first element in the order it appears in the DOM or Apple could simply promote one format only. If only it were that easy. <link rel="alternate feed"> is not just about promoting multiple XML feed formats, it can also be used for alerting user agents to multiple content feeds: recent entries, recent comments, recent links, and so on. There's no easy way out for Safari and it probably does the most logical thing it could. (For the record Firefox does the same thing ... I'm not sure about Opera or IE. It doesn't really matter because I'm assuming you'd like to let bots know you have different feed formats. Google might prefer Atom and Microsoft might prefer RSS... it is a crazy world out there. Sadly, not everyone parses feeds using the Universal Feed Parser.)

Update: Well there is a very light specification for RSS Autodiscover. I wouldn't call this an official standard though... it is more of a "gentleman's agreement." This specification recommends Dean's approach:

Publishers who offer the same feed content in several syndication formats SHOULD NOT use autodiscovery links for all of them. Choosing only one feed format for autodiscovery makes it easier on new subscribers, especially if they are unfamiliar with syndication and can't distinguish between the Atom, RSS 1.0 and RSS 2.0 formats.

I still think there are use cases for providing links to alternate feed formats. Especially in the world of feeds there are a lot of bozos.

For background, here's a note from Lachlan Hunt on how HTML 5 is handling Feed Autodiscovery.

Following-up on my conversion to HTML 5 it looks like <meta http-equiv="imagetoolbar"> will not be considered valid in HTML 5. I missed an email, which is easy to do, back in Feburary 2008 from Ian Hickson about the IE Image Toolbar hack. Henri Sivonen raised this issue, probably because he gets gruff from authors who use his validator:

In short, some authors want to use <meta http-equiv="imagetoolbar" content="no"> but (X)HTML5 doesn't allow it.

Personally, I think that authors who want to disable User Agent features like that are misguided.

Ian Hickson responded:

Proprietary extensions to HTML are just that, proprietary extensions, and are therefore by intentionally not conforming.

And you know what? I agree and I've removed it. If Internet Explorer wants to implement a usability flaw then who am I to disable it. If IE users don't like the image toolbar they should complain to MSFT or switch to Firefox or Opera.

Via 37 signals and Socialized I see that JetBlue is actively participating on Twitter. Seeing transparent conversations makes me extremely happy.

Creative Review remembers Paul Arden. Odd that there is no Wikipedia entry for Paul Arden, who was a significant industry changing executive creative director for Saatchi & Saatchi.

John Gruber has written up a detailed comparison of the Firefox 3 and Safari 3 UIs.

John nails many of the things that are frustrating about using Firefox or Camino when you've come from Safari (or even other bundled OS X applications.) People get really bent out of shape about interface chrome that "looks" like Mac OS X but I don't see nearly as much effort put into working like a Mac OS X application should.

I would like to point out that there is a plugin called Fission for Firefox that will emulate the Safari style progress bar.

Rafe Colburn notes an important disconnect between Apple and 3rd party developers on mapping keyboard shortcuts to tabbed windows.

Apple uses "Command-Shift-Arrow" while 3rd parties are using "Command-#" where # is equal to a tab's position starting from the left of the application window (what happens in right-to-left language friendly applications?)

As someone working on the HTML 5 specification I thought it made sense to convert my weblog into valid HTML 5.

Nearly.

It is not quite valid in a few spots:

1. I'm still using the <meta http-equiv="imagetoolbar" content="no"> IE hack to prevent the image toolbar feature from kicking in. I believe that's still useful and I don't clearly understand why the spec prevents me from doing it. Sean Fraser was confused too, posted about it and got Ian's attention (scan the comments on Sean's post). Update: Highly unlikely this will be part of HTML 5.
2. My use of the footnotes feature in PHP Markdown Extra causes an issue because it utilizes a rev attribute on anchor elements. rev is currently missing from the HTML 5 working draft but I believe that was done because not enough research had been done to support including it at the time. I've started a dialog with the maintainer of the PHP implementation of Markdown (Michel Fortin) in hopes of proposing a solution to the W3C HTML Working Group.
3. Anywhere I've just blindly embedded the YouTube cut & paste code has a problem. YouTube doesn't automatically insert the data and type attributes on their <object> elements and that's a validation error. Given all of the issues with <object> I think forcing data and type is a good thing but the requirement does seem to fly against the "pave the cowpaths" design decision of HTML 5. Then again embedded YouTube videos hardly have any lasting meaning since I suspect many of these embedded uses will disappear with age in a very short period of time.

Though I'm about a year behind my swedish cohort my implementation makes use of the more experimental tags like <article>, <section>, <header>, <footer>, and <nav> where possible. I'll keep tweaking the format over time because there's no way I've interpreted the spec 100% correctly.

A growing list of people who find the Adobe Photoshop Element 6 install process clunky:

• Jens Alfke
• Michael Tsai
• Chris Turner
• And we'll throw in John Gruber's comments about all Adobe installers (except Lightroom) since the 90s.

Think anyone at Adobe is listening?

Thanks to a heads up from John Gruber I eagerly read all 818 perfectly chosen words from Dean Allen's return to writing at Textism. He's also been posting on Twitter if you feel the need to get all stalky. I love his Twitter avatar that features Orson Welles playing the brilliant, crafty, and cyncial Harry Lime from the 1949 film noir classic "The Third Man."

Let's not forget Dean's photo collection of his beloved dog -- the Daily Oliver (which has been lovingly tagged.)

Now if I could get more banter from 2lmc I think my internets will have returned to normal.

I don't think Mike Gravel exists as a candidate for President of the United States without the influence of YouTube.

If you've been using Adobe products for any length of time, you know the first-run experience generally falls on a scale between annoying and frustrating. Jens Alfke's rant about the "clunky" setup of Adobe Photoshop Elements 6 on Mac OS X 10.5 describes an experience similar to my own when installing Adobe software (on both Mac and Windows.) One should expect more of a product designed as the friendly, lightweight, easy-to-use version of the Photoshop family.

Ian Bicking throws nine Python HTML parsing tools at python.org and benchmarks the results with lxml (based on the C library libxml) coming out on top (at least in terms of performance and memory). The lesson here is that libxml is extremely fast and powerful and if your scripting language of choice provides access to it you should use it.