In the meantime, if anyone wants to try and break my WordPress install by injecting funky XHTML, please be my guest on this page. Currently Sam is in the lead with two breakages (now fixed). Oh, and your name doesn’t have to be Philip, Jacques, Mark or Shelley either.

What I was wondering was if there was a way to link each post in the feed to the comments feed of that story. This would allow a good feed reader to let people easily subscribe from the main feed to the conversation feed of a particular story where they have left a comment. Turns out it was fairly straightforward.

Doing a quick dig around the web turned up RFC 4685, which is an extension to the Atom format to support “threading”. It’s been around since 2006. Apparently there was a similar effort on the RSS side called commentsRss.

Anyway, the spec addresses much more than I need at the moment. All I want to do is, for each <entry> element, to include a link to the comments feed for that post. I do this by adding the following element inside each <entry> element in the feed:

To do this, I updated my feed-atom.php file to:

Ta da. Then I thought I’d track this down in WordPress and see if there was a bug/patch. Guess what… Sam has already submitted a patch for this. Two months ago. It will be in WordPress 2.5. Weird… Cool…

But the real question is why haven’t feed readers (like Google Reader) made more use of this? I think this is the biggest problem with having conversations in the blogosphere. You may subscribe to a feed that you enjoy. You may read a good story that someone publishes. You want to contribute to the discussion so you post a comment. Now if you want to keep following that story you either have to search for that story’s comment feed or (more often than not) you have to continue visiting the web page to see if anyone posts a new comment. Wouldn’t it be great if your feed reader provided you with a button next to that story you can click to automatically subscribe to that conversation (i.e. the comments feed for that story). After a while the conversation may dry up, upon which you can unsubscribe by unchecking a box in the UI or something.

Hey, this may already be out there and I might get laughed off the face of the blogosphere for still re-visiting web pages throughout the day. Feel free to leave your laughter below…

I’ve just started to use clip art on my blog. I use it for a variety of reasons: To add some colour/interest, to quickly give an indication of the topic, to provide a link to a page related to the topic. I plan to reuse the clipart over-and-over again. In my opinion, the best way to do this is by using the <object> tag that references a compressed SVG file. This means the SVG content is as small as it can possibly be. It allows the browser to cache the file. If I want to update the image with a link, then I only have to update it in one place and all my entries get the updates. It also gives me a mechanism to provide fallback content for browsers that don’t support SVG content (like Internet Explorer). Note that at the moment, I do not do provide fallback content because I can’t be bothered to rasterize the SVGs for just one browser – but I could do this if I wanted to.

You may argue that the gzip-compressed SVG is less accessible, but I also provide the de-compressed version in the same location (just remove the ‘z’ from the file extension). I also have a growing list of my clip art here.

However, Sam has brought up in the past that allowing <object>s into syndicated feed formats like Atom is less secure than inline SVG itself. The other arguments in favor of inline SVG are: the image and article text are self-contained, the source can be more easily viewed, and you can’t hot-link to the SVG image.

His suggestion to Erik was to provide referenced SVG <object>s in the browser, but when producing feeds to take the SVG and put it inline with the XHTML content. This is a great idea. Since my feed-producing code is now within my WordPress theme (thanks to a tip from Shelley), I might try to do this…

P.S. Something that just occurred to me: Wouldn’t it also be possible for Sam to do this object->inline conversion on the planet side? Requiring everyone producing feeds to do this seems like more work than to do it in one central location.

• 3833 – Extra </p> inside blockquote
• 3914, 4746 – Two feeds on Dashboard don’t work with application/xhtml+xml
• 4466 – Serve application/xhtml+xml if browser compliant
• 4857 – More issues with wpautop()
• 5144 – Paragraph end-tag wrongly inserted after object tag
• 5250 – wpautop() issue with nested lists
• 5998 – Invalid Unicode characters

I know there are a heap more. I know more will be submitted. This is just what I found when scanning the first few pages of a search for “xhtml”.

I’ve encountered 5144 directly on this blog with my clip art. I’ve found that I have to start the paragraph right after the <object> tag without a newline. A little annoying, but workaround-able.

Shelley just created Bug 5998 right now. This is a bug for WP accepting illegal Unicode code points like U+FFFE, which Jacques so kindly demonstrated.

Sad/Funny sidenote: When he did this, I ran into the very problem that Mark mentioned years ago and I had to poke my WordPress database option to switch back to text/html for the WordPress admin panel so I could correct Jacques’ invalid character. Tail now less bushy…

I like the idea of having a seamless transition between my blog and website. so this evening I decided to flip the switch on the blog, even though the WordPress theme is very much a work-in-progress. I still need to figure out what to do with the sidebar, but I can always hack away on the theme on my old blog installation internally and publish updates once they have been verified on a set of decent browsers (Firefox 2+, Opera 9+, Safari 3+).

I use SVG in a bunch of different places: inline as decoration around the page (the blue gradient and the title) and referenced (via <object>) for the icon menu (at the top) and W3C validation badges (at the bottom). Once I nail down all the particulars, I’ll compress menu.svg and serve only menu.svgz so it can be neatly cached (at roughly 15kb). But I’ll keep menu.svg around for web developers to look at if they’re curious.

Work on this led to a few bugs reported at Mozilla, WebKit and Opera – but no show stoppers. The best user experience is in Opera 9.5. For the first time, I’m using declarative animation (in a simple way) for icon mouse-hovering. Firefox and Safari users miss out for now, unfortunately.

It turns out, as Shelley has mentioned, that the best developer experience to work on XHTML is also (by far) Opera. Instead of Firefox’s “yellow screen of death” we’re greeted with Opera’s “light grey screen of mild achiness”. Instead of cryptic messages about unexpected tags, the element which failed to be terminated and the tag that broke the XML parsing are highlighted for you.

I encountered some funniness when I tried to validate my pages on the W3C Validator. Apparently it thought they were text/html pages. So I had to add a little catch in my PHP content negotiation code to force application/xhtml+xml when I want to. Anyway, the PHP content negotiation code looks like this:

You might find some of my old site themes amusing, sad, or boring:

• 2004-04 – Early static HTML, table-based layout, no CSS.
• 2005-04 – Reworked into a templated PHP site. Eventually I turned it from table-based to CSS layout-based (snapshot is table-based).
• 2006-01 – Theme from 2006. Using CSS for layout. Embedded SVG aqua buttons for navigation menus. All modern browsers now support the features I was using on this page.

Tonight I updated my Firefox extension, FXPointer, so that you can right-click on some web page text and get the XPointer element link that will drive people directly to it. This is the first time the extension comes close to being semi-usable, so I thought I should start to get the word out. It’s very similar to Doug’s excellent Idiri extension, except that FXPointer tries to use the XPointer specification for HTML documents. Thus, it will allow you to link directly to any element in a web page.

Truth be told, Firefox already supports XPointer to some degree on true XML documents. Tragically, it doesn’t work with XHTML documents (see Bug 235409). Worse yet, the amount of HTML on the web vastly outweighs the amount of XHTML, meaning that XPointer will never really reach critical mass without a boost in the HTML direction.

For Opera users, please see Jeroen’s web page that gives you some User JavaScript to get things going. This means that you can get some XPointer/HTML functionality on two of the four big browsers out there.

Anyway, I plan to start using these more-specific links going forward. If you don’t have XPointer support, you’ll just get a less-specific link. I’ll try to make improvements that degrade even more gracefully in the future.

Some future plans that may or may not transpire:

• Support for the xpointer scheme so you can use XPath and search strings (probably less brittle)
• Support for SVG’s XPointer-friendly scheme svgView
• Some configuration of the context menu

If you want to submit patches, download the .xpi, unzip it and hack away.

FXPointer does its best to use IDs where it can, so this is less brittle than it seems, but I still wouldn’t recommend this for any dynamic web pages with wildly changing DOMs. Of course the ultimate would be to support the xpointer scheme in some way such that people can use XPath and string searches.

If you think this extension is useful, please help lobby for native XPointer/HTML support in browsers.

If you haven’t read about XPointer before, you can start at my recent blog post here.

At the moment, things are pretty much in a raw, not-at-all-ready-for-prime-time state, though I’ve traveled down some lanes that I’ve always wanted to try out (specifically I’ve got my first real taste of XUL and XBL). Unfortunately it took me a while to get even a little clue on some of this stuff and it can be a bit discouraging. Here’s hoping the Mozilla documentation improves both in coverage and recency – but I’m not holding my breath.

The goal is: I want to modify the view of an HTML document if any XPointer parts show up in the URL bar.

I started with simply adding a “load” event handler to the gBrowser. This worked fine any time a page had to load (including in a new tab or in the existing tab). However, what I noticed was that a “load” event would not fire if the link was in the same page (i.e. just the “hash” part of the URL had changed) if you clicked a link or when you typed it in. So if I’m at page foo.html and that page has a link to foo.html#element(bar), when I click that link I do not get a “load” event.

So that led me into learning a bit more about XBL to try and add some bindings to the chrome.

Where I sit now: I’ve got XBL defining an evalXPointer() method on the “urlbar” XUL widget. When a new document is loaded, I invoke this method. Also, when a new URL is entered into the location bar (and the user presses Enter), I invoke this method. Finally, if the “Go” button is clicked I also invoke this method. All my “logic” sits in JavaScript in the XBL at the moment.

Anyway, I kind of get the idea that what I’m doing is not appropriate. That’s what community feedback is all about. The above bindings seem kind of like a hack. What I really want to do is get notified when any link has been activated (by click or otherwise) and regardless of whether this link causes a “load” event or if it’s in the same page. Does anybody know the sane way to do this?

Better yet, is there a way to detect when a browser tab’s address has changed in a definitive way? I don’t want to look at every keypress.

First, some high-level overview: XPointer is “an extensible system for XML addressing”, meaning that with it, you can address arbitrary portions of XML documents. XPointer is specified by the XPointer Framework and then realized through various “schemes”.

The element XPointer scheme

The element scheme allows to do relatively simple addressing within an XML document. You can address an element that has id=”foobar” like: element(foobar). You can also use a step-wise navigation within the element scheme to get at an arbitrary element. For example, element(/1/3/5) would address the fifth child of the third child of the first element (i.e. the root). Another example would be element(baz/2) which addresses the second child of the element with id=”baz”.

Now, how can you use an XPointer address? Well, the way in which I’m interested in doing this is by using it as a URL fragment. For instance, in yesterday’s post I talked about linking to the “NodeList” section of this page. Well to do that with XPointer framework using the Element scheme, my URL would be:

http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html#element(/1/2/3/5/1/15)

There are some problems with the above, not least of which is that the above document is NOT well-formed XML (see the <link> tags for starters). No, unfortunately the document is HTML tag soup. Could an XPointer implementation support an HTML document?

This brings me to another topic: Implementation Support of XPointer. Anne let me know that Mozilla has some form of XPointer support. I guess this bug was used to introduce it. It could enable some really cool features. But there are some problems with it. And also, someone wants to drop support because no one uses it yet (you have to love the referenced YouTube video in that bug, though).

So I took the HTML page and reformatted it to be proper XML (defined the &nbsp; entity, closed all <link>, <hr>, <br> elements and wrapped the script in <![CDATA[ ]]> tags). Once I did this, the following URL worked in Firefox 2.0:

file://d/ecma-script-binding.xml#element(/1/2/3/5/1/15)

The fact that this works on XML documents but not on XHTML documents (and especially HTML documents) is a crying shame. I would love to use this feature to direct people to static, non-changing web pages like specifications…

The xpointer XPointer scheme

The element scheme is arguably the least complicated XPointer scheme. The other scheme of interest is the confusingly named xpointer XPointer scheme. This scheme uses the XPath language to allow richer addressing into documents. For instance, to address the first instance of text “foobar”, I could use: xpointer(string-range(/, foobar)). Now wouldn’t that be cool? Then I could change my URL to:

http://…/ecma-script-binding.html#xpointer(string-range(/,square%20bracket))

so that the reader is instantly drawn to the words “square bracket” in that document.

Now I realize that XPointer is inherently brittle and can break on even the simplest document change (hell, regular web links are similarly brittle when you come down to it). I also realize that the preferred mechanism is for authors to use the id attribute wherever possible, since all browsers support the simple #some-id anchor. Furthermore, I realize there are problems with trying to use XPointer (a XML technology) on HTML documents. However, despite all that, I still think this would be a cool feature to be able to use on those web pages that are static and not likely to change over time (“frozen” specs, blog entries). This benefit would be particularly noticed by those people browsing the web on smaller devices with potentially painful-to-access “text search” facilities (hint: iPhone and the like). Of course with any technology, both implementors and authors have to get behind it to make its benefits known.

If you are a web developer, I am sure you are very familiar with how difficult it can be to get the Internet Explorer browser to display your web pages correctly and still use web standards that are implemented more properly by other browsers. Many hundreds of people wish that this were not so, but it’s an ugly fact in web development today. IE includes a clever little feature called “Conditional Comments” that can allow you to select what elements on your page are displayed for certain versions of IE. I wish that Conditional Comments were not necessary (because they muckify my markup), but that is the state things are in right now.

The traditional way of explaining this is by some examples:

<!--[if IE]>
  <p>Only IE will display this paragraph</p>
<![endif]-->

Figure 1 – Conditional Comments for IE

If you know your HTML (especially how HTML comments work), then it should be pretty obvious that the whole code above looks like one big comment, meaning that it will not be displayed. However, IE treats the square brackets differently by displaying the code between [if IE] and [endif] as code that it should display.

So that’s how to include code only for IE and exclude code from other browsers. Now how to do the reverse:

<![if !IE]>
  <p>All browsers except IE will display this paragraph</p>
<![endif]-->

Figure 2 – Conditional Comments for Other Browsers (The Wrong Way)

In HTML browsers, the above code displays in every browser except IE (which will ignore everything between [if !IE] and [endif]). It seems to rely on some de-facto implementations where anything between <! and > is ignored by browsers as if it was a comment. The problem is that the above is not valid XHTML (comments in XHTML are anything between <!– and –>).

This is how I was feeding SVG to IE (in an <embed> element) and other browsers (in an <object> element). However, it always rankled me that my pages wouldn’t validate as XHTML as a result of the conditional comments.

Then, I was reading this aging article by Mark Pilgrim and found an example of valid “downlevel-revealed” comments (as Microsoft calls them):

<!--[if !IE]>-->
  <p>All browsers except IE will display this paragraph</p>
<!--<![endif]-->

Figure 3 – Conditional Comments for Other Browsers (The Right Way)

NOTE: It took me some time to figure this out because I was putting spaces between [if !IE]> and –> and between [endif] and –>. Make sure there are no spaces and things should work. Here’s a test page so you can see how things work. There should be 4 paragraphs displayed in every browser.

In fairness, after I started writing up this entry, I found that several other people had already discovered this.

Anyway, I know the other debate out there. The one about how XHTML is not worth the trouble and can be harmful if served as text/html, but I’ve already written too much today to get into that