humorist + humanist (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
erinptah) wrote in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png)
style_system2012-02-17 10:32 pm
erinptah) wrote in style_system2012-02-17 10:32 pm
Entry tags:
Layout help, fixed & fluid (Tabula Rasa)
I'm working on two Tabula Rasa layouts -- one fixed, one fluid, with matching graphics -- and starting to hit the limit of what my understanding of CSS can handle. Help?
Here's the current state of the fixed-width layout, currently enabled atpunditfic:
And here's the fluid version, visible in action atandthatstheword:
Issues in the fixed-width layout:
When the page isn't tall enough, module-content and module-powered show up in the middle of the sidebar. Avoided!
In the main entry view, how can I get usernames to display reliably under the userpic? The best I got (through messing with margins) was "it'll appear there, but entry text will overlap it." (Also a problem in the fluid version.) Solved in both!
New issue...when #primary is shorter than #secondary, the page only scrolls down as far as #primary.
Things in the fluid layout that I can't get to match the fixed-width layout:
On the calendar-by-month view, the entry information isn't indented with respect to the date. Prettied up!
Similarly, the bulleted list on the tags page isn't indented. Solved!
Information in the entries on the main page is all squished together (title overlapping with date/time, tags overlapping with entry tools). Solved!
Everything to do with comment display just isn't happening. The tools won't display inline, there's no space around comment-content, the header has no background... Solved!
Other issues with the fluid layout:
Can I make the #primary and #secondary divs extend to the bottom of the page (to extend the background) without covering the header?
Looks like I need to do something with module-content and module-powered here too. When the sidebar is on the left, they try to squeeze into the gap between #secondary and #primary. This isn't a problem when the sidebar is on the right (or at least, it hasn't been at my resolution). Solved!
Anyone who can point me in the right direction on any of these points would be greatly appreciated!
Here's the current state of the fixed-width layout, currently enabled at
punditfic:And here's the fluid version, visible in action at
andthatstheword:Issues in the fixed-width layout:
Things in the fluid layout that I can't get to match the fixed-width layout:
Other issues with the fluid layout:
Anyone who can point me in the right direction on any of these points would be greatly appreciated!
no subject
.two-columns-right #tertiary,.two-colums.left #tertiary {
clear: both;
}
needs fixing and then #tertiary will pop down to the bottom.
As far as the columns in the fluid go, the method used to fake full length columns, which you can't get for real unless you can set a height on them, is to use the parent element which extends to the bottom of both columns.
This article about column layouts is the most straight-forward explanation of using the border trick that the original Tabula Rasa has to contain floated columns.
The idea is you colour the area under the column, not the column itself (the border or background in #content). Your issue is the use of an image, rather than a colour. You can apply images to borders, but guess which browser doesn't support that?
You might want to consider using the original Tabula Rasa column layout and colouring the #content background or border and applying an opacity to it to make the stars shine through rather than an image. It has greater support in IE than border images. Or perhaps someone else will have a more elegant solution.
no subject
It doesn't look like the floating-over-the-border trick is going to work, since I want that line of dark space between the two light columns. It's not a priority, though, just something that would look nice if it's possible.
no subject
Yeah...isn't that annoying? I've resorted to setting heights on them only to strip the code out without including it in my layout's final versions because setting a height is always going to make the resulting columns too short for some posts and page views and too tall for others. The only possible workaround is to use lj-cuts to keep posts to an exact height that always works with the resulting column flow, which is a ridiculous way for anyone to keep their layout looking somewhat right, and doesn't address the problem with various page views not matching height correctly at all.
I'm not good at setting column heights anyway, especially given DW's limited capacity for such things (you need to be able to muck around in the HTML to use divs to set the columns up yourself, a feature we're lacking here unless we get into editing existing and/or creating new s2 layers), so this is the one convo here that has gone right over my head, on top of everything else...
no subject
You just go
#column_one, #column_two {display: table-cell;}Set appropriate widths on them, and bang, you're done.
But, and there's always a but isn't there, IE old doesn't get it. So you have to be able to put a conditional style on it for IE older than 8. And, crucially, some screen readers treat it as if it was a table, delivering the information as if it's tabular data. Which I don't think they should do.
They don't scale down like floated or inline-block columns either, but in some cases, like a fixed-width layout, or on DW where you can switch to one-column via options, that's okay.
Frustrating to have this tool you can't use unless you're making a private layout. But if you are, then, try it.
Always a but (or in IE's case, yeah, a butt)...
Heh, why would this not surprise me? There's a reason my Quick Launch thingy includes stuff like:
So you have to be able to put a conditional style on it
But if by that you mean a conditional comment, yeah, I'd love to trick IE Old out in just that way with all my layouts, but DW/LJ strips out such possibilities by invalidating your entire style sheet for improper syntax if you include that code. You can't use backslashes, any non-UTF8 chars or any conditional comments. And of course, you can't link off-site to additional or even primary style sheets. Which might sound like a complaint on my part, but is actually one of the reasons I love coding for DW more than any other place (such as my own website or Wordpress, or whatever); you're so limited in what you can do here that you're forced to get really creative to make stuff work at all.
While I would enjoy the added flexibility of Moar Options, there's something to be said for having to work within such narrow confines, too.
And, crucially, some screen readers treat it as if it was a table, delivering the information as if it's tabular data. Which I don't think they should do.
Thanks for mentioning that because I had no idea. Assuming all display: table values have the same effect, that's bad news indeed. I began using display: inline-table after noticing Google uses that to set some elements
on results pages, and I found it comes in handy for coding forms....but...if it's going to hurt accessibility, then I need to find a better way, I guess.