All posts in CSS

“Fun” with Internet Explorer 6 seems never ending, as the case with recent internationalization efforts I did in the office shows. We needed to create a Hebrew version of our flagship web site product — a language where writings goes right to left.

Hence, our three-column layout, done with floats, was supposed to be inverted. Along with that, a number of other parts was to be horizontally flipped — one of them being variable tabs I created way back. CSS2.1 spec defines few rules responsible for right to left display. So, what we did was:

body {


unicode-bidi: embed;


direction: rtl;


} 

With these rules, Firefox worked ok, but IE6 almost totally collapsed. It’s not only messed when displayed — when you move your mouse over elements they disappear, move to different places… Only direction rule is enough to mangle it — I added just this one line to previously mentioned tabs example:

#tabs {


direction: rtl;


} 

Here is the screenshot, if you can’t check it in IE:

Holly-hack does not help here, setting width/height or position neither. Nothing helps here, I tried them all. It is somehow connected with float, but removing that rule does not really helps.

Workaround is to override direction for floats and re-apply it to elements that contain actual text:

body {


direction: rtl;


}


#tabs li {


direction: ltr;


}


#tabs a {


direction: rtl;


} 

Of course, last two lines would go under cond. comments, so that only IE is targeted. I’ll see if something else comes up during ongoing work…

I’m in danger of becoming tab-fanatic. It’s not my fault, really. All the stuff presented here, either as Sparks or hidden away as casual posts are the fruit or consequence of my day job. The curse of working the job you love is that you don’t leave it in the office. I encounter the problem and instead of working on it for few days, I take it home and finish it up in the wee hours.

And for some reason, I often encounter tabs. Tabs are self-contained and can easily be extracted from the layout where they are used. As such, they make perfect post-topic.

It’s hard to do something new in tabs domain. I thought that too when few months ago (yes, that’s how much it took me to write this) I looked for tabs that overlap each other. You see, all the various tab techniques around the Net, no matter how graphically different they are, share one common attribute. The linked parts of the tabs do not overlap, like the following well-known examples illustrate.

The area you hover will change only part of the screen occupied by li and/or a. It does not change anything outside that block. And I need to implement just such design.

Continue Reading →

Rounded corners are one of the most sought-after graphical elements on the web. Hence we have a myriad of implementation with more or less bloated code. The reason is that you need four hooks to attach the four images needed for flexible boxes. With typical box markup of header plus paragraphs/lists, it can be hard to find appropriate elements, especially with outdated and buggy browser implementations.

Once you do away with browser constraints and develop for the best in the field, all the markup is 100% semantic.

<div class="hifi">
<h2>Nice box<a name="anch2">with anchor</a></h2>
<p>And few...</p>
<p>paragraphs. </p>
</div>

div defines the box, h2 defines the header, p defines content and a defines fast-access URL point. Semantic, flexible and good looking. What else to ask for? Apart from browser support, nothing.

Continue Reading →

About one year ago, I published two posts dealing with creation of tabs out of unordered lists. Nested tabs or two-level navigation was about one line of tabs + subtabs for each, with active (selected) item. Variable tabs were one-line navigation, were some items have different design.

Back then, I knew that none of them was perfect, but it suited my needs and I left them be. One year is the long time though, especially in the fast-blossoming field of CSS design. New tricks were discovered since then and it was time to update that code. I had some time to do it now.

Both tabs examples are improved and works almost perfect. Unneeded markup (like clearing div) is removed in both cases.

Continue Reading →

Weekend discovery (could be hot water for some)…Look at this example page. No CSS at all is applied to the first line of input fields. input { font-size: 1em; } is applied to the second line.

Now, open this in IE, and try setting your default text size to Largest and then to Smallest. You will see that first two fields do not change their size at all, while the second two obey. In few other browsers I tried, this does not happen.

What exactly is the core of the problem is unknown to me. One guess is that IE sets the predefined field size in pixels, and it is known fact that IE can’t resize pixels. When the unit is changed to ems, it works as you expect.

No matter what is the cause, this is the issue to watch for.