Web-Standards Markup Certainly Won’t Give You Cross-Browser Sites at higher resolution…

How I want my site to look: Web-Standards HTML 4.01 and CSS3 in Internet Explorer 8. Click on any of the screenshots in this post for a larger view. They’re saved as JPEGs.

I hope readers of this blog who struggled all the way through the long post on screen resolution now understand why I’m so keen on being able to create paginated, multi-column content on the Web which people can read with as few distractions as possible.

If you read all of that post, you did a lot of scrolling in order to read the single-column layout. I hope – like me – you grew to resent all of the unused screen real estate either side of that single column.

Single-column layout can get tiring, and make the reader want to go elsewhere. But the Web shouldn’t be a place only for those with Attention Deficit. It should be a place where people can publish any kind of content, and where people who want to spend time reading that content should be able to do so as comfortably as possible.

If you prefer to bounce around the Web like a gadfly, spending a little time at each of a large number of different sites, that’s fine. But the Web shouldn’t force you to behave that way. It ought to be possible to take the time to absorb information, too – and feel comfortable while doing so.

I’ve been doing another set of experiments on my website, and produced a set of screenshots to illustrate what I’m trying to do, and some of the problems I’ve hit. Some of those problems arise because I’m trying to live in a “high-resolution world”, and doing both my website authoring and viewing on my new MacBook Pro laptop at 133ppi (pixels per inch).

The more I use this machine, the more I realize the future I want could be a lot closer than I thought. Let me explain…

The resolution of human vision is about 600 dpi (dots per inch). So theoretically we need 600ppi screens to make what we see on a computer as “real” as the natural world.

The problem is that to go from the ~100ppi of the average computer screen of today to 600ppi means computing 36 times as many pixels per second (n-squared, because you increase the resolution in both directions) That’s a huge mountain to climb for graphics cards, the batteries which run them – and the heat they generate.

That’s not necessary. The glossy magazines you buy are normally printed at no more than 185 lines per inch. And with ClearType – which is a resolution multiplier for text, since it has 3x the number of sub-pixels with which to work – you have gone past the equivalent of 185ppi on this 133ppi display.

It’s more than that, though. Not all high-resolution displays are created equal. I had a 133ppi Dell laptop about 12 years ago, and a 147ppi Dell laptop ten years ago. But I have to say, their displays were not in the same class as this 133ppi display from Apple. It’s stunningly bright and crisp. It seems a lot brighter running Vista than MacOSX – which probably means I’d be voraciously devouring battery charge when running without mains power. But I don’t really do that very often. And I like the brightness. Makes OSX look positively dingy…

It’s not only ClearType that looks good. I went on to Adobe’s site to try out their new DF4 rendering, and found it very crisp and readable on this screen.

It might be that 133ppi on screens of this quality is quite enough resolution – at least until there’s some kind of graphics technology breakthrough.

When it comes to Web authoring and surfing, email, FaceBook, LinkedIn, news sites etc., I still prefer the Windows versions of all the browsers.

Now I’m no longer at Microsoft, I’ve been deliberately using FireFox as my default browser to make sure there’s no lingering “you always prefer what you’re used to” bias. I also have the latest versions or betas of Chrome and Safari, and of course the shipping version of Internet Explorer 8.

I’m using only Web-standards markup. Everything gets checked using the W3C’s HTML and CSS validation tools.

Since this Mac screen is so bright, I found the white backgrounds I’d been using previously on my site to be punching out too much light, even with multicolumn text layout. So I switched to white text on a black background – same as on this blog. However, even the white text on that seemed too bright. So I ended up with light gray on black. It reads very well on this display, and feels very restful for the eyes. I’d love to get your feedback on how it looks on your screen. Here’s the link to the test page…

I included the Internet Explorer 8 screen shot at the beginning of this post because that’s exactly how I wanted my site to look. Authoring in Notepad++ gave me results in Internet Explorer which were entirely predictable. Unfortunately, the same was not true in any of the other browsers, even with absolutely Web-standards markup.

I’m not certain whether the problem is the way different browsers deal with the markup – it really shouldn’t be – or whether it relates to the high-resolution display and the way they cope with that.

In IE8, I found the 12pt text I’d been using on my site was too small at this resolution. I took it up to 17point, and changed all other text sizes to fit. I was really pleased with how the final page turned out.

Then I fired up the other browsers to check it.


Firefox – not too dreadful, but a few glitches…

  1. Badly positioned paragraph
  2. Navigation buttons have floated to wrong position
  3. Photo not scaled up to fit column
  4. One-line caption becomes two lines, changing column line-break
  5. This is an issue I’ve seen in Firefox for ages, and one they should fix. When you go FullScreen (F11, or Fn-F11 on the Mac) it forgets to repaint the new area of the screen created at the bottom, leaving garbage or old lines of text from the previous rendering.

Google Chrome on Windows Vista

Quite a mess! Lot of content you have scroll to see, since it no longer fits on a single “page”.

  1. Headings become too big. Masthead sticks out too far; “SECRET BLOGOZINE” heading becomes two lines, busting the layout
  2. Paragraph sets too big, overflowing space provided
  3. Picture is scaled up too big, sticking out into column 2
  4. Pull quote takes up too many lines; so does all the body text, forcing scrolling to read all content.
  5. No Full Screen switch. I thought the latest beta had one – but it seems to have disappeared. So you end up having to scroll.

Safari4 on Windows Vista

Where did the graphics go? (picture and navigation buttons have all disappeared) Again, you have to scroll to see all the content. Many issues seem similar to Chrome – probably because both use Webkit.

  1. No Full Screen mode
  2. Headings break
  3. Text overflows
  4. Picture didn’t show up at all
  5. Navigation buttons got lost
  6. One-line caption becomes two lines
  7. Pull quote takes up too many lines
I have a feeling that the problems with Chrome and Safari are more to do with not handling higher resolutions very well. The issues look very like those I used to hit all the time when switching to higher-resolution devices. I tried using their Zoom capabilities, but that didn’t solve the problems either.

Now I’m still quite the newbie here. I’m sure many of you old and grizzled Web designers are shaking your heads, and saying, “Well, he should (or shouldn’t) have done X or Y, and that wouldn’t have happened”.

But why should anyone wanting to create Web content have to learn the secret handshakes? Shouldn’t Web authoring be easy and open to everyone? Shouldn’t it be democratic – and not controlled by some “priesthood” who understand the “Latin”?

Shouldn’t Web-standards markup be the lingua franca? So that if you can speak it, you can talk to anyone, anywhere?

I know I’m still using pixel dimensions on my site. And that means I’m not yet resolution-independent. But shouldn’t Web-standards markup at least mean all the browsers handle the same content the same way?

Unless we can get to that point, I don’t see a lot of hope for Web standards. If I wanted to create cross-browser, multi-column, paginated content today, I’d be forced to use Adobe’s proprietary FLEX and AIR formats and their browser plugins.


9 thoughts on “Web-Standards Markup Certainly Won’t Give You Cross-Browser Sites at higher resolution…

  1. Richard Fink

    Bill, you remind me of the character of Lorenzo’s father in the movie Lorenzo’s Oil – brilliantly played by Nick Nolte – who keeps saying “I’m just a simple man asking simple questions.”Of course, the father’s claim to being “simple” was a rhetorical ploy – he was far from simple – but asking simple questions, well, as any trial lawyer will tell you, asking a series of simple questions is a great way to get to the heart of a matter. (And it sounds here like the jury is ready to convict!)Watching you climb the learning curve of web page creation – which you’ve done publicly in your blogs – has been a kind of case study in the barriers facing anybody trying to publish good-looking content on the web.Of course, now you can see why there is a great, great reliance on templates in the world of web design. Trying to get a consistent cross-browser result, even between the latest, supposedly standards-compliant browsers can drive anyone nuts.However, the good news is that cross-browser standardization is not quite as bad as your test pages are leading you to believe. Tackling your test pages point by point would take too much space, (we can go off-blog for that) but the main culprit is the multi-column script. I believe it is creating an illusion of sorts. In order to create the columns, the script re-writes the styling of the HTML of the page on the fly. Now, in a situation like that, you are completely at the mercy of the script. If the script isn’t sniffing out and compensating for the differences between browsers in just the right way, you’re screwed. Plus, I think that particular script has not been revised or updated for some years. (Could be wrong, didn’t check.) This is the reason why well-tested cross-browser script libraries like jQuery are so popular, and necessary. Also, there may be some interactions between the changes to the page the hyphenator script is making and the changes the columnator script is making that also might account for the discrepancies.But anyway you slice it, yes, it’s too hard for the “uninitiated” to get a good result. Way too hard.

  2. Bill Hill

    Yes, I know that particular multi-column script has issues. For a start, since it uses the Document Object Model, it doesn’t have enough granularity to do intelligent line-breaking when a paragraph spans two columns.It’s really a stopgap measure until the browsers themselves support multicolumn natively.The hyphenation script was also a stopgap for the same reasons.As you rightly point out, I elected to take my pain in public. But I’m also trying to point to a future I think the Web needs.I’m a long way from being a computer newbie, or a publishing newbie, or a typography and layout newbie.It shouldn’t be this painful.

  3. Richard Fink

    “I’m a long way from being a computer newbie, or a publishing newbie, or a typography and layout newbie.”Exactly. It should be a piece of cake for someone with your extensive background and problem-solving skills.Imagine the barriers to the average computer user.The question is, what can be done?

  4. bowerbird

    well, this is a switch.most web-designers createsites while looking at themin the other browsers, andthen complain loudly wheninternet explorer mangles ’em.you’ve created a site in i.e.that then gets mangled inall of the other browsers…you consistently say thatother browsers render thetext “too large”. is thereany justification for callingany specific size “correct”?i’d also be interested inhow you conceive thatthis page “should” lookwhen it is rendered ina window half the size.and in 1/3 of the size.and at 75% of the size.-bowerbird

  5. Bill Hill

    @bowerbirdWell, yes. If I choose 17point text in my markup, I’d like it to look like 17point, or thereabouts – not 27point (unzoomed).I appreciate that exact 17point likely isn’t going to happen – but close enough is close enough.

  6. Bill Hill

    @bowerbird, about what happens at different sizes…Don’t hold me to this because I haven’t done the actual measurements, but roughly I’d expect that with a half-size window, the layout would change to two-column. One-third size window, single column layout. Two-thirds size window, two wider columns.Of course, none of this will work without reflow and repagination.The New York Times reader did all of that, and I have seen the same thing working perfectly well using HTML and AJAX.It is NOT dependent on future developments in software; it can be done now, although some fairly minor plumbing would probably help.And no, I don’t think it’s a good idea to be dependent on future hardware or software developments.However, I saw a post the other day by someone longing for the day they’d have a 600ppi display,, when I think that what we can do today – 133ppi and 147ppi – done well, enough, is all we need.I spent years beating on Windows about this, and they have been listening.This blog’s now being visited from at least 30 countries, including South Korea and Japan. Maybe I can have some influence. Especially now I have more freedom.

  7. bowerbird

    > I'd expect that > with a half-size window, > the layout would > change to two-column. > One-third size window, > single column layout. > Two-thirds size window, > two wider columns.sorry, what i meant was toask you how the text wouldlay itself out in those cases.can you give us screenshots?for instance, at the top,the "digital declaration"spans two columns, sohow would that changein case of window resize?screenshots would help meto visualize the text-flow…-bowerbird


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s