if you remove CR you will get a flatter table as in tab 2

In my experience - for what it's worth - I've found that the difference between % and px is key when it comes to (re-)scaling issues. When something is set with %, it will generally rescale depending upon the size of the browser window (i.e. the % is determined by the overall size of the window). When something is set with px, on the other hand, the value is more or less 'absolute'. A px value will not rescale to the window, and will simply push any remaining part of the page out of the screen, causing a scroll bar to appear on the browser window.

Part of the problem here could reside in the fact that most of our templates are a mix of % and px values. Hence, some things scale and others don't. Normally, this is a good thing (for example, you don't want your header to scale vertically, while you generally do want it to scale horizontally). But, on rare occasion, it can cause some serious (looking) problems, mainly because a px value overrides a % value.

This all might be so obvious to everyone here that no one felt the need to mention it. If so, simply ignore this message. ;)

I monkeyed with it and saw that the space at the top is proportional to the number of rows. It's also proportional to the number of cells, because when I pasted 10 rows of 3 cells each (using viszlai's method), the table would march down the page more slowly.

It doesn't have anything to do with the tabview, because the table by itself creates the same space.

I also coded table the way I would have done it (much flatter), and there's no issue.

So it's something related to the coding, but also related to something going on at the cell level. Can't figure out why that would be.

Hope this is correct for you.

And now - some question I have and cannot answer:

Are you using a special CSS ? - the fonts are different - could be the sandbox has another theme)

Why do you use 1% for the tab width?

The pictures cannot be found - this is okay.
Who ever have an idea - can test here..

here is the link: firefrog.wikidot.com/search-for-a-job

you will need to scroll down far

while i'm at it - how do I change the background color of the page as well

Except one that doesn't use tables, as far as I can see.

Allof the other suggests don't seem to address this issue. I'm guessing it is something very simple.

I even added this line as suggested with not impact:

[[table style="width: 1%; margin: 40px; border-collapse: collapse; border:2px solid"]]

Any idea's?

This CSS problem in IE6 and 7 is all tied up in variable window widths. So I just constrained the overall width of the page to ~800 px, which is as lo-res as screen settings come, I guess. It's easier to read text in narrower columns anyway.

I added this into my custom theme, which extends flannel ocean. I haven't tested it fully, but so far, it seems to look OK in IE7 and Firefox. I've mixed em and px widths pretty liberally, so any misalignments are probably because of that.

 #container-wrap { background-color: #ccc; } #container { background-color: #fff; width: 812px; margin: 0 auto 0 auto; } #header h1{ margin: 0 0 0 -60px; } #header h2{ margin: 0 0 0 -60px; } #content-wrap { margin: 1em 0 1em 1em; } #top-bar{ right: 5em; } #side-bar{ width: 10em; padding: 1em; margin: 0 0 1em -1em; } #main-content{ margin: -0.5em 0 0 12.5em; width: 612px; padding: 0 0em; } #page-content{ width: 612px; margin: 1em 0 1em 0; } #page-info{ margin: 1em 5px 0 0; } #action-area{ margin: 5em 0 0 0; } 

… Only in my case it's been 98% purple and gold.

S.

Howto's content might need to be updated. No se.

My stash is much less interesting, so I just keep plugging away.

You're right about different IE versions. When I narrow the window in IE6 and the min-width limit kicks in, everything freezes up. So much for that "fix"…

Meanwhile, I'm now floating main-content right and adjusting margins. With sidebar and main-content pulling in opposite directions, it seems to be working. But I've got to check it out in other browsers first.

I use divs only when really needed. Hopefully in most cases tables will do the trick. (IMHO). I also tend to go for smallish pics.
But then you have to consider what you are going to put in each cell. Thought must be given to what will happen to the content on resizing.

All i can tell you for sure, is that after spending hours apon hours of getting the code to do what you want, as in, looks ok in ff and ie7, as soon as you use ie6 it all goes to pot, which i have found on more than one occasion to make me the same :-)

…Not yet so very elegant. Now the footer doesn't respect the bottom of the sidebar.

I'll sleep on this one. Good thing this wiki doesn't have too many short pages.

I had some minor customization, so I reverted to the standard theme just to be sure. The problem is there too. Then for the heck of it I tried out a bunch of other themes. Same problem.

In the base css, the side-bar is floated left. I'm pretty sure the custom css below positions the sidebar absolutely. But here's a head-scratcher — top: 0 locates the bar where I'd expect, right at the top; top: 1 (or any other positive integer) drops it down to where I want it. No complaints there, but I don't get it.

Here's the custom css that seems to have fixed it:

 #side-bar { position: absolute; top: 1; left: 20px; } 

… and here's the code for keeping the search box clear of the site's title:

 #header { min-width: 750px; width:expression(document.body.clientWidth < 750? "750px" : "auto"); } 

Thanks for the suggestion Craig. It's taken a lot of drilling down and analysis for me to arrive at that one line of code, but hopefully it's an elegant solution.

For instance, I've learned that many web designers don't have much nice to say about Internet Explorer.

I've also started to understand the geometry and logical puzzles of wikidot's page layout. It's a series of nested boxes, kind of like this:

So does anyone have a straightforward fix? Or should I just blame Microsoft and live with it?

S.

Clean, uncluttered, hassle-free layout is one of wikidot's big strengths. But here's my frequent headache with layout. It seems to be true of most (all?) of the standard wikidot themes.

With wider, blockier elements, whenever the window's width is smaller than the combined width of (sidebar + main-content elements), those elements jump down below the sidebar.

The result is a large blank space. At lower screen resolutions (when this is most likely to happen), it's not even clear to users that the page has any content at all.

I'd like to set my css to ensure that the (sidebar + main-content) sections have a minimum width. I think the effect would be to force-justify the content to the top. For narrower windows, the content on the right would be out of view, but that's clearly preferable to having it jump down where it's entirely out of view.

It's not enough to set the minimum width of the main-content section, because it still floats independent of the sidebar. Maybe if css treated the sidebar and main-content as a unified section instead of as independent sections? It's also not enough to simply set the width, because I'd still want the content to fill a wider window.

Also, a narrower screen will push the header's search field into the title, so it feels cluttered. I'd prefer to have the header also respect a minimum width.

If someone can point to a custom css fix, that would be so great. It also seems like this merits a general css fix. Sidebars are such a common website feature, and I don't think I've come across this glitch elsewhere.

I think lots of people have had this issue — here, here, here, and here.

Any insights? Thanks.

http://community.wikidot.com/forum/t-25622

Is your site public so we can see the issue?

-Ed

I've now used a table to lay out my frontpage. I want the table to fill out as much space as the browser window allows. But when the window is narrow, the table jumps below the sidebar. If someone doesn't think to scroll down, it looks like there's no content in the page's main body.

Is there a way to force the table to the top of the screen, beside the sidebar? If the window is too narrow, then the rightmost portion of the table should simply be out of view.

It seems like the solution should be in the css somewhere — maybe a general bug fix — because I can't think of an instance where it makes sense to orient a page that way.