At long last I’m getting around to updating Joho’s look, for several reasons:

First, my last redesign made the page look like it was designed in 1999, although I actually did the redesign about seven years ago, I think.

Second, CSS has made it easy enough to avoid using a table as the container for all of the contents of the page. That was always a hack but, it was easier than dealing with floats, etc., for a multicolumn design.

Third, it was especially easy to move away from using a table because I’ve given up on a multicolumn design. That has meant for now stripping out some early 2000s goodness, including my link-rotted blogroll, categories list, and archives. I plan on adding back my blogroll, if only as an historic artefact, via an overlay.

Fourth, the page page needs to be more readable in the mobile camera phones that the kids all use what with their Facebooking, and Chapnapping, and all the rest. I have by no means done all the work required to make this page truly responsive (Everyday Chaos is my best attempt at employing a modified a responsive template), but I’m hoping it will be responsive enough for the kids who are used to their Facebroking and Snoopchitting and all the rest.

Fifth, Medium.com‘s elegant design redefined what a blog should look like. Yes, that was like 18 years ago, but I was too busy with my Facebokchoying and Schnapssbapping to get around to it. Medium not only transformed our expectations about the tools for writing a post, but also about the reading experience: easy to take in, elegant, content-focused. So, I have increased the font size, removed the distracting sidebar, and I hope made it a more inviting page.

I’m obviously not done. For example, I haven’t yet gotten around to updating the page that shows a single post. But I’m happy so far with the redesign. Or, to put that more accurately, I’m somewhat less embarrassed by the page.

Until design tastes change again.

Aaaand, they just did.

Be the first to comment »

Operating systems play favorites when it comes to fonts: they pick one as their default. And the OS’s don’t agree with one another:

From https://furbo.org/stuff/systemfonts-new.html

But now when you’re designing a page you can tell CSS to use the system font of whatever operating system the browser is running on. This is thanks to Craig Hockenberry who proposed the idea in an article three years ago. Apple picked up on it, and now it’s worked it’s way into the standard CSS font module and is supported by Chrome and Safari; Windows and Mozilla are lagging. Here’s Craig’s write-up of the process.

Here’s a quick test of whether it’s working in the browser you’re reading this post with:

We now return you to this blog’s regular font, already in progress.

Be the first to comment »

I use MailPlane to read my email (via gmail). Having some leisure time I decided to poke around its styling options.

MailPlane’s preferences let you override the default gmail styling with your own CSS. Here are three classes important to the listing of mail in your inbox:

For example:

.xY{
color:white;
background-color: #045D9E;
}
.y2{
color:#8FD5FF;
}
.zF{
color: yellow;
}

That will produce this:

Unfortunately, you never know when Google might decide to change these class names or restructure the entire damn thing. On the other hand, you can always just delete the CSS.

1 Comment »

After all these years, I just found out about CSS alpha as a way of adjusting the opacity of the backgrounds of elements on a Web page.

In the past, I’ve used the opacity setting to do the job. So, if you have, say, a div that’s overlaying another element, setting its opacity to, say, 0.7 will make the entire thing 30% transparent. Opacity, in other words, is inherited by all of an element’s children without the children having any way of contesting the will.

But yesterday the opacity setting wasn’t working on an element for some reason. So I googled around and stumbled upon the alpha setting, which did what I wanted even better. Alpha sets the opacity of the background of the element while leaving the text and border opaque. This is great if you’re putting a label with text over other elements.

Here are two divs that are exactly the same in all their settings except one has its opacity set to 0.5 and the other has the alpha of its background color set to 0.5.

Notice that the alpha setting has left the text and border un-alpha’ed.

To set the alpha, you have to specify it as part of the rgb color setting, using the keyword rgba. For example, here’s the relevant portion of the CSS of the alpha-ed box in the screen capture above:

#e3{
border: 6px solid #FF8000;
background-color: rgba(255,111,207,0.5);
color: black;
}


And here’s a site that will convert your hex colors into rgb colors.

So, I’m hereby giving myself a giant D’oh slap n the hope that you won’t have to.

Be the first to comment »

Thanks to Mirek Sopek, the folks at Mako Lab diagnosed why my new WordPress blog template was going all wonky in Internet Explorer 9. Even after I’d discovered that the problem was that I was declaring the HTML page with Quirks, I’d put the type declaration in the wrong spot. I put it at the top of header.php, thinking that would put it at the top of the HTML page that WordPress assembles out of various files. Nope. You have to put it at the top of the index.php file. D’oh!

We still don’t know why it worked on my copy of IE 9, at the same version level and both 64-bit.

Thank you Mirek and Mako Lab! I would never have figured this out without you.

2 Comments »

In the recent — and probably unabated — unpleasantness attending the launch of the update of this blog’s look, I have learned a little about Quirks mode. I learned this because Internet Explorer 9 was not displaying rounded corners or laying out divs (blocks of content) the way Firefox and Chrome were. Once I switched off Quirks mode in my blog pages, it worked much better.

There’s a good explanation and some very detailed info here. But as I “understand” the story, quirks mode was introduced to handle the problem that different browsers were expecting different sorts of markup (particular for CSS style information). Then, once the browsers realized it would be helpful to everyone if they agreed to support truly standardized standards, they had to decide what to do with the old code written in the particularities of each browser. So, they agreed to allow the HTML developer to specify whether the page she’s created should be interpreted according to the modern standardized standards, or if it’s quirky and ought to be interpreted according to the idiosyncratic expectations of the various browsers.

You, the HTML developer, specify your intentions in the DTD declaration at the very beginning of your HTML pages. This page will help you figure out exactly how that line should read.

Meanwhile, the shame and humiliation the launch of the new look of this blog has brought upon me only deepens, for I have given up on controlling the placement of divs by getting my floats in order. Screw it. I’ve plunked them into a table. Yeah, I’m CSS-ing like it’s 1995.

2 Comments »

I’ve found myself using Google Docs more and more. It’s about a Bronze Age word processor at this point, but it makes collaborating easy, I like being able to get at my work from anywhere (even when offline), and the continuous backup and versioning is comforting.

But, not only is Docs way under-featured and butt ugly, Google is fixing it up really slowly.

What would Google have to do to enable The Community to enhance it?

We presumably (i.e., I don’t know what I’m talking about) could write an enhanced system that uses Google Docs for storage, but that slaps a new UI on it and adds features. In fact, maybe this is something that Adobe’s beautiful Air-based word processor, Buzzword, should be (or is?) looking at.

Even better: Google could make Google Docs as amenable to add-ons as Firefox is. Of course, I have no idea how hard that would be, and what the possibilities of terminally screwing up your docs might be.

At the very least, while Google Docs is getting better at allowing us to redefine existing HTML elements, to create new classes, and even to create new elements (albeit without giving us a UI to use these classes or elements, other than entering into HTML editing mode), letting us attach CSS style sheets seems like an obvious and non-destructive improvement.

But, IDKWITA (I don’t know what I’m talking about … and why isn’t that a standard Web acronym?), so there may be obvious technical issues mooting all of the above. But I’m sure that won’t mute you from telling me what I’m missing.

Please. [Tags: google google_docs word_processors openness css ]

Marco Barulli at Clipperz (a password manager) blogs about what it would take to get more freedom and privacy from the providers of Web apps. He has a three-part solution…

4 Comments »