Wrap Up: Standards-Next NYC

On Friday Nov. 20th, ending a wall to wall week of conferences and general geeking out about web technologies I had the pleasure of both attending and speaking at Standards-Next at the Time-Life building in Manhattan. Industry big shots HÃ¥kon Wium Lie [inventor of CSS! OMG!], Molly Holzschlag, Andy Budd and Pete LePage of Microsoft [sans flak jacket] guided an enthusiastic audience through the tools we’ll be using to build web sites over the next few years.

Andy Budd on CSS3

Andy of UK agency Clear Left and co-author of CSS Mastery, 2nd edition kicked off the day introducing everyone to some of the new toy we have to play with in CSS3. Beyond rounded corners, he demo’d border images, multiple background images and some tricks like those he’s used on the Silverback site [make sure to change your browser width when visiting].

Molly Holzschlag on Color

Molly followed up all that talk of tags and borders with talk of color on the web — both rgba() which extends rgb() with transparency, but also hsl() and hsla() which gives an additional option for defining color based on 360 hues which may make creating color pallets or transitioning colors easier.

A note for those at the event, here’s an example of how to define color so that non-rgba() supporting browsers will display the same shade of “gray”, in some cases with and others without transparency.

body {
background: rgb(255,255,255);
div {
background: rgb(204,204,204);
background: rgba(0,0,0,0.2);

I use this technique in the footer of Hike NJ.

The Lightning Round!

The audience was prompted for volunteers to join in a series of 5 minute talks to compliment the topic of the day. Among the ones I found most interesting were Mike Taylor on HTML5 web forms support and Paul Irish on JavaScript ‘bridge’ style library Modernizr

I took the opportunity to present some rough ideas on mixing the good parts of CSS2 with new things from CSS3 to create web sites in today’s browser ecosystem that take into account the needs of site owners and communicate the design or brand identity across both old and new browsers. I’ll have more on being clever with the tools we have at our disposal in an eventual follow up blog post.

Pete LePage on The Future of IE

The initial reaction on twitter to the announcements about IE9 earlier in the week seemed mostly hit the “OMG, they’ve finally got rounded corners, thanks for almost catching up” sour note. Though we really didn’t get any more information about IE9 then the rest of the public has Pete did a good job of reminding everyone of some of the other features in IE8 and IE9 that do take us beyond IE6 & IE7. Things like data stores, native JSON support & CSS2.1 selectors. So don’t hate on MS or IE8/9 when you decide not to use a data: uri because IE7 doesn’t support them.

HÃ¥kon Wium Lie on CSS3 and Web’s Future

Starting with a walk down memory lane [and the halls of CERN] father of CSS HÃ¥kon talked about where we had been, where we are now, and then looked to the future in what is on the horizon. His set of photographs from CERN and the creation of the first internet terminals [and jokes to go along with them] were great. After a walk through some CSS3 features like font-face he demo’d some fun things to do with the Opera Unite local browser / peer to peer computing concept.


In the end, I walked away from the event jazzed both about the features of the specifications, but also about the web development community and the enthusiasm on display both by the speakers and by the attendees. If you want to get some of that too, watch the Standards-Next web site for slides [and video?] from the event and for future events about surrounding new web technologies. Also check theMechanism blog for some live blogging and notes from the event.

Again — many, many thanks to the events sponsors Opera and Time for bringing a great & free event to the NYC web community.

Things I Should Have Blogged This Week

one big alt

Instead of writing about these things this week I let them fly into the twitter, IM, or news reader ether likely not to be mentioned by me again. Maybe I’ll make this recap a semi-regular features on this site as I expect to be quite busy over the next couple of months.

In The Web Standards World

IE8 Standards Mode Blacklist

The fiasco of the week in the web world is the Internet Explorer 8 Standards Mode opt-in-or-not-opt-in behavior for large sites that get reported as not working well in IE. Here’s the blog post that kicked the discussion off.

Molly mentions it — along with announcing she has a new position at Opera! Andy and many respond on For A Beautiful Web, coworker Michael Bester shows his sympathetic side. All required reading. And Via Twitter IE team member Chris Wilson mentions that there may be more clarification for web site owners and managers is to come.

And Then Those Other Yahoo’s…

Not content to sit on the sidelines in the ‘you need to include this new tag in all your pages’ game, this week Yahoo, Google and MSN have announced support for a new link rel value “canonical”. The SEOmoz blog has great coverage in Canonical URL Tag – The Most Important Advancement in SEO Practices Since Sitemaps. The really short of it is that adding code like <link rel="canonical" href="http://placenamehere.com/tag/seo"> in the top of the page will wrap all the duplicate indexed pages at other domains [www.] or other addresses [?tag=seo] into a single entry in search results.


  • Errorlytics gets an official launch. It is an interesting take on web services and customer service letting you easily manage complex rules for dealing with 404 errors. If you’re running a site with many pages or one that’s gone through a few redesigns check it out.
  • Accession Media, a web development and marketing firm I work with on occasion has relaunched their own site with a new look and tighter focus. They’re also the team behind Errorlytics.
  • Michael Raichelson has as fun new tumbler template up on HACKADAISICAL!COM
  • In the wake of the meltdown at ma.gnolia I’ve moved back to using my delicious account for storing and sharing bookmarks.
  • Amazon.com announced the Kindle 2 in part via a giant JPG splashed up on their home page complete with imagemap to reproduce the behavior of the text links in the copy. The big image was not to be outdone by the bigger contents of the image’s alt attribute which included the full text of the letter from Jeff Bezos. I don’t know about you, but I’d be fired if I ever attempted that on a client’s site — and for good reason.

one big img

New In Print

New Browsers Bring New Bugs And New Tools

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.

White Space bug in IE8b2

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:

screenshot of whitespace bug in IE8b2

Opacity Bug in Google Chrome

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:

screenshot of opacity bug in Chrome

Reporting bugs in these new browsers

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.

Google Chrome

Instructions on reporting a bug or broken website in Chrome

Browser crash... go boom

Internet Explorer 8 Beta

Download the Report a Webpage Problem Internet Explorer 8.0 Beta Add-On

What Does X-UA-Compatible Mean For Me?

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.

Right Now

In an XHTML1.0 IE6 & IE7 world my typical structuring of code to ease browser hacking and targeting has been as follows:

  • use an XHTML1.0 [transitional or strict] doctype that triggers “not-quirks-mode”
  • start code with no browser hacks
  • For combined IE6&7 adjustments [hasLayout type stuff usually] use a separate style sheet linked inside conditional comments
  • For IE6 but not IE7 use the * html hack when needing to hide stuff, or remember a few extra rules that anyone can get safely [display:inline; float:left;]
  • Ignore IE5.x and less
  • Keep more complex CSS and other hacks to a bare minimum [e.g. clearfixing, etc.] and instead design and code as ‘universally’ as possible

That has worked for the last 1-2 years in a world that knew nothing about IE8.

With IE8 in our sights

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.

  • Do I leave my above solution in place and do nothing? In doing so I have to hope that IE8 will be good enough to not get IE7 hacks but act like Gecko or WebKit — that or reside myself to expecting that some adjustments will have to be made once IE8 lands.
  • Do I prematurely start to include the like-IE7 meta tag so that I don’t have to revisit the site later and just let the site live forever as IE7 compatible? Is it realistic to expect that this will still work, and there will not be any testing when IE8 hits required, and that things will work flawlessly without going through the same motions that should happen with any new browser release?
  • Does it make a difference if I think the site will have regular staffing and updates or if its just a site build to get something published and nobody manages it again until the next redesign in a year or two?

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.

After IE8 hits

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?

  • Do we continue to play in IE7-standards-mode, coding down for IE6 and hope IE8 needs no adjustments and get nothing out of the IE8 progress?
  • Do we use no compatibility flag and presume IE7 compatibility mode and then code up or down as needed and cross our fingers?
  • Do we use the use the IE8 compatibility flag and code down to both IE6 and IE7?

What about JavaScript?

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?

Read, Reflect, Opine — IE8 Rendering Switch Proposal

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.