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.

Thoughts?

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?

Things are getting a little old and dusty around here as a result of me being quite busy with work as well as contributing more elsewhere on sites like flickr, ma.gnolia and newsvine.

To honor its crusty-ness I’ve aged the site’s color palette some, like a fine, aged, um, newspaper? Enjoy.

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.

Let us also be clear, the group of participants in this event are self selecting, that is no one is forcing a site to remove their CSS [and perhaps other features such as JS that may manipulate style information]. Therefore I don’t see some of the objections to the promotion holding much water, or at least are made up of valid but misdirected concerns.

The maintainers and stakeholders of the sites participating shouldn’t do so lightly, but probably are not, and I would also suspect they aren’t doing so without considering all of the problems involved. And for the rare few that are participating for other motives [e.g. publicity alone] perhaps seeing their work in the unstyled state will lead to improvements.

And for the record, neither of my personal sites will be involved again this year. For most other sites I work on the group of stake holders is far too large to get a change like this through for what is primarily a social or quasi-political statement with little concrete benefits. But that’s the corporate world for you.

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.

Though not glitzy, there are a few tricks hiding in the new design which I’ll cover in detail in a future post. One element in particular is the code used to create a “liquid” like layout via JavaScript. If you are reading this and seeing a two column layout the left column is made of content that has been pulled out of the main column and repositioned to fill the gap on the left. This is similar to using floats where content will stack if there isn’t enough room to go side by side, but in this method I can pull content from anywhere in the flow of the main column depending on the given page — introduction content from the top, extra content from the bottom, or something I’d like to highlight from the middle.

Another new site feature is the beginning of better integration with the aggregated content on Place Name Where?. This can be seen in the combined tag searches found on pages such as the PHP tag page. This was really what I build the mechanics behind PNW for, but hadn’t gotten to any implementation before this redesign.

More about the guts of the site can be found in the updated colophon. Please take the new look for a spin and let me know what you think in the comments.

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.

• Day 5 brings Accessible Dynamic Links by Mike Davies covers a few different ways to enhance the links around your site.
• Rachel Andrew contributed Day 2 with the simple but powerful Faster Development with CSS Constants
• And as a look into what is coming up in the future (or present for Safari users) of CSS Andy Budd wrote Rounded Corner Boxes the CSS3 Way

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. Though a bit of a simplification, he follows a line that looks similar to:

1. Gecko
2. Safari
3. IE 7
4. Opera
5. IE 6

And then trails in with testing the stragglers at various degrees based on spec, but always for at least access to content. I don’t have too much to add to that other then I agree. When I’m coding I will typically be working on my mac with Camino open (it always is), Firefox (for the DOM Inspector + JS console) and Safari. When the page is stable in those I will turn to IE/Win (flipping between 6 or 7, depending on which box I’ve got easiest access to) and then work out from that base. The only real difference in our approach is that more often then not I still give IE5/Mac style information.

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.

Safari Web Inspector

Safari, err, WebKit nightly builds have had a DOM Inspector tool of their own since January, Web Inspector, announced in this post. The tool really holds up well to its older counterpart listing node information, all individual and combined style rules, highlighting the active element in the browser window and more. It also has some interesting new features—two shown here—identifying what style properties have been ignored or overridden by another rule and a ‘metrics’ view which shows the box, padding and margin dimensions of any given element.

The only feature I find that I miss from the other tool is the ability to change CSS properties on the fly, but its an easy one to work around.

IE Developer Toolbar

What did I do before this thing? Seriously.

Its kind of a mix between toolbar and inspector with common items like outlines and validation tools, but the key feature is certainly the ‘View DOM’ window. Again, the features are in line with the other available tools, you can walk the DOM tree, inspect properties, change attributes of individual nodes and see important information like ‘hasLayout’ values right along side the CSS properties. But there seems to be one big missing piece that I find getting caught up on regularly when working on complex sites—no view of individual CSS rules, only combined rules—this can make trying to trace values through different style sheets (and sometimes IE only ones) still a bit hit or miss on complex sites.

Don’t let that prevent you from installing it, even without that key-to-me feature it still is a tool that has saved me countless hours since I’ve installed it. You can grab the IE Developer Toolbar here for IE6 and IE7 and read up on it here.

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.

The downside of the client side CSS method is that you’re introducing new styles for microformat content where there may already be styles to highlight the hcards, or where the styles will otherwise clash with what the site’s author has coded. Chris Messina has posted a one example of this on Flickr. And here are two examples from Tantek’s site:

Even when there aren’t bugs, the effects of the style sheet can be gaudy or just feel out of place like in this screen shot of an article on ChunkySoup.net.

But presentational quirks aside, the idea is great and the implementation dirt simple. Its clearly a step in the right direction and another good example of how easy it is to leverage content marked up in these simple HTML based formats.

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.

1 – Find an item with microformat content. Here I’m using a feed from Eventful with items containing events with embedded contact data.

2 – Activate the script

3 – Select what to do with the data

4 – Copy the saved data to your favorite app