Things and stuff

In Safari 2.0 (and presumably all versions since 1.3), the javascript method window.getSelection() returns a Selection object, but not the same one that Mozilla/Gecko browsers return. Instead it is more of a bastardization of the DOM’s Range object. Of course, this isn’t documented anywhere. No, I found this by reading the source code for the window.getSelection method itself.

What’s perplexing is that WebCore does have a DOM-compatible Range implementation, and yet window.getSelection() still returns this not-quite Selection object instead. What’s even more amazing, is that the type property of this object (i.e.: window.getSelection().type) returns Range, even though it isn’t a Range! This is probably a bug.

The only workaround I found for this was here and suggests converting the Selection item in Safari to a string and working with it from there, but in my case there’s already code expecting a Range and so that method wouldn’t work. I had to dig to find out what the hell window.getSelection() was returning, and seeing how it was so hard for me to find, I figured I should publish it in case someone else needs it.

To save you the trouble, here’s a table with comparisons of Safari Selection objects properties/methods with the equivalents for the W3C/Mozilla implemented Range object, since that’s basically the equivalent and many of the field values (if not their names) are the same. Using this, you can write Safari specific JS that will pull what you need from Selection in place of a W3C compliant Range object.

I think I might start a “Friends don’t let friends use Safari” campaign.

Edit: So I ordered a copy of the O’Reilly fifth edition javascript book and they have what might be the best cop-out ever. From page 342, emphasis mine:

function getSelectedText() {
	if(window.getSelection){
		// This techniquge is the most likely to be standardized
		// getSelection() returns a Selection object, which we do not document.
		return window.getSelection().toString();
	}
 		/* … */
}

I spent the other night trying to compile PHP5 under Mac OS 10.3 for a couple hours but every time I get to the compilation phase I was getting the same error:
/Users/alice/php-5.1.6/ext/libxml/libxml.c:43:28: libxml/xmlsave.h: No such file or directory

I figured out what I needed to do, but since I couldn’t google for a decent answer I figured I should publish what worked for me.

Basically, the libxml that ships with Panther is older than the version PHP5 is expecting at compilation time. According to the help message for ./configure there’s a --with-libxml-dir flag you can use, but I wasn’t actually able to get that to work. Instead it was easier to upgrade my version of libxml.

Go to http://www.xmlsoft.org/ and get the newest source package of libxml2. Next you need to install it, but since PHP5’s Makefile looks in /usr/include you need to change the default prefix for the libxml2 installation. You can do this using the flag:
./configure --prefix=/usr

This will put the correct C files into /usr/include/libxml2/libxml and you can then build PHP5 with no problems.

I don’t recall having this problem with Tiger, and looking on my iBook it appears the default shipped version of libxml2 is more up to date (although I may have installed a new version before, I don’t think I did at least). There’s probably a way to get libxml2 to install in /usr instead of in /opt, but I haven’t figured that out yet.