Anne van Kesteren

The perfect weblog system

If I'm ever going to write a weblog, or someone else is going to write one I'm going to use, here is an outline of what it should (or must) have. Inspiration comes from an article of Henri Sivonen: Outlining the “Ultimate” Blogging Server and various people: Asbjørn Ulsberg, Mark Wubben and Robbert Broersma. I was going to use a definition list, but dropped that option in favor of the unordered list, since that seems to be used for this kind of things. I hope your screen is wide enough.

• Content
  • How the content should be typed in is something that doesn't bother me that much. I personally use a subet of XHTML (yes, not HTML), but I can understand that this may be too advanced for most of the end users.
  • Content must be valid after inserted into the templates.
  • All links should be stored in a separate database table. Referenced to from within the post.
    • This is needed so links can be easily checked. (If you find errors in the following, please contact me and I will update it accordingly.)
      • If the link returns a 200, leave it. (You might want to check if the title is updated though.)
      • If the link returns a 301 (permanent redirect), it can be updated. (The old URI could be stored in a separate database field temporarily so the that the end user can see what changes are made.)
      • If the link returns a 410, it can be removed immediately. (No need to check again, do inform the end user.)
      • If the link returns a 404, it should be checked each day one time 10 days long and after that by the end user to see if the file is really missing.
      • All other error codes should get the same treatment as 404.
      • All other status codes should get the same treatment as 200.
    • The title of the referenced URI should have a separate database field.
    • The language(s) of of the referenced URI should be stored.
    • The MIME type(s) of the referenced URI should be stored.
    • The status/error code should be stored and checked regularly.
  • All abbreviations should be stored in a separate database table. Referenced from within the post.
    • Abbreviations that are used more than once in a single post only need the TITLE attribute at the first occurrence.
  • Images
    • Convert GIF to PNG and use pngcrush to make them smaller.
    • Make sure every image has a correct alternate text (the ALT attribute). (This is needed since Internet Explorer doesn't support OBJECT.)
    • The user must be able to enter the full alternate content, like a table for example or several paragraphs of text. Markup must be allowed for this information.
    • The title of the image that is going to be set in the TITLE attribute should really be a title and not a description. The weblogging software should make the author aware of this in some way. For example, the title should be "Mona Lisa" and not: "A women with a very nice smile... et cetera", which would be more appropriate for the ALT attribute.
  • Updated
    • If a post is updated a diff marked version should be available. (Updated means that 'minor change' is unchecked.)
      • The diff marked version must use the appropriate markup. The DEL and INS elements.
      • The diff marked version can have the following URI: http://example.org/2004/02/google?file-one=10&file-two=13. It doesn't have to be a fancy URI, since the content isn't important.
    • The updated post should probably be a new row in the database with the same information as available in the first post, except for the updated things, which are changed.
    • Every version should still be readable: http://example.org/2004/02/google?version=11.
    • http://example.org/2004/02/google must give the latest available version.
• Comments
  • Threaded comments should be possible. One comment can be a reply to multiple others.
  • Comments must be valid. Either with a comment validator or a comment fixer or a comment system that doesn't validate or fix, but does ensure valid comments.
  • People who comment should be allowed to enrich their content in a way. For example: you could allow people to enter XHTML.
  • Trackbacks, pingbacks and other forms of comments (by SMS, email or fax) should be displayed along with the other comments (with a note what type of comment it is) and must be UTF-8.
  • Comments must have a forced preview.
  • Both name and email must be required, but the email address should never be displayed.
    • Weblogging software may give the people who comment an option to show their email address, but this is not required. In case the weblogging software does not give this option, it must never be displayed.
  • People who comment should be allowed to edit their comments one time within ten minutes, based on a cookie. Their original comment should be stored and a diff may be made available to the user (optional).
  • Provide the option for people to select the main language they give the comment in.
• Post metadata
  • Links
    • These links should be stored in the same database table as the links inside the post are stored in.
    • Related
      • The user should be able to enter one or multiple URIs along with their metadata that are related to the post.
        • The publishing tool should be able to extract the metadata itself from location given by the end user. However, the end user should have an option to enter it himself as well or modify the information that was retrieved.
    • About
      • If the post is in reaction to some post the user should be able to specify its or their URIs.
    • Via
      • if the user was inspired by a post, the user should be able to specify its or their URIs.
  • Summaries
    • Each post must have a summary (even if the post has one line, but it could be identical to the post in such cases). This summary must be stored in the database and may either auto generated or being created by the user. The summary may contain markup.
    • Besides the more extensive summary users want a short summary of one paragraph sometimes. This summary should be stored in a separate field in the database and should not contain markup.
  • IDs
    • Every entry should have one numeric ID, generated by SQL.
    • Every entry should have one universally unique, absolute URI. If you have no clue were you should start: How to make a good ID in Atom.
      • It contains the domain (example.org).
      • It contains the date.
      • It contains the post slug.
      • It contains, optionally, the numeric ID.
  • Categories
    • One or multiple categories per post.
    • Subcategories should be possible. Subsubcategories should be possible too. Subsubsubcategories… well, you get the point, do you?
  • Title
    • Each entry must have a title. In case a title isn't provided a timestamp should be used instead. This timestamp contains year, month, day, hour and minute.
    • A title may contain markup.
      • Optionally, a publishing system has two database fields. One for the title with markup and one for the title without markup. (This is recommended.)
  • Slug
    • Each post must have a slug. The slug is based on the most important words of the title and must be unique enough, since the permanent location of the post is based on it. It should be lowercase and it should use hyphens to separate words, since that is readable and search engine friendly. In case a slug isn't provided, a timestamp is generated. The generated timestamp does not include parts that are already part of the URI. So if your URI structure is http://example.org/2004/02/slug. You need a timestamp that exists of the day, hour, minute and optionally second. The resulting time stamp could look like: 04235000. (In the example URI 'slug' would be replaced with the aforementioned timestamp, obviously.)
    • If the slug is changed, the post is updated; this is never a minor change.
  • Dates
    • Dates should be completely transparent to the end user.
    • Created
      • Stored when some button is pressed in the Admin area. (Status of the post, draft/publish et cetera doesn't matter.)
      • Stored only once.
    • Published
      • Stored when the post is published.
      • Stored only once.
      • The single post archive page is based on this date.
    • Modified
      • Stored when some button is pressed in the Admin area. (Status of the post doesn't matter.)
      • Updated each time a button is pressed.
    • Updated
      • Stored when 'minor change' field is unchecked.
      • Updated each time a button is pressed an 'minor change' is unchecked.
  • Language
    • Entering the language of the post is required and should be stored in a separate field in the database.
• Markup
  • Output should be HTML 4.01 for compatibility with Internet Explorer.
    • Optionally sending XHTML 1.x to browsers who support it should be considered ok as long as the correct MIME type is used.
    • For minimal, but sometimes important, bandwidth saving closing tags, if optional, can be left out.
  • LINK element must be used.
    • rel="top" should be used to navigate (for example) from /2004/02/slug to /.
    • rel="up" should be used to navigate (for example) from /2004/02/slug to /2004/02.
    • rel="first" should be used to navigatie (for example) from /2004 to /2002 (if that is the first year).
    • rel="prev" should be used to navigate (for example) from /2004/02 to /2004/01.
    • rel="next" should be used to navigate (for example) from /2003/12 to /2004/01.
    • rel="last" should be used to navigate (for example) from /2003/02 to /2004/08 (if that is the latest month).
    • All examples mentioned above should apply to everything that has a certain order.
    • More LINK elements should be used when they are found appropriate. rel="search" for example should point to /search and rel="author" could point to /about.
• URI structure
  • General
    • The URI doesn't need a 'www.' subdomain, remove redundancy. (This does not apply to the URIs stored in the database, obviously.)
    • URIs should not have extensions of server side scripting/programming languages such as '.php', 'asp', 'aspx', '.cfm', '.cgi', '.py', '.pl' and other. They are useless and tell the end user completely nothing, since the URI, in the optimal case, has nothing to do with the kind of processing that is needed on the server side.
    • URIs should have optional extensions if multiple formats are available, for example '.htm' (HTML), '.xht' (XHTML), '.rdf' (RDF), '.pdf', (PDF), '.atom' (Atom, this one has a 4 letter extension since that is what is being standardized). These extensions should be optional, files should be available without extensions.
    • If a post is available in multiple languages. They should have a language "extension", like '.en' for an English post and '.fr' for a French one.
      • This is as long as the slug of the post isn't modifed. 'google' can't be translated for example. 'mother' as post slug can be translated into 'moeder' in which case a language extension isn't necessary. (This does make content-negotiation a bit trickier perhaps, but is more user friendly.)
      • If a post is both available in multiple languages and in multiple formats, the language should come first and after that the format. For example: http://example.org/2004/05/google.nl.pdf.
  • Individual entries: http://example.org/2004/02/slug
    • An additional /archives/ before the year isn't necessary. It makes the URI complex and long.
    • The actual day isn't important for most weblogs. However, if your weblog or news system publishes at least 5 items a day it might be worth considering adding it.
    • Both the relative (/2004/02/slug) and absolute version of this URI should be stored in the database.
  • Monthly archive: http://example.org/2004/02
    • In case it isn't possible to distinguish between /02/ and /02, /02/ should be used.
    • Full posts should not be published on this page, only summaries.
  • Year archive: http://example.org/2004
    • /2004/ should be used if the above isn't possible.
    • Year archives are considered optional by some people who choose to redirect al requests for year archives to the archive index page. I think you can better keep them and add a list with all posts from that particular year.
  • Specific category archive: http://example.org/category/general
    • Same as monthly archives.
  • Category archive: http://example.org/category
    • Provide a list of all categories, optional.
  • Archives: http://example.org/archives
    • Gives an index of at least all months when posts are made and a category index when categories are used.
  • Homepage: http://example.org/
    • The trailing slash here must not be considered optional. It is required, in other words.
    • Lists the last post or last few posts. Every post must have a link to the archived post page and may have a link to the categories the post was posted in, to the month the post was posted in and to the year the post was posted in.
• Character encoding
  • The unchangeable default should (or must) be UTF-8. If you are not comfortable with UTF-8 you can read my quick guide to UTF-8.
  • If a user enters any character references they should be converted to UTF-8 characters. Like replacing '—' or '—' with '—'.
  • If a user enters any entities they must be converted to UTF-8 characters. Like replacing '—' with '—'.
    • Publishing systems are encouraged to do this for MatmML entities as well. XHTML entity conversion is a must. (Character references are not required, since those are forward compatible. That doesn't mean it shouldn't be done, since it can save a few bytes and looks cleaner.)
  • The character encoding must always be explicitly mentioned in the charset parameter of the content-type header. When retrieving a page, when sending a trackback, et cetera.
  • All incoming trackbacks and other ways of user input should be checked on their encoding. If they are not UTF-8 encoded they must be converted before published. If the publishing system is unable to convert them to a safe UTF-8 string it should either remove the characters or show them on a HTML page so they can be edited by the author of the weblog. (XML based pages are supposed to crash on these kind of encoding errors.)
• HTTP
  • Headers must be used correctly. For example: last-modified should not be a random date in the past, but the actual date the file is modified for the last time.
  • Use HTTP in favor of the META element with the HTTP-EQUIV attribute. Actually, that attribute must not be used.
  • If an entry is explicitly deleted. Use 410.
  • If an entry is updated and the author says the older entry isn't relevant anymore a permanent redirect should be used.
  • If an entry can't be found, don't say the entry can't be found, but return an actual 404 header. (Current weblog software doesn't use this and rewrite everything to a single file that handles the request and shows some custom error message instead of returning a header.)
• Syndication
  • Use Atom where possible.
  • Provide an optional RSS 1.0 (based on RDF) feed.
  • You must not use RSS 2.0, since it has big problems.
  • Provide feeds for everything (you must at least have a feed for your latest entries, other feeds are optional, but this option must be provided by the weblog system)
    • http://example.org/index.atom
    • http://example.org/index.rdf
    • http://example.org/2004.atom
    • http://example.org/category/markup.atom
    • http://example.org/2004/02/hyphen-or-underscore.atom (For comments.)
    • Et cetera.
  • Embed your XHTML directly, don't escape it.
• Cache
  • The content of the post should be cached, along with all the abbreviations and links that are included.
  • Sidebars should be cached.
• Compressing output
  • Page should be compressed where possible.
  • Feeds should be compressed where possible (higher priority).

I will update this document if it needs any changes. (For real.)

Comments

1. [...] XHTMLML/CSS caretaker I've encountered recently is Anne van Kesteren, who's recent Perfect Weblog System includes some interesting suggestions [...]

   Posted by Danny Ayers, Raw Blog at 7:52AM

2. Anne, your ideas of URI structure remind me heavily of the proposed URI structure of the (unwritten) Inklog Content Management System. See Inklog: what is it? and Inklog theory: the storage system for more information. Maybe some of Reverend Jim's insights might help you clarify or explore your thoughts, which I agree on. In particular, the content negotiation model with regards to languages and file types is a very good one, but difficult to implement unless the weblogging software works like Inklog, providing "nodes" and elements. Should this be a component of the perfect CMS?

   Posted by Basil Crow at 2:18AM

3. Great work!

   Posted by Randy Charles Morin at 2:22AM

4. As a web application developer I'd like to cast a vote for custom extensions and plug-ins. After all, what good is a blogging engine for if you can't extend it or add fancy gadgets?

   Posted by Milan Negovan at 3:00AM

5. Wiki?

   Posted by Robbert Broersma at 3:31AM

6. normilisation in it's prime.

   Posted by flump at 4:27AM

7. Very well. I've tried some bloging/CMS tools and all have shortcomings, and not the minor ones (yes, WP too). This is a good list of points to consider, altough I do not agree with all you've said, this gave some useful thoughts for a start.

   There are some points about which I never thought before - thanks for sharing.

   Posted by Rimantas at 4:59AM

8. • Comments
     • Threaded comments should be possible. One comment can be a reply to multiple others.

   How is this displayed? What happens with a reply to this comment? Can the (second) reply be to only certain grandparents? I can see how this would cause a lot of problems, and I think that's why you don't see it anywhere. (Or at least, I never have. If you have seen a good implementation, I'd love to hear about it. As a postscript, would this be called "woven comments" rather than threaded? ;-)

   • Post metadata
     • Summaries
       • Each post must have a summary.

   What about one line posts? Would the summary be empty or identical to the post?

   • Comments
     • Both name and email must be required, but the email address must never be displayed.

   What if the user wants their email displayed? They'd have to resort to something like I have right now as my url. (How's it work? Email me with suggestions :-))

   • URI structure
     • General
       • The URI doesn't need a 'www.' subdomain, remove redundancy.

   Just making sure this applies only to the blog itself and not to the database of links. Some of those links may be to poorly configured servers that allow access only to the www subdomain (or properly configured servers that have a valid use for it).

   Posted by dolphinling at 7:15AM

9. »Use HTTP in favor of the META element with the HTTP-EQUIV attribute. Actually, that attribute must not be used.«

   Mozilla »forgets« the encoding when one uses »save as« if you don't use the http-equiv ersatz.
   Sad, but true.

   I'd like to see metadata for images and code to make this better searchable.

   Posted by Thomas Scholz at 7:31AM

10. Okay, so my data url got mangled, which only proves my point more: if I want people to be able to contact me, I should be able to provide an email address for them, and in a way other than the post body.

    One more nitpick: the root of the blog isn't always the root of the domain. (The weblogs.mozillazine.org blogs are a good example.) That's easy to adapt around, though.

    Other than those, though, this looks wonderful. Be sure to tell me when it gets made. :-)

    Posted by dolphinling at 7:34AM

11. Why shouldn't Last-Modified be a date in the past? I thought that was the whole point.

    Posted by J. King at 7:51AM

12. Acts of Volition - Ultimate Weblog System : May 2003

    Posted by Abhi at 9:30AM

13. Ok, I updated some parts that were unclear, especially the thing J. King pointed out was quite a stupid mistake :-)

    I also added some extra parts: caching, compression, images and markup.

    Posted by Anne at 6:36PM

14. • Compressing output
      • Page should be compressed were possible.
      • Feeds should be compressed were possible (higher priority).

    In these instances I think you want 'where' in place of 'were'.

    Posted by Chris Neale at 1:04AM

15. I have one suggestion. I have beef with your demanding to provide feeds for everything. It does not make sense in some situations, and is actively harmful. Think of a log which does not have forced moderation turned on. Anyone can comment, and even if you delete, ban blacklist later, the damage is done via comments feed. To speak plainly, it defeats the purpose.

    Therefore, my opinion is that it should not be an unconditional request to provide feeds for everything. You might just as well tell people to publish their email addresses in plain text. In other words, veto :)

    M.

    Posted by Moose at 12:43PM

16. • Comments
      • Threaded comments should be possible. One comment can be a reply to multiple others.

    How is this displayed? What happens with a reply to this comment? Can the (second) reply be to only certain grandparents? I can see how this would cause a lot of problems, and I think that's why you don't see it anywhere. (Or at least, I never have. If you have seen a good implementation, I'd love to hear about it. As a postscript, would this be called "woven comments" rather than threaded? ;-)

    I would call it a relational comment system (damn you Anne, now the word is out!). Actually this is what's used at Dunstan's blog. It could be visualized using Javascript, for example.

    Anne, I agree with almost everything you wrote here. Some things are highly subjective, such as your URI and syndication proposals. The ultimate weblog system should allow these things and alternatives.

    Posted by Mark Wubben at 6:58PM

17. Does anyone actually use /archives?

    Posted by Redund at 7:24PM

18. ...And alternatives is one of the most important of all comments of all. Thanks Mark!

    Posted by Robbert Broersma at 3:01AM

19. I use /archives -- but I must say I did toy with the idea of getting rid of it.

    A comment: I didn't see "language" anywhere in the post attributes. I think language should be an attribute of a post, even if the post is not available in alternate languages. It could of course be inherited from the weblog language.

    Just for history, some time ago: Requirements for a perfect weblogging tool.

    Posted by Steph at 4:09PM

20. Good call, I added things about languages (for both comments and posts).

    Posted by Anne at 5:20PM

21. All links should be stored in a separate database table. Referenced to from within the post.

    Does this mean to display the post the software has to first look up the link? Or is the link merely copied into the database at time of posting?

    A link database is an idea I had ages ago. It would mean I could keep track of all my links, and search for one I needed.

    The title of the image that is going to be set in the TITLE attribute should really be a title and not a description. The weblogging software should make the author aware of this in some way. For example, the title should be "Mona Lisa" and not: "A women with a very nice smile... et cetera", which would be more appropriate for the ALT attribute.

    I've been guilty of doing it the other way round - short ALT text and long TITLE text. The reason is that a page shows the short text when the image is missing.

    Dates should be completely transparent to the end user.

    What does this mean?

    An additional /archives/ before the year isn't necessary. It makes the URI complex and long.

    Fine if you want to fill your root directory with folders. It makes sense to have a archive folder. Plus it tells users what the URI is.

    The actual day isn't important for most weblogs. However, if your weblog or news system publishes at least 5 items a day it might be worth considering adding it.

    Did you mean "The actual hour"? Of course the day is important!

    Homepage: http://example.org/ The trailing slash here must not be considered optional. It is required, in other words.

    Why so?

    You must not use RSS 2.0, since it has big problems.

    Really? I see it on most major sites with feeds. What are the problems? (Lack of an agreed precise format? People using CDATA?)

    Posted by Chris Hester at 6:01PM

22. • About links:

      If the link returns a 410, it can be removed immediately. (No need to check again, do inform the end user.)

      Surefire way to upset newbies — and "power users" alike.
    • About comments: I'd emphasize the should part, if I were you... User-friendliness and all that, you know? ;-)

      People who comment should be allowed to enrich their content in a way. For example: you could allow people to enter XHTML.

    • About images: I don't understand your using such hairy alt text in this example:

      The title of the image that is going to be set in the TITLE attribute should really be a title and not a description. The weblogging software should make the author aware of this in some way. For example, the title should be "Mona Lisa" and not: "A women with a very nice smile... et cetera", which would be more appropriate for the ALT attribute.

      Surely "Mona Lisa" is the best alt text imaginable for a picture of the Mona Lisa? When I see Here, have a <img src="monalisa.jpg" [ . . . ] />, I don't read that as Here, have a A woman with a very nice smile.

    • About URIs:
      • You shouldn't force holy wars like "no-www" on your users. Some people agree, some people disagree. This should really be a plug-in or extension, not a core feature. It's more server-level than content-level. Also, some domains' DNS settings don't mention the domain name without the "www.", so that could break sites.
      • Is it 1993 again?

        URIs should have optional extensions if multiple formats are available, for example '.htm' (HTML), '.xht' (XHTML)

        What's with the three-letter extensions? Why not use ".html" and ".xhtml" instead of the "DOS 8.3"-compatible extensions?
      • I don't understand why you disallow the trailing slash for archives. Isn't a yearly/monthly archive a directory or index of posts for that year/month? (Especially when only showing snippets instead of full posts)
      • I agree with Chris Hester about not polluting the DOCUMENT_ROOT directory. It strikes me as odd that digging deeper in your URI structure doesn't incrementally add things to the URI. The archive for 2004 is a part of the general archive, and as such would fit best under /archive(s)/
    • About character encoding:
      • This applies to your blog: I tried to use &mdash;, but your comments plug-in said my comment was invalid XHTML, without an indication of why. I figured out, of course, but why not allow those, like you suggest here:

        If a user enters any entities they must be converted to UTF-8 characters.

      • Don't forbid the use of meta http-equiv to specify the charset for offline use.

    Finally, I agree with Steph about this commenting system. It's not a user's job to keep a site valid. No flamebait, honestly, but if I had to type any more XHTML here, I'd expect a paycheck. :-)

    Posted by Jan! at 6:44PM

23. First Chris comments. Stored in the database and in the post probably but they should somehow reference to each other so the post can be updated with the new link if a link changed in a 301 for example or if a link is gone 410.

    The long alternate text is really better, you could of course include "Mona Lisa" in the alternate text, but a description of what the picture looks like is important. The TITLE attribute just does what it says, giving the title. The W3C should of course have released a lot more attribute like HINT and DESCRIPTION to address our needs, but they did not. (Actually, having elements would probably be better.)

    The user of the system shouldn't have to care about something as dates. Timestamps are relevant to the user, but he shouldn't have to enter them himself. The software should generate it as explained in the post.

    Having something like /2004/ also tells what the URI is. Something that has been archived, since it has a date in the URI. It doesn't necessarily have to pollute the root folder by the way. Ever heard of Apache? ;-)

    Day is not an important part of the URI in my opinion. (This post bas heavily biased as is all the internet.)

    RSS 2.0 has problems, don't ask Dave. Ask Mark.

    Jan, my commenting system has nothing to do with this post. Actually, this post is wishlist for a better weblog system. I hoped you figured that out ;-)

    I wonder what you mean with upsetting newbies. A weblog is not meant to be used offline, in my opinion (again).

    Posted by Anne at 7:02PM

24. 'Current weblog software doesn't use this and rewrite everything to a single file that handles the request and shows some custom error message instead of returning a header.'

    Not exactly true: if you were to try to get: http://blog.raena.net/2004/08/06/nonexistent/ and I were using Movable Type or Blogger, you would most likely get a 404 response -- it creates actual files and directories, rather than fudging them, so your server will generally do what it would do for any other missing resource.

    I had Movable Type generate a really nice 404 errordocument for me, including a friendly message and a bunch of links to archives and the search engine.

    'Individual entries: http://example.org/2004/02/slug'

    And if your blog isn't 'like' that, what then? What if my weblog made more sense with URIs like http://www.cakesrock.org/recipes/cheesecakes/vanilla/ ?

    Asides from those nitpicks, I'm right with you.

    The user must be able to enter the full alternate content, like a table for example or several paragraphs of text. Markup must be allowed for this information.'

    Markup allows already. I have long awaited the day where I can write a longdesc for a photo or other image and have a tool auto-generate it for me.

    Posted by Raena Armitage at 7:39PM

25. I would call it a relational comment system (damn you Anne, now the word is out!). Actually this is what's used at Dunstan's blog. It could be visualized using Javascript, for example.

    It is called a threaded-comment system, and it is implemented in BLOG:CMS. Try looking at this sample article, and click on show in context to see what I mean.

    For Anne: brilliant work, was this inspired a bit by my email to you re: your feedback on BLOG:CMS? I guess so, as quite a lot of your items seem to follow BLOG:CMS features ;)

    Posted by rADo at 9:12PM

26. rADo, I haven't had time to fully test BLOG:CMS yet. This post is inspired on features I miss in current weblog systems and I have seen in others (Dunstan's relation comment system for example). I thing that I really miss is good support for dates, which is not a part of Nuclues, not a part of WordPress, Movable Type doesn't do it, et cetera.

    Atom IDs that are actually stored in the database so you can switch your domain, but keep your Atom ID for older entries the same. And endless more things mentioned above.

    Posted by Anne at 10:06PM

27. I thing that I really miss is good support for dates

    Well, within about 5 minutes of trivial PHP coding, you can have in BLOG:CMS exactly URLs you describe, not to mention that stuff like always valid comments, threaded comments, cached articles and sidebars, automatic rel links, etc. are already in there, in a default install package, plus wonderful plugin interface with 100 events, unlike in other systems (like trivial, yes, I am biased, WordPress, or more advanced Movable Type...).

    Posted by rADo at 1:49AM

28. I was not talking about the URIs, I was talking about the dates ;-). But lets take this to email if you think there is more to say.

    Posted by Anne at 1:57AM

29. to: Anne, ok, just drop me few lines, when you install BLOG:CMS, I think most of these requirements are easy to met, if not done already (most of them).

    Posted by rADo at 4:56AM

30. Some neat ideas here. I always enjoy reading these types of posts and mpt's original was an inspiration for the early releases of WordPress. The discussion from this and other posts is helpful in conceptualizing some things. Thanks. :)

    Posted by Matt at 9:33AM

31. The W3C should of course have released a lot more attribute like HINT and DESCRIPTION to address our needs, but they did not.

    There's always the longdesc attribute.

    Having something like /2004/ also tells what the URI is. Something that has been archived, since it has a date in the URI.

    Disagree. "2004" could mean anything. Since that's the current year, it might suggest documents relevant to this year only, such as the latest news, or the Olympics. Ie: not archived material. Far better to tell the user they are in an archive by using "/archives/".

    Posted by Chris Hester at 3:50PM

32. So then you use /archives/; everyone happy. I and others think it is redundant. It is not about the details, it is about better systems.

    Posted by Anne at 3:54PM

33. Good work. Reminds me of Mark Pilgrim's "30 days to a more accessible weblog".

    Posted by Martin-Éric at 4:06PM

34. If an entry can't be found, don't say the entry can't be found, but return an actual 404 header. (Current weblog software doesn't use this and rewrite everything to a single file that handles the request and shows some custom error message instead of returning a header.)

    404 is a status code, not a header, and you can use that status code with meaningful error pages, so what you are presenting as an either/or scenario is actually two unrelated topics.

    I'd say that friendly error messages are something that a good weblog system must have. In particular, 404 pages should offer explanatory text, an explicit suggestion of visiting the archives or search page, and perhaps a list of articles that might be of interest (you can pull keywords out of the slug to find articles of interest). The same applies to 410 and other error states.

    I'd also echo the questions about including the date in the URI. What purpose does this serve? It's metadata, not something that is needed for addressing a resource.

    I think the multilingual requirement of something like index.en.html could use a bit of work. End-users aren't familiar with language codes. It would be much friendlier to have a prefix, e.g. http://example.com/english/foo and only negotiate when the prefix is not given. If you use relative URLs, this also means you don't have to mess around with conditional logic when you just want to output a link.

    Also, why .htm and not .html?

    Posted by Jim Dabell at 4:16PM

35. One reason I can think of for using /archives/ is that many weblogs will want an archive page as a starting point for browsing them. It seems cleaner to have /archives/ with the index page showing the available years and having 2004/ etc as subdirectories than to have a separate /archives.html with 2004/ etc as siblings.

    I don't think anybody has come up with a decent way of visualising weaved/relational comments yet. The example linked to was just confusing. I would suggest that unless you expect this problem to be solved soon (I don't), the complexity and confusion outweighs the usefulness. Email, Usenet and existing comment systems work on a threaded basis and everybody is comfortable with them. Replies to two separate comments can be posted as two replies; having a system that can deal with multi-parent comments seems to me to be of extremely limited value.

    Posted by Jim Dabell at 4:25PM

36. As far as the 'www.' prefix goes, I agree that it is redundant, but leaving it off is very unusual. It looks very odd to me.

    Plus, there is actually a software compatibility issue, I seem to remember that plenty of browsers would recognise a hostname if you left off http://, but only so long as there was a 'www.' prefix. I'm not sure if that's still the case now though.

    Finally, it could confuse people. If you say to somebody "go to www.example.nl", everybody will immediately realise that it is a website. If you say to somebody "go to example.nl" they may not, especially if they are not from that country or are not a techie.

    Posted by Jim Dabell at 4:33PM

37. For language: what I'm going towards (and what I see as ideal) is the following:

    http://url-of-archive-month-or-category/en/ or http://url-of-archive-month-or-category/fr/

    In short, adding a language "tag" at the end of any url would (a) change the language of the "furniture" for the page (the comment link text, the headings, the date) and (b) show only posts in that language.

    Posted by Steph at 8:16PM

38. Anne, I'm glad to see you agree with me that archives in permalinks are unnecessary. They have been bothering me for a long time now, and it so happens that I just posted about that on my weblog (amoungst other things).

    However, I must be honest that I think calling anything perfect is a little too subjective. :-)

    Posted by Charl van Niekerk at 9:36PM

39. Plus, there is actually a software compatibility issue, I seem to remember that plenty of browsers would recognise a hostname if you left off http://, but only so long as there was a 'www.' prefix. I'm not sure if that's still the case now though.

    I think I was a little unclear here. I'm talking about when you type an unadorned hostname into the address bar of a browser.

    Posted by Jim Dabell at 9:50PM

40. In response to URI Structure/individual posts: To make categories more apparent and important, I think it's better to put categories into the URL, like: http://example.org/blog/general/slug. Especially, if the site has more than just a blog, it's good to say "blog" and categories after that are pretty logical.

    For example, my site is done like that: http://www.visiomode.com/

    Posted by Ilkka Huotari at 12:58AM

41. To make categories more apparent and important, I think it's better to put categories into the URL

    That fails when you put an article into more than one category at once. There's nothing wrong with having browsable categories, but the permalink shouldn't be inside them.

    Posted by Jim Dabell at 1:10AM

42. That fails when you put an article into more than one category at once.

    Yes... in case you tend or want to do that. I'm so much favor of structuring the content hierarchically that I wouldn't want to do it.

    Of course, I might change my mind sometime, but not yet :-)

    Posted by Ilkka Huotari at 2:10AM

43. Anne, I suggest you take a peek at what I'm working on over at http://backup.greywulf.net as it includes a lot of the thoughts you've voiced - and added a lot more into the pot which I will certainly think about too. Good work!

    I'm trying to create as small and complete a blogging system as possible. Right now it's focussed on the size of the core engine (using blosxom+photogallery+comments, etc) with an aim to steadily increasing it's useability once I'm happy that the centre is working correctly. The only area you've touched on that I'm not sure about is that of compression. I'd rather have the posts remain as ascii-pure as possible - that way if everything else changes, the content itself will always be visible and accessible. Compression for me adds another unecessary step.

    As an aside - it's just taken 7 attempts to post this one comment because I received numerous errors including "XHTML is not well-formed" and "You need to use block level elements in order to post a comment". It's a comment. I wouldn't expect everyone who posts a comment on a weblog to be converstent in XHTML, XML or whatever. I would want their thoughts, not proof of their technical competence. If something "isn't compliant", it should be silently fixed, not throw an error. That just leads to frustration.

    Posted by Robin Stacey at 8:20PM

44. The perfect weblog system: I agree with most of this list.

    Posted by hitormiss.org: The perfect weblog system at 2:36AM