Closer To The Ideal

Sam Ruby has an awesome article on how to use OpenId. He summarizes:

All told: I signed up for one free service, installed and tailored one PHP script, added one line to my weblog template, created one simple XML file and added a total of four lines to my .htaccess files.

Ruby, Python, Perl, PHP, JSP, etc. For web development, the languages themselves have certain strengths, but they also, eventually, acquire software projects that make them famous. Ruby, of course, has Rails, and through that, all the software of 37 Signals, and also Twitter. PHP, in the early days, was known for projects such as Phorum. Python is known for Zope and the Universal Feed Parser.

I’ve worked with Ruby a little and PHP a lot but I’ve never worked with Python. If I ever learn it, it will be so I can use Venus. Venus uses the Universal Feed Parser to pull in a variety of feeds, and it has a template engine that allows the input to be output in any format: HTML, RSS, Atom, etc.

Sam Ruby explains the role that the Universal Feed Parser plays:

It handles multiple feed formats, date formats, and ill formed feeds. Just one concrete example to illustrate the point: the author name can be obtained from one of eight different places in your feed; and the Universal Feed Parser even handles cases where people simply put names in place of email addresses or tack on names as comments after an email address.

It partially cleans the HTML. It uses SGMLLIB to clean up the tokens, then it removes unsafe constructs (like plaintext), and resolves relative URIs.

The Apache license is more open than the GPL. Richard Stallman claims that version 3 of of the GPL is now compatible with the Apache license. Same Ruby points out that this is a one-way street in terms of compatibility; the GPL can use Apache code but not vice versa.

In the comments, Ruby explains:

In order to preserve the “universal-donor-ness” of the code that we produce, and in order to prevent license surprises, the Apache Software Foundation will not distribute code which has either a direct dependency on GPL licensed code, or will only meaningfully operate when GPL code is installed. None of this precludes, for example, end users from combining code from the ASF with a GPL licensed JDBC driver. Nor is this policy specific to the GPL: it applies to any license which contains more restrictive terms than the Apache License.

Matt Mullenweg has been critical of the PHP core team for abandoning PHP 4. Sam Ruby calls him out and says with open source projects there is no “Us” versus “Them” since you can freely join “Them” whenever you want. Matt replies:

What I think is missing is an understanding of what made PHP 4 such a killer update to 3, where 5 didn’t compel as many people. I also think there is a deeper discussion around language usability from a casual web coder’s point of view. As this comment say there can be a decreasing marginal utility. Every language doesn’t have to do everything. That’s what I was hoping to get people talking about, and it worked.

And Sam replies:

Those that contribute to PHP apparently feel the most pain concerning support of multiple versions. Yes, you can argue that they brought this upon themselves; but it is worth noting that at this point you are along for the ride. When I’m in similar circumstances, I tend to consider the karma implications of cursing the driver.

Read the whole thing, it’s worth it.

I am struggling to accept what Anne van Kesteren announces as the future of the web:

People are slowly starting to realize what HTML5 means and start arguing about individual things:

* No SGML
* No DOCTYPE
* No formal schema
* No versioning
* Defined error handling

It’s hard to grasp that all you ever thought was right — is wrong.

Why am I strugling to accept this? I guess because learning all this stuff was hard and now, having learned it, it is tough to let go. As she says, it is tough to accept that all you ever thought is now wrong.

On the bright side, HTML 5 will have some new tags. Kesteren has been documenting them as part of the draft proposal:

section - represents a generic document or application section. It can be used together with h1-h6 to indicate the document structure.

article - represents an independent piece of content of a document, such as a blog entry or newspaper article.

aside - represents a piece of content that is only slightly related to the rest of the page.

header - represents the header of a section.

footer - represents a footer for a section and can contain information about the author, copyright information, et cetera.

nav - represents a section of the document intended for navigation.

The input element’s type attribute now has the following new values:

* datetime
* datetime-local
* date
* month
* week
* time
* number
* range
* email
* url

While using Google to look up some of Kesteren’s old posts, I stumbled across an older discussion of HTML5, XHTML, and how best to serve these files on the web:

Sam Ruby wrote that insisting on a valid XHTML web page was too hard for people who wanted to create SVG images (that’s Scalable Vector Graphics) as part of their pages. This made no sense to me because Ruby has SVG images on his page and I know he is very smart and can surely work out any problems with validity that he might run into (even making sure his page is valid XML). But then, in the comments, he explained what he wanted and it all made sense:

The world in which I would like to live is one where my daughter could view one of the ever-growing number of SVG images that are hosted on wikipedia, and could select-copy-paste one onto her MySpace template. I would have no problem with the requirement that the SVG image itself be locally well formed, but the requirement that the enclosing page must also be well formed and served with a non-forgiving and not-universally supported MIME type is a non-starter.

Oh, yeah, now I get it. MySpace is a disaster and there are lots of websites out there that are just as bad, yet a JPEG or GIF image will still show up correctly on any of those sites. Ruby wants a world in which SVG images are as portable as JPEG or GIF. That means they have to be allowed to work on invalid pages.

On that same page, in the comments, Ruby raises the question of why the WHATWG weblog is running WordPress, which serves XHTML. Since the WHATWG exists to tell the world about HTML 5, shouldn’t its blog run HTML 5? Lachlan Hunt then explained:

Regarding the WHATWG’s WordPress blog installation and the problems with it, I have attempted to get it to output HTML5 instead of XHTML, but the major problem is that there’s XHTML empty element syntax, string-based processing and other nasty surprises littered throughout the code, that it’s just just as simple as writing a new template for it.

It’s such a fundamental flaw in the way WordPress and many other CMSs have been built. The best option is to write a CMS from scratch that uses real XML tools on the back end and serialises as HTML to output; but the amount of time and effort that would take to set up compared with the one-click installation of Word Press is just too much.

I just posted this to the wp-hackers mailist, and Alex Günsche replied:

It is true that there are XHTML snippets hardcoded in the WP core. But it would be a matter of a couple hours to find and replace that code. (This would also be required on each upgrade.) Then you would need timeto create the template, which can also range from a couple hours whentaking and adapting a simple existing theme, up to a week and more whencreating a new and sophisticated theme.

WordPress is not MVC, which is, without a doubt, its greatest flaw.