"Inline-block" and "position" confuse me when I use them with list items. Dreamweaver CS3 isn't helping since it doesn't show the blocks inline but as a stack of elements. I'm interested in learning the best practices for getting block elements of various heights to align along their top edges while also centering within the total available space.
Would you please look at this pared-down code to see if I've done it properly?
http://www.words4it.com/test_block1.html
Here's the CSS:
http://words4it.com/test_block1.css
Thank you
here is the good article about positioning elements
here is the good article about element sizes, margins and paddings
and after all, my short advice about blocks, inline-blocks and floats:
browser has two general models of aligning elements:
inline model, blocks stick to each other horizontally making horizontal lines of blocks with line-breaks between blocks, you may think about it like words in the text. Using this model you operate the following properties:
font-size
line-height
text-align
vertical-align
etc.
block model, blocks stick to each other vertically making vertical stack of blocks, you may think about it like paragraphs in the text. Using this model you operate the following properties:
margin
padding
float/clear
position
etc.
The corresponding model should be used when you are trying to achieve the described behaviour.
There is little exception: several blocks with the same float value (e.g. float:left) can behave very similar to several inline-blocks, the difference is in browser compatibility and thу choise should depend on situation.
Related
I have barely used anything other than vanilla CSS but would really like to do a couple things that aren't working well now:
I have an inner border inside a div, which I want to actually border the inside of the encapsulating div's border (double border). However with window resizing, the inner border will sometimes have too large/small width/height, even when using a measurement like % or vh/vw. I need the inner border (just a div with a border right now) to always stretch/shrink to fit snug right next to the parent border.
Similarly (notoriously) with centering, I imagine there must be a library with the ability to easily center elements vertically and horizontally. Generally I use flex box but would love something that works more consistently, elegantly and intuitively.
What say ye?
I think you're talking about a CSS framework, they help out a lot, especially when working on a major project. I would check out Twitter Bootstrap or Google's Material Design, I personally use mdbootstrap, which is a 3rd party hybrid of the two.
You could give Tacit a try for this particular need.
Tacit is a class-less CSS framework were all you need is just a single <link> statement in your HTML and the web page will have a complete and finished look.
The centering of elements vertically and horizontally come out of the box, and you can skip the usage of <div> elements or the work of defining classes for your elements.
As a side note, here are a few examples of pages that use Tacit, and the only work put into was including the CSS file: http://filfreire.com/, http://www.jare.io/, https://socatar.com/
I've recently been trying to figure out when it is appropriate to use inline-blocks. They seem to be far more useful than just a block element. In fact, an inline-block element seems to be able to do anything a block element can do, but with a little extra styling.
Is there any reason an element with display: inline-block; width: 100%; is any different than an element with display: block;? (Aside from the fact that one is longer?)
I've been researching this topic by reading the w3c recommendation. I can't seem to find a difference.
What you said is pretty much correct: "an inline-block element seems to be able to do anything a block element can do, but with a little extra styling." This is mostly due to the fact that the one thing both have in common is the fact that they are both block containers.
However, there's a catch.
A block box participates in a block formatting context, and an inline-block participates in an inline formatting context (although it establishes a block formatting context for its descendants, just like a block box does under certain conditions). See section 9.4. Basically, this means an inline-block is treated as though it were text, which in turn means most properties that usually apply to text would also apply to an inline-block. These properties include text-indent, text-align and vertical-align, among others.
This can cause undesired side effects which you can easily prevent by not using display: inline-block in the first place. See this question for an interesting example of what can happen.
The box model for inline-blocks also differs somewhat from that of block boxes. Section 10 contains all the nitty gritty details, but the main differences are:
Without the width: 100% declaration, as you may have suspected, an inline-block will shrink to fit its contents.
Because an inline-block flows inline, you can't center it with auto left and right margins. You use text-align: center instead. It goes without saying that it must then be on its own line with no text surrounding it on the same line, but if you're setting width: 100% then this won't be a problem.
Inline-blocks are never affected by margin collapse.
If you're trying to create a block-based layout, you should be using display: block. Generally speaking, when deciding between the two, you should always default to display: block, and only choose display: inline-block if you have a very good reason to (and no, blocking margin collapse is not what I would consider a good reason).
I'd echo everything said by #BoltClock; he makes a lot of good points.
I would also add to this that because an inline-block is treated as text, the surrounding white space is also treated as text and thus comes into play in ways that it wouldn't for a block element. This frequently catches people out when trying to use inline-block for layout. This is probably the biggest 'gotcha' for using inline-block.
Another slightly more subtle point applies specifically in your case, ie when setting width:100%. In this case, you need to beware of which box model you're using, as the standard box model puts your borders, padding and margins outside of the element's width. Thus if you use borders, padding or margin your element will actually take up space a little bit more than 100% width.
This point applies equally to block and inline-block elements, but is more likely to occur with inline-block because the difference is that block doesn't normally need to be set to width:100% because it defaults to expand to fill the width anyway, and without the box model causing it to go over the edge.
To avoid this, you could switch the box model by using box-sizing:border-box, so that the borders etc are placed inside the box, and thus if you ask for with:100%, that's what you'll get. See the MDN box-sizing page for more info.
I am confused. I have just discovered this CSS property: display:box;
I do not understand what it brings to CSS that was not already possible with display: block, inline, inline-block.
Anyone can enlight me on this ?
Thanks in advance.
It's part of the new flexbox module. From the working draft:
In the flexbox layout model, the children of a flexbox can be laid out in any direction, and can "flex" their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent. Both horizontal and vertical alignment of the children can be easily manipulated. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions.
It's still a draft specification, but worth playing with until it's fully implemented by browsers. It will probably allow us to get rid of floats in many cases!
Please note that display:box is already deprecated in favor of display:flexbox.
Last but not least: do not rely on w3schools!
You may find more info here.
Brief summary:
CSS 3 introduces a brand new box model in addition of the traditional box model from CSS 1 and 2. The flexible box model determines the way boxes are distributed inside other boxes and the way they share the available space.
This box model is similar to the one used by XUL (the user interface language used by Firefox). Some others languages use similar box models such as XAML or GladeXML.
Usually the flexible box model is exactly what you need if you want to create fluid layouts which adapt themselves to the size of the browser window or elastic layouts which adapt themselves to the font size.
...
By default, the traditional CSS box model distributes boxes vertically depending on the HTML flow. With the flexible box model, it’s possible to specify the order explicitly. You can even reverse it. To switch to the flexible box model, set the property display to the value box (or inline-box) on a box which has child boxes.
Take a look at the documentation from MDN:
The CSS box-orient property specifies whether an element lays out its contents horizontally or vertically.
For example, XUL box and hbox elements lay out their contents horizontally by default, but XUL vbox elements lay out their contents vertically by default.
HTML DOM elements lay out their contents along the inline-axis by default. This CSS property will only apply to HTML elements with a CSS display value of box or inline-box.
display:box allows:
Flexible distribution of boxes with box-orient, box-direction, box-ordinal-group... You can modify the normal distribution of boxes inside another box not only from vertical to horizontal (can be achieved by inline, inline-block or block with some float trick) but also in a reverse order (horizontal reverse order can be achieved by some float trick) and even in an explicit order.
Flexible sizing: the size of the boxes can be computed as the explicit size (using height, width, max-height, max-width...) or the size of the parent box and available space (with box-flex).
Handle the available space with box-align, box-pack, box-lines...
the new box model can do something the old model can't without additional javascript calculation, not much
I find myself placing a lot of divs, images and content in general with position:relative to stick to the design I'm following.
For example if I wanted to place a form closer to the top I'd put in :
.form_class{
position:relative;
bottom:150px;
}
Since the element keeps its position in the flux, I'd then have to put every other element upwards of 150px with position:relative as to keep the gap closed.
I feel like this is sloppy programming, how do real web integrators position their elements ?
Thanks in advance.
There is a potential problem with using relative positioning.
If you are using the relative positioning to circumvent a problem with a gap, the problem is still there in the background. If the gap comes from a margin for example, then the margin is still there. If you don't know where the margin comes from, you don't know if it's the same in all browsers, and you don't know if any seemingly unrelated changes in the markup might change the margin.
Also, as you mention, you are just moving the gap from the top of the element to the bottom of the element, so you have to keep adjusting all the elements that follow. With each adjustment you are potentially adding another level of insecurity, where the layout might break in another browser.
Most browsers have a developer tool, where you can inspect an element to see exactly what CSS is applied to the element, and what the margins and padding are. You can use that to find out where gaps come from, so that you can remove them at the source instead of circumventing them.
There are a lot of ways to position elements, from margins and paddings, absolute positioning, floats, parent containers, explicit widths and heights. Without seeing your markup it's hard to critic but usually there are better ways than relative positioning. If you want to post some markup try http://jsfiddle.net
I sometimes find myself creating a div which serves no other purpose than to hold another element.
For example when creating a menu, I would create a div and assign it a background colour, position etc. Then within it I would create an unordered list.
I could surely assign all the properties I assigned to the DIV to the UL and not use a div at all.
Any ideas of what is best practice and reasons for it.
Thanks
Zenna
DIVs can be useful for grouping semantically related elements. If you are simply wrapping a single element that is also a block element, then you are simply adding bytes to the file.
No, they are not. The purpose of a div element is to create block level structure in the document. If you can lose them just lose them. Never use divs to solve design purposes, css is for that. Use html elements each like list, data definitions or tables (which were overabused in the past and used as the divs are now for css purposes). The more diverse your HTML knowledge is the less you are using divs all over the place.
I use often divs to keep child-padding/margins from ruining parent-width. But you need to be careful with this type of stuff - you could end up adding a bunch of nonsense.
The real issue is that we are using HTML in ways that its creators had never imagined. The need for 'all those divs' is because some really smart people have found some very creative ways to take a very old standard and do some very modern things with it.
Best practice should be to use as few div elements as possible. If you've got a div elements with only one child, chances are it's a useless div. The div element should really only be used when you need a block element and there is no semantic pre-defined element at hand. This includes grouping elements as Renesis suggests.
In the case of a UL, yes, the DIV is unnecessary. They are both block elements, so anything you can do with a DIV wrapped around the outside you can do directly to the UL itself.
However, because of the Box Model problem with some IE browsers, some people tell you to add these DIVs as a workaround. When you combine padding and width, IE6 disagrees with other browsers about what the final size of the element will be. So one workaround is to put padding but no width on an inner element, and width but no padding on an outer element.
Div's are really a necessary evil without a more semantically rich set of tags.
Their purpose is to server as a generic container. Therefore, I suppose you could say they do their job well.
If you can do what you're trying to do without the additional div, then leave it out. If it's an important part of your design that you can't fix with some clever CSS, then it's still a whole lot better than using tables...
I use DIVS primarily for at least one of two main reasons:
I need it to provide a new physical level of CSS in some way (either child padding inside a fixed width element, a shadow or a double border around an image, etc.)
It logically groups the elements it contains (for future portability and semantics in both HTML and CSS - I.E. "div#menu .label". This way I can use the "label" class several places but have a specific style applied to labels within the "menu" div).
For example, if you were to transfer all attributes to the UL, but then decided you wanted a caption or image above or below the menu but in the same location, you would have to create the DIV again to place the new element inside, and transfer half of the attributes back to it.