Categories: , ,
Posted by: bjb

I want to put rounded borders on a stretchy box — expandable vertically and horizontally. I searched the web for solutions to this using pure CSS and found … none.

All the solutions I found had some kind of drawback. They all require you to either have a non-stretchy box in at least one dimension, or they require that your corner graphics be non-transparent. I’m not interested in the solutions that require javascript. The javascript just adds HTML elements or changes the CSS, anyway. And it’s slower than pure HTML and CSS, and sometimes people turn off javascript. Heaven forbid that they should miss out on the rounded corners.

The non-stretchy solutions involve having a single graphic to cover two or more corners — making stretching in the dimension between the two corners impossible.

There are a few non-transparent solutions that allow you to have a stretchy box. The solutions are various ways of stretching the sides of the box out to the corners, and then putting corner graphics on top of the sides. Thus the requirement to have opaque corners. One method is the sliding doors, another the Russian doll divs, and there are more as well.

One solution uses the pseudo-elements :before and :after, which is not supported in MSIE. Unfortunately, some people who read my blog (there are one or two people) use MSIE and complain when my blog looks funny. And they won’t switch browsers (or OSs, too bad).

Some solutions to the rounded-corners problem require you to have a certain set of elements in your html structure on which to place the corner and side graphics, and then claim that the solution does not require extraneous html elements. But if you don’t want a header element or a definition list in your box, you’re out of luck for that solution.

But I want stretchy sides and transparent-background corners around arbitrary contents.

Given that in order to implement this, I’m going to have to introduce extra HTML elements anyway, I think it is worth mentioning that a table can do what I want. A three by three table, with narrow fixed-width first and third columns and rows will allow the middle cell to stretch to accomodate its content. The first and third column and row cells can each have a different background image and each image displays in its own space with no overlap, allowing for transparent backgrounds in the graphics. Or, if you don’t want to have to maintain the table column and row widths and heights in sync with the graphics, you can put the graphics into those cells as HTML elements. Hey, one method is as evil as the other.

So, sometimes I’m going to use tables in my HTML. It is the best possible solution for this problem at this time. I sure hope HTML 5 has some sensible help for layout.

Categories: ,
Posted by: bjb

The first two steps in fixing the html on my page have been taken. I’ve decided that no, I’m not going to fix it the easy way (by getting rid of the category cloud). And I upgraded my byteflow to the latest development version.

I looked at mercurial, and decided I didn’t want to learn yet another revision control system, so created a local git repository for my copy of byteflow, and checked the latest byteflow into it. Then created a branch for my changes and put my customizations into it. I have a separate sandbox where I can check out the latest from hg, test it, and check in to the main git repo. That’ll be fun.

Next, will be to report the problem to the byteflow people, and possibly try to fix it myself (if they don’t do it first).

UPDATE:

byteflow ticket 152

04/7: byteflow

Categories: , ,
Posted by: bjb

I tried validating (see below) the html on my new(ish) blog — it didn’t validate. It seems the category cloud is non-compliant. But I fixed up the CSS and that validates now.

I will check into the category cloud later.

<a href="/bjb/tag/android/"
title="Click to filter by android"
alt="count: 2"
class="tag-2"
rel="tag">android</a>

<a href="/bjb/tag/apache/"
title="Click to filter by apache"
alt="count: 1"
class="tag-1"
rel="tag">apache</a>

...

The validator doesn’t like “alt” tags on the “a” elements, for starters. The question is, why is it there? Of course it could be commented out (it’s in templates/tagging/tag_cloud.html) but what would break? … Stay tuned.

 continue reading