Simulating a "Card Layout" when using Flexbox - javascript

I'm having a rather complex problem here. I'd like to make a Layout in CSS featuring multiple Layers which means basically having multiple <div> elements stacked ontop of each other (or at least make it look like this) and only the top one is visible.
In many other GUI Environements this is known as a Card Layout.
So the plan was:
Create all <div class='layer'> elements in one parent <div class='container'> element
Make them have display: none initially
invoke $.show() or $.hide() to show or hide them
HTML:
<div id="containerOne">
<div class="layer a"></div>
<div class="layer b">
<div class="inner b1"></div>
</div>
<div class="layer c"></div>
</div>
CSS:
#containerOne {
width: 150px;
height: 150px;
background: red;
}
#containerOne .layer {
display : none;
width: 100%;
height: 100%
}
.a {
background: green;
}
.b {
background: orange;
}
.b1 {
width: 50%;
height: 50%;
background: yellow;
}
.c {
background: blue;
}
This works at first since the elements will not have any space reserved on the page initially and will only occupy space when shown.
Now if i have a nested element inside a Layer and i want it to have a size of 50% x 50% this also works well: Even if the layer div is set to display: none initially.
Now by default my Container div is set to display: block and all the size calculation seems to work fine and here's where my problem begins:
I need the Container div to have display: flex to take advantage of the Flexbox features of modern browsers. Instead of setting a fixed width for my Layers i now configure them to have flex: 1 so they grow to the full size of the container.
This also works as expected. With one exception: The nested Element that should have a size of 50% x 50% won't have a size at all. Debugging this in JavaScript shows that this is because at the moment the Layers are created they will all have a size of 0 x 0 and will first get their size assigned when they are shown by $.show().
What i would expect is that once they are shown, the nested element will grow to its 50% x 50% size but it doesn't.
Is there anything i can do about it? (good solutions and back-hack-workaround solutions).
I also made a Fiddle to demonstrate the problem and to play around with.

The thing you're expecting to happen should happen, but it doesn't (in Chrome) due to a bug. It actually works correctly in Firefox.
Here's a simplified version of your testcase with no dynamic changes:
http://jsfiddle.net/CN7e8/4/
This behavior was actually recently changed in the flexbox spec, to the behavior you're expecting. The issue is that your 50% height on b1 is resolving against an auto-height element (the flex item, b) and Chrome is treating that auto-height as an invalid percent basis, even though the auto-height can actually be resolved to the container's height. (It'll become the container's height due to the default align-items: stretch on the flex container, which makes auto-height flex items take on the container's height).
For reference, the spec change to clarify this is mentioned under ISSUE 3, part (a), in this post:
http://lists.w3.org/Archives/Public/www-style/2014Mar/0350.html
ANYWAY. To work around the Chrome bug, you can't have an auto-height on your flex item b, given that you're depending on it being a percent-basis. You have to give it an explicit height, e.g. height:100% (which more directly resolves against the container's height). Here's your fiddle, with that changed: http://jsfiddle.net/CN7e8/5/

Related

Problem with nested flex containers. Inner container's item is not respecting its parent's width [duplicate]

I have 4 flexbox columns and everything works fine, but when I add some text to a column and set it to a big font size, it is making the column wider than it should be due to the flex property.
I tried to use word-break: break-word and it helped, but still when I resize the column to a very small width, letters in the text are broken into multiple lines (one letter per line), and yet the column does not get smaller width than one letter size.
Watch this video
(at the start, the first column is the smallest, but when I resized the window, it is the widest column. I just want to respect flex settings always; flex sizes 1 : 3 : 4 : 4)
I know, setting font-size and column padding to smaller will help... but is there any other solution?
I can not use overflow-x: hidden.
JSFiddle
.container {
display: flex;
width: 100%
}
.col {
min-height: 200px;
padding: 30px;
word-break: break-word
}
.col1 {
flex: 1;
background: orange;
font-size: 80px
}
.col2 {
flex: 3;
background: yellow
}
.col3 {
flex: 4;
background: skyblue
}
.col4 {
flex: 4;
background: red
}
<div class="container">
<div class="col col1">Lorem ipsum dolor</div>
<div class="col col2">Lorem ipsum dolor</div>
<div class="col col3">Lorem ipsum dolor</div>
<div class="col col4">Lorem ipsum dolor</div>
</div>
The Automatic Minimum Size of Flex Items
You're encountering a flexbox default setting.
A flex item cannot be smaller than the size of its content along the main axis.
The defaults are...
min-width: auto
min-height: auto
...for flex items in row-direction and column-direction, respectively.
You can override these defaults by setting flex items to:
min-width: 0
min-height: 0
overflow: hidden (or any other value, except visible)
Flexbox Specification
4.5. Automatic Minimum Size of Flex
Items
To provide a more reasonable default minimum size for flex items, this
specification introduces a new auto value as the initial value of
the min-width and min-height properties defined in CSS 2.1.
With regard to the auto value...
On a flex item whose overflow is visible in the main axis, when specified on the flex item’s main-axis min-size property, specifies an automatic minimum size. It otherwise computes to 0.
In other words:
The min-width: auto and min-height: auto defaults apply only when overflow is visible.
If the overflow value is not visible, the value of the min-size property is 0.
Hence, overflow: hidden can be a substitute for min-width: 0 and min-height: 0.
and...
The minimum sizing algorithm applies only on the main axis.
For example, a flex item in a row-direction container does not get min-height: auto by default.
For a more detailed explanation see this post:
min-width rendering differently in flex-direction: row and flex-direction: column
You've applied min-width: 0 and the item still doesn't shrink?
Nested Flex Containers
If you're dealing with flex items on multiple levels of the HTML structure, it may be necessary to override the default min-width: auto / min-height: auto on items at higher levels.
Basically, a higher level flex item with min-width: auto can prevent shrinking on items nested below with min-width: 0.
Examples:
Flex item is not shrinking smaller than its content
Fitting child into parent
white-space css property is creating issues with flex
Browser Rendering Notes
Chrome vs. Firefox / Edge
Since at least 2017, it appears that Chrome is either (1) reverting back to the min-width: 0 / min-height: 0 defaults, or (2) automatically applying the 0 defaults in certain situations based on a mystery algorithm. (This could be what they call an intervention.) As a result, many people are seeing their layout (especially desired scrollbars) work as expected in Chrome, but not in Firefox / Edge. This issue is covered in more detail here: flex-shrink discrepancy between Firefox and Chrome
IE11
As noted in the spec, the auto value for the min-width and min-height properties is "new". This means that some browsers may still render a 0 value by default, because they implemented flex layout before the value was updated and because 0 is the initial value for min-width and min-height in CSS 2.1. One such browser is IE11. Other browsers have updated to the newer auto value as defined in the flexbox spec.
Revised Demo
.container {
display: flex;
}
.col {
min-height: 200px;
padding: 30px;
word-break: break-word
}
.col1 {
flex: 1;
background: orange;
font-size: 80px;
min-width: 0; /* NEW */
}
.col2 {
flex: 3;
background: yellow
}
.col3 {
flex: 4;
background: skyblue
}
.col4 {
flex: 4;
background: red
}
<div class="container">
<div class="col col1">Lorem ipsum dolor</div>
<div class="col col2">Lorem ipsum dolor</div>
<div class="col col3">Lorem ipsum dolor</div>
<div class="col col4">Lorem ipsum dolor</div>
</div>
jsFiddle
I'm finding this has bitten me repeatedly over the years for both flex and grid, so I'm going to suggest the following:
* { min-width: 0; min-height: 0; }
and then just use min-width: auto or min-height: auto if you need that behaviour.
In fact, throw in box-sizing as well to make all layout more sane:
* { box-sizing: border-box; min-width: 0; min-height: 0; }
Does anyone know if there are any odd consequences? I've not encountered anything in several years of using a mix of the above. In fact, I can't think of any cases where I'd want to layout from content outwards to the flex/grid, rather than flex/grid inwards to the content --- and surely if they exist, they're rare. So this feels like a bad default. But maybe I'm missing something?
The pure answer to your question is that by default, browsers tend to display as much information as possible to the reader (and not to hide anything).
That happens by default, and even includes showing default black color fonts on a white background (for maximum page contrast and readability), adding a scroll bar where content is larger than the viewport height (or width) or still showing content from a markup (or the background color) even if this was mistakenly placed after </body> or even </html> tags in the html file.
In context of CSS, this applies as well, but you also are allowed to play with many customizations on top of that.
Even in a screen if using a huge font (like font-size: 50em;) this initially acts as an overflowing element (and placing the font inside a flexible child container by using display: flex doesn't change this default behaviour unless you use overflow: hidden or resize the element in some way.
An elegant solution is to use a dynamic resizing of the letters, for example
font-size: calc(0.5em + 2vw)
which works great even in a responsive scenario.
As a previous answer mentioned, A flex item cannot be smaller than the size of its content along the main axis (for the same reason, that is not only specific to the flexbox model implemented in CSS but because of the inner browser way of working). Even a long word is displayed with a scrollbar if it's longer than display width as if being a block type element with a fixed size instead.
This is mentioned in old html 4.01 specifications as
"By convention, visual HTML user agents wrap text lines to fit within
the available margins. Wrapping algorithms depend on the script being
formatted.
In Western scripts, for example, text should only be wrapped at white
space. "
as seen here in paragraph 9.5.3. This means that, since then, the text had to be continuously displayed by default (unless we decide to split it but not at single character level: a single non-white character shown at 120em size will trigger scrollbars displaying on the browser).
Words are also clearly defined in paragraph 9.1 in the same source:
we use the term "word" here to mean "sequences of non-white space
characters"
The purpose of displaying the original format of any word is to not destroy, hide or distort the original information, the meaning or intent of the code author. As such, we also have for keeping in same line two words that are connected - when breaking them might be disruptive (such as New York, 10 PM, 10 km/h, § 10, etc)
For this code below, adding width: 100% solved my problem.
.post-cover .inner {
display: flex;
flex-direction: column;
flex-wrap: wrap;
justify-content: center;
align-content: flex-start;
align-items: flex-start;
word-break: break-all;
z-index: 21;
}
.post-cover .article-page {
padding: 20px 0;
margin-bottom: 40px;
font-size: 0.875em;
line-height: 2.0;
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
width: 100%; /* Add this */
}
I tried everything, even putting the below code in the index.css.
* {
min-width: 0;
min-height: 0;
box-sizing: border-box;
}
But nothing worked.
finally I made the div I wanted to shrink past it's content to have position: absolute;. Then it started shrinking.
It's parent div would need a defined height and width. This might not be the best solution for every scenario but if this works for you, good!

Nested divs with flexDirection: column; show vertical scroll bar on inner div [duplicate]

I have 4 flexbox columns and everything works fine, but when I add some text to a column and set it to a big font size, it is making the column wider than it should be due to the flex property.
I tried to use word-break: break-word and it helped, but still when I resize the column to a very small width, letters in the text are broken into multiple lines (one letter per line), and yet the column does not get smaller width than one letter size.
Watch this video
(at the start, the first column is the smallest, but when I resized the window, it is the widest column. I just want to respect flex settings always; flex sizes 1 : 3 : 4 : 4)
I know, setting font-size and column padding to smaller will help... but is there any other solution?
I can not use overflow-x: hidden.
JSFiddle
.container {
display: flex;
width: 100%
}
.col {
min-height: 200px;
padding: 30px;
word-break: break-word
}
.col1 {
flex: 1;
background: orange;
font-size: 80px
}
.col2 {
flex: 3;
background: yellow
}
.col3 {
flex: 4;
background: skyblue
}
.col4 {
flex: 4;
background: red
}
<div class="container">
<div class="col col1">Lorem ipsum dolor</div>
<div class="col col2">Lorem ipsum dolor</div>
<div class="col col3">Lorem ipsum dolor</div>
<div class="col col4">Lorem ipsum dolor</div>
</div>
The Automatic Minimum Size of Flex Items
You're encountering a flexbox default setting.
A flex item cannot be smaller than the size of its content along the main axis.
The defaults are...
min-width: auto
min-height: auto
...for flex items in row-direction and column-direction, respectively.
You can override these defaults by setting flex items to:
min-width: 0
min-height: 0
overflow: hidden (or any other value, except visible)
Flexbox Specification
4.5. Automatic Minimum Size of Flex
Items
To provide a more reasonable default minimum size for flex items, this
specification introduces a new auto value as the initial value of
the min-width and min-height properties defined in CSS 2.1.
With regard to the auto value...
On a flex item whose overflow is visible in the main axis, when specified on the flex item’s main-axis min-size property, specifies an automatic minimum size. It otherwise computes to 0.
In other words:
The min-width: auto and min-height: auto defaults apply only when overflow is visible.
If the overflow value is not visible, the value of the min-size property is 0.
Hence, overflow: hidden can be a substitute for min-width: 0 and min-height: 0.
and...
The minimum sizing algorithm applies only on the main axis.
For example, a flex item in a row-direction container does not get min-height: auto by default.
For a more detailed explanation see this post:
min-width rendering differently in flex-direction: row and flex-direction: column
You've applied min-width: 0 and the item still doesn't shrink?
Nested Flex Containers
If you're dealing with flex items on multiple levels of the HTML structure, it may be necessary to override the default min-width: auto / min-height: auto on items at higher levels.
Basically, a higher level flex item with min-width: auto can prevent shrinking on items nested below with min-width: 0.
Examples:
Flex item is not shrinking smaller than its content
Fitting child into parent
white-space css property is creating issues with flex
Browser Rendering Notes
Chrome vs. Firefox / Edge
Since at least 2017, it appears that Chrome is either (1) reverting back to the min-width: 0 / min-height: 0 defaults, or (2) automatically applying the 0 defaults in certain situations based on a mystery algorithm. (This could be what they call an intervention.) As a result, many people are seeing their layout (especially desired scrollbars) work as expected in Chrome, but not in Firefox / Edge. This issue is covered in more detail here: flex-shrink discrepancy between Firefox and Chrome
IE11
As noted in the spec, the auto value for the min-width and min-height properties is "new". This means that some browsers may still render a 0 value by default, because they implemented flex layout before the value was updated and because 0 is the initial value for min-width and min-height in CSS 2.1. One such browser is IE11. Other browsers have updated to the newer auto value as defined in the flexbox spec.
Revised Demo
.container {
display: flex;
}
.col {
min-height: 200px;
padding: 30px;
word-break: break-word
}
.col1 {
flex: 1;
background: orange;
font-size: 80px;
min-width: 0; /* NEW */
}
.col2 {
flex: 3;
background: yellow
}
.col3 {
flex: 4;
background: skyblue
}
.col4 {
flex: 4;
background: red
}
<div class="container">
<div class="col col1">Lorem ipsum dolor</div>
<div class="col col2">Lorem ipsum dolor</div>
<div class="col col3">Lorem ipsum dolor</div>
<div class="col col4">Lorem ipsum dolor</div>
</div>
jsFiddle
I'm finding this has bitten me repeatedly over the years for both flex and grid, so I'm going to suggest the following:
* { min-width: 0; min-height: 0; }
and then just use min-width: auto or min-height: auto if you need that behaviour.
In fact, throw in box-sizing as well to make all layout more sane:
* { box-sizing: border-box; min-width: 0; min-height: 0; }
Does anyone know if there are any odd consequences? I've not encountered anything in several years of using a mix of the above. In fact, I can't think of any cases where I'd want to layout from content outwards to the flex/grid, rather than flex/grid inwards to the content --- and surely if they exist, they're rare. So this feels like a bad default. But maybe I'm missing something?
The pure answer to your question is that by default, browsers tend to display as much information as possible to the reader (and not to hide anything).
That happens by default, and even includes showing default black color fonts on a white background (for maximum page contrast and readability), adding a scroll bar where content is larger than the viewport height (or width) or still showing content from a markup (or the background color) even if this was mistakenly placed after </body> or even </html> tags in the html file.
In context of CSS, this applies as well, but you also are allowed to play with many customizations on top of that.
Even in a screen if using a huge font (like font-size: 50em;) this initially acts as an overflowing element (and placing the font inside a flexible child container by using display: flex doesn't change this default behaviour unless you use overflow: hidden or resize the element in some way.
An elegant solution is to use a dynamic resizing of the letters, for example
font-size: calc(0.5em + 2vw)
which works great even in a responsive scenario.
As a previous answer mentioned, A flex item cannot be smaller than the size of its content along the main axis (for the same reason, that is not only specific to the flexbox model implemented in CSS but because of the inner browser way of working). Even a long word is displayed with a scrollbar if it's longer than display width as if being a block type element with a fixed size instead.
This is mentioned in old html 4.01 specifications as
"By convention, visual HTML user agents wrap text lines to fit within
the available margins. Wrapping algorithms depend on the script being
formatted.
In Western scripts, for example, text should only be wrapped at white
space. "
as seen here in paragraph 9.5.3. This means that, since then, the text had to be continuously displayed by default (unless we decide to split it but not at single character level: a single non-white character shown at 120em size will trigger scrollbars displaying on the browser).
Words are also clearly defined in paragraph 9.1 in the same source:
we use the term "word" here to mean "sequences of non-white space
characters"
The purpose of displaying the original format of any word is to not destroy, hide or distort the original information, the meaning or intent of the code author. As such, we also have for keeping in same line two words that are connected - when breaking them might be disruptive (such as New York, 10 PM, 10 km/h, § 10, etc)
For this code below, adding width: 100% solved my problem.
.post-cover .inner {
display: flex;
flex-direction: column;
flex-wrap: wrap;
justify-content: center;
align-content: flex-start;
align-items: flex-start;
word-break: break-all;
z-index: 21;
}
.post-cover .article-page {
padding: 20px 0;
margin-bottom: 40px;
font-size: 0.875em;
line-height: 2.0;
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
width: 100%; /* Add this */
}
I tried everything, even putting the below code in the index.css.
* {
min-width: 0;
min-height: 0;
box-sizing: border-box;
}
But nothing worked.
finally I made the div I wanted to shrink past it's content to have position: absolute;. Then it started shrinking.
It's parent div would need a defined height and width. This might not be the best solution for every scenario but if this works for you, good!

Why does will-change:opacity treat fixed elements differently than will-change:transform in chrome?

I am trying to optimize the scrolling of my web app. I have data tables with tons of data, and scrolling gets pretty bad. I added will-change: transform to the data table but it broke my table headers that are position: fixed (I make them fixed to allow them to scroll with the viewport). The elements don't move with the viewport at all, they just stay stuck in the flow of the document.
But by chance I discovered that if I use will-change:opacity instead, my fixed headers are fine. Can someone explain this behavior? I haven't been able to find any documentation that says they should act differently.
Here is a code pen with an example of what I am talking about. Toggle between the values, and scroll in blue div.
https://codepen.io/bkfarns/pen/aLYgrN
Here is the basic code from the pen too:
html:
<div class="container">
<div class="fixed">should be position: fixed</div>
<div class="too-tall">div that is too tall</div>
</div>
css:
.container {
margin-left: 100px;
background-color: blue;
width:400px;
height:300px;
overflow: auto;
will-change: transform;//changing this to opacity fixes the issue
}
.fixed {
background-color: grey;
position: fixed;
margin-left: 150px;
margin-top: 100px;
}
.too-tall {
background-color: red;
width: 90px;
height: 600px;
}
The whole point of will-change is to make all possible changes that browser would have to apply when the specified property will change in advance, reducing the time needed for the change itself. Effectively it means that by specifying will-change:transform you make the element transformed (though visually it stays in the same position), and descendants of the transformed elements can't be fixed per the CSS Transforms spec. Opacity doesn't have such effect, so will-change:opacity doesn't break fixed positioning.
Also, will-change per se doesn't have any "optimization magic", it only optimizes the changes of the specified properties. Some properties force the elements to the composite layers that theoretically can be processed by the GPU more efficiently, but if there is too many such elements it may have the opposite effect. For optimizing scrolling, probably other strategies would be more efficient.

jQuery-ui's resize functionality fails to interact properly with the flexbox model in chrome but succeeds in FF and IE

I have made a div which is split in two columns with a handler in between. The user can drag this handler right or left and the column widths will adapt accordingly (one column will widen, the other will become smaller and the total width will remain constant).
How I tried to accomplish this can be found in the following jsfiddle example: minimal working/failing example. If you test this with one of the latest versions of FF or IE, you will see that this works as intended. In Chrome, however, the handler becomes invisible.
I think this might have to do with an interaction between the flexbox model and the way jquery-ui's resize functionality works (which uses css positioning tricks). I have found some hacks (setting position to relative and left position to 0) in order to overcome this. I think Chrome reacts differently on these hacks than FF/IE.
Can anyone explain to me what is going on or hint me in the right direction for solving this?
ps: This question is where I got the ideas for the hacks
HTML:
<div id="container">
<div id ="left">left</div>
<div id ="resizable">
<div id="handler" class="ui-resizable-handle ui-resizable-w"></div>
<div id="right">right</div>
</div>
</div>
JavaScript:
$("#resizable").resizable({handles: {'w' : '#handler'}});
css:
#container{
background-color: black; /* we are not supposed to see any black but we do in Chrome indicating that the handler of the resizable box is not visible(in IE and FF everything works as intended) */
display: flex;
flex-direction: row;
height: 100px;
}
#resizable{
display: flex; /* a flex box itself so the right panel can take all space not taken by the handler */
flex-direction: row;
width: 50%;
/* hack to ignore the absolute positioning done by jquery ui */
left:0 !important;
position:relative !important;
/* removing this completely destroys the functionality in IE and FF */
}
#left{
border-right: 1px solid yellow;
background-color: darkred;
flex : 1;
text-align: center;
}
#right{
border-left: 1px solid yellow;
background-color: steelblue;
flex : 1;
text-align: center;
}
#handler{
background-color: green;
width:5px;
/* hack to ignore the absolute positioning done by jquery ui */
position:relative!important;
left:0px!important;
/* removing these makes the handler visible in chrome but makes it not pixel perfectly positioned in FF and IE as can be derived from the yellow borders being invisible */
}
check this UPDATED Fiddle
I just change it a little bit as below
#container{
...
position:relative;
}
#handler{
...
position:absolute!important;
}
Actually, your problem is quite simple. It's that of inheritance.
What you can do is set resizable to:
height: inherit;
and it works. Alternatively you can also set it to "100%".
Why does this happen? I am not certain; my guess would be that this has to do with the flexbox specification. I am a bit old school and I don't like flexbox at all (though it will rightfully become the standard soon if it hasn't yet). Its specification is a bit tricky. For example the way it works on chrome is that height takes the percentage of the parent container which is explicitly specified.
Now you specify height on "container" and on "handler", but since the parent of "handler" ("resizable") does not have a height specified, it probably uses the 100% of the default chrome value of height which is "auto".
That would be my guess. As to why it is invisible, you can be certain that it's an issue with height/positioning in flexbox setting on chrome.
I tried it on chrome and firefox and it seems to be fine - here's the fiddle.

Reverse HTML Layout

I will try to keep this as short and specific as I can.
This is what I need to display:
-----------------------------------------
#div1
-----------------------------------------
-----------------------------------------
#div2
-----------------------------------------
This is how I need the HTML structure to be:
<div id="div2">...</div>
<div id="div1">...</div>
The reason I need the second div to be higher in the HTML structure is because when the page is printed in Firefox, I have to use fixed position for an image that is contained in "div2". If "div2" isn't at the top of the structure, the image will be printed on the second page, and therefore cannot be moved to the first page using fixed position (as far as I know).
I cannot for the life of me think how I can do this with CSS2 (maybe CSS3?). I also looked into "Any Order Column" but I don't think that will work since I'm dealing with rows, not columns.
Any help would be appreciated :)
Edit: #div2 cannot be positioned absolutely because #div1 needs to be able to collapse, and therefore #div2 needs to follow.
For this you can use css3 display:box property for this. Write like this:
.outer{
-moz-box-direction: reverse;
-moz-box-orient: vertical;
display: -moz-box;
}
Check this http://jsfiddle.net/phSfD/2/
You can do it like this.
HTML:
​<div class="outer">
<div class="a"> [div a] </div>
<div class="b"> [div b] </div>
</div>​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​
CSS:
.outer { position:relative; }
.a { position:absolute; top:100%; }
​Test it out: http://jsfiddle.net/phSfD/1/
The benefit of this approach is you don't need to know the sizes of either element for it to work.
This works because the height of the outer element is determined by the height of its contents. Since div A is absolutely positioned, it doesn't affect the height of its container, so the container's height is the same as div B's height. Setting A's top to 100% (of the container's height) means it will appear just below the container (and therefore just below div B).
One way to solve this is to set absolute positioning of the two divs. You'll need to have a parent with relative position and then set the absolute position of the two divs: div1 above the div2.
When you do so, remember to indicate in the <style> tag that these styles only apply to the on-screen rendering and provide a separate set of styles for printing, so that on print div would would appear below div2.
When you set position: fixed on an element, it is positioned relative to the browser window, irrespective of its container.
So, this
#div1 img{ position: fixed }
and this
#div2 img{ position: fixed }
will render the same result. You can write them in any order.
You can use display: table-*-group properties for vertical reordering of blocks of arbitrary height (dynamically resized in particular):
<style>
#example {display: table; width: 100%; }
/* Will display at the bottom of pseudo-table */
#block-1 {display: table-footer-group; }
/* Will display in the middle */
#block-2 {display: table-row-group; }
/* Will display at the top */
#block-3 {display: table-header-group; }
</style>
<div id="example">
<div id="block-1">First</div>
<div id="block-2">Second</div>
<div id="block-3">Third</div>
</div>
Works in all browsers including IE8+ (there is a small limitation in IE8).
For IE6/7 (if they do matter), elements can be swapped with JavaScript.
For details, see my article.

Categories