Versions of the YUI Selector utility prior to 2.7.0 won’t work with IE 8. There’s a bug in there somewhere that breaks className selectors.

So, something like div.bd won’t return any results.

The solution is to upgrade to 2.7.0. I’m working on a site on which I can’t upgrade the whole package; it would take too much QA time. So, I tried dropping Selector 2.7.0 over the existing file (in my case, an ancient 2.5.2 version). The result: seems to work like a charm, so it’s worth a try.

EDIT: Also just saw that IE8 likes to detect our internal dev servers as intranet sites and throw itself into IE7 compatibility mode. Make sure you use developer tools on whatever site you’re testing (production, in my case), and then reset them wherever you’re developing.

Have a look at that lovely Learn and Explore section on NikonUSA.

Copious uses of the YUI library and a whole bunch of lightbox / media player functionality that I hacked together. My favorite part: the in-page glossary (nice little RegExp there) and the little lava menu I worked up on any of the Glossary pages.

If you’re running an animation for 250 ms and you need a function to execute after that, make sure you either run it as a call back or set a timer that’s longer than 250 ms…

Data not going through? Try adding a call to s.tl() to flush things out and make sure they’re sent to Omniture. It seems to not want to send certain custom events by default.

Bit of an odd one. It seems that in between the beta version of CakePHP 1.2 that I’ve been using and the full release, Helpers now must have lower-case filenames or they go missing.

You’ll wind up with a null object error otherwise.

I wonder if I did something wrong?

I’ve been meaning to mention this for a while, but was waiting on a couple post-launch releases that added some “extras” that I liked.

NikonUSA.com was re-designed and re-built by my company, Molecular. We launched in late February and this was a total overhaul: new CMS (Interwoven LiveSite/TeamSite), new design, and plenty of custom code. I built the entire front-end here, from the overall architecture to writing XSL to build HTML to build pages.

There’s lots and lots of custom stuff I wrote from “Quick View” overlays to DOM stylesheet manipulations, and plenty of YUI, awesomebox, and yCarousel to go around, too.

Cool stuff to look for:

• “Product Detail” page— This one mashes up YUI’s tab component, custom flyout code that I wrote, ycarousel, awesomebox for lightboxing images/swfs/video, and all kinds of loading magic. The D300 serves as a nice example. Take a look at that “Media Bar” right there! Plenty of jazzy stuff.
• Pages I designed: the low-bandwidth homepage and search results page.
• JavaScript-to-XML-to-Flash (built by Alisdair Mills) on the homepage.
• Product views, sample photography, and other images being cranked out by ImageMagick scripts that I wrote (ah, Perl!).
• Liberal uses of iepngfix for good old IE6.
• Plenty of tricks (view source) to add in browser-specific stylesheets and extra print media targeting.
• The CSS-only top nav. Tried and true but always nice to show as cross-browser.

I’m most proud of being able to wrangle some nice, semantic HTML in there. The “AJAX” features feel natural, too, something I always like to do in an app: the lightboxes and carousel presentation makes sense and feels right in context; it doesn’t feel “bolted on”, like these flashy bits sometimes do. I can also now give dissertations on Flash/DHTML layering, ImageMagick, and many other cool things.

I may add a few posts describing bits and pieces of functionality in the future; the front-end here was huge, and I built a lot of stuff (and trained users, and designed pages…). But, it’s still a launch!

Tags: nikon, nikonusa, design, build, launch, javascript, html, flash

I’ve spent the bulk of the day getting CakePHP up and running on the www-side of the amodernfable.com domain. Why? Because I wanted to use a framework to handle things like integrating a database-driven portfolio with some static content and learn more PHP (and the Cake framework, which I’ve heard nothing but great things about) in the process.

The CakePHP installation here on Dreamhost was a snap. No real configuration necessary other than setting up my database config file to point to the right spot. I was expecting worse (I know I’ve seen some nasty stuff happen when I tried to get Ruby on Rails up and running before, but this was simple and easy).

Overall thoughts on the framework (from a couple hours’ use): if you’re used to Rails, you’ll know how things work or where they go right off the bat (there are some differences that will catch you, such as default layouts being enforced right off the bat, and I like the RoR approach better that way). Setting up routing was a bit easier than my last Rails attempt. Documentation is easy to find with the right Google search. My object oriented PHP is a bit on the slim side, but, when you’ve programmed enough, PHP is a quick learn; hopefully, the controllers and models will give me more experience there.

It’s nice to have a framework in place to speed things up. Also, I’ve built in Cushy CMS support right into my views, which should make it a snap to update things. I really dig Cushy for doing one thing (managing small blocks of content) very well. Let’s see how well it plays with Cake. (And, there’s two plugs in a single post!)

Above is the contents of the HEAD element. Just the usual suspects, setting the title and some simple CSS stuff. The only interesting part is at line #3, where we load the jQuery library on the server, because we intend to do some serverside DOM manipulation before the page is sent to the client.The runat=’server’ attribute tells Jaxer to load this javascript library on the server.

Server-side jQuery and more cool tricks with Aptana Jaxer | Aptana

Yes, please. Now, where can I get an environment set up with Jaxer so I can try this?

Why do I think server-side JavaScript will only take off when ECMAScript 4.0 becomes reality and brings with it explicit class declarations, packaging, imports, etc? Those things would make it feel more like those languages Java/.net folks use everyday, and could make them sit up and take notice. Yes, it works fine now, but it’s all about perception.

Tags: javascript, jaxer

Another great opinion, from the comments on Anne van Kesteren’s take on the issue:

Solutions? We can ignore this all together.

Ignoring issues seems convenient but there’s a high risk that things get worse in the end than if we didn’t ignore it.

We can get popular Web server software to set IE=edge.

No. This only leads to IE9 getting a different mechanism for the opt-in switch, because, obviously, if a lot of pages uses “IE=edge” without the author’s consent, IE9 would break all those pages, and that wouldn’t be acceptable to MS. So we end up with yet another switch.

We can convince the world to use a browser that does not have the ability to lock pages into a specific rendering mode.

Yes, but how? I wouldn’t expect IE8 standards mode to be on par with other browsers’ standards mode. People expected IE7 to be CSS 2.1 compliant, but it was the same IE with some bugs fixed, some new features, and a bunch of new other bugs.

For damage minimization, I would recommend Web developers to not use IE8 standards mode, as tempting as it seems. You still have to work around IE7. You know what the workarounds are. Continue to use quirks mode or “IE7 standards mode”, whichever you use today. If people don’t use IE8 standards mode, then MS won’t break many sites by continuing to improve “IE8 standards mode”, and thus they don’t have any reason to introduce yet another rendering mode for IE9.

The Internet Explorer lock-in - Anne’s Weblog

Tags: ie8

<style type="text/css">
  @import(mystylesheet.css);
</style>

vs.

<link rel="stylesheet" type="text/css" href="mystylesheet.css">

Which is the way to go? It’s link, and here’s why:

link is easy to skim. @import very quickly gets hard to skim as it’s more than a single line. If you’re trying to quickly browse through a lot of source, you’ll want as few lines as possible. If you’re searching through source, it’s quicker to type "link" then glance to the right.

What about including multiple stylesheets on a single page? Well, that depends on two things: how many stylesheets you’ll have on a single page and who is going to be maintaining those pages.

If you have a ton of stylesheets, it’s best to create a single, master sheet, then use that to @import what you need: write it once, include it where you need it, and it’s done. The same holds true for the latter point: unless you’re going to be the one maintaining those pages and you’re absolutely sure that you’ll remember exactly which page needs exactly which stylesheet, use the one-sheet-only approach.

Get rid of the need to keep track of more than one stylesheet in all but a single place. If you need to make an update, you’ve got an all-in-one fix, otherwise you’ll have to go page-by-page, and that’s never good.

Finally, I like the modular approach to stylesheets: make a separate sheet for separate page types or pieces of content (put your navigation in one, promos in another, and content in a third). Yes, it makes for more stylesheets in the long run, but you’ll save a great deal of maintenance effort, and that’s what counts the most: it’s just easier to find things when they’re kept in sensible modules than when they’re all lumped together.

Tags: stylesheets, css, link