I have tried everything within my repetoire to fix this. I fall on my knees with open hands!
You can view a draft of the page here:
www.barrettcv.com/draft_so.html
If you would like the gist of how the page should work, simply view it in Firefox (with browser window smaller than 992 and scroll down. The side panels start off attached, and then 'fix' to become static while the rest of the content moves. This is the correct behaviour
Main problem.
The problem arises in Chrome. When the menu column and the details column 'fix,' (scroll down the page a little) all digital hell breaks loose.
Secondary problem.
When the view window is about 1200px, the space between the menu column and the main content panel doubles up. This isn't as big a deal as the first problem (which has had me attempting to destroy my flat's retaining wall with my forehead) - but it's got me relatively flumoxed, as I'm sure there must be a more elegant solution that forcing it back into position with media queries
It looks like you are coming up against an issue in how the different browsers calculate the position of fixed position elements when no positional CSS properties are defined for the element e.g. top and left. From the spec:
...user agents are free to make a guess at its probable position.
For the purposes of calculating the static position, the containing
block of fixed positioned elements is the initial containing block
instead of the viewport...
I think the only way around this is to choose a different positioning scheme. You can remove the .col-md-pull-* and .col-md-push-* classes and reposition the Bootstrap columns by using absolute positioning (depending on media queries to arrange those columns how you want for different viewport sizes). In this case it appears all browsers honour the position of the fixed element.
.row {
position: relative;
}
/* apply to the details column */
.push-9 {
position: absolute;
left: 75%;
}
Example: http://bootply.com/92096
What you need to do is to fix both left and right column, starting from that you will have a much better way of controlling your divs (since you want them fixed as I can see).
So, sumarizing: you need to add position:fixed to both your left and right columns. Modify your left: x% and right: x% so that they match your criteria.
Related
The HTML below specifies a button and a div that have identical class and contents.
<div class="root"><!--
--><button class="outer"><div class="middle"><div class="inner">label</div></div></button><!--
--><div class="outer"><div class="middle"><div class="inner">label</div></div></div ><!--
--></div>
In this example, I have explicitly set every CSS property1 for the classes outer, middle, and inner2.
This means that both the button.outer and div.outer sub-trees of the DOM should have completely identical CSS settings. Presumably, as well, no CSS properties for these elements are getting their values from anywhere else besides the provided stylesheet.
As the example shows, the side-by-side button and div look quite different. Specifically, in the button, the label appears at the bottom of the element, whereas in the div it is vertically centered. (The label is centered horizontally in both cases. Also, note that all the classes have the setting vertical-align: middle.)
I have observed this difference with all the browsers I've tested so far (Chrome and Firefox).
Since there is no difference in the stylesheet settings for the button.outer and div.outer elements, and their descendants, I figure that the difference in their appearance is due to some CSS property with a value (such as auto or normal) that gets interpreted differently by the browser depending on the whether the context is a button or a div element.
My immediate goal here is to understand sufficiently well why the button and the div are being rendered differently so that I can adjust the CSS intelligently.
My longer term goal is to make CSS coding more predictable. Currently I find that my CSS is completely unstable due to gross inconsistencies like the one shown in the example.
My question is:
how can the difference in appearance between the button and the div be explained?
1 As reported by Chrome's devtool.
2 I took the vast majority of the values for these settings from Chrome's devtool's listings. The point was to ensure that both the button and the div elements had the same setting (whatever it may be) for each CSS property.
This is likely due to different meanings for the value of auto for the position of elements inside of a button. If you expand the size of a div, the content by default will be in the top-left corner. If you do the same for a button, the content will be centered horizontally and vertically.
Since the button's top and left values for auto is to be centered and not in the top left corner, you can reset top and left to always act like a typical div would. These are the properties to change on .middle:
.middle {
top: 0;
left: 0;
}
Here's the forked JSFiddle with those changes to .middle.
Different elements have different default settings. There is an enormous amount of CSS in your demos, and it's largely overkill and very hard to determine where exactly the differences in rendering are coming from.
Have you tried a CSS reset instead? These will resolve most of the discrepancies between elements and browsers, giving you a blank slate to add your own styles.
how can I determine the property (or properties) that account for the difference in appearance between the button and the div?
By clicking through them one by one and toggling them on and off in Dev Tools. If you turn off position:absolute on the middle class, you'll see what you're probably expecting in layout. I found this by clicking through all the properties in the Elements > Styles panel. See:
https://jsfiddle.net/vfdd9p8L/
This is probably a bug that you're encountering. Browsers have lots of them! By layering on so many styles at once, you're probably backing into a weird corner case with respect to the layout algorithms. To isolate the bug for help and/or reporting, try to create a reduced test case, which creates an unexpected discrepancy, but using the minimal number of elements and declarations.
(Also note that your fiddle is including jQuery CSS, which includes Normalize, which is a whole other layer of styling.)
I have a unordered list of thumbnails that work on every other page except one. On this one particular page, there is a large amount of whitespace on the third row. See below:
I don't get why it is doing this, it happens even if you take away padding and margin. The page that this is doing this on is http://bransonweekend.net/cabins/trailsend
This is because you are using:
.picture-board .pinned-photo img {
max-height: 160px;
}
and in that row the first image form factor makes it go the max-height but the other two are too wide so the height is less than the max 160px.
try adding this:
.thumbnails>li{
min-height:172px;
}
this will make sure they are the same height even if they are too wide
Try out this library:
http://masonry.desandro.com/
It's useful in cases like these, where elements have to line up on a grid. Masonry is used all over the internet.
This probably was answered somewhere, but I can't find it :s
My question is about dynamic resizing of divs based in percentages.
Please look at code example below for the examples and possible solutions I made.
I ask if there is a better way to do resizing?
More detailed explanation:
Say I am writing a plugin that people can insert in their pages. (Imagine login form).
I go ahead and design the plugin's divs. I use media queries to achieve desired look for different devices. I work on a div straight inside of a 'body' element.
I use percentages for design (I like percentages). Say I set div to 80% width.
Now I give this plugin to the user. User goes ahead and puts the plugin's div inside of another
div that is 100px in width. Now everything looks awful. (80% of 100px is not a lot [80px]).
And of course I want user to put my plugin inside of whatever small-width divs that he have.
The solutions I saw so far to this problem was to create a holder div of certain width - say hardcode 300px. (ex - jQuery UI's Datepicker div; Meteor's login widget div). And then code to it always knowing the 300px width that I set before is not going to change.
But I don't know how good of a solution this is.
Moreover if I decide to go with hard-coding width, my plugin would need width of ~ 1000px. Because I want div to resize with media queries.
And if I go with hard-coding width (say holder div of 1000px width) and put it on a page, the page will have horizontal scrolling. And you cannot simply hide holder div (parent div) and have child to show at the same time. So this requires setting position:relative for holder (parent) div, putting it outside of window, and use same for child div - position:relative with same offset in opposite direction of parent offset.
I hope I am being clear so far and have not confused you!
A code example to illustrate what I am talking about:
http://jsbin.com/ifawez/18/edit
#cimmanon's comment cleared things out for me.
The problem is with lack of HTML/CSS "tools" available at the moment. Since responsiveness came into play fairly recently there are not a lot of CSS-native tools to accommodate changes in dimensions.
For instance media-queries exclusively work with width of window/document and not of other elements such as divs.
The solution I currently employ is using Javascript to determine width of a div and resize accordingly.
What I resize is the number of columns I want to display (I use Multi-Column module as suggested by cimmanon) which is pretty stable on webkit browsers. Since it is all done in Javascript (and jQuery's Sizzle) I keep an array of sizes like so:
var widthArray = [
{min:0, max:250, columns:1, secondary:false},
{min:251, max:350, columns:1, secondary:true },
{min:351, max:479, columns:1, secondary:true },
//more div sizes
];
// more code here
$(element).css({
"column-count": object.columns,
"-moz-column-count": object.columns,
"-webkit-column-count": object.columns
});
This is sort of like media-queries, but allows to work with width of html elements, not screen size alone.
Additionally I follow the way jQuery UI displays its components: using position relative/absolute.
.outer_div {
position: relative;
}
.inner_div_with_elements {
position: absolute;
z-index: 1010;
width: 99%;
float: left;
overflow: hidden;
...
}
.inner_components_displayable {
position: relative;
display: block;
}
.inner_components_hidden {
display: none;
}
So in Summary:
Media queries alone work with size of screen, and resizing of any inner element can be done in percentages to the screen size. They can be of huge help, but you turn into making your components work either with percentages based off screen, or specifying something like min-height and !important (as suggested by #Octavian)
Javascript manipulation of elements is currently easier, but is a costlier alternative (jQuery SIzzle is pretty slow)
A lot of libraries (ex. jQuery UI) use Javascript together with position relative/absolute to make sure their components/plug-ins will work nicely on all users' screen sizes.
I ended up combining position with javascript to emulate media-queries and multi-column design at the same time for responsiveness.
Thanks everyone who participated!
If I am reading this correctly, the main issue here is that it can potentially become too small based on where the code is located.
So why not just add a min-width property with !important? That way you can still base the size off of the parent container, but be sure that it doesn't get too small and ugly.
Potentially, you could even have a script to base the width off of the parent div and the min-width off of the screen size.
I have a %-based grid with a fixed-width (for the moment). The code is based off of this css-tricks article: http://css-tricks.com/dont-overthink-it-grids/
Works great until I have a column that has multiple responsive images in it that are the same size and need to be stacked next to each other (floated). Because of padding issues and what-not, I can not get all three images to come out the same width and height, despite the fact that they start that way. The last one is always taller. Here is a codepen showing the issue: http://codepen.io/joshmath/pen/dEuIv
Any help with this would be really appreciated. I've run into this issue before and always just end up hacking my way through it on a case-by-case basis. Thanks!
For whatever reason, if you remove the padding-right: 0 style from the last element, it fixes the issue.
It looks like you're trying to add spacing between the elements using padding. What I tried instead using the Chrome dev tools was to use a margin instead of padding, and then slightly reducing the width of your elements to around 29.5%. That seemed to work.
just add the following to your css. set the size to whatever you like and all images within your grid will remain that size, if they need to grow / shrink use height/width percents instead.
.grid img
{
width: 350px;
height: 400px;
}
First up, for extreme clarity, here a JS fiddle demonstrating what I'm trying to achieve:
http://jsfiddle.net/bb_matt/VsH7X/
Here's the explanation - my rationale:
I'm creating a responsive site using the 1140 grid framework.
It's a fairly complex layout.
I've created a re-usable simple gallery class which can drop into any defined column size & using media queries, I apply relevant percentage widths to the li elements.
Each of the li elements has a right margin of 5%.
I'm using nth-child(xn+x) in the media queries to remove the right margin at the end of each row.
Everything works well - images resize as the layout resizes, the number of gallery items in a row work as I've defined based on percentages.
The only remaining issue to fix is to clear between rows.
I can't add additional html markup and I want to steer clear of overly complex jquery fixes.
I know of two ways to fix this, but I'm not keen on either of them.
First fix, simply using display: inline-block on the li elements, with a vertical align of top, would flow everything correctly... however, all the percentages get shot and the gallery items no longer neatly fit in the allocated space.
Second fix, give the list items a height. This is the route I will go down if necessary - it will require a different height depending on the resolution - no big deal, but not as neat.
I updated your fiddle here: http://jsfiddle.net/VsH7X/5/
I added a clear: left to the first item in each new row.
ul.gallery li:nth-child(5n+6) {
clear: left;
}
Keep in mind that the :nth-child pseudo class does not work in IE6-8, or FF3 and under.