Professional Web Developer, Amateur Photographer
Creating a site for yourself has always been a refreshing outlet for web builders. Without rooms of stakeholders, you alone have the control over which technologies to use, what features to include and what browsers to support. Part of that control is deciding how you are going to deal with browser bugs and often having the freedom to take the ‘high road’ and leave defects be so that they can be used for bug reporting, test cases, and to help prod browser vendors into maybe making those bugs a higher priority.
While I have no desire to work around them for my personal site, I think its worth it to point out and work to get these bugs fixed at the source, including the following 2 CSS bugs with visible on the new Place Name Here that I decided to let be — one in Microsoft Internet Explorer 8 beta 2 and the other in Google Chrome.
In a few places on this site I have a “compact” formatted list of items such as various skills or tag listings. The last round of the site had these lists as well. To make them compact I have set the LI element to display:inline so they to follow each other horizontally. In addition, to make them easier to read and maintain some integrity of each item or phrase they also have white-space set to “nowrap”. This created the desired behavior where a line only wrapped in between list items across browsers including IE7, but not in IE8b2. There it also applies the whitespace rules to the gaps in between each LI and creates one long non-breaking line. Test Case
. Screenshot:
Most JavaScript frameworks like jQuery which I’ve used on PNH come with transition or animation libraries built in or as plugins. Everyone seems to love their slowly expanding layers or blinking colors behind content changes, fading in and fading out transitions. I’m no exception and if you’ve found the site’s poorly hidden easter egg you’ve seen some of them used.
Chrome, while the animation and timing is smooth and comparable to other browsers, shows a problem with rendering the antialiased portions of type when the type is partially transparent such as it is in the middle of the fad in transition. This is not something I’ve seen in its close WebKit relative, Safari, so I’ll make the assumption that the issue is somewhere on the platform or application specific side of the fence. Test Case. Screenshot:
Both of these bugs have been reported to the browser vendors. And it was far easier then the old days of signing up for a bugzilla account and hoping you get the right category and don’t have a duplicate entry — or just passing an unstructured note somewhere into the email black hole. With the increased competition in the browser marketplace there has been some quiet advances in bug reporting tools. Both Google Chrome and Microsoft IE8 offer simple bug reporting tools that include the ability to pass along site URLs and automatically take a screenshot of the active web page to get sent when submitting the bug report report.
Instructions on reporting a bug or broken website in Chrome
Download the Report a Webpage Problem Internet Explorer 8.0 Beta Add-On
Place Name Here has gotten a much needed facelift and a bit of reorganization. A bit grungy, it harkens back to the black and white color palette that has haunted the site for most of its nearly 10 years [domain registered in December of ’98]. As usual the design is fairly simple simple, and as always I have found some way to fit some obnoxiously big type. The refresh also marks an increased interest on my part to post more regularly and more substantial then the recent link here and photograph there.
Web2.0 Sucked The Blogging Out Of Me, and so did everything else.
Since its launch I’ve never seen Place Name Here as having a very specific focus. If its been any one thing its just been a warehouse for whatever digital thing I’ve been working on — technical experiments, sharing and debugging with colleagues, photographs, you name it. My most active writing spurts have been on the heals of learning new technologies or working through the process of teaching others about those technologies. Both cases times have left me with ideas running around my head or solutions that I felt I needed to make more concrete by publishing them online.
At other times, like much more recently, the site been quite dormant because I didn’t feel I had much to add to active conversations. I just found that some of the more prolific sites were [and still are] doing the basic flagging of important things for web professionals to read so well that it was silly for me to duplicate their efforts.
It seems like a good time for me to get back into the habit of writing on the various areas of my expertise. The great sites are still doing great things, and I still don’t have any desire to repeat what they’re posting just to make this site look active, but I have found myself itching to share as I work though some different things.
On the web development front the browser landscape is changing, the device landscape is changing, and how people are using sites and interacting with properties is at an increasingly interesting place after being stagnant for so long. I’ve also been spending a lot of time in working with photography tools and on photography forums and seeing the intersections of those tools with web technologies. It all makes for some interesting connections that I don’t see many people exploring and that I think deserve more attention and more standards advocacy. With some many of my web geek friends owning great cameras and experimenting with different workflows and photographers wanting to get their work online I think that the cross pollination between these topics might be interesting to explore and discuss.
So that’s where PNH will be heading for the next little while. More web development topics, more writing on digital photography tools. And to keep it unique, perhaps a bit of chatting about some of the local parks and hiking areas I’ve been escaping to.
Enough with the promises. I want to point out a few new features on the site that might not be obvious on first look [or to those of you reading this in a feed reader].
I’m not a graphic designer by nature or by trade. When it comes to web layouts I think of myself more of an architect who might try and plan the use of the space in new and interesting ways and play more off of the environment. One of these environmental constraints that I think is so often ignored is how to leverage the range of shapes that a browser window might be sized. Although the new site is not ‘liquid’ in the typical sense I’ve built it with some flexibility to reform to a couple different base dimensions as space is available.
I’ll break down the layout flexibility in a future post, but to see some of the changes you can resize the width of your window to go from a one column style to two.
This is a 10 year old web site and throughout that time I’ve tried not to delete anything. This leaves a lot of code samples, downloads and other information published that folks might find through google, old bookmarks, and however else, and while I didn’t want to take the content down, I did want to try and flag it so its clear that the content may no longer be up to date. You can see the warnings in action on this old page of JavaScript doodles.
Some of you old timers might recall a day where each iteration of “Place Name Here” had some facility to do just that — submit your name to appear somewhere on the site in a creative take on the old guestbook scripts. It was an excuse for me to play with some early CSS techniques and do something unique. Well it is back as an [obvious] easter egg, and powered by AJAX, PHP and a database instead of the old perl scripts and flat files. So go ahead…
Find the form [hint: look up] and Place /Your/ Name Here.
The New York skyline will never be the same.
View here of the Twin Towers and the rest of lower Manhattan as seen from Eagle Rock Reservation, 13.4 miles away. Taken some time in March 1998.
On Place Name Here: Photos from the morning of September 11, 2001, Hoboken, NJ
On Flickr: WTC, September 11 Memorial
:(
Word from NetNewsWire developer Brent Simmons is that the next update to the great OS X feed reader will drop microformats support. Quoting the post:
My favorite thing was deleting the microformats parsing code. Any CFXML-based code should be nuked. (I have no inside knowledge about CFXML being deprecated or anything — but it should be.)
It also means a slight performance boost when opening news items and web pages, as NetNewsWire now doesn’t look for embedded microformats. (It still looks for feeds in web pages, though, of course.)

Much of software development is a balancing act, and I can’t fault Brent for the choice here, but I also can’t help to feel a bit down on this loss.
I’ll happily admit that the large majority of feed items I see do not contain microformats, but for those that do include events, contact info or related info this was a great feature. Its important to note too, that with the use of RSS / Atom feeds for so much more then blog posts that there are some really great use cases for this functionality [feed of latest users added to an application being one example that comes to mind].
Some time ago — before this support had been added to NNW — “I had written some simple scripts to do microformat detection and extraction from feed items. Perhaps its time to resurrect that old code.
Those who read photography blogs may have already come across the dustup, but the discussion over [ab]use of the Flickr API and application developers not respecting copyright on content should be of interest to the web developers out there as well.
The discussion centers around the realization that last weekend Every Flickr Photo Ended Up on Sale as cell phone wallpaper at MyxerTones.com — regardless of what copyright terms were designated on the photos — including All Rights Reserved and Creative Commons Non-Commercial flags. After complaints the store quickly shut down its Flickr integration, but its not the only usage of images that bothers some photographers.
As with all publishing on the web there’s a balance that both individual copyright holders need to think about and realization that if you publish it the bits /will/ be out there for people to take. There is a similar balance that those building web sites and other tools need to consider between ease of use and ability to protect the integrity of their systems and users. The interesting part of the current discussion is that there are so many ‘end users’ participating and those people not commonly thought of when considering and designing APIs.
This last week saw two big JavaScript projects debut with releases and live code. John Resig has released Processing.js and Richard Herrera has introduced the Flow library.
Unless you’ve been living off the grid you’ve probably seen some mention of John Resig’s ‘big and pretty’ project, Processing.js. He’s gone and done it again, this time with a port of the Processing visualization language to the web via JavaScript and the canvas element. If that means nothing to you visit the site and check out some of the pretty demos.
Is this the beginning of the end of Flash? I’m not gonna go anywhere near that one, but Chris Blizzard has point out a few ways the open web has embraced the code in just a few days.
Richard Herrera, who I’ve had the pleasure of working with over the last year, has completed and released his JavaScript library — Flow. Sure, you say that the JavaScript library space is already crowded, but that doesn’t mean that there isn’t room for another tool in your arsenal.
Richard has aimed to create a small, lean, code base for cross browser implementation of standard DOM features and the ability to customize the library by picking and choosing the additional features you’d like.
Flow is already in use at the new South Park Studios, and you can see examples and docs and grab the code from its project site.
So here I am a couple weeks after the IE team announced through a variety of different channels their proposal to help cushion the blow of their next browser release through the use of a META declaration and HTTP header, “X-UA-Compatible” describing what browser(s) the page and its associated styles and javascript files target.
I’ve got plenty of thoughts on why vendor extensions and related adjustments to behavior are bad. I also have some concerns over this one in particular. Extensions, and more general workarounds and hacks of all kinds [vendor driven or not] get buried into code, reused, copy and pasted, dropped in application templates, removed by accident, and generally used by people who don’t know why they’re doing it, but instead just because it works. As anything other then a very temporary, one time use solution this doesn’t seem to me to solve any problems that are inherent with either web standards or an ecosystem where content publishers are open to who they let see their content. But let me not get too far off onto that tangent and consider first that the proposed solution goes through.
For the moment I want to focus on the practical — what does the additional rendering mode and the ability to switch to it via META declaration mean to me as a working web developer?
There’s been lots and lots of discussion of the proposals via blogs, mailing lists and other forum, but they’ve focused on either how the proposal was raise and whether its appropriate direction for the technologies web developers work with to take. Through all those discussions however I’m still having trouble wrapping my head around the long term impact of the proposals and how I need to manage my very non-theoretical code and projects. In a search for discussion of these practical examples on how one would start to tailor their code in this new model I’m turning to you all. Can the extensions, and the additional rendering mode they’re implying be worked around with no impact at all, or if it requires new planning on the part of developers, or is it just more of the same planning we’ve been doing for ages.
In an XHTML1.0 IE6 & IE7 world my typical structuring of code to ease browser hacking and targeting has been as follows:
That has worked for the last 1-2 years in a world that knew nothing about IE8.
But now we’re in a world that knows IE8 exists which changes things just a little bit if I want to be a responsible web developer. Any document I publish or help a client publish from today on I have to consider [with limited knowledge of details] if and how I want to prepare them for the upcoming browser changes.
Reasonable approaches all — I may flip flop some while I decide what I think works best and see what others are doing. However, they’re also solutions for the extreme near term. Looking further out the answers and options start getting fuzzier.
Shortly after IE8 hits web developers will have to switch from asking themselves how to code for the unknown, isntead having to code for the new known. It is easy to anticipate that a requirement for any new site in this time will be to cover exsiting compatibility [IE6 & IE7] and extend to the new kid on the block. So how might we do that with all these rendering modes floating around? At the pace standards move along, as well as the need to avoid total screwy quirks mode in the older browsers lets presume we’ll need to stick to the same languages that we’re using currently [for some time at least]. So to revisit my current model of structuring code for compatibility’s sake out 2 or 3 years what would that look like?
One thing we, as web developers, haven’t had to deal much with — ok, I lie, we’ve had to deal a lot with — but anyway, IE8 promises to have some large javascript feature changes and it has been cited [or presumed] that this as a big reason about why the separate “mode” is needed. Though I welcome the progress on the scripting front, the “rendering modes” is not an angle that has yet impacted JavaScript code. What real impact if any will the same browser and version changing javascript behavior based on mode have on our existing or future sites? Will it have any impact at all? Is the last option for browser version management feasible if the JS changes are indeed drastic?
We may not know how to answer this until some concrete information on JavaScript changes in IE8 is posted, or even still not until we see a public beta build released to the public. That said, I’m not sure the question, nor the answers are premature if we’re being asked now to evaluate and embrace the proposal.
In a roundabout way I’m trying to both air, but also think through, my concern that the middle term outlook [2-3 years, or as long as XHTML 1.0, IE6 and IE7 all live] the additional rendering mode of IE8 and mode switching mechanics will keep developers in a “think like its IE7” mindset and not take real advantage of IE8 because of the difficulty of mixing the IE8 benefits with something that would work reasonably well in IE7.
I think its great to have a handle on the short term solutions, and its certainly enjoyable to envision a future with HTML5, CSS3, SVG, Canvas, DOM3, XML, XSL, and whatever other standards may be in the works. But should I be concerned that we’re setting ourselves up for a /worse/ middle term outlook then we would be if we kept on as we have been? Am I way off base with these concerns? Have I totally missed the point or the timeline?
Are there potential solutions or coding practices I haven’t thought of?
Through ALA and the IEBlog comes a proposal for a new mechanic of handling the backwards compatibility of web sites — pushing the familiar DOCTYPE Switch aside and going with a new mechanism of declaring target browser versions via meta tag.
The perfect solution or the last sign of the web standards apocalypse? If you’ve got an opinion let it be heard.
Molly recently lamented that twitter has sucked the blogging out of her. I’ve been feeling the same way for some time, though I was never as prolific a writer has she is. Though for me I think it was Web 2.0 that has sucked the blogging out of me, and unfortunately the slow down isn’t all that recent.
Bookmarks hidden in one service, interesting news stories in another, photos and other content in yet another. I tried to remedy that with the creation of a tumblelog-like Place Name Where but I never did get it integrated into this site beyond tag searches and so it never felt like part of any discussion that might take place here.
So where to next? The basic tumblelog format doesn’t appeal to me, nor does simply putting a bunch of widgets on page or daily “this is what I bookmarked today” posts along side of any blog content. That kind of leaves most existing solutions behind. I’m not quite sure what form this site will end up in when I’m done or what purpose it will serve. But I do want to start playing again and posting more doodles or pieces of what I’m playing with for others to see.
In the mean time I also have a backlog of posts I’ve been meaning to write or finish writing, some even describing subtle features of the current design [open the site in a browser, not a feed reader and resize the width!]. I may revisit those ideas as a way to get some activity here again and get myself back into the habit of posting on web dev stuff.
A little thank you to Jeffrey and a promotion of Web Standards. More info here
Due to rain last night some town had postponed their 4th of July fireworks. Millburn, NJ was one of them
Don’t miss these!
I’m reading John Resig’s Pro JavaScript Techniques and really digging it. Expect a review in the coming weeks.
I didn’t want to let today go by without a post acknowledging the 2nd birthday of Microformats.org and the related community.
Thought the first year was huge for microformats, the second one has seen additional growth in all areas from format maturity, to huge growth in the community and sites using various markup constructs, to greater support from application vendors.
Here’s a recap of a few recent news items or tidbits incase you missed them.
Drew McClellan has just posted The State of Textpattern over on his site. Drew is not a core TXP developer, but a long time user who has seen the product change and change hands over its life. His concerns are no surprise to me, as we’ve often gone back and forth over IM trying to ease each other’s frustration with the state of the project.
I think Drew has covered most of my frustrations in his State of Textpattern address. I’ve been using it since the Place Name Here redesign in late 2004, and evaluated it for other projects before and used it since. In that time there are some enhancements to the sites I’ve done via other’s plugins, plugins written myself after I’ve seen a need, times when I’ve done things simply to participate in the community and make it look like it had some life [like the theme contest and been in the code enough to know how it works and make a fair amount of my own customizations.
But as time has passed, like Drew, I find myself both concerned and hesitant about continuing to contribute in any way, or keeping it in future plans for my own sites.
I don’t use the product in my typical day to day web development duties [projects are bigger, using other often custom frameworks or languages besides PHP] but I occasionally find myself with time outside of work that I could offer to the project if the motivation was there.
The times in the past when both motivation and time have aligned and I’ve made contributions like the microformat plugin. The times more recently when that has been the case, were time and motivation to revise my plugins or look for other things to enhance [hAtom templates or OpenID as examples], I haven’t had enough confidence in the project to justify the effort. “Big” changes that have been talked about forever like admin side redesigning or the decision to include [or not] a particular JS library would have a big impact on how I should approach my code and what features I think are a priority. With no development roadmap in sight [again not a timeline, just a commitment to features or general development direction] and no assurances that what has been done in the so called experimental branch will be there next week I find it impossible to plan my own contributions.
And that’s my own biggest area of frustration for the last few months. My investment in any particular product on my own blogs is light. I could jump to WP or EE or some other solution in a weekend and be done with TXP and onto plotting how to address my peeves with the new platform. The investment in a product that others might be downloading and using is a bit more difficult for me to abandon.
As much as the direction [or lack there of] is a concern, its only the latest symptom of a something that has always plagued textpattern.
The way product development has been handled since it was opened up to a larger, more open team, has always been difficult to follow. It is a chore to cover the forums, blogs and mailing lists on a regular basis. That their use by the core team go in spurts and ultimately most of the insight into the product comes in the form of replies to inquiries on the forums or individual code checkins only makes it more difficult. Unless it is your job to do so and you’re building sites with TXP on a day to day basis, the commitment that needs to be made before one can just jump in and be a productive contributor has been too great.
Its nice that a core team has formed over time and they’re now looking for ways to sustain themselves, but I agree 100% that its the the lack of open direction, and the occational feeling from some contributors that direction doesn’t need to be or is somehow in a state of development where it cannot be stated that has me concerned and questioning continued use and support of textpattern.
I’ve seen an increase in spam comments, or fishy comments with short semi-on-topic quips that I can only suspect are left as spam. [Yes, thank you, I’m glad you like my blog and think its interesting and informative]. As a result I’ve resorted to turning on comment moderation / manual approving of messages until I have more time to investigate solutions.
Bulletproof Ajax is a newly released book from New Riders and author [and fellow WaSP member] Jeremy Keith. Devoted to teaching the proper way to design for and use the technologies behind everyone’s current favorite buzzword. If you’re looking for a step by step guide on how to recreate your companies Flash application click for click this probably isn’t going to help too much (other then perhaps help push you into the direction of rethinking your approach, or just going back to your old friend), but instead it does a wonderful job of breaking down the systems that make Ajax work and putting them in context — that being a new dynamic way of enhancing, interacting with and manipulating web documents.
Bulletproof Ajax by Jeremy Keith
People who are new to the concepts of Ajax, or may have rusty JavaScript chops will find the introductory chapters quite useful although I found I breezed through them. For the developers who have been using these technologies for some time, or those whose experience is primarily via using a specific library or toolkit and simply learning its API the books coverage on some topics that you may not have put much thought to is worth the read.
This is where the book shines. While other venues may be touting Ajax for their wiz bang animations, or flashy page updates Jeremy makes sure that core topics like progressive enhancement, unobtrusive Javascript are covered. Throughout the book he covers using the new wiz bang technologies appropriately and in ways that don’t compromise accessibility, overall browser compatibility and other benefits that come with good web development practices.
Having been knee deep in a few projects with Ajax usage from heavy to light over the course of the last year or two I was left feeling like it could have offered just a bit more in the way of complex coding examples. Without recreating some monstrous desktop application and running the risk of flying in the face of the advice found in earlier chapters, I think it would have been helpful to see some examples or suggestions on how to deal with situations where multiple parts of pages or updated or you would have to reinitialize events on multiple objects. Perhaps that area is best left up to a text on proper object oriented JavaScript coding, but I find they come up quite often when dealing with more complex interaction, and it certainly has a good deal of impact on how one architects an Ajax based site.
On the flip side of that, by its nature and scope Bulletproof Ajax would be a book I’d encourage non-coders — those who plan, design, and work with web sites — to spend some time with the book [possibly skipping specific coding examples on the way] to get a grasp on the fundamentals.
At the end of his review, Gary Barber also notes that the book does not cover server side implementation in depth, which is also true, but I cannot say that I noticed it was gone until it was brought to my attention. Its a topic much like general JavaScript coding topics that couldn’t be covered in a complete manner in this book, but just maybe could have been given a little more bandwidth.
But for a 200 page book it covers what it sets out to do extremely well and I’d highly recommend it to anyone working on the web.
Tomorrow, April 5th, we will see the return of CSS Naked Day a novel idea where participating sites will remove all styling information in an effort to promote standards, get a little self promotion, and have a little fun. My take, reposted from the discussion at webstandards.org, is below. I said a bit more about it last year in I’m Not Naked, most of which still applies.
It’s meant to illustrate the importance of CSS and graceful degradation.
My interpretation on it is that it is meant to illustrate the importance of good HTML and markup practices as much as anything else — that CSS is great, but it should overshadow it all. Or maybe that’s just my own philosophy bleeding through. I surely would have called it “Naked HTML day” had I thought the idea up, and explicitly included scripting in the ’stripped’ category.
Let us also be clear, the group of participants in this event are self selecting, that is no one is forcing a site to remove their CSS [and perhaps other features such as JS that may manipulate style information]. Therefore I don’t see some of the objections to the promotion holding much water, or at least are made up of valid but misdirected concerns.
The maintainers and stakeholders of the sites participating shouldn’t do so lightly, but probably are not, and I would also suspect they aren’t doing so without considering all of the problems involved. And for the rare few that are participating for other motives [e.g. publicity alone] perhaps seeing their work in the unstyled state will lead to improvements.
And for the record, neither of my personal sites will be involved again this year. For most other sites I work on the group of stake holders is far too large to get a change like this through for what is primarily a social or quasi-political statement with little concrete benefits. But that’s the corporate world for you.
Quickies! Don’t miss these.
Ethan Marcotte just posted his slides from his presentation today at An Event Apart Boston. Grab them from this post. He’s been busy, also writing Where Our Standards Went Wrong for A List Apart.
And John Allsopp wraps up links to microformat presentations given around the world by Tantek Çelik, Dmitry Baranovski and himself over at Microformatique. John too has been busy, his new book, Microformats: Empowering Your Markup for Web 2.0 was released this week.
I’ve just updated my microformat plugin for the textpattern CMS and blogging tool. This update is a maintenance fix to add support for Textpattern v1.0.4 and some changes made in the way tag helpers are built. Users of older versions of TXP should stick with the 1.0 version of the plugin.
Future updates to the plugin are planned to add additional microformats support, expand the flexibility of the tag helpers and to streamline the underlying PHP code. If you’re using this plugin — or have chosen not to — please help by posting a comment letting me know how well you think it fits into your writing style.
Oops. Looks like I brushed aside the browser report updates around here last month. That’s OK, cause its all up to date now — both here and here. Like most months I’ve had to update the script I use just a bit to account for new user agents that come up this time with a few more bots trying to spoof Firefox, and a few new sightings in the “fun” category:
[Wondering if that means I get to write off my Wii as a business expense?]
Seems like a good time for a little update on my contributions to other sites around the internets…
I’m looking for your vote, if you think the shot is worthy, on this image of seedlings for the JPG Magazine ‘Breakthrough’ theme for their next issue.
And last weekend was the Lunar New Year parade in Chinatown, the weather was pretty good and the costumes better. A bunch of photos from the event are now up in a new Flickr Set

Just getting around to some much needed maintenance on some of the projects around here and had to chase down something that was plaguing Place Name Where? for a few weeks now. Though I looked at it when it first came up I just didn’t see the cause of the “Node no longer exists in…” messages that PHP5’s SimpleXML was throwing.
Turns out the cause was as simple (pardon the pun) as a string change in Flickr’s RSS feed
The media namespace URL was changed from “http://search.yahoo.com/mrss” to “http://search.yahoo.com/mrss/” (note the new trailing slash) which meant that my application was no longer addressing those elements properly, manifesting in it not loading the Image and Thumbnail urls properly. GRRRRR.
Always the little things I guess. All better now!
Interrupting the dearth of posts to bring you this important announcement… 24 Ways is back this year with a round of daily web development related articles. So far we’ve got a few great pieces, with a mix of immediately useful information and some things to look forward to.
And don’t overlook the comments, which can be as interesting as the pieces themselves.
Andy Clarke has posted a quick write up of his approach to browser testing new site designs. Though a bit of a simplification, he follows a line that looks similar to:
And then trails in with testing the stragglers at various degrees based on spec, but always for at least access to content. I don’t have too much to add to that other then I agree. When I’m coding I will typically be working on my mac with Camino open (it always is), Firefox (for the DOM Inspector + JS console) and Safari. When the page is stable in those I will turn to IE/Win (flipping between 6 or 7, depending on which box I’ve got easiest access to) and then work out from that base. The only real difference in our approach is that more often then not I still give IE5/Mac style information.
Californian, friend, fellow WaSP member, and “Web Geek” Dori Smith has recently had her personalized license plate stolen. Have you seen this plate hanging in someone’s cubicle? Someone’s dorm room?
If you have, please contact Dori.
I’ve gushed here numerous times about the Mozilla / Firefox DOM Inspector tool and how the insights it provides into the way the page is parsed and rendered by Gecko are indispensable when building a web site. What I haven’t spent nearly enough time doing is gushing about similar tools in other browsers—specifically Internet Explorer and Safari.
Safari, err, WebKit nightly builds have had a DOM Inspector tool of their own since January, Web Inspector, announced in this post. The tool really holds up well to its older counterpart listing node information, all individual and combined style rules, highlighting the active element in the browser window and more. It also has some interesting new features—two shown here—identifying what style properties have been ignored or overridden by another rule and a ‘metrics’ view which shows the box, padding and margin dimensions of any given element.


The only feature I find that I miss from the other tool is the ability to change CSS properties on the fly, but its an easy one to work around.
What did I do before this thing? Seriously.

Its kind of a mix between toolbar and inspector with common items like outlines and validation tools, but the key feature is certainly the ‘View DOM’ window. Again, the features are in line with the other available tools, you can walk the DOM tree, inspect properties, change attributes of individual nodes and see important information like ‘hasLayout’ values right along side the CSS properties. But there seems to be one big missing piece that I find getting caught up on regularly when working on complex sites—no view of individual CSS rules, only combined rules—this can make trying to trace values through different style sheets (and sometimes IE only ones) still a bit hit or miss on complex sites.
Don’t let that prevent you from installing it, even without that key-to-me feature it still is a tool that has saved me countless hours since I’ve installed it. You can grab the IE Developer Toolbar here for IE6 and IE7 and read up on it here.
On my trip through my feed reader this morning I ran across a post by Jason Kottke talking about how he recently picked up a Kodak Duaflex II camera in hopes of taking some digital shots through the lenses of the old camera.
It just so happens I had sitting on my shelf as decoration (has a few cracks and dings that prevented me from trying to use it for its intended purposes) a Duaflex III. 4 minutes with the cardboard insert from an Amazon shipment for the sides of the hood and the last bits of a roll of gaffers tape and I have my own TTV ‘contraption’.
Operation is a bit awkward given I’m not using an SLR, but a smaller Nikon 995, and I need to spend some time looking for the right focus and zoom settings to get the best results, but it shows promise. Here’s one of my first test shots (no out of camera processing):
I only had the time to give it a try and see if I can focus it and if I’ve cut off any glare (pretty good). Hopefully I’ll have some time this week to take it out for some real use.
Via new hockey blog On Frozen Pond comes word that the world’s oldest hockey stick will soon be put up for auction on eBay with proceeds going to charity.

Comes with its own custom 150lb glass display case—imagine the shipping!!!
A week or two ago I posted some comments about working with CakePHP for an upcoming project. Well, I’m happy to announce that that project—Place Name Where?—is up.
Place Name Where? is a personal information aggregator that tries to reverse the trend of decentralized content contributions that seems to be one of the core features of “Web 2.0” sites.
Web 2.0 is great, but at a certain point one can feel too distributed. You’ve got news stories here, pictures of your pet dust bunnies over there, and in the cellar you keep your favorite wines. Each service is kind enough to provide ways to include the content you added to their site back into your own site, but typically this is limited to a presentation that doesn’t go further then “hey, look at the last 10 things I did on this other site”.
The site works by regularly grabbing several feeds associated with my accounts on the selected services and then permanently storing a copy of the data on my end. Once I’m free of the restrictions of RSS feeds, APIs or JavaScript embedding techniques I can build much more elaborate views on the data like displaying recent activity across all services or looking up all things tagged with nhl regardless of the type of thing it is. I dubbed it a “Web of Web Things” after the discussions of similar tagging and aggregation of real world Web, or Internet of Things (call them spimes, blogjects, or whatever you’d like) by Bruce Sterling, Adam Greenfield, and others.
This aggregator isn’t intended to be a stand alone site forever—though it does work fairly well as such. I need to find some time to spend working on design and integration issues, but I hope it won’t be too long until the ideas behind Place Name Where? are integrated into this site and appear both in place of the current “link” lists as well as integrated into tag lookups and maybe search results.