After experimenting with the css3 flex-box proporty, I quickly noticed some differences in Chrome and Firefox.
In particular: if you set a width on an element that should be flex,
firefox will flex the element according to what it needs, it takes the width style into account but its only a variable.
Chrome will respect the with style fully,
An example:
<div id="box">
<div class="flex-box">Test</div>
<div class="flex-box">Test Text</div>
</div>
If the 2 divs inside the box have the same width assigned, chrome will make them the same size. Firefox will reconize that the second div needs more space, and thus it gets more allocated.
who is right?
Remember the flex doesn't apply to the width, it applies to the free space after the minimum intrinsic width has been determined. This produces counter-intuitive results in several common cases, as has been pointed out on the www-style mailing list. I've found that, unless you want the CSS re-ordering or the multi-line (which isn't yet implemented in Firefox and Chrome), what you think you want to use display: box and box-flex for you really want to use display: table and display: table-cell.
But back to your actual question: I found Firefox and Chrome display identically if you set a width in pixels, but not if you set a width as a percentage. As far as which browser is doing it correctly at the moment, it's a fair bet Firefox is implementing what the spec originally intended as the original spec is describing what the XUL property does, and the XUL property is what this is all based on. As others have mentioned, whether or not the final spec ends up matching this original intention is unknown.
I don't think any browser is right or wrong as flexbox is still a working draft. At any time the spec could change and render another browser right or wrong.
http://www.w3.org/TR/css3-flexbox/
I disagree with robertc's statement "But back to your actual question: I found Firefox and Chrome display identically if you set a width in pixels, but not if you set a width as a percentage."
I am currently using the flexbox in an attempt to show how simple it is to convert a rather heavy in JS and CSS site to a very simple HTML/CSS3 site. Once conclusion I have come to with regards to setting width in pixels:
#main {
display: box;
}
#main > section {
width: 120px;
padding: 10px;
border: 5px solid #000;
}
In chrome, the total width = 120 + 20 + 10 = 150px
In ff, total width = 120px (the 20px padding are inside the 120 and the 10px border is as well)
Another inconsistency I found, in chrome, #main IS greedy and takes up 100%, as you would likely expect. In Firefox, you need to set with to 100% on #main in order for it to act as you would expect.
I'm still working on ironing out all differences in all supported browsers, I will try to post when I have more to add to this. Sadly, as cool as he flexbox model is, and as easy as it makes a lot of shit, its far from consistent.
One more thing, using CSS transitions to change dimensions works well with explicitely defined dimensions (ie. pixels)... but if the dimension is defined by the box's flex, the animation simply jumps between the flex values... no where near as smooth (though, instead of heaving flex of 5 and 1, you could have flex of 500 and 100). In fact, chrome will not animate between flex values, just jumps. FF on the other hand does this nicely.
I'm just really hoping things progress to the way FF handles flexbox, while chrome is close, I just don't agree with how some things are handled, and the lack of animation between flex values just plain sucks.
Related
I'm trying to add a flexbox element to the content area of a two column layout. The layout has a fixed width sidebar and fluid content. It uses float: left and negative margins to achieve this.
The goal is for the flex container to be 100% width of the parent. Flex items should be displayed in rows, with excess items wrapping to the next row.
The straight-forward approach works fine in Firefox and Chrome:
.flex-container {
display: flex;
flex-direction: row;
flex-wrap: wrap;
align-items: stretch;
}
.flex-item {
flex: 1 0 100px;
padding: 10px;
border: 1px solid gray;
}
...
<div class="flex-container">
<div class="flex-item">Item</div>
<!-- more items here -->
<div class="flex-item">Item</div>
</div>
Full example (works in FF and Chrome, but not IE 11):
http://jsfiddle.net/btc9chw0/3/
The problem
In Internet Explorer 11, all items are displayed on a single row. They never wrap to the next row, even when there are lots of items. This causes the page to become much wider than the browser window.
After lots of experimentation, it appears that this is somehow related to the fact that the flex container is inside a float: left element. Removing the float allows items to wrap correctly, but breaks other parts of the layout. The content area can have other content in addition to the flexbox, and some of that content needs to use float: left and clear: both. Without a floating parent element, a clear: both would push everything below the sidebar. Giving .flex-container a fixed width also fixes the problem, but in this case we want it be 100% width.
Firefox screenshot:
IE 11 screenshot:
The question
Is there are way to make flex items wrap to the next row in IE 11 when the parent of the flexbox container has "float: left"?
Disclaimer: Please disregard, for the moment, the fact that this layout uses both floats and flexbox instead of just one or the other. In this case, flexbox is a nice-to-have enhancement for one part of the page, while the general layout must be more robust.
The underlying issue here actually has to do with the auto measurement of a container in a shrink-to-fit context. By making .content have a min-width of 100% you've left the max-width to auto so the browser needs to measure the content to know its max-width to shrink down around it.
In IE, complete layout will be done to get the exact result with no limitations if none were set (as is the case here, we actually have infinite space since we can scroll and you have limited the width anywhere within its ancestor tree). Webkit and Gecko had made some changes in the past to avoid having to actually do layout and do an approximation, even though the actual measurement results were incorrect since they didn't know how big other (shrink-to-fit containers were) they decided the perf benefits were worth the tradeoff. With Gecko, Webkit and Blink (due to forking from webkit) all using this same behavior we changed our implementation to match this in Microsoft Edge and so we render the same as Firefox, Chrome, Safari. To get the same result in IE11 you'll need to provide a maximum width constraint when in a shrink-to-fit context (floats, abspos, table cell, etc).
Ultimately I prefer the IE behavior because it actually makes sense and is consistent. If there is enough space to lay out the content, the layout shouldn't change (as is the case here). Here is a simpler example showing why this approximation can cause issues, there is still enough room in the viewport to render the same result in each case but because they can't determine the actual dimensions of the floated blocks you get different results in Chrome/Firefox/Safari/Edge; while in IE they produce the same consistent result.
Sorry for the long reply, but I wanted to provide the context for why IE seems incorrect here.
Let me know if you need any further clarification.
I am trying to get a div to fit to only the content using intrinsic sizing, but chrome dev tools seems to be rejecting that style.
In the dev tools, that style has a strike-though through it and a yellow triangle with an exclamation mark as if it is an invalid style.'
The style gets a strike-through if I do it without vendor prefixes or with so none of the following are working:
.box{
width:-moz-fit-content;
width:-webkit-fit-content;
width:fit-content;
}
All of them have a strike-through through them.
What am I doing wrong? I have the latest versions of Firefox and Chrome and they are supposed to support this.
Update:
Here is a screenshot of what I am seeing in chrome dev tools:
http://cl.ly/image/1k0I21192Q36
The code you have written in your answer:
.box{
width:-moz-fit-content;
width:-webkit-fit-content;
width:fit-content;
}
should work totally fine. However the code in your screenshot:
div.container{
height:-webkit-fit-content;
height:fit-content;
}
won't work. This is because fit-content only applies to width and not height.
See the Mozilla Developer Network for working values for width and height - there are way more available for width:
https://developer.mozilla.org/en-US/docs/Web/CSS/height
https://developer.mozilla.org/en-US/docs/Web/CSS/width
According to MDN, the fit-content width does the following:
fit-content Experimental The larger of: the intrinsic minimum width
the smaller of the intrinsic preferred width and the available width
So for a height you can expect a div to expand it's height to fit the content within it (unless the content is positioned absolutely or floated). To get it to fulfil the last part (making sure it doesn't exceed the available space) you could add max-height:100%; depending on the structure of your html.
I'm trying to accomplish something specific around platform constraints I'm under.
I created a somewhat self-explanatory jsfiddle of the problem at http://jsfiddle.net/MrV5M/4/
The specific problem:
On Chrome, the right border of the input box is cut off.
On Safari, the width of the content class cell exceeds the container so it spills over the border.
On IE9, the label doesn't float to the left of the content div
The main reason I care about Safari is because I'm working on a JQuery Mobile/PhoneGap app which is also a web app. I'm only supporting modern browsers, but this is driving me nuts. Normally I'd just use a table for the container, but the text-overflow: ellipsis styles on the content div don't work when inside a table. (Basically, I'm trying to keep the content to a single line and have ellipsis without enforcing a fixed width or calculating a width with Javascript)
Anyone have the l33t CSS skills to make this work? I sure don't... :)
Just add this CSS to your Stylesheet, and get peace of mind on your issue :D
* {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
You may not like this answer. I made some adjustments in the css which fixes Chrome and IE9 issues. Take a look,
http://jsfiddle.net/MrV5M/11/
There are many ways to do what you are trying to do, but if you insist on using 'flex' stuff which is largely un-supported (even in the majors see here), you'll need to add the vendor prefixes to flex.
e.g... -webkit-flex, -moz-flex
Also, I don't think you need to be setting widths on elements that have the flex property.. not positive though.
So your browser issues:
-IE doesn't support flex at all so you're label won't float unless you use a float.
-The reason your input/content is spilling over the container and getting cut off is not really anything to do with flex.. but the way css works.. setting an element to 100% width means setting it to the width of its parent. But by default, css doesn't count the padding/border-width as part of that width. So you end up getting 100% width plus the L/R padding and border. But, since you are only supporting modern browsers.. box-sizing:border-box; to the rescue. Google it for details, but putting it on your input element should do the trick.
I'm trying to create a site which uses laterally-stacked "blades" of content. The element containing them is moved laterally inside a div with overflow-x: hidden to create the desired sidescrolling effect. This seems to be working fine: The element containing the "blades" is set to display: table; width: 100%; table-layout: fixed and each blade is styled as follows: display: table-cell; width: 601px; border-right: 1px solid white; padding: 10px. Finally, the nav element has width 621px, with no horizontal padding or margins.
It all seems simple enough, but I'm getting a very odd cross-browser bug: Firefox and IE9 agree on how the page looks, but Chrome has a different opinion. I've figured out what Chrome is doing, but I haven't been able to figure out why it's doing it.
The doctype's set and everything else seems to be working fine. Except for background-colors, the rules above are all I've defined in the stylesheet, and there are no inline styles. Here are some screenshots which illustrate the problem behavior.
Here's the page in Firefox - as desired, the right edge of the navigation bar aligns with the right edge of the content box.
Same in IE9.
In Chrome, the padding is subtracted from the width, creating the overhang shown above. I never set border-box anywhere in the stylesheet, nor do I see it in the computed rules in Chrome - it just says that the width is 581px, whereas it's 601px in the other two browsers.
[Note: I saw that there were other posts on padding issues, but none where Firefox and IE9 agreed and Chrome did something different.]
Edit Here's a JSFiddle link: http://jsfiddle.net/aCeAw/
This is just a bug in Chrome. When it computes column widths for table-layout: fixed, it incorrectly ignores cell padding. See discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=652941 complete with spec quotes, and the almost-5-year-old WebKit bug report at https://bugs.webkit.org/show_bug.cgi?id=13339.
You may be able to work around this by using width styles on display: table-column elements, as discussed in the Mozilla bug report above. Alternately, you could add a first row with 0 height and no paddings, but the cell widths you want... I realize both of those mess with the actual site markup, which may not be an option in your case, of course.
I am trying to make a table-like calendar page, using fixed width and height block level elements. There is an outer container, which sets the width, and the cells get aligned by float: left. It works well in every browser, except in IE6, where the list gets split after the 29th element.
If I make the outside container a bit more wide (by at least 3 pixels) the problem gets fixed in IE6. Because the elements are more than 3 pixels wide, it doesn't change how the page looks. But I really don't understand why it happens, and what should I do not to make it happen.
I tried IE7.js, but it didn't help.
I know IE6 is such a buggy old browser, but while my sites are simple I prefer making them IE6 compatible.
link to the page in question
You can fix it by adding this to the bottom of style.css:
/* IE6 hack */
* html #naptar-list a, * html #naptar-list div {
width: 77px
}
This works by using the Star HTML hack to feed to only IE6 the declaration width: 77px (1px less than the actual width), which in my testing, fixed the problem: I'm not entirely sure why.