article

|

So a Windows version of Safari is finally here. Hurrah, another browser to support. Cynicism aside, is it any good?

Now, bearing in mind this is a beta version, there are a few issues I have. These are only my personal annoyances, based on first impressions, and in no way a comprehansive list of bugs.

It’s Fugly.

Fugly in the sense of it dowsn’t fit in with the surrounding OS one little bit. Not even an iota. I give Apple credit for porting the thing in the first place, and I know there’s a kind of UI “branding” to stick to, but the window border looks awful.

Another issue is the font rendering. I have Windows ClearType turned on for font smoothing. Safari has its own font smoothing (which can’t be turned off – another annoyance). The combination of two font smoothing algorythmns makes text look almost bold. It needs sorted ASAP.

There’s the Aqua-style widgets as well, but there a minor annoyance.

It’s Inconsistent

I can middle-click on a link in a web page, and it opens in a new tab. If I middle-click on a bookmark, it does nothing. That irritates me no end. Off the top of my head, some dialogs open in OSX-style “slide-down” windows, others don’t. Maybe this is a OS limitation? Or am I imagining it?

No dotMac Sync

I know, I know… dotMac sucks. But it has one very useful feature which I use extensively – bookmark syncing. I had hoped the Windows version of Safari would include this, but alas, it’s not there. Maybe they’ll add it in before the final version? If not, I don’t know if Safari will be able to compete against Firefox + Google Browser Sync as my first-choice of browser. I’m giving it the benefit of the doubt for the moment, simply for the speed boost over Firefox, but speed alone won’t keep it in front.

So all round, Safari on Windows is a bit meh, hovering precariously close to pure dissapointment. For now, I’m willing to the give Apple the benefit for the doubt – it is a beta version, after all.

As one final note, how to do you bring up the web inspector panel I’ve heard so much about? Email chris@ this site with the answer, please!

Article

|

I know, I know, in theory we should be developing sites that work in every browser and not just targeting specific applications. However, the reality isn’t quite there yet. Support for the different web standards varies massively from vendor to vendor.

Usually we make the decision on how much effort we put into making a site work in a particular browser down to the visitor statistics of that site. If your site only receives a handful of visits from a certain browser, why spend hours – or even days – trying to work around its faults?

So my question is this: just how low should the numbers be before a particular browser gets ‘cut off’? Take, for example, the top 5 browsers in Pixel Meadow’s Mint logs:

  1. Firefox (54%)
  2. Safari (31%)
  3. Internet Explorer (8%)
  4. NetNewsWire, Camino & Opera (2%)
  5. Shrook (1%)

From those numbers it’s clear that I need to support Firefox and Safari (which by extension means support for NetNewsWire and Camino), but what of IE, Opera and Shrook? Do I go out of my way to make sure any future revisions of Pixel Meadow work fully in these browsers, or do I just make sure they’ll degrade gracefully if need be?

Of course, this is assuming an existing site… It stands to reason that a new site with no clear visitor demographics should target as wide as possible until their visitor statistics are known.

note

|

Elastic layouts have been getting a bit of talk over the last few months. John, Roger and Patrick have all talked about them. I use an elastic layout in the new design.

What is an Elastic Layout?

Traditionally, web designers talk about either “fluid” or “fixed” layouts. Fluid layouts change width with the size of the browser window, while fixed layouts are set to a specific width. There are arguments for and against each type. Where elastic layouts fit in, is to try and combine the best of both worlds.

The Theory.

Text sized in em units is scalable in browsers (theoretically). So what if we were to specify the widths of our page elements in ems? Our page elements should scale inline with the size of our text.

The Reality.

Using em units to size page elements does work pretty much as expected. However, there are a few things we need to do to avoid some problems.

Global Reset for Less Hair-Pulling

If you let the browser apply its default font-size, margin, padding and line-height, you’ll be in for a very rough ride. Make things easy – apply the global reset:

*{ font-size: 100%; line-height: 1; margin: 0; padding: 0;} /* Global Reset */

This resizes the text on everything to 100% of the default size (16px by default), sets the height of a line to the size of the text, and removes any default margins or padding. By doing this, we remove a lot of the guess work. I use a percentage value because I’ve found that this makes scaling text a little less error prone in browsers. 1em is now equal to 100% or 16px.

Browsers are Crap at Maths.

All the major browsers suffer from rounding errors to some degree. I must admit that it’s been a while since I checked on this, but both Opera and Safari used to render text sized in ems and percentages wrong – 10px would render as 9px, for example. To get around this, the fix was to size text slightly larger than 100% on the top level element. 100.01% was found to be the magic number. So our global reset becomes:

*{ font-size: 100.01%; line-height: 1; margin: 0; padding: 0;} /* Global Reset */

Make the Maths Easier.

I was never very good at maths (much like the browsers), so working things out in multiples/fractions of 16px wasn’t appealing. It’s also harder to visualise how big 16px is, compared to, say, 10px. So to make things easier to work out and visualise, we reduce our base font size down to 10px (using percentages, this is 62.5%). We can apply this to the html element and it will inherit down the line:

html{ font-size: 62.5%; } /*Resize text to 10px */

1em is now equal to 10px. Much better!

Make Everything an EM.

Well, almost. I’ve found that some browsers (the Gecko ones, mostly), will not render a 0.1em thick border, when 1em = 10px. Any border you want to be equivalent to 1px by default, just make it 1px – it might not scale but it will render. Other than this small caveat, the rest should be sized in em units: margins, paddings, widths, font-sizes… Doing so will make everything proportional to the text size, stopping things looking crowded at larger sizes.

Remember – EM Sizes Compound!

By that, I mean that if you apply a font size of 1.2em to the body tag in our example, then for all elements contained in the body, 1em now equals 12px. So a 3em h1 would be 36px high, not 30px like you might have expected. It’s something you need to be on the lookout for.

A Note About Background Images

Elastic design is geared towards using repeating background images. Unless it’s something like the “Latest Little Thing” icon on the homepage, using non-repeating images will land you with holes in your design where the container is wider than the image. A great example of using repeating background images in elastic layouts is the Elastic Lawn CSS Zen Garden entry.

Give it a Try

With all this talk about maths, compounds, et al, I’ve probably put you off elastic layouts. Don’t be afraid to try them. Once you get in the swing of things, it soon becomes second nature. Practice does make perfect, so all I can say is have a go!