I've finally hacked support for comments into my home-grown CMS. Following Simon Willison's lead, comments here are run through an XML parser to first check for well-formedness, then to ensure only selected elements and attributes are used.
I've opened comments on the two most recent entries to start. Let me know if you run into any problems posting, or if you think any of the error messages could be made more clear.
The Creative Commons 2.0 licenses are out. Matt Haughey, Creative Director at Creative Commons, has already announced that he's upgrading his blog's content to the new licenses. I'm not a lawyer, so take what follows with a grain of salt: Upgrading to a new Creative Commons license appears to violate the terms of the original licenses.
I pointed out two very important aspects of the Creative Commons licenses last year in response to unfortunate confusion regarding the terms. Each is important enough to repeat here:
Creative Commons licenses are inclusive. Additional provisions are irrelevant. From the Attribution-ShareAlike 1.0 license, section 8e:
This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.
Creative Commons licenses are perpetual, irrevocable. From the Attribution-ShareAlike 1.0 license, section 7b:
Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work).
I read no equivocality in those provisions. How do you upgrade a perpetual, irrevocable license? Creators are now violating their own agreements instead of traditional copyright. Progress! I hope Matt's getting a written agreement to the new terms from each of his readers.
That the target attribute is not by default allowed in valid XHTML 1.1 or XHTML 1.0 Strict continues to be a source of frustration for designers. It simply doesn't have to be. Others -- Jacques Distler and Dave Hodder, namely -- have pointed out that XHTML is designed to be modular and that it's easy to extend the specification by creating your own DTD. Jeffrey Zeldman suggests caution:
This approach is very much in the spirit of XHTML extensibility but leaves open the question of whether browsers that use DOCTYPE switching will render such a page in Standards or Quirks mode. Such browsers (IE, Mozilla/Netscape, and now Opera 7) do not download and parse DTDs; they rely on known DOCTYPE declarations stored in an internal database to determine how a page should be rendered.
Zeldman's better-safe-than-sorry response is understandable, but there's no evidence that Internet Explorer, or any other browser, will punish you for extending XHTML. In fact, there's a lot of evidence that custom DTDs are supported by the major players. Mozilla, for example, invokes Standards Mode at the sight of any unknown DOCTYPE, as well as for DOCTYPEs extended via an internal subset. (I've been using an internal subset to extend XHTML 1.1 since September 2003.) Internet Explorer, too, defaults to Standards Mode when confronted with an unknown DOCTYPE. Opera's docs don't explicitly claim similar support, but the following tests suggest identical behavior.
See for yourself:
DOCTYPE declaration. Rendered in Standards Mode by Opera 7, Internet Explorer 6, and Mozilla 1.7.DOCTYPE declaration. This document is also rendered in Standards Mode by Opera 7, Internet
Explorer 6, and Mozilla 1.7.The tests determine if extensions are invoking Quirks Mode through use of the JavaScript compatMode property, which returns BackCompat when in Quirks Mode and CSS1Compat in Standards Mode, and the CSS box model, which behaves differently in Quirks and Standards Modes.
Extending via an external subset of the declaration is convenient (since you don't have to create your own DTD), but this method leaves a short string of characters -- the end of the subset, in fact -- at the top of pages served as text/html. Documents served as application/xhtml+xml do not have this problem. As such, Jacques's method is the best solution for most cases.
The test documents are served as text/html for two reasons:
In other words, serving XHTML as application/xhtml+xml to Gecko browsers gets you Standards Mode every time, as does serving a custom DTD to any browser. There's no indication that extending XHTML will rain on your standards parade.
Update: The Mozilla "View Page Info" tool (Ctrl+I) also tells whether a particular page is in Standards Mode or Quirks Mode. I wasn't aware of this feature when I first wrote these tests.
Simon Willison has now successfully served his weblog as application/xhtml+xml, with comments enabled, for nearly a year. His own PHP HTML checker keeps comments sane:
The system I have implemented works by running submitted posts through an XML parser, which checks that each element is in my list of allowed elements, is nested correctly (you can't put a blockquote inside a p for example) and doesn't have any illegal attributes.
He uses Jesse Ruderman's excellent bookmarklet to validate his own posts.
It can be done.
John Allsopp, CSS Samurai and head of Western Civilisation Software, waxes nostalgic about the early days of CSS and the people who made it possible:
These guys, along with a few others, were also real driving forces in the style sheets newsgroup in the late 90s, when belief in css was, in hindsight and to be honest, probably a little optimistic at best. They and people like Alan J. Flavell, Liam Quinn, Braden N. McDaniel, Todd Fahrner, Daniel Glazman, David Baron posted tirelessly on the newsgroup, started sites like the Web Design Group's CSS reference and css.nu, formed the CSS Samurai at the Web Standards Project and basically created a community that continues to this day.
...
But all you out there who read, write and care about CSS and web standards, stop for a moment and give some quiet thanks to these people, and all the many midwives who helped bring the possibility of web standards into the world.
You owe it to yourself to read John's piece if you care at all about Web standards.
In a piece Isofarro thinks is mostly FUD, Andrew Grumet asks:
When someone claims that Atom is a better format, try to get them to explain what user-visible features Atom makes possible that are not currently possible.
It's a question that deserves an answer, if only to serve those who know what's wrong with RSS, who want to switch, but who don't really know why they should. Phil Ringnalda responds to Andrew's query with some excellent thoughts:
Features? From my perspective, the feature thing is pretty damn simple. In Atom, I know whether the title element is encoded HTML, or plain text. I can use pointy brackets in titles, without worrying about them being interpreted as HTML. In Atom, there is an element for a summary/description, and an element for content. In Atom, there is an element for the author's name, not just an element for the author's "give me more spam, please" email address. There's a date modified, to help start figuring out a way to deal with posts that change.
Sounds about right.