I have quite large text (font size 28) I'm trying to align vertically in a fixed-height container.
I'm doing this by eye and just setting a margin-top so that it gets to the right spot. However, when in Firefox, I need a margin-top of 20px, in Safari I need like 15px (else it's too far down). I saw that the discrepancy was because in Safari the text element is taller than in Firefox and includes a slight amount of whitespace on top that doesn't show up in Firefox (in Firefox, the top of the text element is exactly when the text starts).
I've tried all kinda of display combinations with line-heights and perhaps adding a width/height for the text and whatnot. Nothing works.
What can I do to make this consistent? I'd hate to use JS but it seems like the only option...
For cross-browser CSS normalization I'd recommend a reset - YUI3 has a good one, Twitter Bootstrap is another good one. It basically sets paddings and margins to 0 so all browsers will behave and only adhere to YOUR css rules and not their own default rules.
For vertically aligning text to containers, if it's a single line of text, use the line-height property, and set it to equal the height of the container.
For example:
CSS:
div {
height:300px;
width: 400px;
line-height: 300px;
font-size:28px;
background-color:#F0F0F0;
}
HTML:
<div>
Some vertically centered text
</div>
Example: http://jsfiddle.net/Djvv7/
You need to apply a css reset. Good practice to use one on all projects. The most famous I know of is: http://meyerweb.com/eric/tools/css/reset/
Related
I've been trying to find/prevent why my page is freezing at Firefox, I'm using Chrome's Developer Timeline to track the layouts and paints (freezing doesn't occur at Chrome, a huge issue at Firefox with ~300 UI tiles on the page)
It's understandable that gifs cause paints at each frame (a much much larger paint area than the gif itself, unfortunately) - however I don't understand why Chrome reports a "whole document" layout before each frame - since the size of the gif is constant, it should only cause paints in my opinion
I'm guessing these "whole document" layouts are causing firefox to freeze when there are many elements on the document
(I've researched reflows/layouts, repaints in depth, however none of the articles cover gifs, by looking at the timeline, I would say gifs are major resource hogs)
After more careful inspection and testing, I was able to prevent full document layouts by utilizing a gif container div, such as:
<div style="position: absolute; right: 0px; top: 10px; width: 45px; height: 15px; overflow: hidden">
<img src="/gif_url" style="vertical-align: top"/>
</div>
The issue was probably occurring because of the gif's positioning, happens with both float:right and position: absolute, even when the img element has fixed height and width of it's own (might happen with other positioning styles too)
I didn't dive into the issue too deeply to see what triggers the full document layouts and what not, however, it seems like a good idea to wrap every gif with a blocker div to be sure that browsers calculate partial layouts (I'm guessing there might be a combination of styles that might be able to achieve this inline, but I haven't pushed it yet)
- EDIT (after much inspection) -
It turns out the root cause is Bootstrap 2.3.2's default "max-width: 100%" style for img's
Removing that definition seized layouts caused by gifs
If there is going to be even one gif on the page, that style should definitely be removed / cancelled - otherwise at each gif frame the whole document is being laid out by the browser (chrome in this case, possibly others too)
I've been trying to create a couple of typical layout examples using Singularity, and I have a question about grid-span and floats.
I've created a sample scss stylesheet and html layout. Here's the complete example on Sassmeister.
http://sassmeister.com/gist/a7ca98b7520b12bd6241
My question is whether the containing content div <div id="content"> is necessary? I'm having to use it with a clearfix mixin in order to 'pull' the div down and keep the footer below the content section and aside.
Is there another way to achieve this layout with Singularity, without having to use the surrounding clearfix div? Is there an option for grid-span in the main section that will either not use a float, or self clear this section?
To understand your problem you have to learn how floats and clearing work.
0.
When you float an element, it is removed from the flow. It's vertical height does not count when calculating the height of the container.
1.
The intended usage of floats is to add images to a long sheet of text. The text would wrap around the floated image and increase its overall height and stretching the container vertically, just like an object submerged into water increases the height of water surface.
Before:
After:
2.
If the floated image is located very close to the bottom of the text, it will pop it's bottom out of the bottom of the container, just like an iceberg exposing it's top from the water.
3.
Now imagine that your text is comprised of paragraphs and each paragraph starts with a title. When there's an image floated at the bottom of a paragraph, the image would stretch into the next paragraph, pushing the next paragraph's title aside.
4.
If you don't want that to happen, you apply clearing to paragraph titles:
h2 { clear: both; }
This basically tells the titles: don't let floated images push you aside, let them push you down instead.
5.
But web pages have become more than formatted text, and HTML/CSS didn't provide any means of formatting layouts. So we started using floats for layouts. It's ugly, it's like using wallpaper to sew your clothes, but we have no better option (until Flexbox becomes a thing, and it seems to already).
What happens when you float all content in a container? There will be no flow left, no text to stretch the container vertically, and it's height will be zero (plus border and padding):
6.
You already know that in order to make containers regain their height (wrap around the floated content) we have to apply a clearfix to the container. But what a clearfix actually is?
When you apply a clearfix to a container, you use :after in CSS to create an additional element within the container, after all it's content. Then you apply clearing to the little mother fcuker:
.container:after {
content: '';
display: block;
clear: both;
}
7.
Now back to your question! What's the alternative of using the clearfix?
You've probably have guessed already.
If you've got got content below the floated element, simply apply clear: both to the next element below the floated one! Just like we did in #4 for paragraph titles.
In your case:
footer { clear: both; }
And here's a demo: http://sassmeister.com/gist/df8af8a3c7f8d3df2796
I'm having a problem on a website with Safari 7 (on OSX).
The website address is:
<Edit: Address not valid anymore. Sorry.>
If you click on vertical newsletter button, on the right edge of the content box, an overlay will pop-up.
This overlay looks good on most browser, but there is a problem with safari.
The overlay content is an absolutely positioned box of fixed width. It contains a div with the class "bg", which is a div with CSS position set to fixed and CSS top, right, bottom left set to 0.
The desired (and normally obtained) effect, is that this bg box sizes up to the width and height of the viewport. In safari, it just behaves as if it had it's position set to "absolute" - it just sizes up to the width and height of the container div.
Is this a known issue with Safari? Is there a bug filed? An update?
I could probably fix that by rewriting small parts of the HTML, CSS and JavaScript (if someone has an easier solution, you're welcome to share it!) but I'd like to understand what's happening at first.
I'm not sure what's going on with that positioning thing, but here was my approach to get the same result across the browsers:
#overlays .overlay { /* line 1081 */
...
width: 100%;
height:100%;
...
}
#overlays .overlay .content.text { /* line 1185 */
...
margin:0 auto;
...
}
You could use Z-index but Z-index is not reliable with position:fixed, as shown in this fiddle: http://jsfiddle.net/mZMkE/2/ use translateZ transformation instead.
transform:translateZ(1px);
on your page elements.
EDIT: In your code, Add this css:
.bla, .projects, .contact {
-webkit-transform:translateZ(1px);
-moz-transform:translateZ(1px);
-o-transform:translateZ(1px);
transform:translateZ(1px);
}
and then remove z-index refs from those elements and .intro.
Also You can try in other browsers as well
I have a div class set up with the following CSS style:
div.multiple_choice{
border: 1px solid black;
max-width: 300px;
max-height: 200px;
overflow: auto;
}
The problem is, when the text inside doesn't force the DIV to reach the maximum height of 200px, the vertical scroll bar still shows up. I can click on the up and down arrows but it only moves the contents up and down by about a pixel or two.
This is occuring in Google Chrome (version 18.0) and Iceweasel 11.
As it turns out, another CSS style was causing the issue:
body{
line-height: 1;
}
Anyone interested in learning about how and why this would cause an issue, can read about the line-height property here
I was having an issue with this, and I found that having position: relative on the child elements was causing the problem. Obviously this can't be the solution for everyone, especially if position: absolute is being used, but for me it worked.
Just to put in evidence the #Kuba Orlik's solution (he posted as comment on the accepted answer) that's the only one that worked for me.
Add this on inside elements:
line-height: normal;
Note: Explicitly normal not 1 because it's different
I have encounter this problem.But I solved this use the following css style:
div.yourcontainer{overflow-y:auto;}
If the container was higher than max-height,the vertical scrollbar will show.
I had this problem when trying to wrap a list (flex column) of react components in a div, I resolved it by changing margin of elements within each list item to be 0.
The approach to troubleshoot this for me was to inspect the list items (perhaps each <li> in OP) and see what styles were making the div think each list item was larger than what was visible to the human eye.
Here is an example of inspecting a rogue margin on an icon within a list item in my project:
Solution is to set the style of that icon to have a vertical margin of 0, though in my application I just made all the margin 0 and added some padding-right.
I also had this problem using Bootstrap and nav. It occurred because bootstrap definds the li in nav-tabs as: .nav-tabs > li { margin-bottom:-1px; }. To counteract this, you must also do:
.nav-tabs > li:last-child {
margin-bottom:0;
}
Without setting the last-child, the following example would always show scroll, no matter how much content is in the list:
<ul class="navs nav-tabs nav-stacked" style="max-height:80px;overflow:auto;">
<li></li>
...
</ul>
I came across this bug earlier today. In my case a list of child elements had display: inline-block instead of display: block. Switching to display: block for my list of child elements in the truncated div fixed the issue for me.
In my case, the problem was with the font. We use font-family: Galano Grotesque. Apparently, this font is rendered higher than the computed height.
<div>
<p>some text</p>
</div>
So even without max-height, when the inner p and the outer div were both computed as 20px height, there was still a scroll bar (with overflow: auto) because the font was about 1px higher than expected.
So the solution can be any one of:
Use a different font.
Add padding to the outer div. This way it will be large enough to cover the extra pixel that comes from the font. In my case, adding one pixel of padding to the bottom and one to the top solved the problem.
Set line-height to a bit larger value (in my case, from 1.25 to 1.4), so it won't interfere with the font.
Set line-height to normal because then the actual value will be influenced by the font. However, according to Mozilla, this is not the preferred way.
The reason for the vertical scroll is obvious: the scrolled content is higher than scrolling area. But when you observe their heights, they are equal!
The causes are multiple but all come down to a common one: an element inside the scrolled content overflows it and makes the result taller.
How to fix this?
find the guilty element by looking near the bottom edge of the scrolled element (or to the right if you're scrolling horizontally), because they are the most likely to overflow. You should observe a height larger that their parent's.
see what makes them overflow, be larger than their container. As other answers suggest, it can be line-height, some margin, etc. Change those properties to make them fit, or as an alternative, set overflow-y: hidden to their immediate parent.
I'm running into a vertical positioning problem with a couple of elements on a page in Firefox 5. When I set a line-height on a piece of text, and give it an equal height, it doesn't center vertically the way it should. Instead it sticks to the top of its line-height.
The page in question is here: http://www.tyndale.ca/~missiodei/
Here are the two problem elements along with their CSS. In both cases the text is pushed up in FF5 but displays properly (vertically centered within its line-height) in Chrome/Chromium.
the large title link in the banner (#blogtitle a)
position:relative;
display:block;
margin:0;
padding:0;
color:#fff;
text-decoration:none;
letter-spacing:.1em;
font-family:"Palatino Linotype", Palatino, serif;
font-weight:bold;
opacity:0.6;
height:120px;
line-height:120px;
any of the drop-caps that float at the beginning of new sections of body text (p.openingPar:first-letter)
font-size:3em;
font-weight:bold;
position:relative;
float:left;
height:48px;
color:#ccc;
line-height:48px;
margin-right:4px;
You might not see these drop caps unless you look at the page using Chrome or Safari, since most of them aren't showing up at all in FF. (I'm not sure why these styles aren't being respected either).
Finally, it would be helpful to know whether this is a problem unique to FF5 or whether 3.6 and 4.0 have the same problem. I don't have any old versions of FF available for quick testing.
Thanks ahead of time for help. I've imprinted my keyboard on my forehead bashing my head over this one!
The vertical centering seems to work fine for me....
The lack of first letter styling is https://bugzilla.mozilla.org/show_bug.cgi?id=8253
Try using <span class"dropcaps">W</span> instead of styling your opening first letter in the paragraph by selector :first-letter. Let us know if it works.