This isn't helping

A few days ago, Robert Scoble asked what we think Microsoft should do in the future, both with technology and to improve their public persona. I haven’t done much for coming up with a list of what they should do, but here’s a hint to Micosoft: this is something you really shouldn’t do:

Anti-spam activists and a state attorney have argued against a proposal pushed by Microsoft that would weaken Washingtons tough law against unwanted e-mail.

In one way, Senate Bill 5734 would expand the states Commercial Electronic Mail Act by requiring that unsolicited commercial e-mail must include “ADV:” as the first four characters in the subject line, to make filtering out such messages easier.

But it would also carve out a broad exemption in the law for mail sent by companies the recipient has done business with, and completely exempt Internet service providers — including Microsoft.

Microsoft is one of the worlds largest providers of Internet service, and a company that has an existing business relationship with virtually every computer user.

“The way its written, it exempts them from the whole thing,” said Jim Kendall, president of Telebyte Northwest in Silverdale, a small Internet service provider.

(Via /.)

Creative Commons

There’s been a fair amount of discussion recently in the weblog world about the Creative Commons copyright licensing system. The CC meme spread like wildfire after it was introduced — spread, in part, by the recent Eldred vs. Ashcroft court decision that extended copyright terms. Today, Shelley wondered if she and Jonathan Delacour — who have both decided to forego the CC licence in favor of the more traditional “all rights reserved” copyright — “…can be the only two people who want to have some control over how our work is used. We can’t possibly be the only two people who believe this. Can we?”

Well, other people have already chimed in, but I can too — no, you two aren’t! I took a look at the CC licences when they first appeared, and considered adopting one of them for my weblog, but in the end, also decided not to. At the bottom of every page on this site, you’ll see the standard copyright line, and that’s how I intend to keep it.

Now, I sincerely doubt that anyone would ever go to the trouble of abusing the copyright I’ve claimed. Little of what I write here would really be publishable in any form other than that of a weblog — short comments, the occasional witty-in-my-head comment that very likely falls flat when read by anyone else, and the occasional long, rambling blather about my oh-so-(un)interesting life. However, whether or not it’s something that is of a quality to “deserve” copyright protection isn’t really the point — everything here that I’ve created, I’ve created, and I have every right to determine the ultimate fate of my creations (even if that fate is nothing more than getting lost in the great bit bucket of the Internet).

So — this space, such as it is, is mine, and copyrighted as such. Quote me if you like (preferably with a link back to me — I could use the traffic!), just respect the copyright and don’t steal from me. That’s all I ask. Simple enough, isn’t it?

Browser Daydreaming

A few days back, Phil asked what we’d like to see in a web browser. I initially responded in my usual semi-flippant fashion, but after running it through my head for a couple days, I’ve actually got some ideas.

To start with, I’ll look at web browsers as divided into two core components, as outlined by John Gruber on Daring Fireball:

It is essential to understand that there are two huge, almost completely separate tasks involved in producing a web browser. The first is the HTML rendering engine — the part of the browser that parses HTML and turns it into an on-screen graphical representation. The second is the browser application: the windows, menus, buttons, and dialog boxes.

I’ll start with the second part — the application itself. The things I’m most interested here are scattered across multiple browsers at the moment, and I do end up wishing that they were all in one package. Key things I’d like to have in my ‘ultimate browser’:

  • Safari’s clean, simple interface (without the ‘brushed metal’ look, though).
  • Safari’s speed.
  • Chimera’s tabbed browsing (unless someone can come up with something better).
  • Safari’s bookmark management.
  • Internet Explorer’s form autofill.
  • OmniWeb’s beauty.
  • The ability to tab among all page elements — links, form elements (text fields, buttons, and menus).
  • Full-featured contextual menus (Safari’s are pretty anemic at the moment).
  • And there’s probably more that I’m not coming up with at the moment.

When looking at the other side of the browser experience, I was kind of inspired by Jason Kottke’s browser integration musings and Mark Pilgrim’s wondering if Safari should be intentionally buggy (and for the record, no, I don’t believe it should, but that’s another post for another time).

Dreaming about the perfect UI for a browser is all well and good, but we’re still faced with the dilemma of which rendering engine to use. Each of the major engines out there (IE Mac, IE PC, kHTML [Safari, Konqueror], Gecko [Chimera, Mozilla, Netscape], Opera and OmniWeb] has its own collection of bugs to be worked around, causing frustration for both web designers trying to design sites that look equivalent under all browsers, and for end users who, depending on their level of expertise, may or may not understand why any given site doesn’t seem to work in whatever browser they use.

So, what I’d kind of like to see, would be a plug-in based interface for the rendering engine, easily changed via a menu choice somewhere. Find a way to wrap the latest build of any given rendering engine in a small piece of plug-in code, and drop it in an “engines” folder for the browser app. The app would come with one default engine (and as long as I’m living in a perfect fantasy world, let’s make that engine an as-yet mythical completely strict standards-based engine), but at any given point, you could go to a menu and switch to another rendering engine, which would then re-render the current page (or all pages — let’s add a preference option to select whether rendering engines would apply on a global basis or window-by-window) with whatever engine was chosen, which might be less strictly accurate, but might be more compatible with whatever mess of code the user is currently attempting to view.

I have no idea how feasible something like this might be, and I don’t think it’ll ever happen, but hey, I like the idea. Of course, in a perfect world, I’d much rather see standards-compliant websites that worked in standards-compliant, bug-free browsers, but I don’t expect that’ll be happening anytime soon. I can dream, though….

Breakin’ the law! Breakin’ the law!

Okay. More stupidity. Or maybe ‘stoopidity’.

It’s just come to my attention that in my post “Kudos to the Onion“, and in Kirsten’s comments to “Stoopid. With two ‘O’s.“, my site is in violation of The Onion’s (don’t-)link policy.

Can I use a headline to link to The Onion on my site?

The Onion does not support the use of its headlines without the express written consent of the publisher. You can put a link to The Onion on your site but may not use the headlines or content. More information on how to link to The Onion is available at our Link Page.

Oh, come on. Looks like whatever ‘powers that be’ that exist at The Onion have decided to join the many other sites with stupid anti-linking policies. That’s a shame, too.

Oh, well. I’ll keep everything linked as it is, until such time as I get a cease-and-desist letter from the Onion (not likely to happen — this isn’t exactly a highly-trafficked site — but ya never know, do ya?). If that happens…well, I’ll probaby end up taking all links to The Onion off my site. Would be a bummer, but hey (shrugs). I won’t be the first.