Finding the Missing Pixel
Spelling aside, we take our search wijit very seriously. It is by far the most visible component of Lijit’s offerings and, as such, necessitates some extra special design attention. A few weeks ago we noticed that a rendering issue started showing up in webkit based browsers (Safari, Chrome, iPhone), which was affectionately dubbed “the missing pixel.” This bothersome bit of negative space was much more than a compatibility issue. It was - to put it simply - our wijit failing on us.
How Did We Get Here?
So how does something so simple get so complicated, such that it starts breaking in the most modern, standards-compliant browsers? Well as it goes in any start up, results must come quick and that often costs certain details. We had written so much CSS quickly, to solve so many one off issues, our code was becoming brittle. And the missing pixel wasn’t even half of it. We had focused so intently on our technically supported browsers that the unsupported browsers were treated as second class citizens. Opera was a mess, both desktop and mobile. And with IE8 on the horizon it was time to go back to the drawing board and build a better wijit.
Planning a Happier Wijit
Rethinking the wijit posed a unique design challenge. It needed to render exactly the same across every browser/OS/rendering combo imaginable (text-based mobile browsers excluded). This is contrary to an extremely popular mantra in web design: websites do NOT need to look the same in every browser. Just ask Dan Cedarholm. I still advocate this philosophy in almost every context. However, a piece of functionality as visible and essential to our product as the search wijit requires visual consistency. And considering the alternative who’s name we do not speak, we had to do it with good ‘ol HTML/CSS/JS.
Step One - Identify Rendering Issues
After analyzing the legacy CSS we identified the source of almost every rendering issues: quirks mode. Quirks mode is a deprecated method of CSS rendering used by browsers on pages that fail to declare a document type. You can learn more about quirks mode and the doctype switch here. Because of the diversity of blogging platforms and web sites that our wijits reside on, supporting quirks mode was a must. We had previously written CSS that simultaneously accommodated quirks and standards mode. This created a very unstable house of cards. Make a change for standards mode and something falls over in quirks. Not a good place to be.
Step Two - Target Quirks
With a little JavaScript wizardry we were able to detect the browser’s rendering mode. Mix that with a conditional quirks mode style sheet and voilà! We have healthier, happier wijits. The main rendering inconsistency between standards and quirks was the height of the text input field (hence “the missing pixel”). This is due to various box model differences that I won’t bore you with here. All we needed to do was set the height for the input 6 pixels higher in quirks mode like so.
Standards Mode CSS (base styles used by all wijits)
- /* Text Input */
- #lwp_main #lwp_sfd {
- float: left;
- height: 15px;
- padding: 2px;
- margin: 0;
- font-size: 12px;
- }
Quirks Mode CSS (only loads when browser is in quirks mode)
- /* Text Input */
- #lwp_main #lwp_sfd {
- height: 21px; /* overrides standards mode height */
- }
This solves 90% of our wijit rendering issues. The rest are taken care of by a swooping CSS reset.
Step Three - The CSS Reset
As stated earlier, the wijit needs to look consistent across countless platforms and within countless codebases. A common problem with the old wijit was inheritance of CSS from the blog or site it lived on. This can be good in certain circumstances, but is usually undesirable. For example, if your blog theme placed a custom bullet icon on list items in the sidebar, all the list items would inherit those bullets unless explicitly overwritten in CSS. In steps the CSS reset. By telling all HTML within our wijit to start completely unstyled, we can maximize rendering consistency. We used a fairly liberal reset which allows us to start our wijit’s rendering with a clean slate.
Now we have a (more or less) bulletproof CSS/HTML wijit that will render consistently in more places than you can shake a stick at.
Step Four - Testing Testing Testing
Once this new front end code was integrated with the back end and we were serving wijits to real Lijit users, it was time to start testing. I set up a WordPress install and ran through roughly 100 different WordPress themes on every browser I had handy (IE 6/7/8, Safari 3/4, FireFox 2/3, Chrome, and Opera) and that’s before handing it off to QA. Things looked good. Really good.
The missing pixel was found and we now have a much more stable wijit that lives up to our publisher’s needs. We hope you like it as much as we do.
