I try to use flex in firefox, it doesent work, in Chrome, it works like a charm!
Here is the result in Firefox:
And here is how it looks (should look) in Chrome/Opera:
What is the problem?
Here is the CSS, that doesent work on Firefox:
.jawcontain {display: flex;flex-direction: column;justify-content: space-between;border: white solid 7px;border-radius: 23px;}
.jaw {background-color: rgb(24, 24, 24);border-radius: 5%;display: flex;flex-direction: row;padding-top: 2%;padding-bottom: 5%;border: 10px solid rgb(0, 151, 255);justify-content: space-around;}
.hala {border: white solid 2px;padding-left: 10%;border-radius: 5%;margin-right: 2% display: flex;flex-basis: 40%;flex-direction: column;background: black;justify-content: space-around;}
The problem is that .jaw are flex items, and you use
.jaw {
padding-top: 2%;
padding-bottom: 5%;
}
In CSS 2.1, percentages in padding were specified as
The percentage is calculated with respect to the width of the
generated box's containing block, even for 'padding-top' and 'padding-bottom'.
However, in Flexible Box Layout Module,
Percentage margins and paddings on flex items are always resolved
against their respective dimensions; unlike blocks, they do not always
resolve against the inline dimension of their containing block.
Therefore, Firefox attempts to resolve those percentages with respect to the height of the flex container. But that height is auto, that is, it depends on the height of the content, including the vertical paddings. It's a circular definition, so the paddings compute to 0.
But Chrome does not agree, and resolves the percentages with respect to the width of the flex container. The spec warns about that:
Note: This behavior is currently disputed, and might change in a
future version of this specification to match the behavior of blocks.
Since you don't seem to be using flex, you can remove
.jawcontain {
display: flex;
}
Then, .jaw will no longer be flex items, and the paddings will be resolved with respect to the width of the containing block.
Related
If you look at the CSS box model spec, you'll observe the following:
The [margin] percentage is calculated with respect to the width of the generated box's containing block. Note that this is true for 'margin-top' and 'margin-bottom' as well. If the containing block's width depends on this element, then the resulting layout is undefined in CSS 2.1. (emphasis mine)
This is indeed true. But why? What on earth would compel anyone to design it this way? It's easy to think of scenarios where you want, e.g. a certain thing to always be 25% down from the top of the page, but it's hard to come up with any reason why you would want vertical padding to be relative to the horizontal size of the parent.
Here's an example of the phenomenon I'm referring to:
<div style="border: 1px solid red; margin: 0; padding: 0; width: 200px; height: 800px;">
This div is 200x800.
<div style="border: 1px solid blue; margin: 10% 0 0 10%;">
This div has top-margin of 10% and left-margin of 10% with respect to its parent.
</div>
</div>
http://jsfiddle.net/8JDYD/
Transferring my comment to an answer, because it makes logical sense. However, please note that this is unfounded conjecture. The actual reasoning of why the spec is written this way is still, technically, unknown.
Element height is defined by the height of the
children. If an element has padding-top: 10% (relative to parent
height), that is going to affect the height of the parent. Since the
height of the child is dependent on the height of the parent, and the
height of the parent is dependent on the height of the child, we'll
either have inaccurate height, or an infinite loop. Sure, this only
affects the case where offset parent === parent, but still. It's an
odd case that is difficult to resolve.
Update: The last couple sentences may not be entirely accurate. The height of the leaf element (child with no children) has an effect on the height of all elements above it, so this affects many different situations.
For "n%" margin (and padding) to be the same for margin-top/margin-right/margin-bottom/margin-left, all four have to be relative to the same base. If top/bottom used a different base than left/right', then "n%" margin (and padding) wouldn't mean the same thing on all four sides.
(Also note having the top/bottom margin relative to the width enables a weird CSS hack that allows you to specify a box with an unchanging aspect ratio ...even if the box is rescaled.)
I vote for the answer from #ChuckKollars after playing with this JSFiddle (on Chrome 46.0.2490.86) and referring to this post (written in Chinese).
A major reason against the infinite calculation conjecture is that: using width faces the same infinite calculation problem.
Have a look at this JSFiddle, the parent display is inline-block, which is eligible to define margin/padding on it. The child has margin value 20%. If we follow the infinite calculation conjecture:
The width of the child depends on the parent
The width of the parent depends on the child
But as a result, Chrome stops the calculation somewhere, resulting:
If you try to expand the "result" panel horizontally on the JSFiddle, you will find that the width of them will not change. Please note that the content in the child is wrapped into two lines (not, say, one line), why? I guess Chrome just hard-code it somewhere. If you edit the child content to make it more (JSFiddle), you will find that as long as there is extra space horizontally, Chrome keeps the content two lines.
So we can see: there is some way to prevent the infinite calculation.
I agree with the conjecture that: this design is just to keep the four margin/padding values based on the same measure.
this post (written in Chinese) also proposes another reason is that: it is because of the orientation of reading/typeset. We read from top to down, with the width fixed and height infinite (virtually).
I realize the OP is asking why the CSS specification defines top/bottom margin percentages as a % of width (and not, as would be assumed, height), but I thought it might also be useful to post a potential solution.
Most modern browsers support vw and vh now which lets you specify margin numbers against the viewport width and viewport height.
100vw/100vh equals 100% width/100% height (respectively) if there's no scrollbar; if there is a scrollbar the viewport numbers don't account for this (while the % numbers do). Thankfully, nearly all browsers use scrollbar sizes of 17px (see here), so you can use css calc function to account for this. If you don't know whether a scrollbar will appear or not, then this solution will not work.
For example: Assuming no horizontal scrollbar, a top margin of 50% of height, could be defined as "margin-top: 50vh;". With a horizontal scrollbar, this could be defined as "margin-top: calc(0.5 * (100vh - 17px));" (remember that the minus and plus operators in calc require spaces on both sides!).
I know this question is a bit old, but I'd like to refresh it for CSS3. While it's true that the CSS2.1 specification says that percentage padding and margin are defined relative to the width of the containing block, this is not always the case. It depends on the writing mode. This comes straight from the CSS3 specs:
As a corollary, percentages on the margin and padding properties, which are always calculated with respect to the containing block width in CSS2.1, are calculated with respect to the inline size of the containing block in CSS3.
I cover this in my tutorial on aspect ratios with CSS.
Specifically, there's a section on Percentage Padding in Horizontal vs. Vertical Writing Modes. By default, an element has a horizontal writing mode, where text flows horizontally (in the "inline" direction) from left to right. However, using the writing-mode CSS property, you can actually set the mode to be vertical (with text either flowing from right to left or left to right). Here are some diagrams of horizontal vs vertical writing modes:
These are taken from the MDN docs on writing modes.
In vertical writing modes, percentage padding will be relative to the height of the containing block, not to the width.
Here's proof:
.document {
writing-mode: vertical-rl;
width: 100%;
height: 100vh;
}
.parent {
width: 100%;
height: 200px;
background-color: black;
color: white;
}
.child {
padding: 10%;
background-color: white;
color: black;
border: solid 1px;
}
<div class="document">
<div class="parent">
<div class="child">
Child
</div>
</div>
</div>
The child gets 20px of padding, which is 10% of its containing block's height (200px).
As to the why in the question, this was covered well in the other posts here.
This question already has answers here:
Chrome / Safari not filling 100% height of flex parent
(5 answers)
Why don't flex items shrink past content size?
(5 answers)
Closed 5 years ago.
In the following questions, I've been able to get all the cases to work out, I'm just looking to debug my mental model. I'm also only concerned with Chrome, if that makes answering easier.
I have an overflow:auto within nested "holy grail-ish" flexbox layouts. The overflow:auto behavior works fine for 2-level and 3-level nesting.
However, once I get to 4-level nesting, it "breaks," requiring me to specify the min-height:0 property (despite my having consistently specified flex-basis:0 via flex:1, which should annul the flex-basis:content/content-sized default). Why is this only happening at 4-level nesting?
Also, the element I need to slap the min-height:0 onto is .orange. Why this element, and why not the other ancestors?
Can anyone explain the above two questions? I have been consulting the spec and am having trouble connecting its rules back to my 4-level-deep example.
Note that this is different from the other questions I've been able to find on SO regarding flexbox and overflow, for instance (see in particular my answers):
overflow: auto in nested flexboxes
Nested flexbox with scrolling area
I have an overflow:auto within nested "holy grail-ish" flexbox layouts. The overflow:auto behavior works fine for 2-level and 3-level nesting.
Your 2-level code does indeed work as intended in Chrome, and IE11. However, it fails in Firefox. Same thing with your 3-level code: Works in Chrome and IE11, but not Firefox.
However, once I get to 4-level nesting, it "breaks," requiring me to specify the min-height:0 property (despite my having consistently specified flex-basis:0 via flex:1, which should annul the flex-basis:content/content-sized
default). Why is this only happening at 4-level nesting?
Once again, your statement is true for Chrome and IE11, but not for Firefox.
Solutions
Let's start with the fixes, so that all demos work in Chrome, Firefox and IE11. (I didn't test in Safari, but that's WebKit like Chrome, so it should be fine with vendor prefixes for any versions prior to 9.)
Also, I'll use compiled code in the answer, as not everybody uses preprocessors.
Revised 2-level (added two lines of code)
.violet {
flex: 1;
background: violet;
display: flex;
flex-direction: column;
min-height: 0; /* new */
min-width: 0; /* new */
}
Revised 3-level (added four lines of code)
.violet {
flex: 1;
background: violet;
display: flex;
flex-direction: column;
min-height: 0; /* new */
min-width: 0; /* new */
}
.orange {
flex: 1;
background: orange;
display: flex;
min-height: 0; /* new */
min-width: 0; /* new */
}
Revised 4-level (added one line of code)
.violet {
flex: 1;
background: violet;
display: flex;
flex-direction: column;
/* For some reason this is not needed */
/* min-height:0; */
min-width: 0; /* new */
}
Breaking Down the Behavior
There's a lot going on with your nesting. I'm not going to debug the code line-by-line, but I'll offer three concepts that may be useful to you.
1. Calculating Percentage Heights
Chrome, Firefox and IE11 can have different interpretations for an element's height.
Here's what it says in the spec:
CSS height property
percentage Specifies a percentage height. The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly and this element is not absolutely positioned, the value computes to "auto".
auto The height depends on the values of other properties.
Traditionally, when calculating percentage heights, browsers have interpreted the spec's use of the term "height" to mean the value of the height property.
Based on a reading of the height definition, the interpretation could just as easily be the computed height, but the height property requirement has become the predominant implementation. I've never seen min-height or max-height work on a parent when dealing with percentage heights.
Chrome expects to see the height property when calculating height. If it doesn't, it computes the height to auto. Firefox, however, has a broader interpretation of the spec. It accepts flex heights, as well (as evidenced here and here and here).
It's not clear which browsers are more compliant.
It doesn't help matters that the height property definition hasn't been updated since 1998 (CSS2).
In all three of your demos you're combining percentage heights, pixel heights and flex heights. You may want to keep the differing browser interpretations in mind when troubleshooting your code.
Here are some more details: Working with the CSS height property and percentage values
2. Why doesn't flex item shrink past content size?
3. flex-basis: 0 vs flex-basis: auto
flex: 1 1 auto (or flex: auto, for short), sizes a flex item based on the content size or height properties.
flex: 1 1 0 (or flex: 1, for short), sizes a flex item based on the free space in the flex container.
Each may have a different effect on the behavior of overflow: auto.
More details here: Page-filling flexbox layout with top and side bars not quite working
I have a div with 1-pixel-border and height:29%. Chrome for some reason renders it without the bottom border.
See http://jsfiddle.net/9WVuC/4/
This issue depends on the actual percentage value and container size; when I change them, border sometimes appears and sometimes disappears. Seems that there is some rounding error in Chrome rendering engine when it's calculating actual div's height. Also, it occurs only if overflow and position are specified for that div.
Is it a known bug and maybe some workaround exists? Of course I can get rid of that percentage values by recalculating height manually and setting it with JS, but it's not very elegant solution.
this is because of the overflow:hidden; style you have on the div, the border actually appears outside of the div in question, so according to the height of the div (with it being a %) it doesn't take this border into account.
Looking at your code i would recommend moving your overflow:hidden; to the containing element of the divs (the td) that fixes the problem and will have the same effect on the content of the class="lower" element if it overflows.
You can fix this "bug" by setting height to height: 28.95%;
Make sure you do not use tables for layout. They should only be used for tabular data.
decrease the height or remove overflow: hidden
lower{
height: 28%;
position: relative;
overflow: hidden;
border: solid 1px black;
}
Fiddle demo
This is probably a rendering issue depending on screen/window size and the element's computed size (with decimals). A workaround for me was to put an invisible box-shadow where the border is missing and it fixes the rendering. For the bottom border it would look like this:
box-shadow: 0 1px 0 0 rgba(255,255,255,0);
Why don't we have box-sizing: margin-box;? Usually when we put box-sizing: border-box; in our style sheets we really mean the former.
Example:
Let's say I have a 2 column page layout. Both columns have a width of 50%, but they look kind of ugly because there's no gutter (gap in the middle); Below is the CSS:
.col2 {
width: 50%;
float: left;
}
To apply a gutter you might think we could just set a right margin on the first of the 2 columns; something like this:
.col2:first-child {
margin-right: 24px;
}
But this would make the second column wrap onto a new line, because the following is true:
50% + 50% + 24px > 100%
box-sizing: margin-box; would solve this issue by including margin in the calculated width of the element. I would find this very useful if not more useful than box-sizing: border-box;.
Couldn't you use width: calc(50% - 24px); for your cols? Then set your margins.
I think we could have a box-sizing: margin-box. The css box model shows exactly, what are the positions of the margins of the frames.
There are minor problems - for example, the margin boxes can overlap - but they aren't hard to solve.
I think, the situation is the same, as we can see with the overflow-x & overflow-y combinations, with the absolut positionied divs in table-cells, with the combination of min|max-width|height with the box-sizing, and so on.
There are features, really simple features, which the browser developers simply doesn't develop.
IMHO, box-sizing: margin-box were a very useful feature. Another useful feature were the box-sizing: padding-box, it exists at least in the standard, but it wasn't implemented in any of the major browsers. Not even in the newest chrome!
Note: #Oriol 's comment: Firefox did implement box-sizing: padding-box. But others didn't, and it was removed from the spec. Firefox will remove it in version 50. Sad.
The guy at the top is asking about adding margin to the overall width, including padding and border. The thing is, margin is applied outside the box and padding and border aren't, when using border-box.
I have tried to achieve the border-margin idea. What I have found is that if using margin you can either add a class of .last to the last item (with margin, then apply a margin of zero, or use :last-child/:last-of-type). Or add equal margins all the way around (similar to the padding version above).
See examples here: http://codepen.io/mofeenster/pen/Anidc
border-box calculates the width of the element + its padding + its border as the total width. So if you have 2 divs which are 50% wide, they will be adjacent. If you add 8px padding to them, then you will have a gutter of 16px. Combine that with a wrapping element - which also has padding of 8px - you will have a nicely laid out grid with equal gutters all the way around.
See this example here: http://codepen.io/mofeenster/pen/vGgje
The latter is my favourite method.
I'm sure all of this is obvious, but I'll type it out anyway because...well, I need the exercise. Would the following outcome not be just as efficient as box-sizing: margin-box;:
.col2 {
width: 45%;
height: 90%;
margin: 5% 2.5%;
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
float: left;
}
http://jsfiddle.net/Fg3hg/
box-sizing is used to control from which point the padding and border are assessed to the overall size of the element. So while it's not kosher to include px margins with a % width (as is usually always the case), it's easier to calculate what the relative percentage amount should be because you don't have to incorporate padding and borders to the defined width.
This is because the box-sizing attribute refers to the size of an element after computing the given dimension-specific values (padding, borders). "box-sizing: border-box" sets the height/width of an element and takes into consideration the padding as well as the border width. The scope of an element's margin is greater than the element itself, meaning it modifies the flow of the page and its surrounding elements, therefore directly altering the way the element fits within its parent relative to its sibling elements. Ultimately a "margin-box" attribute value would cause major problems and is essentially the same as setting the elements height/width directly.
Dimensions of block-level, non-replaced elements in normal flow must satisfy
margin-left + border-left-width + padding-left + width + padding-right + border-right-width + margin-right = width of containing block
When over-constrained, browsers must adjust either the left or right margin.
I think that means the width of the margin box must equal the width of the containing block (i.e. 100%).
For your case, transparent borders with box-sizing: border-box can work much like margins.
On Codrops there are a couple of good articles on the subject of the effect of margins and row's forced to overflow. They suggest using the rem or em unit with a normalizer css setting font size to 100% for all browsers, then when you set widths and margins it is easy to keep track of the effect on the row's width by simply making a note in comments for the total width. A conversion of 16px to 1 em is the way to calculte the targeted viewports total witdh.
Working like that for the dev stage at least and then if you want 'responsive' templates you can convert widths to % including the margin widths.
The other and often simpler way they suggest to handle gutters is to use the pseudo after and the content: ''; on each of your columns which I find works really well. If you set a div class that is the defined last column such as end you can then target that class not to have the pseudo after, or to have a wider one; which ever best suits your layout.
The added bonus of using this pseudo element method is it also gives you a target for shadows that can give a more 3d effect and greater depth to the flat image on the readers monitor as well. I am experimenting with this effect at the moment by scaling up the effects being used on buttons, 'tweaking' the gradients, and the z-index.
Perhaps set the border to 0% opacity using RGBA and use the border as a margin.
There interesting situation when using box-sizing inside body content
no content no border box gives no any value on left-right margin % recount of this two box recount algoritms
.body{
box-sizing: border-box;
margin:0 3%;
}
Firefox versions before 57 also supported the padding-box value for
box-sizing, though this value was been removed from the specification
and later versions of the browser.
So margin-box even not planned...
There should be a box-sizing: margin-box;
But does the following work:
Put a div around it with
.divX{
width: XX%;
display:flex;
align-items: center;
justify-content: center;
}
i have a div on a web page that basically acts as a panel container. i want it to:
have a minimum width of 1000px; So no matter how small the content inside the div is, it will at least keep the panel to 1000px in width:
in terms of max width, it should keep going as big as the content within it. So if a person has a 24 inch monitor and they want to maximize the browser it should keep growing until the content inside doesn't have any scroll bars and then stop.
needs to work in all browsers.
how would i do this in css?
Assuming this item is a block element (i.e. "display: block"), it should scale automatically as wide as its containing element (in this case the browser window).
In CSS, just specify "min-width: 1000px." This will work in IE8+ and all modern browsers.
try this
#panel {
min-width: 1000px;
diplay: block;
overflow: hidden; }
Try this:
#panel
{
/* Other styles */
min-width:1000px;
/*width:100%; - removed as it will create horizontal scrollbar if margin and padding aren't 0 as per Josh's comment.*/
}
However, you will problems with older browsers like IE6 which do not like the min-width thingy in which case you will need to use JavaScript.