the mozilla DOM inspector is very handy, but i sure wish the left-hand tree view had a horizontal scrollbar. some pages i look at are quite deep… i have to keep resizing the DOM inspector window so i can see everything. *sigh*

messing around with xanga some more…

xanga allows <script> tags in parts of your "look & feel"… but not in blog entries. xanga allows iframes in blog entries… but not your "look & feel". meanwhile, embeds are allowed in both.

how weird and annoying… *bangs head*

warning: long ramble! these are just some notes to myself about providing code for people to embed their pets in their own web pages.

goals

1. code pasted into the web page shouldn't be TOO long — macromedia's recommended HTML code for flash is pretty verbose (there are shorter versions, but they all have minor issues with one browser or another that affect my pets)
2. link text back to the site should be in the external page itself, rather than in an iframe or generated from javascript, so that search engines will find it on their page
3. should work on windows and mac, internet explorer 5+, mozilla/firefox, safari

approaches

• use macromedia's flash tags as is. this violates goal #1.
• <script> tag with external src file (this is what i currently use). the script generates the verbose flash tags. script tag is surrounded by a table so that the "adopt your own virtual pet!" link can be directly below it. it would be nice if the script generated the entire table, too (good for goal #1) but then that would violate goal #2. i suppose i could also do the text-link alignment with CSS instead of tables…
• iframe. the iframe's src points to a script that generates all the flash tags. this would also require a table around the iframe (or div/css solution) so that the "adopt" link can be directly below it.

why did i go with embedded scripts instead of iframes? i think it's because i was still partially supporting netscape 4.x (!), which doesn't know iframes. the reason i was still partly supporting netscape 4 is because the toronto public library's public internet terminals were still using netscape 4 as recently as last year (!!), and i felt like i needed to support local kids using library computers, for whatever reason…. today, though, the library computers run IE, i don't test on netscape 4.x at all, and the browser barely registers in my stats, so it's no longer really a concern.

that's also why i used tables instead of divs, come to think of it…

specific services and HTML filtering

i never considered livejournal, xanga, msn spaces, myspace, etc when i first created the pets, so i hadn't considered what those sites allow.

• livejournal strips out most of everything (javascript, objects/embeds, iframes), so only images are allowed. msn spaces is pretty much the same way.
• xanga allows javascript in parts of your layout, so the regular version of the code works.
• myspace has strange filters. scripts are stripped out. images are allowed, unless they don't end in .gif, .png or .jpg (so my original image script broke because the url looked like /adopt/petimage.php?param=value. i had to change it to /adopt/petimage/encoded-params.png…). objects are not allowed. embeds are allowed, but only if the filename ends in .swf (i think some other extensions are allowed too, i haven't tested)… but embeds are turned into iframes! plus all the embed parameters are stripped out. iframes are allowed, but only for certain filename extensions (like embed).

i'm about to make some myspace-specific code for the pets, using iframes and a bogus .swf extension… but perhaps i will change the general code to use iframes instead. hmmm should test this on other services first.

well the pets now allow a wider range of characters to be part of the name and adopter name. this is cool, but the downside is that the SWF files are now anywhere from 20-35% larger, due to the increased size of the embedded font. this has a direct impact on my bandwidth usage… and now that i've allowed those characters, it would be unfair to remove them, as it would break existing pets.

one way around this would be to use a device font instead of an embedded font. the downside of that is that unless the user had the century gothic font installed, it wouldn't look as nice.

hmmm now that i think about it… i should double check to see how lighttpd handles cache headers and conditional http GETs and stuff…

update: lighttpd returns HTTP 304 (not modified) just fine when appropriate. perhaps i should look at the individual swf files and see what cruft i can chuck out of them to slim down the file sizes.

good to remember: when flash submits a form via LoadVars.send(), it sends text encoded as UTF-8. my current PHP scripts expect ISO-8859-1 (ISO-Latin1), so in my PHP scripts, i have to utf8_decode() the values.

this is all part of a process of making the pets less english-centric. right now they only allow the letters a-z in adopter and pet names. supporting all the alphabetical characters in ISO-8859-1 is just the first step, i hope.

i haven't delved into unicode and multibyte string support in PHP4, but i hear it's not so good :-\ it's supposed to be better in PHP5. i may upgrade if that's the case…

things like this make me miss java i also may start looking into other server-side scripting languages with better unicode support.

i've been wondering if it's possible to have multiple versions of safari running on a single mac, for browser testing purpose. then today i read dave hyatt's blog post about running the latest build of safari from cvs. he says:

One question people have asked is "Does this have to replace my system frameworks?" The answer is "No." You can run this custom version of Web Kit with a particular instance of Safari without replacing your system frameworks.

i'll have to take a closer look at this, but this does sound like multiple versions of safari on a single mac may be possible.