views:

512

answers:

5

I've just come to think about this issue which really hasn't bothered me at all since everything works just fine. Anyway, what does the community think about the following:

Say I have textboxes, dropdownlists and submit buttons. They are all inline-elements. Which means that "officially" margin, padding, width and height properties should be ignored (in practice not really). If I were to go the right way to set the height to a button I would write something like display:block and then define the height. But there are considerations that a block level element would expand itself unexpectedly so I'd better set its width to some fixed value. The problem is that I don't know its width since it can be dynamically defined upon the text of the button.

Another scenario: I wish to create a menu via <ul> and <li>. I want to have it horizontally aligned, with some items grouped to the left, and with a few stretched to the right. Both <ul> and <li> are block-level elements. Since I wish my menu to take all available horizontal space, then to play with the items height and to have menu items pushed to both sides, the block-mode is fine to me. I'll just use float:left and float:right to achieve the task. But again use should kinda set a width to menu elements, since they are block elements. I do not know their widths because the text of the items can vary. But it seems that everything is rendered just fine as it is.

I have not noticed any issues with both inline elements forced to render as block elements without being floated or width set, or with the list item example. It works just fine in IE7, FF3, Opera 9 and Safari whatever the current version is. The question remains: should I worry about these inline-to-block elements or real block elements floated but without the width set or just leave everything as it is? Am I missing something or is it just one more of those things you simply should not expect to get right?

Would very much like to hear your opinions...

A: 

You're getting yourself a bit over stressed I think :)

Check out these links, especially 9.4, 9.5 and 10.3. And ctrl-f "inline-block"

annakata
A: 

If we take the "Official" line that you mention then life is easy as we don't need to worry about widths, heights and on for these elements.

Don't think pixel perfect, don't worry about the minutia of presentation, follow the standards, allow the browser & its users to define styles...

(if only it was really that straight-forward in the "un-Offical" real-world)

bochgoch
+1  A: 

Say I have textboxes, dropdownlists and submit buttons. They are all inline-elements. Which means that "officially" margin, padding, width and height properties should be ignored (in practice not really). If I were to go the right way to set the height to a button I would write something like display:block and then define the height. But there are considerations that a block level element would expand itself unexpectedly so I'd better set its width to some fixed value. The problem is that I don't know its width since it can be dynamically defined upon the text of the button.

Unless you're referring to Internet Explorer's box model quirks, you shouldn't be worried about anything expanding or contracting unexpectedly. As long as you take care of normalizing for browser variation, you will be fine. If you have an unexpected and unwanted side-effect along the way to design glory, you debug it, as that is programmer error you contend with. CSS can be quirky, but that is not an appropriate excuse 95% of the time for most major browsers. The other 5% we don't talk about.

This is how I understand your problem:

You want a menu of floated <li> so that you have a horizontal menu that spans the width of the viewport (what your user sees 'in the browser window') to be consistently the full width of the viewport.

It sounds like you are thinking in terms of a fixed width design, when really what sounds like it would suit your purposes is a fluid-width design. This means you create a design that is 'elastic' and expands and contracts relative to the size of the user's browser window. If you created your design anticipating pixel widths being set on each element, you can probably find an elegant way to maintain a fluid-width header and navigation, but have a fixed-width main content area. You can find a happy medium without a full redesign. This walkthrough will likely be what you're looking for. A good explanation of the terms fixed-width and fluid-width can be found here if you're unfamiliar with the jargon and want a closer look at these ideas.

One more for the road:

Setting a width on all floated elements is not only recommended, but is a part of the CSS2 standard as per W3C.

  • Angelina
Angelina
A: 

Ok, I suppose my question was not understood correctly. What will happen if i do not set width for floated boxes? I can't set it, I don;t know it. because it depends on the content. Will all boxes just shrink to their content width? This is how it's working in practice. And i'm satisfied with it. Is there any official confirmation that this behaviour should be expected?

Added: I foudn something interesting here: http://www.webmasterworld.com/css/3811603.htm

I suggest checking the recommendations for a more technical explanantion for the differences, but simply put, the behaviour of floats changed between css2(1998) and css2.1(a couple months of 2005, and then 2007). Per css2 it was mandatory to set a width on floats, while the "shrink-wrapping" you see in ff3 is css2.1. That means pre-Jul/2007 browsers are conforming to the recommendation relevant to their time of manufacture when they stretch div#container the full viewport width. (Which doesn't explain Opera, but it always has done its own thing.)

If so, then i'm contended. As I mentioned, it works in current IE7, FF3, Opera 9 and Safari.

Any more comments?

it will "shrinkwrap" and this is the behaviour expected and defined in the links I posted
annakata
The only browser I'm aware of that stuck with the CSS 2.0 behaviour (full width, non-shrinkwrap) was IE5/Mac. Which is not worth worrying about today, and its old layout engine (Tasman) will almost certainly have much bigger rendering problems than just floats.
bobince
@annakataThank you, I looked through you links, but maybe too quickly. Will do a more thorough reading when I'm home in the evening.
A: 

(assuming if i understand you problem)

In most cases you don't need to set width on list items. But (yes, there is a but here) if you have a link with display:block (let say you want to use sliding door) you have to do a little trick:

the html:

<ul class="menu">
    <li><a href="#">Link</a></li>
    <li><a href="#">Link</a></li>
    <li><a href="#">Link</a></li>
</ul>

And CSS:

.menu li {
    float:left
}
    .menu li a {
     display:block;
    }
    /* ===================== */
    /* = and the IE6 trick = */
    /* ===================== */ 
    * html .menu li a {
     width:1%;
     white-space:nowrap;
    }

If you don't do like this, then the LINK will be stretched to all parent. The LINK not the LIST Element ;) Doing this way you set a "min-width" to IE6 and you won't have any other problems.

Ionut Staicu
That's funny. I have links inside that are exactly blocks....I tried to set the width:1px to LIs, but that collapsed the menu into a tiny mess.Thanks for a great hint!But really, do I have to worry about IE6 these days? I haven't seen it anywhere since maybe two years already...
Yes, you still have to worry about IE6. I hope this is the last year of IE6 :D
Ionut Staicu