Will Oller .com

The problems with the new solution are many. The ones that concern me:

• After just a few versions, the browser will be hopelessly bloated and bogged down trying to maintain several versions with all of their features and bugs
• The point of the solution is to make browser bugs immortal. But will there be bugs in the bugs? Will the peekaboo bug or hasPosition act differently on the embedded IE6 from the original IE6? My head hurts just thinking about it.
• Like it or not, web design is a craft. The building industry doesn’t give special exceptions to architects who want to build a skyscraper out of wood just because they’ve always built birdhouses and wrap-around decks. Instead, they tell the architects to learn about steel and concrete and glass or find a new industry.

Those issues aside, maybe version targeting is not all bad (God help me, but I trust that Eric Meyer). But I agree with Ethan Marcotte that the solution is elsewhere; and by elsewhere i mean right here.

It’s not complicated. The flaming will die down. The Web will be saved. Our job - our craft will get a little easier and a little better.

The Solution

Microsoft should release stand-alone downloadable versions of Internet Explorer.

It should also give IE7-8-9-10 the ability to “nest” browsers in the parent browser window, just like Firefox already has. Sure, the tag could still be used to automatically specify the IE version, and the user could be asked if they want to view the file in the pre-selected X-UA-Compatible version or in the current (IE8-9-10) version they have now. Then, if the version is not installed, they could choose to install it or go ahead and view it in some other installed version.

IE7 has a plugin architecture; IE8 should too. The only thing missing is the standalone IE releases (MultiIE already does it for XP, but it fails horribly in Vista).

I think this gives all of us the best of all worlds: Corporations who need a certain version of IE for their intranet will have it. Users who want cutting-edge compatibility and speed will have it. Developers who need a solution for future-broken sites under IE11 will have it. Standardistas who need those versions to browser-test for backward compatibility will have them.

Freezing all future versions is not the answer; we will be sorry. Let us pick-and-choose the fossilized browsers as we need them and we will all have what we want.

The use of px units, when viewed with IE6 or IE7, leads to fonts you can’t resize (unless you turn off some seriously buried preferences). Every other browser on every platform can enlarge or reduce fonts in any CSS unit, including px. It’s true that pt makes sense only for print stylesheets, but px is a “relative” unit, as I keep reminding people.

Squashing a persistent myth ¶ Personal Weblog of Joe Clark, Toronto

Joe Clark makes a good point about the nature of font resizing in ie vs all other browsers.  I, too, think it should be up to the consumer to use a browser (or accessibility software) that is compatible with their needs.

However, I still use relative font sizes in my web design projects.  It seems to me to be the most accessible method because of the ie limitations.

Whither do I turn? Do I embrace my capitalist side, saying caveat emptor, download Opera if you’ve got a problem with your eyes or do I continue listening to my communistic all-for-one accessibility side that says keep struggling late nights with relative font sizes?

I think the capitalist (and pragmatic) side is winning. Is that wrong?

squish squash

For those of us who care about the semantic web, standards, or the W3C, The Web Standards Project needs to be in your feed reader. I’ll admt, it wasn’t in mine; until now that is.

The design of the site is awesome, and they eat their own cooking. (Plus, they use Wordpress!) They employ css tricks I have seldom seen used before, and consistently use semantic tags (<abbr>, <q>).

The best trick of all: the sibling selector. Why? Because it allows for truly semantic output with the leanest markup possible. Before, I might have marked up a simple content block like this:

<div class="content">
   <h1>Title</h1>
   <img src="url" alt="pic related to story">
   <div class="block">
      <p class="intro">This is an introduction sentance or paragraph.  It is supposed to represent a blurb about the article below.</p>
      <div class="mainbody">
         <p>content</p>
         <p>content</p>
         <p>content</p>
         <p>content</p>
      </div>
      <p class="footer">Footer.  Date or links, or whatever.</p>
   </div>
</div>

This way, all of the elements have class hooks. CSS is applied using the classes and simple hierarchies:

div.content { }
div.content h1 { font-size:1.8em; }
div.content div.block { border:1px solid black; }
div.block p.intro { font-weight: bold; }
div.block img { float:right; }
div.block div.mainbody { clear: both; }
div.mainbody p { color: #006; }
p.footer { font-size: 0.7em; color: #888; }

Class hooks are helpful, but not really needed if you use sibling selectors! You, too, can write super-styled code without the additional markup headache!

<div class="content" >
   <h1>Title</h1>
   <img src="url" alt="That image again"/>
   <p>This is an introduction sentance or paragraph.  It is supposed to represent a blurb about the article below.</p>
   <p>content</p>
   <p>content</p>
   <p>content</p>
   <p>content</p>
   <p class="footer">Footer.  Date or links, or whatever.</p>
</div>

See, that code is cleaner and easier to maintain. The CSS required to

div.content { }
div.content h1 { font-size:1.8em; }
div.content p { color: #006; }
div.content h1+p { color: #000; font-weight: bold; clear:both;}
div.content h1+img { float:right; }
div.content img { float:left } /* Just for fun */
div.content p.footer { font-size: 0.7em; color: #888; }


That’s all there is to it.  Now, the line between content and design is darkened.

One thing: the class hook remains on the footer element.  This is because adjacent-sibling selectors do not work in reverse.  The selector applies only to the element after the +, and there is no selector that applies to a previous adjacent-sibling element.
Sources

Eric Myer wrote about them.
The W3C recommends them.
John Gallant and Holly Bergevin say IE7 supports them.