From Blork, a great follow-up to my complaints about Snap.com the other day: How To Disable Snap Shots on Blogs. Step-by-step instructions about how to spare your readers from this annoying “feature”.
An open message
Dear users of Snap.com,
Please stop!
It is annoying, provides me (your reader) with no benefit, and in fact makes it radically less likely that I will read your post – the stupid pop-up windows obscure your text and make it difficult to read the pearls of wisdom you are trying to communicate.
Best,
Michael
Unreadable URLs are bad
Scott Rosenberg takes up the case in his post, Terror of tinyurl.
From the earliest days of the Web to the present, there’s been a fundamental split between people who get the value of “human-readable URLs” and people who don’t.[…]
Today, though, we’re taking a step backwards, or at least sideways, in the cause of human readability, thanks to the growing popularity of the “tinyurl.”
I have had this discussion (arguing for human-readable URLs) with well-intentioned but clueless developers so many times it borders on the absurd. In fact, Nadia and I were just discussing it last night! Like Rosenberg, I understand why it’s important in the twitterverse, but outside of that relatively limited context, tinyurl is a user-hostile pain in the backside.
Many people
have weighed in on the question of CSS now that the issue has become a “live” one in the weblog world. A representative opinion on one “side” of the thing (if sides here makes sense, which I don’t actually think it does) is that of Matt Bridges in CounterProductive. He wrote, “When a designer uses CSS to mimic what can be done with tables, separating content into different boxes that are placed at specific parts of the screen, they tie that content to that layout. This completely defeats the purpose of separation of style from content.”
It’s a perfectly reasonable statement, and having worked on some CSS layouts I do see the drawbacks alongside the advantages. The problem is, however, that most people seem to have the foundational principles wrong. And their error leads in ugly directions.
CSS is about style. But there’s something much more important than that. Implementing CSS also returns structure to HTML. And that is where the value is – it’s not about separating content from style – that’s what a CMS is for. Rather, it’s to return the third variable – structure – to its rightful place in the mix. So that not only do you have the flexibility to do anything you want with the content (in the CMS), and to redesign that site as you like, but there’s also a fully degradeable version at the heart of the human-readable, “published” version that any device can read, as long as it can interpret HTML in some rudimentary way.
So with a fresh approach
I managed to get the new mikel dot org design working, more or less. But really more or less. It appears perfectly in both IE5/Mac and IE 5.5 Win. It appears OK in Netscape 6.2. The whole thing is very weird though. It started working when I commented out all the margin variables and nested the bottom two divs inside the div containing the top content (the title graphic etc.). Then I used top and left positioning to put up the main text div. Fair enough. The positioning worked OK at the top and left.
Now the funny part. I didn’t want to specify a width for the main text div, as I want the site to be perfectly fluid. When I set a right position it worked perfectly in IE 5.5/Win. It didn’t work at all in IE5/Mac. So just for kicks I put in a “margin-right” as well. Suddenly it worked perfectly in IE on both platforms (which I don’t think it should do). Only Netscape does things as I would expect, which is to start the margin x pixels over from where the right edge is supposed to be (from where “right: #px” tells it to start counting).
Anyhow, it validates as valid CSS now, and the content is very readable on the platforms that I’ve tested it on, so I’m going to implement it in the next few days. If anyone can set me straight on my CSS foibles, however, I would really appreciate it.
