Do you write Eifel Tower with a lowercase or uppercase 'T' in 'Tower'? Apparently yes. Uppercase. That is how you write it. Meaning it must be the Eifel Tower and not the Eifel tower. Just something I've been wondering about...

Moving on: I just made some drastic changes in the site stylesheet! I read an inspiring article on the perfect paragraph while whimfully tweaking the layout today, and with some trial and error turned this previously very blocky and justified body of text into something hopefully much easier to read.

You may notice text sizes are suddenly incredulously large, paragraphs are stylistically narrow, previously regular-length paragraphs now look huge, and a bunch of layout elements are inadvertently messed up.

But it is easier to read... right? Not just because the text is bigger, but because there are fewer words in each line, because the lines are shorter not just in word length but in actual width - so you don't need to move your eyes so much from side to side to read, and because the spacing between words is even and the previously pro-longed white spaces don't become like 'boundless gaps' for certain autistic (I think it was?) individuals. There's no justification for justifying text!

And this is the optimal character amount per line, a balanced 50-70, even if it is mostly going towards and maybe over that high end 70. But it used to be 129. For newcomers, this is how it used to look:

I'm still not entirely sure this is the perfect format. I find myself suddenly writing shorter paragraphs to better suit the layout. Blank space fills up incredibly fast. I wonder if posts in the archives are still readable with this style, or if I'll have to revise them and shorten random segments of text so they don't take up an entire page. But then again, the practice of writing less is a good practice, and one it wouldn't hurt to start using!

What do you think? I think I'll leave it like this for a while. See if it sinks in. See if - once I've found and fixed all the odd quirks such layout changes inevitably cause - I do like this formatting better after all. After not daring to move higher than 13.4px in textual size over the span of the last decade, this is a sizable change.

I thought I'd type up a post on what characters to and what characters not to use when it comes to naming files.

First off, the basics: don't use /\?{}#*&"':<> or |

These are all restricted system characters used for other purposes, and depending on what OS you use, it shouldn't even be possible to enter them while renaming a file. Though it feels like this goes without saying right now, it didn't always. I've learned this by trial and error over the years.

Also: never use spaces in file-names you choose to upload. It's good practice to replace those with a - or suitable supported symbol of choice. File-names with spaces do work with modern browsers, but that's thanks to the browsers recognizing this as a common mistake people make, and the file-names are actually renamed on the fly by either the browser or a server-side script for them to work each time they load. You've probably seen the occasional %20 in the address bar. That's a space.

The reason I'm posting this post however is not because of spaces, or any of the characters above, but because of å, ä and ö, the final three characters of the Swedish alphabet. Maybe this also goes without saying for some of you veterans, but I just recently discovered that these characters are also ones you should avoid.

I recently uploaded a bunch of images with Swedish names, and these letters all produced a replacement similar to the %20 for spaces, but rather than through the browser they were in the actual filenames themselves. Ä became Ä, lowercase ä became ÇÏ, ö became Çô, and I have no idea about the others. I haven't researched the matter, but obviously whatever variant of Unix is being used on my server (I don't know much about that... yet) doesn't support these characters, and I'm guessing no other foreign letters either.

Moral of the story: stick to the 25 validated, working characters of the English alphabet and common supported dividers such as dashes or regular brackets whilst naming files. It's not just good practice for online use, but for whenever you plan on moving to another platform, sending a friend a file, etcetc. And you never know when you will until you do!

In my case, I discovered this little error a year or two after uploading the images because a few images weren't being displayed correctly on an old draft I'd just decided to post (secondary moral of the story: don't wait so long!). I looked around for solutions, and found a plugin to easily rename these files in both database and directory to avoid any potential conflicts. Picture below.

I did try other alternatives, but the above worked best for this specific purpose: renaming names and database entries individually, with a custom value.

Hope this might be useful knowledge for someone somewhere out there pondering characters! That's all.

Here's a little causerie in code about a little problem that's been hanging around in the back of my mind for a few years, that I finally did something about. If you're not working with or interested in WP, this might be a blog to skip reading. Short story, long blogpost, and it all starts...

A few years ago, I installed Custom Upload Dir. It's a one-of-a-kind plugin that lets you specify a custom upload folder within the base upload folder you've specified in WP, using a series of placeholders to modify directory structure based on things like file type, date, user, etc. I didn't need any of these extra modifiers, I just wanted to add an additional upload directory with a name of my choice for new files, but couldn't do this via WP since changing your upload directory directly by default changes the URL for all already uploaded images as well. So, I used this nifty plugin to start building a sequence of numerical sub-folders within the base directory that I'd switch between as they filled up over the years. On that note, it would be nice with a simpler plugin that automatically creates and shifts to a new directory when the current upload folder reaches a specified amount, creating this new directory based upon a naming pattern you specify. If any reader just so happens to catch onto the idea, let me know! I'd love to use it!

Anyway, I had previously used img/ as my base directory for all uploads, and was now planning to change this to work with the new directory pattern above. But since WP stores all meta-data links in relative form, I couldn't search and replace these links in my database with a new URL. There was just no URL to search for, and all images had unique filenames so there didn't seem to be a pattern I could use to search and find either. I thus changed my base directory to img/1/ and initiated my new practice of sub-folders within this sub-folder, leading to my images getting stored in img/1/, img/1/2/ and img/1/3/ and so on. I planned to change this later on, easily moving everything to the root folder, but I never figured out how.

Eventually, I changed the base directory back to img/, and moved all sub-folders into this directory, keeping the 1/ as just a sub-folder in the series. I searched and replaced all full URLs to these images in my post content, where the links were absolute, but couldn't do anything with them in post-meta, the table in which media library entries were stored. So since then they've worked in my posts, but not in the back-end where I browse these images.

A few days ago I decided on a whim to try this again. I opened up PhpMyAdmin not sure how I'd be able to accomplish this, but in exploring the database structure I quickly realized that all attachment images were stored in wp_attached_file entries within the wp_postmeta table. Wouldn't it be easy if I could just automatically search through the entries and add the folder number between table name and entry title? Aha. I exported wp_postmeta as an SQL file, opened it up in my favorite search and replace program (in this case TextRep 2.0, NoName Software), and searched for all wp_attached_file fields there were. I started the search and replace by searching for the first words in large series of images, like this:

wp_attached_file', 'One-Piece
wp_attached_file', '1/One-Piece

...but soon realized that using single letters would be much quicker! I searched by both upper and lowercase letters, like so:

wp_attached_file', 'O
wp_attached_file', '1/O
wp_attached_file', 'o
wp_attached_file', '1/o

...and 50 searches later, it was done!

You could probably do this via phpMyAdmin too, if you know how, but personally I found it much faster and easier to do it this way. Were my upload folder troubles entirely over? I looked through the postmeta file I'd downloaded and realized to my agonizing aggrevation that the thumbnail URLs remained unchanged. I had only changed the URLS to the images. Thumbs are stored in larger chunks of annoying text that look something like this:

a:6:{s:5:"width";s:3:"580";s:6:"height";s:3:"500";s:14:"hwstring_small";s:23:"height=''96'' width=''111''";s:4:"file";s:16:"One-Piece-40.jpg";s:5:"sizes";a:2:{s:9:"thumbnail";a:3:{s:4:"file";s:24:"One-Piece-40-200x200.jpg";s:5:"width";s:3:"200";s:6:"height";s:3:"200";}s:6:"medium";a:3:{s:4:"file";s:24:"One-Piece-40-280x241.jpg";s:5:"width";s:3:"280";s:6:"height";s:3:"241";}}s:10:"image_meta";a:10:{s:8:"aperture";s:1:"0";s:6:"credit";s:0:"";s:6:"camera";s:0:"";s:7:"caption";s:0:"";s:17:"created_timestamp";s:1:"0";s:9:"copyright";s:0:"";s:12:"focal_length";s:1:"0";s:3:"iso";s:1:"0";s:13:"shutter_speed";s:1:"0";s:5:"title";s:0:"";),

The really annoying thing with these chunks of text is that the numbers before the filenames for the thumbnails don't necessarily match. In one place it could be s:16, in another chunk s:18. It's a serialized array, where the numbers are apparently defined by the number of bits in each textual string. So, what did I do? What could I do? Nothing. I gave up. I changed the wp_attached_file URLs, but no wp_attachment_metadata data at all. I couldn't figure out how to do it, and neither could Google. I uploaded the postmeta SQL anyway to at least solve part of the issue aaand... it worked! The images worked. The thumbnails worked. Everything worked. As it turns out, I'd done all I needed to do!

To explain this totally unexpected surprise, I'm assuming either the wp_attached_file stores not only the filename (and relative URL if you are using a custom prefix as I am) but in fact the file info it's entirety, used as much for showing image info as for generating thumbnail info. That, or WP has changed how it handles this information and no longer generates thumbnail strings from uploaded images, relying on the image file to directly fetch such information when it's displayed. Of course I'm a total noob at this stuff and these are all very vague attempts at explaining this miracle. But the important thing is: that's all there is to it. :)

If I hadn't already started this blog ten years ago, I'd know till next time that how you structure the site from the ground-up is incredibly important. Choose a directory structure you like and stick to it, or make sure it's easy to change. Don't get lazy and stop naming, tagging and keeping track of files properly, and if you move the site: do an SQL export rather than a XML file export. Not that it's relevant to anything, but XML files don't store Media Library entries, so if you want to have a browsable gallery of all included images still available be weary of having them all wiped out! There are plugins for this, but none of them currently work with large directories and selections of files. But that's something for another post.

Read on...

For a long time (until today) I thought that a privacy policy was an obligatory part of any online website to declare to the public how public data is gathered (if it is) and how it is (if it is) handled or used. Though different sites say different things, having a privacy policy on your page is not mandatory at all. People include them simply because it's a practiced practice, and they have (as I had) the impression that it was needed. Don't get me wrong, many sites really do need privacy policies, but most personal sites do not.

If you run a business it may be wise to have a policy in case you collect information and handle it in such a way that it is required you notify the user of it. At the same time, creating a privacy policy is a guideline made as much for the visitor as for yourself, and if you do not follow your own policy, then the real trouble could fire up. So don't create a policy just to have one, and be certain that you'll follow the regulations you create if you do. If you use third-party services, they may require that you have a privacy policy. Apart from that, you do have an obligation to adhere to the Children’s Online Privacy Protection Act of 1998 (COPPA), and if you collect data from users of California, there's the California Office of Privacy Protection you need to be aware of. In different countries, different laws may apply, but most don't have any laws regarding privacy policies on websites. Most people don't really care or know about privacy policies anyway, except for the website owners.

I guess I don't need one. This is a personal website, completely non-commercial and I'm not collecting any data from users in Calfornia either. But what happens if a user from California posts a comment? What then? The topic of privacy polices is rather unclear, and it would be nice with some W3C regulations that clearly state what you must have. For now, I'm just posting my 29 cents. If you're interested, there's plenty of debate to look up.

IE implemented special styles of their own to allow users to color scrollbars, but not everyone uses IE. What about other browsers? Turns out: no, it's not possible. For one it's against W3C regulation, for two... it's just not supported by any other browsers.

Q: could you add scrollbar-* properties?

Do you add Scrollbar Property like in MSIE scrollbar-*-color (for example: scrollbar-shadow-color: #DEE3E7; or scrollbar-face-color: #DEE3E7; ). I think it should be added because scrollbars are like cursor. There are a lot of scrollbars in forms and in other block with overflow: scroll

A: Though it may make sense to design a styling mechanism to control the presentation of scrollbars, the MSIE scrollbar-*-color properties make too many assumptions about a particular scrollbar appearance design.

The working group considered adding the scrollbar-*-color properties and rejected them quite some time ago.

For CSS3 Basic UI, it is too late to add such a significant new feature. It could be considered for a future version.

source: http://www.w3.org/Style/css3-updates/css3-ui-comments

So, there you have it. No scrollbar color in a foreseeable future...

The title attribute in HTML. The one that appears as a hover over effect on images and links. Is there a way to break that caption into multiple lines? I looked and around and found a solution. Check this out.

Here's the code for it:

<div title="I just&# 13;broke the line!">Hover Here</div>

Remove spaces between &# and 13;.That's all. :)