I'm using Font-awesome in my project, and every icon is aligned in the middle of the line. On Chrome, Firefox and IE, They are aligned corretly, but on Safari, the icon drop around 3 or 4 pixels.
I inspect the icon and in every browser, they are render and ocupate the exactly space they should be. But in Safari, they are rendered with extra top size, a transparent padding on top of the icon. It's not vertical-alignment or line-height problem, the character itself have this "transparent padding" on top.
That seens silly, but on a huge project, every icon is aligned 3/4px down than it should be give me a lot of headache.
One possible reason is that you have a different default line height in the different browsers. Try explicitly setting this to see if if it makes a difference:
CSS
i{
line-height:20px;
}
or even
i{
display:inline-block;
}
depending on the specifics of your styling, you might need to also set a class on the i tag, e.g.
i.icon-class{ ....}
Good luck!
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).
This may sound strange, but I don't understand how designers determine the image widths in their bootstrap layouts.
Consider the following template:
http://startbootstrap.com/templates/blog-post/
The 900x300 placeholder image is clearly not 900 wide on desktop 1080p monitor. It only ever gets shown full size when the browser is around 1000px wide.
Q) Am I being dense here? How are these widths determined/decided upon?
This is important as I want to make some designs using bootstrap, but obviously I want to make sure I select appropriate image widths.
Many ways to do this, but simplest is to use Chrome's "Inspect Element".
1) Right-click on photo and choose "inspect element". Scroll down until you see diagram of it's dimensions, padding etc
2) Adjust browser width to max out photo width (in your example it's between 990px and 1200px)
2) Keep editing the the placehold.it image-width until the inspector diagram stops changing photo width (see attached photo). This tells you the max threshold, in this case is 940px.
FYI, you can also try to determine knowing your column widths, padding, margins, and assuming you have properly reset nested column padding, but there is a lot of assumption and calculation there, so I tend to use the inspector method, at least to confirm.
The WP responsive theme I'm working on:
http://www.wpexplorer.me/tetris/
I use Firebug for Firefox browser addon thingy to make changes before messing with the actual files. So if you have it or something similar, you will see that by adding position:fixed; to the #header section the header width shrinks well more than half its original size and the navigation menu is jacked up within the new shrunken space.
I have added other snippets of coding to the #header section like width:100%;, width:959px; and other percentages and pixels, which messes up the layout; especially when you resize the window down to what you would consider to be for a tablet and a mobile device - it's all out of whack. I can't get the sticky header for this theme to function or do right. Oh, I've also added z-index:200; to the #header section and margin:160px 0; to #main-content; these don't give me issues.
Adding the width: ; code to the #main-content doesn't seem to help either (which I read somewhere online that this was where the width code goes).
Anyway, does anyone know what code I need to make the header of this theme scroll up until it gets to the top of the page where it becomes sticky/static/fixed/on top (whatever the real term for it is) at all times? And, can you get it to work with the layout being in tact when the window is resized all the way down to the size of a mobile device?
Thanks.
This should work
#header-wrap{position:fixed;top:0;z-index:999;}
#pre-header{margin:20px 0 15px;width:960px;}
#main-content{margin:215px 0 30px;}
The position is fixed at the top using 0 with a z-index:999 you then need to set the width of the inner container pre-header 960px to match the rest.
You will need to setup the media queries for the other sizes you have setup. Easy, and Enjoy.
If you want the menu itself and not the social icons to become the top fixed bar without the social icons then you want to make a jquery scroll CSS change so that the #header becomes the fixed position.
It working with fixed header and social:
An illustration of it working without the social bar using a Jquery Scroll CSS change:
This is the way I would do it, I would move the menu down, and add the social icons to the menu itself. (Below is a screenshot of what I mean, the social icons are reduced to 75%)
PS. The social icons stand out to much so I would add a CSS3 Greyscale, and when the visitor hovers over them it turns on the color with a transition effect.
Hope this helps ;)
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.
I'm working on a Firefox extension, and am having problems getting relative constraints on the width of elements in the sidebar. For example, I want a description element in the sidebar that will always be as big as the sidebar when the sidebar is resized, and has text wrapping accordingly.
If I put a description in a box with a fixed maximum width, it will wrap correctly, but I can't get relative widths to work correctly using css. If is set the max-width to be 100% in css, it seems to just ignore it and the text will be on a single line and will overflow the sidebar. Any suggestions on how to put relative width constraints on a box in XUL so that text will wrap correctly?
It sounds like setting maximum width isn't what you really want. Have a look at https://developer.mozilla.org/en/XUL_Tutorial/The_Box_Model, setting flex attribute would be the right approach to make an element fill all the available space (typically flex="1"). The corresponding CSS property would be -moz-box-flex: 1.