We used to have an article here about styling textareas with CSS in IE. It was one more post on the web about one more bug in Internet Explorer 6. It has been fixed in between.

In case you still need this, we had a workaround which consisted of applying width:100% on a div around the form, like this:

<div style="width:100%">
    <label for="t1">Try to type in here:</label>
    <textarea id="t1" style="width:100%">Try to type here!</textarea>

Web application caching

Blogs, as most current web applications, need to address the server-side caching issue in order to reduce webserver load.

It looks like most people are quite happy with caching static versions of their pages for some defined amount of time. This method has often been called something like "half-baked/half-fried" in reference to the long running baked (static) versus fried (dynamic) discussion.

I'd actually call it "baked on demand"... but regardless of what name we use, I would not be satisfied with this.

I have actually done some experiments caching my blog homepages which is enough to significantly reduce load, but this really makes them too static for me. I do want to log some stuff in realtime, I do want new user comments to show up instantly, and most of all: I do want the page to be customized for each user: display new posts since last visit, display his personal choice of categories, etc... Caching a whole page for every possible combination seems plain stupid. (And it is! :>> )

Actually, the only smart caching mechanism one can be satisfied with in high-end web-applications is block-caching. As a matter of fact, a web page can actually almost always be considered as an assembly of different blocks. Some are static, some are dynamically updated several times a day, some are related to the user himself and some are so dynamic they change everytime the page is displayed, no matter what! By caching each of these blocks individually when it makes sense and rebuilding only those necessary at a given time, you can then reconstruct your whole page dynamically significantly faster than if you had to reconstruct all blocks from scratch every time.

And there you have it: performance and functionality. Yeah, Okay, I know... it's also much more complex to implement than any other caching mechanism... ;D

Unsubscribring from spam *STILL NOT* ;)

Following up on wether or not to unsubscribe from spam, Cédric [site gone] adds some clarifications:

I am talking about the particular case of a spam email that defeated my filters and ended up in my Inbox. This is the one I want to get rid of. I don't care if more spammers end up getting my email address this way because their spams will most likely join all the others in my Spam folder (I suspect the success rate of my various filters is about 99% these days).

Very interesting point! Unsubscribing from those particular spams that pass the filters makes total sense and may succeed in getting less visible spam... but still, I'm not sure: what if they resell your qualified address to 50 spammers and 10% of them use clever spam filter defeating techniques? You run the risk of replacing one known spammer by 5 new spammers.

But I must admit: I'm far from conviced myself that 10% can really make it through the filters! :.

What puzzles me more is this:

[...] we are fighting a different war on spam these days. The goal is no longer to eradicate spam (this will never happen) but simply to acknowledge that spam is a reality and therefore, do your best so that its nuisance is limited to a minimum. In other words: design excellent spam filters.

=> I think that filtering is only the worst solution we have found so far: all the extra spam we allow to generate but don't see in our inboxes still harms network and mailserver fluidity... sometimes a lot! So replacing 1 unfiltered spam with 50 filtered ones just doesn't feel right to me...

...and I'm so glad I'm not administering mail servers any more :>>

Actually, we're all bearing the costs generated by all that spam on our networks! So we really may want to think twice before we promote any behaviour potentially allowing for (even slow) exponential growth! |-|

Introducing evoSkins

b2evolution 0.8 will come with blog skins (evoSkins).

What are blog skins?

Well basically if you've used any skin-enabled software (like WinAMP) you probably have an idea. ;)

Bloggers using b2evo will be able to select a complete look & feel for their blog by just clicking on the "skin" they like the most.

b2evo will come with a few selected blog skins from cool people who already allowed their design to be included in the release package. B) Hopefully, new skins will be made available in the community so bloggers not knowing or willing to design their own will have a great choice available... :D

The other benefit of evoSkins is that your readers can also choose, from a selection of skins you provide, which one they like the most! :D

(Of course, this is optional... in case you don't like the idea! ;) )

What about my current blog template? :?:

If you already have a b2 blog template and just want to upgrade, you can just reuse it without worrying about skins.

Alternatively, you can turn your existing template into an evoSkin (instructions provided) and take full advantage of the evoSkins skinning system.

What's the difference between evoSkins and a CSS style switcher? :?:

Good question! Why do we need evoSkins when we already have CSS? :)

As a matter of fact, a blog skin can be as simple as a custom CSS design. But evoSkins can also provide more variations than what you can do with CSS. Here are a few examples:

  • Some evoSkins may have popups for comments while others display them inline
  • Some evoSkins may have a very light HTML footprint for use on Palm and mobile devices and others may have a full-featured output
  • Somes evoSkins may use plain standard HTML/XHTML, others XML, others WML, others cHTML, and others even FLASH! (=> BTW, if you are a Flash designer and want to work on accessibility compliant Flash Blogging, please contact me! :) )

I'll put up a demo as soon as I have a minute. I'm a little overloaded by the upcomming week-end right now... :roll:

Unsubscribring from spam *NOT*

Cédric [site gone] posted some interesting thoughts about whether or not to unsubscribe from spam.

Cédric advocates that unsubscribing has become less a trap than it used to be, basically because spammers are better off collecting new masses of addresses than preventing their mailers to automatically unsubsribe people who'll never buy from them anyway. And also, because there are legal risks in spamming twice someone who asked to be removed.

Cédric also says:

Another thing I can see coming in the near future is that these "do not spam" lists will one day be forced to be shared among spammers. In other words, any "do not spam" list you are a member of right now might end up in having your email address removed from others as well.

=> Well actually... this is precisely the point: some day spammers will have to share their "do not spam" lists...

Oh... actually they do it already! It's just that they do not share, they resell... and they donto not call them "do not spam" addresses, they call them "qualified" addresses!

The buyer can spam you without worrying too much... after all you haven't yet asked to be removed from this one!

The problem with spammers is that they are dumb and smart at the same time!