Long time lurker, first time asker! I'm unable to find what I want after a few nights of searching.
I'm looking for very standard bootstrap behavior.
Greater than/equal to 760px width resolution, I want fixed width.
Below 760px width resolution, I want the two lists to stack and take 100% width.
The problem is that above 1200px there is a different fixed width. I tried to fix this by making setting the .container class a fixed width, but then the sub 760px is also fixed --- no longer fluid. I've also tried using media queries.
Here's the code I'm working on: http://travelprobiotics.com/
Any suggestions?
thank you,
Evan Jerkunica
If you are hosting bootstrap yourself, you can't go wrong using bootstraps customization tool found here.http://getbootstrap.com/customize/
Look under the 'Media Queries Breakpoint' section and changed the screen-sm to 760px. (it is already defaulted to 768px so if you're OK giving away the 8 pixels, skip this step and use the code snippet below by itself.)
After that, add this snippet below in your own stylesheet, set the container to whatever width you want to be 'fixed'
#media screen and (min-width:760px) {
.container {
width: 960px !important;
}
}
Related
Think I'm missing the obvious here, but I have a Bookstrap 3 navbar that works great in desktop view but as I squeeze the width and it gets to tablet size rather than collapsing into the toggle menu it's jumping the menu onto two lines:
http://www.doorsets.org.uk/
I've tried reducing the text size in the navbar via a media query but that isn't solving it.
What am I missing?
Appreciate it. Thank you.
NJ
One solution might be to change the point at which the navbar collapses, you can do this by creating a customized Bootstrap and setting the #grid-float-breakpoint to a larger number.
This variable unfortunately also influences the dt and dd inside a .dl-horizontal which might be a problem.
If you want to use a media query to reduce the font-size you can use the .navbar-default .navbar-nav > li > a selector. It however needs to become 9px at the smallest viewport size to still stay on a single row which is quite unreadable.
From the Bootstrap documentation:
Overflowing content
Since Bootstrap doesn't know how much space the content in your navbar needs, you might run into issues with content wrapping into a second row. To resolve this, you can:
Reduce the amount or width of navbar items.
Hide certain navbar items at certain screen sizes using responsive utility classes.
Change the point at which your navbar switches between collapsed and horizontal mode. Customize the #grid-float-breakpoint variable or add your own media query.
It goes on to say:
Changing the collapsed mobile navbar breakpoint
The navbar collapses into its vertical mobile view when the viewport is narrower than #grid-float-breakpoint, and expands into its horizontal non-mobile view when the viewport is at least #grid-float-breakpoint in width. Adjust this variable in the Less source to control when the navbar collapses/expands. The default value is 768px (the smallest "small" or "tablet" screen).
Please have a look at http://www.bootply.com/133473.
I have at least a couple of problems and I didn't find any solution up to now...
First problem:
The leaflet map is 0px height and the next row is not in the correct position.
Second problem (but maybe it is related to the first one):
On a small device the width of the map is the full width but I'd like to have a margin and I wasn't able to get it (I tried but margin-left, margin-right and padding-left, padding-right...) and of course the text row is superimposed to the map and that's not what I want...
Looking at your bootply posting, it looks like your first problem was solved (I see the map so the height must not be 0px).
As for your second problem, it is the Bootstrap Editor that is not able to show your app on smaller screens. This problem may go away when you view your app on its own web page.
I'm working on an iPhone app where I'm using Pixate:
navigation-bar back-indicator {
background-image: url(backIcon.png);
background-size: 25;
}
This results in:
however its not centered with the Back text. How do i get the image to move down slightly?
Ive tried background-top-padding however that simply squashes the image down.
Any ideas? Thanks.
After playing around with padding options, it seems like anything larger than the default indicator height (22pts) cannot be pushed downward with padding.
If you want to create a smaller back indicator, you can account for an increased padding by adjusting the height (or width) accordingly, like so:
navigation-bar back-indicator {
background-image: url(custom_arrow.png);
background-size: 17 19;
background-bottom-padding: 2;
}
Also, it's worth noting that adding right padding to the back indicator will not move the back button text right, so you won't be able to fix the horizontal overlap in your particular example with padding on the back indicator. However, several examples from Apple drop the text altogether when using large indicators, so you might want to consider this as an option.
There is a large amount of white space below my flexslider and I do not know how to remove. I have played with the CSS quite bit and nothing seems to work, without breaking the "responsive" behavior. Any help is greatly aprpeciated.
Regards...
Site can be viewed here, all code in located in the head tag:
http://destinjustlisted.com/new/
Your div which contains the slideshow items must have the class "flexslider." Various things are setup for that class in flexslider.css, which is part of the download. One of the CSS properties it has is "margin." You'll see three values there. It looks like this:
margin: 0 0 60px;
I don't know if you're familiar with this property format, but it's common in CSS when you've got 4 settings, as with margin, border, or padding (all of which have 4 sides). You can have up to four values which represent: top, right, bottom, left (like you're going around a clock dial, starting with 12 o'clock). So, for example:
padding: 0 1px 0 2px;
would give no padding on the top and bottom, but 1 pixel on the right and 2 pixels on the left.
The flexslider CSS has 60 pixels of margin on the bottom. That leaves room for the navigation buttons if you want a visual representation of where you are in your slideshow or for you to select a specific slide. Unfortunately, if you set the property "controlNav" to "false" when you're setting up the plugin if you don't want to show those "buttons," then you just end up with the big blank area under the control. If you just set that property to this:
margin: 0;
all your problems will be solved!
If your images are different sizes (heights in particular), the Flexslider container will display as high as the tallest image. This can create the gap that you might see.
If this is the cause, resize your images in advance so they all have the same heights and widths.
Is this an Opera bug? Please compare this jsfiddle jsfiddle.net/n5hBf/1 with this one jsfiddle.net/n5hBf/2 You should see the difference in the height. Those two jsfiddles are the same except in the first one I set styles in one statement and in the second jsfiddle I set them one after the other. That works well in other browsers but not in Opera, so you'll definitely need the latest Opera to see what I am talking about.
EDIT:
Well, now I think it is not actually a bug but rather the way how word-wrapping is handled by Opera. It differs from how it works in other browsers such as FF, Chrome, and IE. If you add word-wrap: break-word; to the textarea element, you'll see what I mean: http://jsfiddle.net/n5hBf/5/
EDIT 2:
Problem:
Say, if we have a textarea element that is 100x100 in size and contains too much text to be fit inside the textarea element, the text will overflow, thus enabling the scrollbar(s) to appear.
Goal:
In the two jsfiddles, I was trying to expand the textarea element to the size that is large enough to accommodate the content without the need in scrollbars.
Wrong solution:
The first jsfiddle behaved badly in Opera because it expanded the height too much than needed. The second jsfiddle worked well in Opera (meaning that it changed its size to the actual dimensions needed for the content; not much, not less), though the result in Opera differed from what I could observe in the other browsers. In the other browsers, only the height got changed. The result was wider in Opera as it changed both width and height.
Understanding:
As I figured out, by default Opera doesn't break long words into lines but instead it adds a horizontal scrollbar. While the other browsers do break them into lines. Also, browsers render it so that the scrolling is added only for the sake of those long words while the rest of the content occupies the same width... And then I got the clue!
Right solution:
I understood that the actual dimensions of the content were defined according to the initial textarea's size, so one of the dimensions turned out to be invalid once we changed the other one. That is, if we change the width the height is no longer actual because the content spreads over the new width making itself shorter in height. That explains why the second jsfiddle worked as intended: firstly I got the new width and applied it, then the content occupied the new dimensions, and only after that I got the new height and applied it. So, if we need to change both width and height, we need to firstly change the width and only then change the height. In browsers other than Opera it was only needed to change one dimension, so there was no difference whether the styles were changed in one statement like in the first jsfiddle or they were changed in two statements like in the second jsfiddle.
The only reason it breaks in Opera is because it's the only browser that doesn't use word-wrap: break-word by default on textareas. So it's not a bug, simply a result of a different default style.
If you add word-wrap: normal to the textarea CSS in your fiddle it will break in the same way in the other browsers (except in IE, where it breaks in a different way).
Without word-wrap: break-word, the width is different from the scrollWidth, which means that changing it will affect the scrollHeight.
However, by doing this
$textarea.css({
width: $textarea[0].scrollWidth,
height: $textarea[0].scrollHeight
});
both the scrollWidth and scrollHeight are evaluated first before they are actually set. That means that that change in the scrollHeight which would be caused by changing the width is not taken into account.
Setting the width and height in separate .css() statements one after the other will mean the scrollHeight will have been updated before it is set.