The fluid elastic reboot

Or why did I do it

Why so elastic?

I have always been a fan of elastic design and after reading a couple of Dave Hyatt’s recent posts, I realised that not all computer screen are equal with some having 96 pixels per inch and others over 150 pixels per inch. So to give all visitors the same experience I have gone for a truely elastic design. The only exception is when the browser width is less than 600 pixels, I will be creating a seperate layout for handhelds, narrow browsers and special purposes in the near future.

How it was done

That was fairly easy, all the unit measurements in the stylesheets are in in ems, including the dimensions of the flash elements. There is a little bit of javascript (fontsize4.js) that reads the browser window width in pixels and the converts that to a percentage and feeds it to document.getElementsByTagName(“body”).item(0).style.fontSize (.) Being lazy, early in my calculations I decided the maximum window width was going to be 60ems, my opion the smallest font size in 10px and nobody should browse the web on a computer with a browser window under 700 pixels and expect to see a site without horiziontal scrolling. I had this fancy formula of %font-size = (browse width) * min font size 62.5% / min width 700 and the number was close to 10% so I made it %font-size = 10% browser width and set minimum width to 600px. So the default sizes at browser width of 625px are a font size of 10px at 750px the font size is 12px, at 1000px it is 16px and at 1500px 24px.

The technical problem at the moment is for those people who have increased the size of the default font size in their browser, if your default font size is 24px, then this web page is 150% of your browser window width, at 32px it is 200%. It looks like I can resolve that with a little bit of javascript. The solution that is available, ignores user preferences, I would prefer to take user preferences into account.

Why flash for images?

With an elastic design, scaling bitmap (jpg, gif and png) images are a challenge. You need to use large jpeg images ( in both dimensions and therefore file size) to get the desired results. The results from gif and png files are ugly. You really need to be able to scale vector images, which if there was wide support for the SVG format, it would be easy. Unfortunately SVG supprt is limited, you get some support in the latest versions of FF and Safari. However, flash support is pretty universal.

The major issues with flash are:

  • the eolas patent and IE
  • what happens when visitors do not have flash or the right version of flash installed
  • flash’s bad reputation for creating large inaccessible splash pages

While I can’t resolve flash’s bad reputation, the first two are easily resolved using Geoff Stearn’s swfobject which is a little piece javascript that replaces a designated block element (preferably a div) with nominated flash object. And while you include the pixel dimensions in the information you parse to the script inside the HTML. You control the size of the flash through the CSS. If you turn off your javascript you will see the non-flash version.

Some people might argue that using javascript to insert flash into a webpage is wrong, because flash can do everything that javascript does and more people have a flash plugin than have javascript turned on. I disagree, using javascript you can easily provided allternative content for browser agents that do not have javascript or flash enabled.

The image you see at the top of this page if you have flash 8 plugin (required for the stroke on text), native size is 1120px by 140px, scales from 100px to over 4000px without any degradation and is less that 4k in size.

The only problem I am having is with flash plugin for mac, it has major problems in dealing with layering an elemnt (flash or html) on a flash element. Even when the order is determined by the source code and z-index. The mac flash plugin, ignores it and randomly determines which element should be on top. At the moment I have not fixed the footer, if you are using a mac or *nix scroll down to the bottom of the page and then scroll up and down a few times and watch the bottom menu appear and disappear at random.

Why no sIFR?

The previous design relied on sIFR for all the headings, which caused a couple of problems. Because this is a blog, there was up to 15 headings on a page to render. This takes time, often too long. Because I was using relative units of measurement, there were some despcrencies with type size and alignment. Also as my font of choice is Garamond, if you were using OS X or XP with font smoothing turned on, your are now getting the same results, without the delay and the other problems without sIFR. If you have not got font smoothing turned on in XP do it and notice the different.

tagged

6 Responses to “The fluid elastic reboot”

  1. stelt Says:

    Though SVG support is not nearly perfect out-of-the-box ubiquitously, there’s a bit more than you mention: see http://svg.startpagina.nl

    One of the most popular Mozilla extensions is FlashBlock, that renders a PLAY button instead of Flash content.

    Both formats have a range of things for which using that format is great. These ranges partly overlap.

  2. RE Mogul Says:

    If only a way to turn-on Clear-Type…
    On page load…
    Without IE…

    Outline Fonts (& SWF) render without anti-aliasing.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Perhaps an Outline Font could be embeded in a piece of XML, and loaded style-sheet-esque. Such fonts could be easily whisked-away with < 5k bandwith consumption, on the orginating page load.

    The Outline Font could also be used for the HEADER, and sub headings. I would imagine one could put all sorts of things into a font package: symbols buttons, or ANY REOCCURING ELEMENT on the page.

    The beauty: browsing devices are generally text first, and images second — which is precisely how the page would prograde.

    Script could replace Alt text with Outline Font ASCII.

    And… The Loathsome IE handles snap-in fonts NATIVELY!

    The solution would also solve the image-scaling dilema for functional elements. Most browsers already scale font respectably.

  3. RE Mogul Says:

    The SWF header is buggy in a variety of Alternative Layouts/Browsers. The images on the Elastic Images Page are not.

    The issue is the layering. Any thoughts on layering for accessibility?

    Also: why is the web so reticent about image mapping. Surely there is an efficient mapping TECHNIQUE that is accessible?

  4. RE Mogul Says:

    If the ALT Text/Metaquery is an issue one could simply snap-in an image over ALT Text. Doing such a thing for a header would require gigantic ALT Text, and a graphic defined in ems.

  5. Nick Says:

    RE Mogul a few issues here, the SWF header will work in any Windows machine with the flash plugin and javascript turned on. No flash or javascript and you get the alternative content.

    In Mac OS or other *nix devices, the problem with layering occurs because how the flash plugin interacts with the underlying system. In other words flash works with hidden hooks inside the Windows OS. Either these hidden hooks do exist in *nix systems or flash does not interact with them.

    By the Adobe definition of accessibility (late model computer with windows XP or newer and a current version of JAWS or Windows Eyes) the SWF header is accessible. It is also accessible to lower specifications by my design.

    The big difference between the SWF header and using an elastic image is size. The .swf file is only a few kilobytes, a .jpg equivalent is over 500kb. Bandwidth is still important, here in Australia there are people who have a choice of a 28kps dial up connection or paying $2.00 a Mb for faster wireless download.

    And image maps are not accessible or work in mobile devices.

  6. WEB 3.0 » Blog Archive » ¿Así que querías saber de CSS? Says:

    […] The Fuid Elastic Reboot – Nick Cowie […]

Google