In my last post, Scott mentioned being able to change the stylesheet based on the mood of the writing–derived from the occurrence of trigger words such as ‘anger’, or perhaps mention of certain names.
The problem with a keyword-based solution is that without knowing the context, you really can’t determine how a word is being used. For instance, I could have a funny post that uses anger a lot, and it could be blazing red by the time I’m done, but there’s no real anger involved.
In addition, we’ve learned from Google how keywords can work, sometimes, and not, other times.
I believe no better tool exists for setting the context of a writing than the human brain. Of course we’ve found that many other factors can come into play even when the context is defined. This is the reason that smileys–those spawn of the devil– are so popular: to add hints so that a person can tell if something is supposed to be a joke or not. As we get to know each other, we’re better able to differentiate the mood of our writing based on past experience, known triggers, or word use. Even with this exposure, we still fall into little traps of misunderstandings.
In preparation for other work I’m doing, such as Poetry Finder, I’ve started working with WordPress’ key-value meta tags with each post, in this case to set a ‘tone’ of the individual writing. I’ve begun with a small set of tones and appropriate stylesheets; a set which I’ll add to over time. I’ve managed to get five tones so far, but only annotated ten postings.
If you use Emotive from the front page, category, or archive, you’ll get my favorite of the emotive sub-stylesheets. However, if you access an individual page, you can see the stylesheet based on the tone I set in the writing. If a tone isn’t set for the posting, again you’ll see the default.
Why do something like this? Well, it’s fun. More than that, though, I want to see how far I can ‘blur’ the lines between traditional front end technologies, such as (X)HTML, CSS, and JavaScript; and traditional backend tech such as PHP and MySQL.
The latency you see with the stylesheet being applied with each page is due to the fact that there is some overhead on the server when serving up the stylesheet. In addition, changing from page to page doesn’t allow caching. That’s the downside of this type of server-based processing in stylesheets – if the stylesheet changes from page to page. A better approach could be to use Javascript on the client to make the changes, triggered by a value set by the PHP application.
But it’s an interesting exercise.
(I’ll cover the technology used a little later in another writing.)