Is it really that hard ...? (or how i finally learned to hate CSS)

Tuesday, August 24. 2010

Is it really that hard ...? (or how i finally learned to hate CSS)

I confess that i've been hiding under a stone for quite some time when it comes to contemporary HTML stuff, for most of the things i'm doing on the presentation level even good old HTML 1.0 would be sufficient if it weren't for the occasinal tabular data ...

So while i know CSS in theory i've never really looked into the black magic of doing CSS layouts and stuff ... until now ...

What i'm up to right now was to produce a small series of step by step examples on how to use OpenLayers to present customized OpenStreetMap based maps, and for that i wanted to have a simple layout like this:

  +---------------------+
  | Some text           |
  +---------------------+
  |                     |
  |          MAP        |
  |                     |
  +---------------------+

So a little descriptive text on top (about 4-5 lines max) and the map taking all the remaining vertical space of the browsers content area, but not beyond that so that no scrollbars will appear.

Looks like a simple layout manager task, doesn't it?
So i wrapped the text and map areas up as <div>s and started to play with their CSS height settings.

Just to summarize: epic fail.

Quite a few google searches, some selfhtml study and some chats with people who should know i only came to the conclusion that this does not seem to be possible using CSS alone.

Next station: JavaScript

So the new plan was: use JavaScript to detect the size of the upper <div>, set size of lower <div> to window size minus upper text size, then initialize the map. Then catch resize events from both the document window (window size changes) and the upper text div (font size changes will change this even if the window size stays the same). OpenLayers is a rather heavy weight JavaScript solution anyway, so a few more lines of JS code should not matter in this case.

But, surprise, size change event handlers only exist on the document / body level (at least in FireFox), and for default font size changes there doesn't even seem to be any event handler at all.

So looks as if i need to actively poll the size of the window and the text part on a regular basis and take action when detecting size changes, probably with some extra delay logic that waits for sizes to stabelize before taking resize action on the map div to avoid constant redraws while the user is still performing window or font size changes ...

Fun .... NOT!

Is there really no better way to deal with such IMHO rather trivial layout management tasks in HTML/CSS/JavaScript land?

PS: for now i'm just going to settle with a simple 20% text, 80% map split even though that will waste some vertical space and will break if the user chooses to increase font size to some very large value ... it's still frustrating though that the browser can't just do a "whatever space is left" calculation even though it has all the necessary input data anyway

Posted by Hartmut Holzgraefe in PHP, OSM, Why? at 11:09 | Comments (9) | Trackbacks (0)

Defined tags for this entry:

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

that's pretty simple to solve with pure CSS !

the allpage's DIV should be :

#ALLDIV{position:absolute;width:100%;height:100%;}

and the 2 inner div :

#TOP{position:relative;width:100%;height:30%;}

#MAPS{position:relative;width:100%;height:70%;}

and That's all folks, no need to troll 'bout the good ol dayz ....

#1 T1B0 on 2010-08-24 12:12 (Reply)

@T1B0: have you read up to my "PS:"?

a static split is exactly *not* what i wanted to avoid

#1.1 hartmut on 2010-08-24 17:38 (Reply)

This is actually pretty easy with a combination of CSS and javascript without using any sort of resize event capturing.

You can use absolute positioning in css to position the map's bottom edge to 0, then use JS to get the height of the text div and set the map div's top attribute to that.

Here's my CSS:

#container{

height: 100%;

width: 100%;

background: #666;

position: relative;

}

#text{

background: #D66;

}

#map{

background: #6D6;

position: absolute;

width: 100%;

bottom: 0;

}

And my JS (I used jquery for simplicity's sake, but it wouldn't be hard to write it in pure js)

function resizeMap(){

$('#map').css('top', parseInt($('#text').height())+'px').html($('#map').height());

}

$(document).ready(function(){

resizeMap();

});

I made the resizing a function in case it needs to be called again, but in Firefox I didn't see any issues in scaling up the text.

I hope this helps!

#2 Anthony Harris on 2010-08-24 12:52 (Reply)

I probably should mention that the advantage to this approach as opposed to the CSS percentages is the lack of wasted space. Because the top of the #map element is determined in JS after the page loads, and the bottom is statically set to 0, the map cannot drop below the bottom of the page. I'm not sure how this will affect your maps, but divs filled with text are acting fine. The only time a scrollbar is created is when actual content is being cut off. If the map itself needs to be resized there should still be a solution to this problem.

#2.1 Anthony Harris on 2010-08-24 13:01 (Reply)

This will be my last comment - I promise

I went and looked at this openlayers thing, and played around with the code. I saw a bit of a problem when the map wouldn't load because there was no explicit height set on #map in the CSS. The solution to this is to get the computed height of the div, and set it to that. That will convince the map to load, but be ignored by the browser when creating the box for the map, allowing for resizing and no capturing events.

So as not to ridiculously enlarge the comments section agai, I've put the full code on pastebin. You can view it here: http://pastebin.com/GumWwSMB

PS: Don't hate CSS, it's your friend!

#2.2 Anthony Harris on 2010-08-24 13:37 (Reply)

Thanks Anthony, that works as intended indeed ...

I'll continue to claim that CSS is a mess though, it should have something like "height: auto-as-small-as-possible" and "...: auto-as-large-as-possible" instead of having to fall back to custom JS code for this ...

#2.2.1 hartmut on 2010-08-24 22:46 (Reply)

You don't have to resort to JavaScript, if you're willing to put up with a little extra markup. All you need is the oft-overlooked CSS tables (well, in browsers that support it--so not IE6 or IE7).

http://www.w3.org/TR/CSS2/tables.html

Unfortunately, your comment system insists on buggering some example code, so you'll just have to play around on your own.

#3 pinterface on 2010-08-25 02:19 (Reply)

On second thought, since it took me a bit of playing, I went ahead and threw up an example on my little corner of the 'net.

http://web.kepibu.org/tmp/css-test.html

#3.1 pinterface on 2010-08-25 04:13 (Reply)

heheeh so very true!

I had the same awakening few years ago when i though i would learn the proper way of using css instead of hacking this or that in nasty way ..... i got 2 books on css and guess what! they both said you need hacks to do the simplest 3 col layout. There is just no proper way to work with css as i see it.

I manage to do what i need but even now css is still annoying.

#4 Artur Ejsmont (Homepage) on 2010-08-25 10:31 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Wiki format allowed Standard emoticons like :-) and ;-) are converted to images. E-Mail addresses will not be displayed and will only be used for E-Mail notifications To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry