Professional Web Developer, Apprentice Photographer
There are some interesting new things going on the world of web site layouts with CSS and JavaScript all the time. Tricks and tools to add to a client side developer’s arsenal for making flexible, content accommodating navigation, layouts and presentations. Though I wouldn’t give away any of our progress, I can’t help but wonder if sometimes the amount of work we ask a visitor’s browser to do is overkill. One way to shift this workload off the browser — without placing undo burden onto the site management staff or its budget by requiring a high level of technical expertise with each site update — is to move the it to an offline or backend CMS tool creating static code for publication. This is particularly useful when doing multiple site deployments with a similar theme or building different localized site versions where the need for flexibility in type doesn’t change from user to user, but from content update to content update or deployment to deployment.
Through the use of fairly simple to create build tools we can create ‘static’ CSS for deployment and consumption and trim the amount and complexity of layout code sent with each page.
For a recent project I was given the task of creating a lightbox style help dialog. The dialog was intended to highlight content of an odd or unknown size in addition to the more controlled information box. Essentially a figure in the shape of 2 adjacent rectangles of variable sizes that needed to be highlighted. The backbreaker — the 8 sided popup needed a large, opaque & diffuse drop shadow to make it stand out off the content.
This was the perfect use case for CSS box-shadow, but its also a public facing promotional site that for good reasons couldn’t just thumb its nose atMicrosoft Internet Explorer. The value proposition for any new CSS property – to make things like shadows and gradients easy to develop and manage with one rule replacing old complex solutions – is lost if you still have to code for that old complex solution juggling multiple PNG images and layering in added markup. Still, that work sounded painful to write for IE6, IE7 & IE8 as well as Firefox, Safari and Chrome so I started looking for an alternative in the proprietary MS filters which are supported in Internet Explorer 5.5 and up.
A little while back I mentioned that I had reclaimed an old domain of mine and was looking for something to do with it. It took about two months to pull the free time together to design and build it, but I’ve just relaunched the site: Hike New Jersey.
Some of the most powerful CSS2 and CSS3 selectors defined in the specs are avoided by web developers because they’re not supported by commonly used web browsers. Sometimes in order to work around these shortfalls solutions with large overhead such as javascript libraries are used or code becomes littered with many specialized classes and sites become difficult to maintain.
Over time I’ve developed the habit of using specifically named class attributes to represent exactly where a pseudo-class would have applied. To aid in clarity and maintenance these classes are named with the same text as the name of the pseudo-class being represented.
Drew McLellan has for the 4th year running wrangled a bunch of great authors and launched the Web Development Advent Calendar 24ways.
It isn’t December yet [in this time zone anyways] but the first day’s article has been posted for your enjoyment — Easing The Path from Design to Development. This is a nice piece on interaction between different sides of the site building process, something I’m intimately familiar with. A few pointers from my experience that are worth adding to Drew’s comments…
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.
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?
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.
Hey look, I did it!
After roughly six months of sitting on a design I was happy with I’ve found both the time and ambition to finish building an update to Place Name Here. Not quite sure what version of the site this is, but 6 seemed like a good number when I started.
Like with all previous versions of the site the new layout is fairly simple, and doesn’t use a lot of images or tricks to play things up. This site always proves to be difficult to rebuild in a uniform way because of the patchwork of different side projects, and technical demos that have been posted since the site first launched in late 1998. The new design and slightly rearranged navigation will hopefully help give a better perspective of what is hiding on the site.
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.
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.
Jon Hicks has taken the idea of client side style sheets to highlight microformats that I implemented in my NNW Extract Microformats tool and ran with it. He’s cleaned up the presentation and made a user style sheet that you can use in most any mac browser—like Camino, Safari and OmniWeb (though the idea works in most other browsers as well). Combine the detection of microformats on the page via these style sheets with some bookmarklets (also provided) and you have a simple system for grabbing hcards or hcalendar events from any web site.
I’m pleased to announce the release of my latest little hack for adding microformats support to NetNewsWire (not lite)—Extract Microformats v0.5.
This little script is actually a combination of theme files (css) and applescript to bring a bookmarklet like option that uses Technorati’s microformat services to save hCard or hCalendar data found in the content of feed items. After installation (just copying some files) saving events or contact data is as easy as 1, 2, 3… er… 4.