Tag: css

Posted on
by

I’ve been meaning to write a post about email newsletters that still assume you’re reading on a desktop and send out layouts that rely on a wide screen size and end up with tiny 2-point type on a mobile phone — you know, where most people read their email these days.

Then I stumbled on this usability article by Jakob Nielsen.

From 2012.

It pretty much covers what I would have said, and more. But a decade on, I still get email I can’t read without moving to a bigger screen.

The Time Before Tables

The funny thing is that HTML, by design, already adjusts to different sized displays, windows and terminals. In the very early days, you couldn’t make it not be responsive unless you added a block of pre-formatted text.

Once HTML picked up a little more rendering capability (tables, images and image maps), you had people designing websites who were accustomed to fixed-size media, and the paradigm stuck.

— Build your layout in Photoshop at 800×600, then slice it up into clickable pieces and reassemble the whole thing on a page!
— Wait, now we can aim for 1024×168!
— Oh, hey, we have widescreen now!
— Huh? What do you mean the window isn’t always fullscreen?
— Phones now? Ugh, I’ve gotta make a totally different website!

And so on.

Responsive Styling

These days you can apply relative sizes to everything, and tweak the layout based on the logical screen size instead of physical pixels. (Shout-out to high-definition displays here!) Modern HTML+CSS is amazingly improved in flexibility, and if you plan it right, you can often just rearrange the same page for screens from small cell phone size up to those widescreen monitors. Obviously this depends on what kind of site or application you’re building.

But for email, especially for newsletters, where reading the text is the main point, it should be an obvious choice!

Expanded from this thread on Wandering.shop.

Posted on
by

I recently tried to retrofit a mobile layout onto an old table-based site using CSS. It was a fairly simple layout: A banner across the top, two columns, and a footer. I figured I’d use CSS to “unwrap” the table and make the sidebar and main content area into full-width sections instead of side-by-side columns.

In theory this should be simple: CSS handles tables by using the display property and assigning it table, table-row and table-cell for the <table>, <tr> and <td> elements. You can assign these properties to other elements and make them act as tables, or you can assign block or inline to these elements and make the table act like a series of paragraphs.

Initial testing worked perfectly in Firefox 3.6 and Opera 10.5x. Internet Explorer 8, as expected, ignored the changes entirely. Chrome, however, did something very strange, and Safari reacted the same way: The banner shrank, and the columns changed from a narrow sidebar to a 50/50 split…making it actually worse for small screens.

Clearly WebKit didn’t like something I was doing. Unfortunately, WebKit powers the exact platforms I was targeting: the iPhone and Android!

I dug around with the developer tools a bit to see if I could figure out what was going on. Was the browser not applying the property? Were the table cells inheriting the “original” property from somewhere else? Did I need to change properties on thead and tbody as well?

What I found was that WebKit did recognize the display:block I had added, but somehow the computed style was reverting to display:table-cell. This only applied to table and td, though. Table rows actually did what I told them to, which was why the result ended up looking bizarre.

If it hadn’t changed anything, I probably would have chalked it up to the capability just not being implemented yet. But since it worked on table rows, but not on cells, I decided to treat it as a bug in WebKit and went looking for the best way to report it. I ended up creating a WebKit Bugzilla account and reporting it as bug 38527.

Check out the testcase in Firefox 3.6 or Opera 10.5 to see what it should look like, then take a look in Chrome 4 or 5 or Safari 4.

Posted on
by

Microsoft is really pushing for people to make sure their websites and apps are compatible with IE7. Apparently this is a real concern for a lot of people who relied on certain proprietary features, bugs, and quirks in IE6. I guess they figured they wouldn’t have to worry about future versions. (Hmm… I wonder where they got that idea?)

The fact of the matter is, I’m not worried. I tested my personal sites and the sites I’d built for work months ago, using the IE7 betas, and more recently with RC1. I made a couple of minor changes to some stylesheets, but that was about it.

Why? I’ve been writing standards-based code for years. I validate it from time to time, and I test to make sure it works in the latest versions of Firefox, Opera and Safari as well as IE. So the code was already portable.

Plus, anything new I’ve built since January has been designed with IE7 in mind from the beginning.

Most of the changes were to workarounds for IE6. Either stopping them from running on IE7 (if the bug was fixed), or keeping them running on IE7 (if it was done using a CSS hack).

Posted on
by

I installed the just-released Netscape 8 Beta. It imported most of my settings from Firefox, including bookmarks, cookies and even history. One of the first things I always check with a new browser is how it identifies itself, which in this case is as Firefox 0.9.6. (Presumably they’ll get on this by the time the final version is out.)

First impressions: importing was clean and worked well. UI is a bit freaky, as things are spread all over the place—like the main menu, which is in the upper right and in line with the title bar instead of where the menus are on every other Windows application. The multiple toolbars seem confusing at first (it took a while to dig up my bookmark bar, for instance). Then I looked at the site trust/rendering choices, the big exciting feature of this release. And I’m not impressed. Or rather I am, but not favorably.

The current tab shows a shield icon indicating the trust level of the site: Green if it’s been verified by a “Netscape Security Partner,” yellow if not, and I would presume red if it’s a known phishing/virus/etc. site. There’s also an icon indicating the trust level: a check mark if it’s trusted, an ellipsis for “not sure” and an exclamation point for not trusted. Unverified sites are, by default, in the “not sure” category. So far this makes sense.

Clicking on the shield icon opens a site controls dialog box enabling you to choose to what extent you trust the website, and below that, whether to display the site using the Mozilla Netscape or Internet Explorer engine: Continue reading →