CSS: Evenly divide random number of elements in a space



  • I have a kind of issue with CSS. The situation is the following: I have a div which is 60% of the page width and is centered in the page. In this div I have several elements (in this case it's actually an UL with multiple display: block; float: left; LI's). I want the width of each of these elements to be the same, but I want them to fill the entire div (so 60% of the page).

    Imagine the page being 1000px and the div 600px. Each element would then be 100px wide and in total 600px wide filling the div. However I want this to be dynamic... when I change the size of the div (eg to 80%, making it 800px) and when I add or remove elements (eg 5 or 7 items) I want it to still be right. In the previous example, if the div would be 80% and I have 7 elements, I'd want each element to be approximately 114px wide (one 7th of 800px).

    Is this at all possible? =)



  • @pbean said:

    Is this at all possible? =)

    yes, use tables for layout :)



  • @Nelle said:

    @pbean said:
    Is this at all possible? =)

    yes, use tables for layout :)

    table layout make babby cry



  •  I think you can do it dynamically with respect to the size of the outer div. If, e.g. you had four <li>s, you could do "li {width: 25%}.

    I don't think there is a way that you can make that work with an arbitrary number of <li>s though. I think the best you could do is to adjust that width percentage dynamically in your server side code or javascript, where you're generating those <li>s.

     



  • @pbean said:

    @Nelle said:
    @pbean said:
    Is this at all possible? =)
    yes, use tables for layout :)
    table layout make babby cry
    Except the structure you're describing is necessarily tabular. It's why we have tables. The "don't use tables for layout" guideline only applies when you're dealing with with parts of the layout that aren't tabular. You're very clearly talking about a structure with a dynamic set of vertical segments each of equal width. Those are normally called columns. A set of columns, plus a repeating vertical component ("rows") is called a table. Hey! There's an HTML element for that!



  • @Welbog said:

    @pbean said:
    @Nelle said:
    @pbean said:
    Is this at all possible? =)
    yes, use tables for layout :)
    table layout make babby cry
    Except the structure you're describing is necessarily tabular. It's why we have tables. The "don't use tables for layout" guideline only applies when you're dealing with with parts of the layout that aren't tabular. You're very clearly talking about a structure with a dynamic set of vertical segments each of equal width. Those are normally called columns. A set of columns, plus a repeating vertical component ("rows") is called a table. Hey! There's an HTML element for that!
    Quiet, you fool!  The W3C will have your head for this treason!  This goes entirely against their long-term goal of having only two possible XHTML elements: <inline> and <box>, with everything else handled in CSS.



  • @bstorer said:

    @Welbog said:
    @pbean said:
    @Nelle said:
    @pbean said:
    Is this at all possible? =)
    yes, use tables for layout :)
    table layout make babby cry
    Except the structure you're describing is necessarily tabular. It's why we have tables. The "don't use tables for layout" guideline only applies when you're dealing with with parts of the layout that aren't tabular. You're very clearly talking about a structure with a dynamic set of vertical segments each of equal width. Those are normally called columns. A set of columns, plus a repeating vertical component ("rows") is called a table. Hey! There's an HTML element for that!
    Quiet, you fool!  The W3C will have your head for this treason!  This goes entirely against their long-term goal of having only two possible XHTML elements: <inline> and <box>, with everything else handled in CSS.
    By then browsers will support all of the nasty display: table CSS options that accomplish the same thing as the table tag except much less readably. He'll still need to make a table, though.



  • @Welbog said:

    By then browsers will support all of the nasty display: table CSS options that accomplish the same thing as the table tag except much less readably. He'll still need to make a table, though.
    Nonsense!  Instead of a table, he could just do something elegant, like this:

    <div class="table">
      <div class="table-row">
        <div class="table-data">A</div>
        <div class="table-data">B</div>
        <div class="table-data">C</div>
      </div>
      <div class="table-row">
        <div class="table-data">1</div>
        <div class="table-data">2</div>
        <div class="table-data">3</div>
      </div>
      <div class="table-row">
        <div class="table-data">apple</div>
        <div class="table-data">banana</div>
        <div class="table-data">cranberry</div>
      </div>
    </div>
    

    Now isn't that so much better than those yucky tables?



  • @Welbog said:

    Except the structure you're describing is necessarily tabular. It's why we have tables. The "don't use tables for layout" guideline only applies when you're dealing with with parts of the layout that aren't tabular. You're very clearly talking about a structure with a dynamic set of vertical segments each of equal width. Those are normally called columns. A set of columns, plus a repeating vertical component ("rows") is called a table. Hey! There's an HTML element for that!

     

    Well, I may be wrong, but I always understood the W3's canon meaning of <table> to be about "semantic" tables, more similar to database tables than layout grids. The idea being (hold the face-palming for a minute) that browsers could do things on a <table> like sorting the rows according to certain columns, export the whole thing to excel, put it into a database, etc.

    By that definition no table with a dynamic number of columns would be "valid", for the same reason you wouldn't want your application modify your database schema on-the-fly.

    Then again, this meaning might be "retconned" by the W3C long after the element was introduced. At least I've no idea how attributes like colspan and cellspacing would fit into that scheme...

    Anyway, I think the root* WTF is that we're supposed to solve all problems with CSS when CSS itself is lacking so many things. This whole struggle is getting creepily similar to the Cristian religion...

     



  • @bstorer said:

    This goes entirely against their
    long-term goal of having only two possible XHTML elements:
    <inline> and <box>, with everything else handled in CSS.

     

    <rant>

    Honestly,
    I don't think this would be such a bad idea, actually. Exact you don't
    have two elements but could use any XML elements you like and do all
    the styling with (a successor of) CSS. 

    I
    mean, seriously, what
    is HTML supposed to actually be?

    A semantic expression language? Pretty
    much all semantic features are completely unuseable by now.

    A
    TeX-Style layout-guide language? With so many hacks and another
    language ready to describe the layout?

    An application platform?
    Apparently, according to some people, if you like the elegance of
    declarative and imperative syntax randomly mixed together with the
    useabillity of the trusty debugging technique of "NOT".

    So, no idea actually...

    </rant>

     

     



  • Navigation is not tabular data. I will not use tables only to accomplish layout purposes. Besides, HTML tables have a lot of quirks themselves.

    I have now 'solved' (aka worked around it) by having PHP divide 100 by the number of items and put that as width percentage of the elements, although this is also buggy. Six items is 16.6% each which leaves some empty space because it adds up to 99.6%. While specifying 16.6666666% works brilliantly in Firefox, IE wraps the last element to the line below).

     

    @PSWorx said:

    Exact you don't have two elements but could use any XML elements you like and do all the styling with (a successor of) CSS.
     

    Have a look at any of the new web sites by Blizzard (like the new battle.net site, the world of warcraft sites, etc). They are all made in XML and use some XML techniques to style it and display it correctly in the browser (is that XSLT?). However because some browsers don't support that, it's still plain HTML for them (I wonder who made the decision to actually make two identical websites using different techniques).



  • @pbean said:

    Have a look at any of the new web sites by Blizzard (like the new battle.net site, the world of warcraft sites, etc). They are all made in XML and use some XML techniques to style it and display it correctly in the browser (is that XSLT?). However because some browsers don't support that, it's still plain HTML for them

    Yeah, XSLT is a pretty nice idea in that direction (even though I can never decide if Blizzard's approach counts as genious or madness). However, it's support is staggering already (I think Chrome dropped it again), there's no way to make life-changes to the DOM (as with CSS) and it's still clunky as hell to use :)

    I think it would be awesome if browsers supported XQuery, but I quess that will stay a dream for a long time...

    @pbean said:

    (I wonder who made the decision to actually make two identical websites using different techniques).

     

    I don't think the HTML and XML/XSLT versions are maintained seperately. It's probably the same source internally, only in the first case the XSLT runs on the client and in the second on the server.

    At least I hope that...



  • @pbean said:

    Navigation is not tabular data. I will not use tables only to accomplish layout purposes. Besides, HTML tables have a lot of quirks themselves.
    You realize there's no legitimate reason to not use a table in this situation, right? One objective reason to not use tables for layout is because screen readers read them in order. But you'd only be using it for a little navigation table and not the whole page, so that's fine. Pretty much all the other reasons are just zealotry. Why would you write a server-side function that calculates percentage values when you could just toss it into a table and have the client do it for you? How can you possibly think your solution is better than mine when you have to do so much work to reimplement something that already exists and is easier to use? WTF?


  • Discourse touched me in a no-no place

    @Welbog said:

    You realize

    They don't

    @Welbog said:

    there's no legitimate reason to not use a table in this situation, right?

    Tables are evil. Don't use them. Because they're evil. CSS is the solution to not using tables. In every circumstance. Circumztance.

    Evar.

    Lost cause - all of them. Or trolls.

    Feel free to decide.



  • @PJH said:

    @Welbog said:
    You realize
    They don't
    Why would pbean come to this forum and ask a question and then ignore the advice he gets from it?

    @PJH said:

    Lost cause - all of them. Or trolls.
    I'm leaning toward extreme dumbassness.



  • I will not misuse HTML elements just because the whole concept of HTML tempts misuse unless there is no other way. Also as I mentioned tables often have curious quirks, especially when used for laying out things like navigation and behavior can vary greatly between browsers. In this case, I much rather use the server side solution work around.

    I do appreciate any advice I get though I won't just simply follow them.



  • @pbean said:

    I will not misuse HTML elements
    Sounds to me like you're specifically not using an element that was designed to do exactly what you want it to do, but you're not going to use it because someone once told you it was a bad idea. Let me guess, you'd never consider ever using a goto because Sun told you they're bad for you?



  • @Welbog said:

    Let me guess, you'd never consider ever using a goto because Sun told you they're bad for you?
    I don't use them because Dijkstra said they're harmful, and he was a pretty good baseball player.



  • Tables weren't exactly designed to lay out navigational components of a website. I explained why I don't want to use a table in this specific case. Nobody told me that tables are a bad idea and that's not what I think about tables.



  • you ask for tabular layout without using tables, you just don't realise it yet

    i've usen this technique quite often:

    ul.menu > li {
      display: table-cell;
    }
    ...
    <ul class="menu">
      <li>A</li>
      <li>B</li>
      <li>C</li>
    </ul>

    this will make <li/>-s side by side, equal width by default. you can control the width ofcourse



  • I think the real solution is to just abandon this weird scalable-nav idea. I'm not sure it works well in Safari -- but the law of interfaces disctates that you can't judge an interface before it's used, (even though I will judge it in the last sentence of this post, because I'm that guy).

    Welbog, you're right in everything you say. It's very easy to implement this layout concept using tables.


    pbean, you're right in everything you say. It's not "right", and tables have some of the most annoying cross-browser quirks, down to IE sometimes just flat-out ignoring what you specify. Percentages are mostly useless. As for decimals, IE tends to ceil, while FFX tends to round.

    I'd go with client-side calculating in JS, or just give in and use a table; quirks or correctness be damned. In any case, PHP is not the right place for that sort of calculation stuff, and I think keeping your application source code in order is more important than any quirky idea you use to make some irrelevant part of the interface work in a quirky way*.

    PS,

    @Resistance said:

    I've used this technique quite often:

    ul.menu > li {
    display: table-cell;
    }
     display:table-cell is not supported by IE6 or IE7.
    The > selector is not supported by IE6, and only in IE7 standards mode.

     

     

    *) an interface where the navigation items change size is considered quirky and a big frown-upon in my book. It's akin to that joke where you try to click a button, and it jumps away when you touch it. Your buttons must remain in a predictable location.



  • @dhromed said:

    display:table-cell is not supported by IE6 or IE7.

    The > selector is not supported by IE6, and only in IE7 standards mode.

    Why give up on standards because of one black sheep? IE has methods for dealing with its own quirkiness (take for example, the <!--[if IE]> comments).



  • @Resistance said:

    @dhromed said:
    display:table-cell is not supported by IE6 or IE7.The > selector is not supported by IE6, and only in IE7 standards mode.
    Why give up on standards because of one black sheep? IE has methods for dealing with its own quirkiness (take for example, the <!--[if IE]> comments).
    Why follow standards the most common browser doesn't support? Do you not want users to be able to see your webpages?


Log in to reply