CSS - Difference between display:(inline|block) and display:box? - css

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

Related

css ignores "display: inline" on zoom

When I zoom, css ignores "display: inline"
problem2 http://screenshu.com/static/uploads/temporary/bc/r3/cf/ae0b2a.jpg
problem3 http://screenshu.com/static/uploads/temporary/91/ll/n6/w2zxbe.jpg
The property you have assigned is not being ignored. That is the correct behaviour for display: inline. The reason this is happening is because upon zooming, the parent container is shrinking relative to its children and the child items do not have a constraint which disallows them to break to a new line. In order to continue being displayed without overflow, one of them displays itself on a new line.
In my opinion, the best option for achieving what you are trying to do is the flex box module. It is a module that was introduced with CSS3 and provides a solution for situations like this one. How to use the flex box module is explained very well here: https://css-tricks.com/snippets/css/a-guide-to-flexbox/. The property you would need to apply to the children in the parent container is:
flex-wrap: nowrap;
This allows for the items to all be displayed on a single line.
This is, of course, not the only solution.
You could also set the parent container's minimum width to be greater than or equal to the sum of the widths of the children it is containing. Yet another option would be be to set the children's widths equal to a percent of their parent container. There are probably even more methods but again, flex box was designed for this sort of situation and offers a very clean and clear solution for not only this specific case, but for a vast number of display problems that have plagued web page styling in the past.

Polymer Nested Core-Scaffold and Multiple Vertical Scrollbars / Scrolling Extent Issues

I'm having some trouble with the current layout of my polymer site, specifically with regards to nested components and their associated scrollbars. I'll preface this by stating that by absolutely no means am I a CSS guru. I wish I was because I probably wouldn't be struggling with this as much as I am. Also feel free to jump straight to the jsbin URL as my issue may become apparent.
The situation:
I currently have a nested core-scaffold element, whose main content often requires vertical scrolling and thus it's vertical scrollbar becomes active as required. However, as it is nested, it's container(s) can also have scrollbars enabled. Ideally, I'd like a single scrollbar on the highest level element which can scroll the scaffold's content to it's full vertical extents, yet also cause the topbar to slide away as it does now when scrolling down. I've also noticed that the height of the scaffold's main content is determined by the first page that is loaded into it. Subsequent page loads with different heights does not cause the scrollbar height extents to change accordingly.
Please note that I've simply inserted an iframe loading external content into the scaffold's content section for the purpose of this jsbin demo. My actual site loads a bunch of data driven collapsible height containers within the content pages, wrapping horizontally as needed. Due to their collapsibility, their containing page therefore has a dynamic height. That height can vary from page to page as container heights within them vary.
Here is the jsbin. Whoever can remove me from this css hell will be considered my hero...
http://jsbin.com/muniqi/1/
In my initial jsbin sample code, you'll notice I have specified core-pages height as '100vh' the top level polymer element (i.e. my-app-element). The second level polymer element (i.e. my-scaffold-page-element), loads within the aforementioned core-pages. Therefore, the nested scaffold element's maximum height is 100vh. Further down the chain, when the scaffold-element's main content area's height flows past its host's height limitation, it caused a secondary 'inner' scrollbar to appear, which has a different vertical extent than the original outer scrollbar...so trying to use the outer scrollbar alone doesn't effectively scroll the inner content to its entire vertical extent, forcing you to use the inner scrollbar as well to get the job done. Ugly to say the least.
Now that I know that is the case, one way to reduce the likelihood of an inner scrollbar appearing for the nested scaffold element's main content area is to change it's parent element's core-pages height to something much greater than 100vh (400vh?). Doing so solves the problem in a roundabout way. The outer scrollbar can now be used to scroll the entire vertical extent of the nested scaffold's contents without an inner scrollbar occurring.
In the new jsbin example (below), you can witness the 'fix', which also happens to remove the reliance on core-scaffold, instead preferring to utilize its individual components in a more configurable fashion.
http://jsbin.com/muniqi/3/

custom centering content in a 960 grid system

I have a 960gs layout but I don't know which is the best approach to center the content of this page (http://andreapuiatti.de/screenshots/question.png) using the 960grid system.
The designer assures that this design is based on 960gs but hell... is everything out of the columns!
The only solution I come up with is that of using a grid_12 and then add custom elements which I will size myself but then why using a grid system?
Decide how many columns the image and text will span, say 12 and create your 12 column row as the parent container (all within the 960 grid framework).
Within that row, I would create a wrapper class (give it a class) and then for the image (or its container) apply a standard CSS rule like margin: 0 auto;. Apply display: block to the image if it is not wrapped in a block level element.
As for the text, the p elements will fill the wrapper element and you can adjust margins as needed.
In general, these CSS grid framework create block level boxes that contain your content, text and images and so on. It is up to the designer to decide how to lay out the elements within each block. 960.gs and similar CSS frameworks define your layout only, not the details of styling the content within each box/block/panel within the grid layout.
About the Screenshot and Designer
Your designer may not understand how grids work and you need to have a discussion with him/her to specify where the edges of the image should be. The problem is not with the CSS framework, but the design specifications need to be more precise. Nothing wrong with that!

What are best practices for using "display: inline-block"

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

Is there a reason why padding adds to the size of an element?

I was very surprised when I found that a <div> with a size of - say - 200px becomes 220px wide if you give it 10px padding. It just makes no sense to me, the external size should not change when an internal setting does. It forces you to adjust the size every time you tweak the padding.
Am I doing something wrong, or is there a reason for this behavior?
EDIT: I know this is how it's supposed to work, my question is why? Is it logical in a way I don't understand? Does this give any advantage over the opposite approach of keeping size and padding separate?
There are two different so-called "box models", one adds the padding (and border) to the specified width, while the other does not. With the advent of CSS3, you can luckily switch between the two models. More precisely, the behaviour you are looking for can be achieved by specifying
box-sizing: border-box;
ms-box-sizing: border-box;
webkit-box-sizing: border-box;
moz-box-sizing: border-box;
width: 200px;
in your div's CSS. Then, in modern browsers, the div will always stay 200 px wide no matter what. For further details and a list of supported browsers, see this guide.
Edit: WRT your edit as to why the traditional box model is as it is, Wikipedia actually offers some insight:
Before HTML 4 and CSS, very few HTML elements supported both border and padding, so the definition of the width and height of an element was not very contentious. However, it varied depending on the element. The HTML width attribute of a table defined the width of the table including its border. On the other hand, the HTML width attribute of an image defined the width of the image itself (inside any border). The only element to support padding in those early days was the table cell. Width for the cell was defined as "the suggested width for a cell content in pixels excluding the cell padding."
CSS introduced margin, border and padding for many more elements. It adopted a definition width in relation to content, border, margin and padding similar to that for a table cell. This has since become known as the W3C box model.
The reason why it's like that is that technically the width of elements is supposed to apply to the content, not the container.
According to the CSS1 specification, released by the World Wide Web Consortium (W3C) in 1996 and revised in 1999, when a width or height is explicitly specified for any block-level element, it should determine only the width or height of the visible element, with the padding, borders, and margins applied afterward.
More info about this behavior*
* Disclaimer: Yes, this is my own blog and I think I did a thorough job of explaining the box model so I'm putting it as reference.
Padding is supposed to be in addition to the given width of an object.
See the CSS 2.1 specification for box model.
While it is true that you can view padding as either an internal or an external attribute, the fact of the matter is that according to the current specifications it is an external attribute. It was a choice between two, as far as I can tell, equally valid options.
I haven't read up on the box-model attribute, but assuming that alex is right, then in the future you will be able to choose between the two ways of interpreting padding.
If the size increases with padding, it's working as intended. In browsers with broken box models like older Internet Explorer versions, the div will be 100 pixels wide, but that's incorrect handling of the CSS.
http://www.w3schools.com/css/css_boxmodel.asp
If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?
It's better that the default behaviour is that the width of the container is not affected by padding or margin values.
If your box is within a box, remove the inner box's width (the one with the padding) and it will fix the problem.
""If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?""
First of all, any good web developer would know better than to put an image into a container where it doesn't fit. That is developing 101. If the padding doesn't allow for the image, the image or the padding should be changed. Pure and simple. So the argument mentioned above is faulty.
Padding is an internal setting, internal to the boundries of the container. So when something is inside that container, and you increase the container's padding, the item(s) inside that container should coded so the can be reduced in size.
The word "padding" itself says it all. Can you imagine if UPS added padding to thier boxes to protect the contents inside, only to find that the box increases in size! Rediculous, right? Of course it is! Padding is meant to add space around the inside of a container WITHOUT the container breaking and expanding in height or width.
It's browsers like mozilla, gecko, and opera that have broken box models, not IE. The box model that the "consordium" implements is faulty at best and reaks havoc on web develpers.
If the "consordium" implemented the same box model as IE, than we developers would have a much easier time with the columns of our webpages. I think you have to agree with me on that point. Plain and simple.
I am so tired of people saying that IE is inferior. I can give tons of examples where IE holds strong while the cheaper browsers like firefox break under the pressure.
My two cents. Hate me if you want, but what I speak is common sense and nothing else.

Resources