Tag: html

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

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 recently stumbled across an old copy of the Demoroniser (which my American-trained sense of spelling keeps trying to spell as demoronizer), a script designed to correct some of the, well, moronic HTML generated by Microsoft Office. Aside from flat-out coding errors, Office would use non-standard characters for things such as curly quotes or em-dashes that would only show up on Windows computers. If you viewed these sites on a Mac, a Linux box, a Palm, etc., they would seem to be missing punctuation everywhere. His solution was to convert these to their plain-ASCII equivalents.

Over the last year or so, WordPress and A List Apart have converted me from “stick with the lowest common denominator” to “let’s show real typography.” Since the days of the Demoroniser, Unicode has become a standard part of HTML, so modern browsers* can either display a full range of characters or convert them to something they can display. You probably won’t be able to see Chinese text in Lynx, but a properly encoded curly quote—“ or ”—will show up as a plain old ".

For one thing, real typography looks much nicer. Continue reading →

Posted on
by

Last week I started looking at ways to cut down on false positives in our spam filters. I’ve only seen two in my own mailbox this year, but of course everyone gets different kinds of email. I’ve been trolling the server logs for low-scoring “spam,” looking for anything that looks like it might be legit, particularly if the Bayes subsystem has already identified it correctly but isn’t enough to counteract the score assigned by other rules. (Unfortunately, it’s hard to tell when all you’ve got is the sender, subject, and list of spam rules.)

One item I noticed was a copy of the Microsoft Technet Flash newsletter. I thought this was odd, since I’d gotten a copy of the same newsletter and it hadn’t been labeled. In fact, it turned out that my copy only scored 0.3 points, and the other hit 6.4! (5 points indicates probable spam.) What could explain such a disparity?

Answer: two very small differences. Continue reading →