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.

Went though a draft of this in my head as a funny Q&A with myself — 19 questions asking if I’d need the newly announced device to help me get existing work done better or if I could expect to jump in tomorrow helping clients create content for a newly introduced publishing model all answered with a simple “NO”. Followed by question 20 “will I still preorder it?” answered with a “Probably”. What I realized as I typed it up was that it all came down to work value vs. consumer value. As someone who is a somewhat recent iPhone owner and a long time Apple laptop user there was no solid work value I could find in this new type of 3G computing device but there is still plenty of consumer value as a consolidation and update of devices we’ve seen before.

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.

After working with some HTML5 web forms attributes on a small project I have come to the conclusion that for now it is best to…

Use <input required="required"> not <input required>

Some backstory — A few weeks back I was working on a small non-public web site heavy on forms and thought it would be a good fit as an HTML5 test case. For a variety of technical reasons [input formatting in particular] I didn’t go whole hog into it using all the various input type attributes, but did use the required attribute as a hook for JavaScript based form validation and styling. What I found was that generally there was adequate support for styling and selecting based on this new, and unknown to many browsers, required attribute — Yay! we can use this stuff today! However, there were a few browser CSS selector and jQuery 1.3.2 quirks that lead me to the conclusion that it is safest to use the expanded form of the required attribute and not the minimized or shorter form as HTML5 allows. This gives you the most solid and flexible options when choosing selectors in CSS or jQuery code.

Today, November 30, is the 3rd annual Blue Beanie Day — a celebration and visible show of support for Web Standards & semantic, accessible markup. Web designers, developers, and users around the world are sporting blue beanies on their avatars to show their support for doing things right.