Jonathan Snook - pixel based layouts

Hey all, I just caught this podcast: SitePoint Podcast #125: Taming the Stylesheet with Jonathan Snook » SitePoint

One thing he mentioned is that he prefers pixel based layouts, going with “px” rather than “em” for the font size, which surprised me. His reasoning being that the people who try to resize the text only is fairly small, especially compared to the people who would use the zoom page feature that most browsers carry these days.

Myself I have found a need to make pages bigger, but I use the page zoom, not the resize text feature. I zoom the whole page.

What are your thoughts?

Another thing is by using ems, everything becomes relative. So that if I set everything in ems involving the type, and my art director says, “It looks nice but the size of the type needs to come up” I just change the value on the body selector, and everything bumps up. That way I don’t have to change a bunch of pixel sizes all throughout the stylesheet for the various adjustments. Very nice.

Given this is coming from a Yahoo employee, it’s hardly shocking. Given what a total accessibility TRAIN WRECK their site is, as Stephen Colbert once said on “The Word” – I for one am shocked, Yahoo still has customers?

The Word of course being “Google it!”

Taking web design advice (particularly when it comes to accessibility) from Yahoo is like taking financial advice from “Popular Mechanics” or technical advice from “Forbes”.

Take one look at the bloated train wreck called “YUI” for proof enough of that. Let’s take the worst of CSS frameworks and merge it with the worst from Javascript frameworks, yeah, great idea!

Though the real thing is %/EM is NOT JUST ABOUT TEXT-RESIZE IN LEGACY IE!!! – which seems to be what most people focus on, completely omitting large font/120dpi users and other non-default system metrics (like the 144dpi I’m running on my media center – aka win7 large fonts, as also used on their TABLE platform).

It’s about basing off the users default font size, which is NOT ALWAYS 16PX no matter how much certain gecko and webkit developers try to tell you otherwise. (but then there’s a reason if you need accessibility you aren’t using gecko or webkit based browsers – sad when IE is better supported)

“PX metric fonts with crappy fixed width layouts for losers” – be a good title for a book.

As a 120dpi user I expect AT LEAST the content to automatically resize +25% without my having to touch the browser’s text-resize or zoom! If a page doesn’t do that, I typically either override their half-assed design with user CSS, or I don’t visit their website.

Which is probably why the last time I visited Yahoo! for anything more than to check my throw-away black-hole mail account would have been 2002.

I love Steven Colbert. That was funny.

I know I will sound stupid, but I don’t mind. I am here to learn. You mentioned websites that automatically resize. Is that something done with Javascript?

I’ve heard of people using JQery. But if I use ems on everything, including non-text, does that have the effect you are talking about? Right now I use ems only for text. hmmmm

EM’s are best for text, PX for pixels. This is because fonts are drawn with vectors, images are drawn with pixels… Usually it’s better to have the text resize and images not, becuase the auto-resizing in browsers usually looks like something you’d scrape off your shoe.

As to javascript, it has nothing to do with it, though it CAN enhance selective width layouts (what was called mcSwitchy for a while) it’s been supplanted in that role by “media queries” and min/max-width. So for things like that, forget javascript unless you REALLY need it supported in legacy IE… at this point I’m just feeding them a crappy fixed width and letting everyone-else get fluid or semi-fluid layout… though again, that has nothing to do with font-size.

The best websites are what’s called ‘fluid’ – they adjust as needed to the screen size. “semi-fluid” means a fluid layout that adjusts between two widths, and is what for the most part I’m designing these days. Truly 100% fluid can result in lines of text ending up too long for some people to keep track of, and while I’m not afflicted by this (give it enough line-height, it’s fine), I do try to keep in mind the people who are. Typically my “screen/tv/projection” pages are fluid between 752px (min-width) and 70em (max-width), giving IE6/lower users (who know not the min-width) the 752 fixed so the layout at least works.

In any case, it comes down to adjusting to the default size the client wants for text, not what some artsy fartsy designer thinks is perfect on their perfect mix of default font size and whatever resolution they happened to choose to draw their pretty picture.

Again, the default font size in browsers is NOT always “16px” no matter how much people try to tell you it is. In Windows V or 7, go into “display” from the control panel, which is also listed under “personalization” in the “see also” part at the bottom right. It will say “make it easier to read what’s on your screen” with the choices of:

smaller - 100% (default)
medium - 125%
larger - 150%

Those first two correspond to the old Windows 3.0 through XP font settings (display properties -> settings -> advanced -> general -> dpi setting, not appearance -> font size!) of small fonts (96dpi) and large fonts (120dpi) – which of course makes win7 ‘larger’ work out to 144dpi. You can also set ANY custom dpi you want scaling it up to 200%.

Browsers SHOULD obey this – IE7 and lower use it directly on %/em rescaling nothing else, as does Opera. IE8 and newer uses this as the default zoom, though you can go in and change it back to the old behavior (which many do). Gecko and webkit browsers like a bunch of sweetly retarded crack babies go “system metric, what’s that?” and ignore it, though you CAN go in and manually change it.

This is supposed to be an OS and device specific setting, NOT a browser one – simply something browsers SHOULD pay attention to, and in this day and age is the real reason to use it – so large font users don’t have to even TOUCH “zoom” or “text-resize” in ANY application, page, etc… as it’s handled for you automatically OS wide.

Though admittedly, this is a concept that other Operating systems usually fail miserably at even TRYING to do, as applications generally aren’t written to even check for it. Just ANOTHER reason I consider anything other than Windows a tinkertoy as a desktop OS.

Pixels don’t have a fixed size - if you set your mobile phone to use 400000pixels across then the pixels will be really small, if you set your three storey projection tv to display 480 pixels across then the pixels will be huge.

Using any other measurement than pixels the text can be visible for both of those without needing a microscope for one and a telescope for the other.

Only if you’re dumb enough to try and resize them… which is from a technical standpoint…

A pixel is a pixel - a HARDWARE measurement of the smallest addressable unit - especially if you’re running at native resolution to the hardware. it is SUPPOSED to be a 1:1 hardware measurement – NOT something you’re supposed to willy-nilly resize any old way in relation to the display.

Which was why I SUPPORTED IE’s decision NOT to resize px metric fonts on older versions of IE, it was the POINT of PX that you couldn’t resize it because it probably had an interaction with another element that couldn’t be resized. That’s why I call the ‘text-resize’ that resizes ALL text (even px) the “sweetly retarded cousin to Netscape 4” behavior.

… and why I like the new zoom that Opera pioneered and everyone else has since copied (and Opera STILL does better than anyone else), as if you’re going to change one thing that’s px, you should change ALL of them!

Of course the whole topic would be a non-issue if certain designers didn’t have a raging chodo for 12px and smaller fonts.

Side note - this is something no two browser makers can agree on how to handle; So web developers? That’s gonna be even worse on the disparate opinions.

So basically, where mobile is concerned, the pixels will be very small, but to compensate, their browser default will be set to a readable size. Basing the font size on ems will work off an already readable size. Is that what you are getting at?

That’s it. Basing off the user’s choice for default size means they shouldn’t have to dive for zoom or text-resize in the first place – it’s the entire reason to use %/em, and why old-school many developers chose PT.

See, PT was the only font that obeyed the system metric in Nyetscape, while %/em did not. FF inherited that behavior since it literally is just Netscape 4’s sweetly retarded cousin. If NS4 were Gomer Pyle, Firefox would be Goober.

See my old page about how the different font sizes are handled by different browsers:
Effect of Font Metrics on Common Sizes

In particular how badly FF 3.5.1 screwed it up – there have been zero changes since that time to FF, and chrome/safari behave in much the same manner. Notice how PT on large fonts enlarges when %/EM does not.

No - they generally choose PX and not PT. PT is a fixed size or nearly so since there are exacty 72PT in an inch when dealing with PT on a computer and 72.1PT to an inch when dealing with PT in the printing industry. PX is fully dependent on the screen resolution that is set and the size of the screen it is set on and so can be any size at all. It just happened that the typical screen sizes and resolutions set at the time Netscape 4 was popular meant that it worked out to 72PX to an inch on most screens at that time. Now of course you can get anywhere between 72IN to 1PX or 7200PX to 1IN fepending on the screen size and resolution but 72PT is still 1IN regardless of how big a PX is.

Tell that to EVERY forum skin other than phpBB prior to five or six years ago, when all the “PT are Evil” idiocy came crawling out of the woodwork en-masse.

SMF, YABB, vBull, UBB, Invasion, Proboards – All used PT as the size of choice back when IE6 was “all that mattered” and many people were still using Nyetscape 4. It was THE size of choice when CSS was “new”. Part of what made phpBB an annoying pile of crap was it’s use of “px on everything” alienating many users… (well that and the fact you used to have to mod the hell out of it for the most basic of functionality – neutering the upgrade path)

In a lot of ways those old sites were more accessible when it came to font sizes than the stuff people vomit up today using PX.

Ignoring the technical differences between PT and PX (I don’t know why that’s even relevant or a point of debate, it’s just a fact on how things work…)…

The reason why px can be better is because it accurately lets you measure the size of the text relative to other pixel based elements on the page such as images and backgrounds.

Now, in an ideal world, we’d be able to use vector images and fluid width/height boxes for everything but even in this case, the layout has to touch the ground at some point and we’re still restrained by the user’s screen resolution… in pixels.

From a design (not usability) point of view, PT is potentially problematic because it is dependant on DPI so the designer cannot accurately size text, which when you have a box that you want to keep a certain height can break.

PX is better from a design point of view, PT is better for usability. However, the number of people negatively affected by using PX is probably fewer than those using IE6. Very few people know how to change DPI let alone actually run a non-default.

In short: It’s a tradeoff but I’d rather have the design look right and let people who need it use the zoom feature than potentially have a broken layout because the bigger text caused all my boxes to become too tall.

Or %/em – don’t forget those which are what you’re SUPPOSED to be using.

Which is why I’ll even still use it in the handful of places it’s necessary for those reasons – small elements like menu buttons, behind image replacements, or on non-content elements like the footer in a min-height layout (and the last of those is JUST because firefox is a retard about calculating %/em the same way twice in a row!), and then I keep in mind that 12px is the smallest practical size, and anything below 14px is just going to piss off lf/120dpi users.

Which CSS3 with background-size, border-image and all the other goodies is FINALLY starting to address.

Which you cannot predict with and height of which is WHY you’re supposed to be using dynamic widths, dynamic heights, and layouts that can adjust to any of those – hence why we’re starting to use these things called media queries…

or %/em

Which is why on CONTENT sections anything you try to fix the height of is a miserable steaming /FAIL/ at web design – ESPECIALLY fixed height background images. If you cannot make your content sections – the stuff people actually visted your page for – automatically adjust their height to fit because of some artsy crap drawn in photoshop you’re trying to slap behind it, it’s time to review the basics of how to make a website or kick whoever is drawing said pretty pictures right square in the junk!

Because again, people do not visit websites for the goof-assed graphics you hang around your content – they visit it FOR the content… which is why MOST of the time over-the-top graphical layouts are nothing more than a can of shellac on a pile.

Just a random thought: Wouldn’t the logical extreme of suggesting the use of px be to use one giant image map for the entire webpage?

Yes, which proves EXACTLY how idiotic the entire concept is for web development.

But then given the schlock people vomit up via “slicing” using automated tools, many of your “but I can do it in photoshop” shmucks are basically doing that in the first place – as evidenced by whenever you go to websites designed by such nimrods and shock turn images or CSS off… and find there’s ZERO content or large sections of content just vanish.

You would of course make it 150px by 150px in size as that’s the maximum size that you can reasonably assume that everyone will have available to display it in - since the minimum browser viewport size is the only thing where browsers themselves have limits defined in terms of pixels.

As someone who is trained in graphic design for web and print, not necessarily web dev, which I came into later, here are my thoughts. Em actually has a really nice benefit for designers over PX. In print design, we use points, where .5 points makes perfect sense. So we can have 12.2 pt, for example. That amount of fine control is not only nice but sometimes critical.

But in web design, 12.5 PX makes no sense, because what is .5 px? That means web designers who use it are stuck with whole “point” sizes and you lose the control you have with a print publishing tool like InDesign. Half a pixel doesn’t exist in any practical way, since PX is the smallest unit as Deathshadow points out. BUT, with ems, you can achieve that fine control, because while half of a pixel makes no sense, half of an “m” makes perfect sense.

So while I have been converting my company’s website to tableless CSS, I have been able to use ems to get finer control over the size. In my design 12px looked way too small, and 13 looked way to big. But with ems I have been able to get that in-between I needed to make it perfect for readability but not garishly big.

Browsers are different in how they render, but on mobile devices I have noticed a BIG difference.

I always size fonts relative to the user settings, that being 1em. All continuous text is always 1em. In cases where I would like to create less or more emphasis using size I generally go slightly up or down from 1em – for headlines and such. Thinking about things in terms of pixels is not a good approach. Think in terms of contrast relative to the machine/browser/setting default.