SitePoint Sponsor

User Tag List

Page 5 of 5 FirstFirst 12345
Results 101 to 119 of 119
  1. #101
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,526
    Mentioned
    182 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by noonnope View Post
    i confess. my google search was: inline-table bugs. but that didn't end up as expected. i actually came across another thing.
    I already explained this in the quiz:

    The reason that this fixes the whitespace bug is down to the rules contained in the specs for table elements here.

    As I understand it the method works because the browser has to construct anonymous elements to make the table complete and so in effect it constructs anonymous table-rows and anonymous table cells around the inline-blocks. I believe its rule 5 here that specifically kills the whitespace in this structure as white text nodes are explicitly set to display:none in this structure.

    i believe the answer is indeed this: inline-block is useless. and since the problem was the use of inline-block in the first place, the answer is always replace it with table-cell.
    I'm afraid that you may have misunderstood because that changes the element to behave like a table-cell in all aspects and the elements will not wrap to the next line as they do with display:inline-block.

    display:table-cell is fine if you want cell behaviour exactly but doesn't satisfy the requirements of the quiz or indeed the OPs original question and isn't suitable for centered wrapping menus.

    Just try your code in the OPs original post or in the quiz and you will see completely different behaviour.

    display:inline-block is the only way to accomplish this.

  2. #102
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    I already explained this in the quiz:
    yes you did. but in "reverse". it implied but didn't point. you know, like for dummies and it was never as clear as this:
    Code:
    <DIV style="display: table-cell">
    </DIV>
    <DIV style="display: table-cell">
    </DIV>
    The above example would have a table and a table row implied around it.
    simple concepts are the mark of genius.

    you're saying: only put the table to generate table row and table cell.
    i'm saying (not really me, i'm just quoting): only put the table cell to generate table row and table.

    the later just feels more right. and in tone with how optional tags and optional elements are described in specs. you can omit the parent (html, body), putting the child in will generate it. but by putting in the parent, the child is not implied to be generated.

    and i was doing the search today, at work. for bugs not explanations. to dismantle the inline-block solution, not to explain it.


    ******************************************************


    Quote Originally Posted by Paul O'B View Post
    I'm afraid that you may have misunderstood because that changes the element to behave like a table-cell in all aspects and the elements will not wrap to the next line as they do with display:inline-block.
    indeed it does not wrap. i see it as a good thing. if it's a horizontal menu, it should not expand multiple lines when viewport shrinks. think about multilevel horizontal menus.


    ******************************************************


    Quote Originally Posted by Paul O'B View Post
    display:table-cell is fine if you want cell behaviour exactly but doesn't satisfy the requirements of the quiz [...]
    a quiz is a quiz. but still...
    |
    \/
    Quote Originally Posted by Paul O'B View Post
    However, I will say that if you do have good alternative or different methods of producing the above then we would still like to see them even if they don't precisely fit into the quiz aspect.
    /\
    |


    ******************************************************


    Quote Originally Posted by Paul O'B View Post
    [...] or indeed the OPs original question [...]
    what was the OP's trouble:
    space between inline items still remains
    setting display:table-cell fully covers it. i don't see any "keep the inline-block" requirement.


    ******************************************************


    Quote Originally Posted by Paul O'B View Post
    [...] and isn't suitable for centered wrapping menus.
    you need to give some reasons.


    ******************************************************


    Quote Originally Posted by Paul O'B View Post
    Just try your code in the OPs original post [...]
    ok, here it is.
    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Untitled Document</title>
    <style type="text/css"> 
    *{margin:0; padding:0; list-style:none;}
    body {text-align:center;}
    ul {display:inline-block;}
    li {display:table-cell; padding:10px; background:silver;}
    li a{font-size:12px;}
    </style>
    </head>
    
    <body>
    <ul>
    	<li><a href="#">Item</a></li>
      <li><a href="#">Item</a></li>
    	<li><a href="#">Item</a></li>
    	<li><a href="#">Item</a></li>
    	<li><a href="#">Item</a></li>
    </ul>
    </body>
    </html>

    ******************************************************


    notice in the code above that i can use inline-block just fine. just for other purposes. i'm not absurd in my rejection of an idea:
    Quote Originally Posted by Paul O'B View Post
    display:inline-block is the only way to accomplish this.

    ******************************************************


    i'm not petty and i can recognize when ANY person proves to be right:
    Quote Originally Posted by deathshadow60 View Post
    Since as a rule I would never put inline-block on a LI since IE knows it not... usually when I need this there are ANCHORS inside the LI and I'd probably never use inline-block on anything other than a menu.
    thank you ds60 and bravo... for your knowledge and instinct

  3. #103
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,526
    Mentioned
    182 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by noonnope View Post

    indeed it does not wrap.
    As I said it then fails on two points it does not wrap and it also does not fix the problem related to inline-block which I believe was the OPs original intention.

    Display:table-cell is a completely different behaviour and has nothing to do with the way that inline-block works and is used. The table-cell elements will not wrap and remain centred and are therefore not suitable for a fluid layout or for many other types of layout (e.g a centered gallery in a fluid layout).

    Display table-cell is useful for other situations where you don't want elements to wrap. Both have their uses but both are different and one isn't a cure for the other.

    I could do something similar with floats but it isn't a cure for the inline-block problem and would have slightly different characteristics just like table-cell does.

    There's nothing wrong with the table-cell approach when the layout requires it so I don't really see where this discussion is going. It's just another method for doing something else. It just doesn't replace inline-block in any form.

    ok, here it is.
    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Untitled Document</title>
    <style type="text/css"> 
    *{margin:0; padding:0; list-style:none;}
    body {text-align:center;}
    ul {display:inline-block;}
    li {display:table-cell; padding:10px; background:silver;}
    li a{font-size:12px;}
    </style>
    </head>
    
    <body>
    <ul>
        <li><a href="#">Item</a></li>
      <li><a href="#">Item</a></li>
        <li><a href="#">Item</a></li>
        <li><a href="#">Item</a></li>
        <li><a href="#">Item</a></li>
    </ul>
    </body>
    </html>
    Ok add another 50 list items and see what happens! The page will be fixed massively wide and you will have to scroll horizontally to see the items. Next try it with display:inline-block to see the different behaviour.

    Both are different and both would be used in different situations.

  4. #104
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    the discussion is going the way: "OP doesn't need to fix inline-block because OP doesn't need inline-block to begin with".

    that's my own conclusion. there is a viable alternative, other than the tag chaining or white space manipulation.

    instead of
    • using display:inline-block on the child elements
    • and use css to manipulate white space among them
    • and then set the parent to display:table where that css fails on them (to force child element behave like table-cell)


    simply use
    • display:table-cell on the child elements
    straight up and lose the roundabout. and that's all.

    (by the way, using display:table on the parent to make the child behave like table-cell is a thing that somewhat overrides your idea of not changing the display:inline-block on the child, don't you think?)


    **************************


    Quote Originally Posted by Paul O'B View Post
    Ok add another 50 list items and see what happens! The page will be fixed massively wide and you will have to scroll horizontally to see the items.
    about that. remember what you said
    Quote Originally Posted by Paul O'B View Post
    Now that example is just plain silly [...]. That's a whole different discussion.

    I can't actually believe that you gave that as an honest example!

  5. #105
    Ripe Tomatos silver trophybronze trophy Rayzur's Avatar
    Join Date
    Jun 2007
    Location
    Texas
    Posts
    4,174
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    i didn't put ie6-7 hacks there to keep it clean and clear.
    Quote Originally Posted by noonnope View Post
    • display:table-cell

    and
    lose the roundabout. and that's all.
    All but IE6/7 that is! Even though you have stated that you excluded them it would require more CSS than the inline-block method to bring it back to working order for them. We also loose the option of setting vertical margins when they wrap. I won't mention horizontal margins since the whole point of this thread was to get the LI beside each other.

    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Untitled Document</title>
    <style type="text/css"> 
    
    body {
    width:50%;
    margin:0 auto;
    text-align:center;
    border:1px solid #000;
    }
    
    ul {
    display:inline-block;
    margin:0;
    padding:0;
    list-style:none;
    }
    
    li {
    display:table-cell;
    margin:10px 0; /*sorry no can do in table-cells*/
    padding:10px;
    background:silver;
    }
    
    </style>
    </head>
    
    <body>
    <ul>
        <li>Item One</li>
        <li>Item Two</li>
        <li>Item Three</li>
        <li>Item Four</li>
        <li>Item Five</li>
    </ul>
    </body>
    </html>
    As Paul stated,
    It's just another method for doing something else. It just doesn't replace inline-block in any form.

  6. #106
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    no, ie6-7 don't need but the same display:inline used before.

    wrapping. on a menu. not desirable. again, think about multiline menus.

    oh, and i can do what you say i can't (wrapping out of the question, since in the example you provided the white space bug has no part; or even a sensible place in this thread):
    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Untitled Document</title>
    <style type="text/css"> 
    
    body {
    width:50%;
    margin:0 auto;
    text-align:center;
    border:1px solid #000;
    }
    
    ul {
    display:inline-block;
    margin:0;
    padding:10px; /*no problem, i can do it here*/
    list-style:none;
    }
    
    li {
    display:table-cell;
    margin:10px 0; /*sorry no can do in table-cells*/
    padding:10px;
    background:silver;
    }
    
    </style>
    </head>
    
    <body>
    <ul>
        <li>Item One</li>
        <li>Item Two</li>
        <li>Item Three</li>
        <li>Item Four</li>
        <li>Item Five</li>
    </ul>
    </body>
    </html>

    maybe you misunderstood. i said: replace inline-block for this example. for the better table-cell. and it does replace it. moreover, i've used inline-block my self. on the <ul>.


    your logic must be screaming somehow, i hope:
    by the way, using display:table on the parent to make the inline-block child behave like table-cell is a thing that somewhat overrides your idea of not changing the display:inline-block on the child, don't you think?

  7. #107
    Ripe Tomatos silver trophybronze trophy Rayzur's Avatar
    Join Date
    Jun 2007
    Location
    Texas
    Posts
    4,174
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Padding is not a REAL substitute for margins.
    wrapping out of the question
    See that's the problem, we can create many versions that have nothing to do with the OP's code.

    no, ie6-7 don't need but the same display:inline used before.
    The OP was using inline-block for a reason: It gives the option of setting dimensions and using REAL margins on either axis.
    (At least that's the reason I use inline-blocks)

    Seems you have abandoned you tag chaining and gone off chasing other whimsical notions.

  8. #108
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    no i didn't.

    the
    • "formatting must be free of constraints so that i can do whatever i like with it, but i will follow no formatting rules but the ones i care since there are no such rules"

    and
    • "you can't impose rules on formatting to prevent stupid bugs because i will try and find a way to break it so that you will look for stupid css solutions"
    are really shady. if i was to use inline-blocks, i would still use tag chaining to remove the white space bug, if that bug was still... bugging me.

    but i did manage to understand, from other's knowledge (ds60 for example, and i'm not petty but admit he was on the right track), an alternate solution for the OP, that doesn't require inline-block on <li>s. which i'm sure it doesn't bother him at all. and i'm sure it wasn't even a requirement to begin with. that was only for the quiz.


    again, one solution for the OP has these steps:
    • set display:inline-block on <li>s
    • use css white space manipulation declarations to remove the white space bug in some UAs
    • use display:table on the <ul> parent to impose a table-cell behaviour on the <li>s to remove white space bug in some other UAs


    that makes this solution look like a like a roundabout.



    my understanding of an alternate solution is simpler, and goes straight to the 3rd step on the first solution:
    • set display:table-cell in <li>s



    this simple one-step makes the first two steps in the first solution look redundant and somewhat illogical.



    i know it's not fair to say that, but it seems you're ignoring the obvious and have gone chasing whimsical notions, w/o a hope of ever turning back.

  9. #109
    Ripe Tomatos silver trophybronze trophy Rayzur's Avatar
    Join Date
    Jun 2007
    Location
    Texas
    Posts
    4,174
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    my understanding of an alternate solution is simpler, and goes straight to the 3rd step on the first solution:
    • set display:table-cell in <li>s

    this simple one-step makes the first two steps in the first solution look redundant and somewhat illogical.
    That's just it, it is an alternate solution that imposes different display rules on me. Rules that I may not want, hence the whole reason I would have been using inline-blocks in the first place.

    We have already explained what inline-blocks can do that table-cells can't.

    an alternate solution for the OP, that doesn't require inline-block on <li>s. which i'm sure it doesn't bother him at all. and i'm sure it wasn't even a requirement to begin with. that was only for the quiz.
    You will have to take that up with the OP since I can't speak for him. But yes you are correct, I set the rules for the quiz using inline-block in order to show how to overcome the Webkit bug while retaining the normal behavior that inline-blocks give us when that is what we WANT.

    i know it's not fair to say that, but it seems you're ignoring the obvious and have gone chasing whimsical notions, w/o a hope of ever turning back.
    No, I understand what you have done with the table-cell and it could work for someone somewhere at sometime. It just has nothing to do with inline-block behavior as we keep pointing out.

  10. #110
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by noonnope View Post
    the discussion is going the way: "OP doesn't need to fix inline-block because OP doesn't need inline-block to begin with".

    that's my own conclusion. there is a viable alternative, other than the tag chaining or white space manipulation.

    **************************


    Quote Originally Posted by Rayzur View Post
    That's just it, it is an alternate solution that imposes different display rules on me. Rules that I may not want, hence the whole reason I would have been using inline-blocks in the first place.


    No, I understand what you have done with the table-cell and it could work for someone somewhere at sometime. It just has nothing to do with inline-block behavior as we keep pointing out.


    **************************


    it seems we begin to see eye to eye

  11. #111
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    wrapping. on a menu. not desirable. again, think about multiline menus.
    scrolling. on a menu. also not desirable (unless your page has a fixed min-width at some point anyway). People don't mind scrolling down nearly as much as they mind scrolling sideways.
    inline-block if whitespace isn't an issue anyway and you want one css for many sizes:
    large
    medium
    small

    You can get away with display: table if it's small enough though:
    large
    medium
    but ultimately has to be changed to something else at small sizes then:
    small
    (last one tested well on the phones around the office, but they're all "smart" ... needs more testing.)

  12. #112
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    scrolling. on a menu. also not desirable.
    yes. desirable. your simple example disregards the fact that most menus have drop downs. and some are multilevel.

    your's is a showcase for severely simple menus.

    accessibility means nada in this case if your drop down multilevel menu would wrap

  13. #113
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    your simple example disregards the fact that most menus have drop downs.
    Source?

    But yes, if there are dropdowns, the menu should not wrap. Yet another reason developers should try to avoid dropdown menus if reasonably possible.

  14. #114
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    But yes, if there are dropdowns, the menu should not wrap. Yet another reason developers should try to avoid dropdown menus if reasonably possible.
    i'm sorry Sp, but that's just hilarious i've used drop down menus on dos programming but i must not use them on gui web?

    you say i should not use some features because there are NOW devices that MAY NOT be able to handle the results properly? that my page should be kept under a certain standard because of the penalty some devices may impose on it?

    going down this road, you should not use images wider than, i don't know, 100px?, restrain from using words bigger than, i don't know, 10 letters?, on <h1>, never use sidebars...

    mind you, that's a list on a short notice, incomplete as i've yet to know what width do you think i should cater for, and what feats i have to rub down for it, instead of providing a normal rich browsing experience.

    and mind you, technology moves fast. in a year, or less, all your current "worries" will be forgot.

    it seems to always come to this: all has been done before web. resolutions for gui os, zoom capabilities for gui applications, resizing for images and video. web and web devices are not bringing any new challenges. there are only old challenges that seem new due to the web hype and improper implementations. and there are already answers for all of them. a little research will keep you from rediscovering America.

  15. #115
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    http://www.useit.com/alertbox/20001112.html this is why I try to avoid them, though megadropdowns get a better score

  16. #116
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i'm a little confuse. from what little i understand, it seems that in the link you provided, the author tries to mouth <select> element but he words out drop down menu, creating a confusion. and he advices to limit the number of <option> elements for it. which i'm all for.

    but isn't that for drop down menus some old recommendations are saying to REPLACE <select> with <ul>? it appears the article and the author experience are previous to them. and we're talking <ul> menus not <select> menus.

  17. #117
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    He means ul menus too (back then there were a lot of people doing these DHTML select-drop-down menus too for some reason). His issue with them are the small mouseover area and multiple levels. He rates the mega-menus better because of their larger mouse-over area, but I find them harder to work with CSS-alone (they can be, but not well... they pretty much need javascript) and of course they are large so also get in the way (again, Javascript is usually necessary to prevent accidental activations as the mouse moves around the page).

    I used to do a lot of drop-down menus when I first started, but the last few years I have looked at ux research and decided to try to limit them. Dropdowns are actually more user-friendly than lots of click-click-click through steps, but that's on downloaded applications and OS software, where the programmer has control over the interface client. On the web you have all those issues with users having crappy mice, Javascript is unknown, browser may not keyboard correctly if a link is off-screen... bleh.

    So I go for menus who are wrappable and hopefully can avoid dropdowns. This way I can ensure better compatibility with screens (menu can wrap) and I don't have to worry "does this user have a touch screen? oh noes" and can think better ways for users to navigate the site.

  18. #118
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    For anyone interested in PDFs, semantics and accessibility:
    http://www.appligent.com/talkingpdf-...ageisapainting

  19. #119
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,319
    Mentioned
    462 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    For anyone interested in PDFs, semantics and accessibility:
    Thanks poes; I iz!


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •