This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!
Post a Comment

CSS for Developers: Horizontal Layout Using CSS

I'm a Java Developer.  But I'm also a Web Developer.  Web Developers have been so badly maligned over the last decade or so that I always feel wary (and sometimes slightly ashamed) admitting this.  There's some sort of assumption that Web Developers (and Front End Developers) aren't real programmers. Similarly, "real" developers don't like to be tainted by coming into contact with that nasty "front end stuff" in case someone mistakes them for a designer.

Trust me, no-one is going to mistake a Java Developer for a designer.  For a start, when designers wear geeky glasses it's ironic.  Or chic.  Or something.

But developers will be forced to do something around the front end at some point in their lives.  Even if it's because they're sick of manually kicking off some process and want to give the users a big red button to press instead.

So, as much to compensate for my own goldfish-like brain as anything else, I'm going to make a note of some of the CSS stuff I've used or found helpful during my mad scramblings to get the LMAX Trader user interface to a) look the way we wanted b) perform fast enough so our awesome back end performance wasn't totally invisible to the retail user and c) Not Suck Too Badly in Internet Explorer.

Part One: Horizontal Layout (or: There's No Excuse For Tables Any More)

You may (or may not) have heard that using tables for layout is a Bad Thing.  But to be fair, most of us don't care.  I've done it myself, it's usually the quickest way to lay stuff out on the page, especially if you're new to HTML / CSS and/or short on time.  There are loads of arguments all over the web as to why this is a bad thing, but the reasons I didn't want tables on the LMAX UI was a) we saw the performance improve by a really simple replacement of tables with divs and b) given the amount the UI was mutating, divs positioned with CSS was going to allow us a much quicker turnaround for the umpteenth re-design of the UI (ideally the upshot of this would be letting the designers mess with the CSS when they changed their minds and leave us developers out of it).

Anyway let's assume Tables Are Bad.  Tables are only for tabular data, not for layout.  In my world.

1.1 Simple Horizontal Layout Using Inline

The most common use of tables for layout is where you put elements side by side - the default behaviour of divs is that they lay out underneath each other.

However it's pretty easy to get divs to behave this way too, and using divs has some advantages over using tables.
<html>
<head>
    <title>Horizontal flow</title>
    <style type="text/css">
        #left {
            background-color: cyan;
            display: inline;
        }
        #center {
            background-color: yellow;
            display: inline;
        }
        #right {
            background-color: red;
            display: inline;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>
</div>
</body>
</html>
The first option is to use display: inline.  This will lay div elements next to each other, similar to a span.  This is the simplest way to get divs to appear side-by-side.

The disadvantage of this technique, however, is that inline elements can't be sized the same way as standard divs.  By default they contract to fit the content.

The screenshot above is from Chrome on the mac - you'll notice by default the elements have some spacing between them.  Reducing the margin/borders on the elements doesn't seem to eliminate this, so that's something else you might need to consider if you use this mechanism to display elements side-by-side.

1.2 Simple Horizontal Layout Using Floats


<html>
<head>
    <title>Horizontal flow</title>
    <style type="text/css">
        #left {
            background-color: cyan;
            float: left;
        }
        #center {
            background-color: yellow;
            float: left;
        }
        #right {
            background-color: red;
            float: left;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>
</div>
</body>
</html>
Similar to using inline, floating a div will do the following:
  1. Make it shrink to fit the content
  2. Lay it out side-by-side with any sibling floating divs.
You'll want to apply padding, margins, height, width and whatever else to make it appear less rubbish.


1.3 Wrapping Horizontal Layout


<html>
<head>
    <title>Horizontal flow</title>
    <style type="text/css">
        #left {
            background-color: cyan;
            width: 50%;
            float: left;
        }
        #center {
            background-color: yellow;
            width: 50%;
            float: left;
        }
        #right {
            background-color: red;
            width: 50%;
            float: left;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>
</div>
</body>
</html>
The advantage you have using divs over tables is that you can get the browser to work out how the elements should flow.  Tables require you to determine exactly how many cells appear on each row, but with divs you can determine a width for each element and have the browser work out whether to show it on a new line or not.  This will work with both percentage and pixel widths.
  • If you want a more table-like structure where you know exactly how many elements should appear on each line, use a percentage of the screen with.  
  • If you know the width of each element, you should set a pixel width on the elements and have the browser work out how many to show per line.

The next CSS post will go over floating behaviour in a little more detail.

Comments

  1. Tracy1 December 2014 at 17:14

    Exactly what I wanted to know, at exactly the detail I needed, thanks!

    ReplyDelete
  2. Unknown31 January 2015 at 22:58

    I have been browsing online greater than 3 hours these days, but I by no means discovered any interesting article like yours. It is beautiful value sufficient for me. In my opinion, if all webmasters and bloggers made good content as you did, the internet shall be a lot more useful than ever before.

    ReplyDelete

Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Image
Recently we open sourced the LMAX Disruptor , the key to what makes our exchange so fast.  Why did we open source it?  Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever. On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand. However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my  NADD audience. First up - the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I've come to realise that while this data structure is at the hea...
Read more

Dissecting the Disruptor: Writing to the ring buffer

Image
This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at...
Read more

Dissecting the Disruptor: How do I read from the ring buffer?

Image
The next in the series of understanding the Disruptor pattern developed at LMAX . After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor. ConsumerBarriers and Consumers I'm going to approach this slightly backwards, because it's probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer? (OK, I'm starting to regret using Paint/ Gimp .  Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.) Your Consumer is the thread that wants to get something off the buffer.  It has access to a ConsumerBarrier , which is created by the RingBuffer and interacts with it on behalf of the Consumer .  While the ring buffer obviously n...
Read more