[personal profile] erinptah posting in [community profile] style_system
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 at [community profile] punditfic:




And here's the fluid version, visible in action at [community profile] andthatstheword:




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!

    Date: 2012-02-18 01:19 pm (UTC)
    facetofcathy: four equal blocks of purple and orange shades with a rusty orange block centred on top (Default)
    From: [personal profile] facetofcathy
    I have one answer so far.

    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.


    What's actually going on here is that you've put a top: 320 px on #primary to offset it from the absolutely positioned #header. This is mucking up the way the page is drawing elements and none of #primary's parent elements are extending down to enclose it fully. So #tertiary is being drawn part way up the page.

    If you must position the header absolutely not relatively, then put that offset and the relative positioning on #content, so #primary can push #content down all the way to enclose it, and #tertiary, the thing your wayward elements are in, will display below #primary.

    Will check back later today and see if any more mysteries remain to be solved. I love debugging, it's a sickness.

    Date: 2012-02-18 02:25 pm (UTC)
    facetofcathy: four equal blocks of purple and orange shades with a rusty orange block centred on top (Default)
    From: [personal profile] facetofcathy
    Ooh, and the same issue in the fluid layout is caused by a typo.

    .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.

    Date: 2012-02-21 09:23 pm (UTC)
    marahmarie: (M In M Forever) (Default)
    From: [personal profile] marahmarie
    the method used to fake full length columns, which you can't get for real unless you can set a height on them

    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...

    Date: 2012-02-21 09:34 pm (UTC)
    facetofcathy: four equal blocks of purple and orange shades with a rusty orange block centred on top (Default)
    From: [personal profile] facetofcathy
    Actually what I said is only partly true. There is a super easy way to get columns to line up side by side and to have the same length as the longest one, no matter which one that is on a given page. The holy grail of layouts.

    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)...

    Date: 2012-02-21 10:19 pm (UTC)
    marahmarie: (M In M Forever) (Default)
    From: [personal profile] marahmarie
    IE old doesn't get it

    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.
    Edited (more info) Date: 2012-02-21 10:35 pm (UTC)

    Date: 2012-02-20 02:48 am (UTC)
    facetofcathy: four equal blocks of purple and orange shades with a rusty orange block centred on top (Default)
    From: [personal profile] facetofcathy
    I deleted the other comment because it was full of dumb.

    Now, when people do fixed width layouts is there any reason not to just set a width of 1080px or whatever on body or canvas? It kills the scrollbar and helps with an idea I had that deals with the #secondary is longer than #primary sometimes issue.

    Just float your columns left and put the right margin-left settings on them to position them. #tertiary will always be below both columns, and you can set the margins on the powered by et al modules to put them where you want them.

    If you have a width set on #canvas, you won't get the #secondary column popping below on narrower page widths. It gets cut off on the right, but that's a feature of fixed-width, not a bug right?

    Date: 2012-02-20 02:12 pm (UTC)
    facetofcathy: four equal blocks of purple and orange shades with a rusty orange block centred on top (Default)
    From: [personal profile] facetofcathy
    Yeah, you have to take off all the horizontal positioning offsets on all elements and fuss with margins to get them to land where they should if you float them.

    Check your overflow hidden effect on the archive page where #secondary is longer--is #secondary cut off? Setting body to the width of the background image and not using overflow: hidden would give you a horizontal scroll bar only if the user is on a screen smaller than the fixed width, which is what you want, yes? Sorry, I'm particularly slow on the uptake with fixed width.

    But, backing up the truck, here--what are you trying to accomplish, and how much customization do you want to allow?

    If you want the modules currently in #tertiary to look like they are in #secondary, why not just put them there?

    Turn off the second module section in the set properties part of your layer and then you never have to worry about what happens when the absolutely positioned thing is the longest thing on the page, because nothing needs to be drawn below it. Then the user can just rearrange modules in the one section however they like.

    If you want the user to be able to customize the modules and put things in the second module group, then you've got to change the current layout technique so that #tertiary will draw below both columns.

    The property is set in Tabula Rasa as:

    # explicitly define what sections the layout has available
    set module_layout_sections = "none|(none)|one|Main Module Section|two|Second Module Section";

    I'm fairly sure you just chop off the last two sections of that declaration string, and you have one module section only on the customize page. Even if your layout is in a theme layer, you can set properties in it and override the parent layer.

    Some answers...

    Date: 2012-02-20 04:43 am (UTC)
    marahmarie: (M In M Forever) (Default)
    From: [personal profile] marahmarie
    In the main entry view, how can I get usernames to display reliably under the userpic?

    .entry-poster{float:right;clear:right;margin-left:.7em;margin-right:.3em;margin-bottom:.3em;}/*--- sets username position*/
    .userpic a {border:0;}/* makes more room by removing possibly unwanted user icon border-bottom */


    Things in the fluid layout...the bulleted list on the tags page isn't indented.

    That's because you have an unclosed, empty statement for the tags container in your CSS:

    .tags-container ul {

    Change that to .tags-container ul {}

    Or just get rid of that line since you're not using it.

    Use this for multi-level indents:

    .tags-container .tags_multilevel li li {margin-left:30px!important;}/* specifying ".tags-container .tags_multilevel" ensures sidebar tags won't be affected by this code */

    I'm posting this without looking through all your CSS for possible adjustments because I have to shut down for the night very soon (but I may or may not post more replies before doing so), but I'll keep coming back to post whatever answers I can rustle up.
    Edited (added/removed some html) Date: 2012-02-20 04:45 am (UTC)

    Some more answers...

    Date: 2012-02-20 09:03 pm (UTC)
    marahmarie: (M In M Forever) (Default)
    From: [personal profile] marahmarie
    Things in the fluid layout...Information in the entries on the main page is all squished together

    For title overlapping with date/time, try this:

    div.entry {line-height:1.6; }/* unsquishes text within entry containers */
    h3.entry-title {margin-bottom: 1em!important; }/* you can also remove all padding from ".entry-title a" in your existing CSS to stop too-low border-bottom and too much left-indent on entry title from occurring */


    For tags overlapping with entry tools, try this:

    .tag ul {display: inline-block;margin-bottom:1em;/* current "inline" setting on this element makes setting white space around it impossible */}

    Question about:

    Date: 2012-02-20 09:25 pm (UTC)
    marahmarie: (M In M Forever) (Default)
    From: [personal profile] marahmarie
    On the calendar-by-month view, the entry information isn't indented with respect to the date.

    Do you mean on this page? I can't puzzle out code until I know what page I'm on, no pun intended. :)

    Also, I'll be away from the computer until possibly tomorrow, but I'll swing around again to see how things are coming along...

    Re: Question about:

    Date: 2012-02-21 09:05 pm (UTC)
    marahmarie: (M In M Forever) (Default)
    From: [personal profile] marahmarie
    OK, I was afraid it was that page. What exactly do you want in place of what you've got? Do you want the entry titles more left-indented beneath each date link? Do you want the usernames to keep floating right (which might be an effect from the code I gave you, I'd have to look into it)?

    What I normally do with that page on my own layouts is display the link to the numerical date in a really big font, make the title link proportionately smaller but not left-indented, and...not much else, really, since the whole page uses nothing but h3.titles and definition lists, which makes it a real PITA to pretty up all that much.

    Example of what I do with it here: http://marahmarie.dreamwidth.org/2012/01/

    If I were you, I might also want to get the word "Tags" inline with each set of tags themselves...so tell me what you want and I will try to produce the code that makes it work. :)

    Re: Question about:

    Date: 2012-02-22 02:14 am (UTC)
    marahmarie: (M In M Forever) (Default)
    From: [personal profile] marahmarie
    Usernames floating right is indeed my fault. "Tags" text poking out from home base is, too. I forgot to give you view-specific code to keep other views from embarking on their own journeys into unimaginably bad CSS.

    So let's fix what I broke. Change this: .entry-poster{float:right;clear:right;margin-left:.7em;margin-right:.3em;margin-bottom:.3em;}

    To: .entry .entry-poster{float:right;clear:right;margin-left:.7em;margin-right:.3em;margin-bottom:.3em;}

    And this: .tag ul {display: inline-block;margin-bottom:1em;}

    To: .entry .tag ul {display: inline-block;margin-bottom:1em;}

    To get the page looking more like your fixed-width layout does:

    .month .tag ul {/* you might not need this line since I wrote it before changing the code snippets above; try skipping it */
    display: inline;}
    .month dd{display:block;margin-left:30px;}
    .month dl .tag {max-width:420px!important;text-align:justify;}


    Also, to keep your style sheet smaller so it will load quicker, you can delete my comments (the stuff written /* like this */ in CSS snippets) if you like.

    Oh and edit do you get DW notif emails of new replies like I do, and if so, did you notice what the email formatting is doing to my code? It spaces it out so that the word "margin" is like "ma rgin"....strange. Are you seeing that, too?
    Edited (dw notif email formatting incorrectly) Date: 2012-02-22 02:28 am (UTC)

    So it's DW, not our email programs, it seems...

    Date: 2012-02-22 08:23 pm (UTC)
    marahmarie: (M In M Forever) (Default)
    From: [personal profile] marahmarie
    In my notif email, it looks like this:


    .entry-poster{float:right;clear:right;ma rgin-left:.7em;margin-right:.3em;margin-b ottom:.3em;}

    To: .entry .entry-poster{float:right;clear:right;ma rgin-left:.7em;margin-right:.3em;margin-b ottom:.3em;}


    [...]

    .month dl .tag {max-width:420px!important;text-align:ju stify;}

    It's awesome that it's flaking out for both of us on the word "justify", since that means I can screencap the relevant notif emails and submit them to Support to look at as a possible bug. I love bug-hunting, even when they sort of randomly fall in my lap like this one did. Unfortunately, I won't have time to do a Support request until tonight or tomorrow, but thanks for letting me know you're seeing it, too.

    So, are both your layouts basically sorted out now? I'm not sure if you have any other questions, but if you do let me know.
    From: [personal profile] marahmarie
    OK, just found that problem on this page: http://punditfic.dreamwidth.org/53735.html

    Change this: #canvas {
    overflow: hidden;
    }


    To:

    #canvas {
    overflow-x: hidden;
    }


    Don't thank me, because I know almost nothing about column flow, as I told [personal profile] facetofcathy up above this thread. It's a trick I picked up years ago from studying style sheets by [livejournal.com profile] grrliz, which I have always kept in mind, because before I saw her do it, I never knew you could set x and y coordinates on columns, and it amazed me.

    But, um, edit, while that seems to restore full navigation/scroll capability to the page, in Web Dev it's giving me a second scroll bar, and I can't even figure out what that scrollbar is attaching to at this point. I'll be offline until late tonight or sometime tomorrow afternoon but if it's also giving you double scrollbars, I'll look again to see what else you might try (setting a min-height like this: html body {min-height: 105em;} also works, but maybe that's not a good idea, either).

    Edited (more info/html cleanup) Date: 2012-02-22 08:50 pm (UTC)
    From: [personal profile] marahmarie
    I'm sorry, but at what resolution are you seeing a scrollbar on? I'm on 1440 x 900 and I'm not seeing it until I reduce res to 800 x 600, and even then, your layout displays just a tiny bit offscreen (maybe an inch on the right) which is entirely normal for a fixed-width layout (view my own to see; (see update/edit below).

    Edit/update: I'm not seeing a scrollbar at 800 x 600 either, as it turns out; Web Dev gives me a scrollbar at that res, but not once I close it and view your journal normally - then there's no scrollbar at all.

    Here's your fixed width layout while I'm viewing a single post on it at 1440 x 900 res: http://i.imgur.com/PuKLZ.png (and yes, when you expand the imgur image to full size on a 1440 x 900 screen, your browser might give you a scrollbar to view it with, but my browser does not give me one when I view the actual page live at that res - I have no idea why imgur is doing that).

    Setting a mi-width on a main body element of no more than 730-740px will probably kill any horizontal scrollbars (and 730-740px because, despite there being an 800 x 600 res in use, actual viewport space is never more than 740px, if I recall the Internet discussions on this that I've read correctly), but it may re-introduce the other problems you've had with setting min-widths, so I'm not sure where you want to go with that at this point.

    Also, you still have as an unanswered request for making the sidebar and main body match in height - but the sidebar only cuts off for me now on your Archive by month view - not on Archive by year, not on Tags, not on Main, and not on your posts.

    So I'll need to look at your code more to see what's still going wrong, and I'll need you to tell me what res you're getting a scrollbar on, so I can come up with the best answer here.
    Edited (more info/update/edit/clarity - sorry for flooding your inbox, btw) Date: 2012-02-23 05:21 am (UTC)
    From: [personal profile] marahmarie
    I was trying to edit again when you replied...when I said, "Setting a mi(n)-width on a main body element of no more than 730-740px" I actually meant max-width...I always get dyslexia writing that out, sorry. Also, With overflow:hidden turned on, the bottom of #secondary gets cut off for me on every page where #primary is too short wasn't happening for me on any page views I checked except for Archive by month, but I have to admit I wasn't exhaustive in my search for that problem, so I might have missed something else (or a bunch of something elses). I'll have to add #canvas{overflow:hidden;} back in and look again, but I'm also out of time so I probably won't have an answer until maybe tomorrow night or later (someone called in sick so I actually have to be back to work soon, and I probably won't get online again until much later).
    Edited (html/typo) Date: 2012-02-23 05:44 am (UTC)
    From: [personal profile] marahmarie
    In the meantime (after taking one last look for tonight) I have to concur with [personal profile] facetofcathy that setting a max-width on body might help by killing that scrollbar you've got on all resolutions now, at least until you find a more flexible answer. You can set a max-width of up to 1285px (I tested it at that width on a 1440 x 900 screen) with no horizontal scrollbars.

    Profile

    Dreamwidth style system discussion

    June 2025

    S M T W T F S
    1234567
    891011121314
    15161718 1920 21
    22232425262728
    29 30     

    Style Credit

    Expand Cut Tags

    No cut tags
    Page generated Jul. 2nd, 2025 11:18 am
    Powered by Dreamwidth Studios
    OSZAR »