I'm using the bootstrap affix js plugin and it works great. The problem I'm having is when I change the body to use a custom font (Google: Lato) it throws the anchor positions completely off.
The affix links lead to bad positions on the page and the page no longer lines up with the affix sidebar when scrolling. It's always off by 100px or so.
ie.
body { font-family: 'Lato', helvetica, arial, sans-serif; color: #221e1e; font-weight: 300; line-height: 150%; }
I'm sure there's another way to compensate for the new smaller font or line-height, but I haven't found it.
If I raise the line-height on the entire body to say 300, it works ok, except that the spacing is horrible. So I tried to adjust the line height on only the titles holding the anchors.
h2 .mw-headline { line-height: 330%; }
And it almost works, except it's still off on the first link and it feels kind of hackish. I'm sure there's a proper way to handle this, I'm just not sure what that is.
You can probably fix this using Bootstrap's custom variables if you're using less or sass.
In your case it'd something like:
#baseFontFamily: 'Lato', helvetica, arial, sans-serif;
#textColor: #221e1e;
#baseLineHeight: 20px;
Find more variables here: http://twitter.github.com/bootstrap/customize.html
Related
I have a problem with certain CSS applied to my website. I use some CSS to set the color, size and alignment of text. It works fine on the desktop browser, everything looks how it is supposed to be. The problem happens only when I load the page on my android chrome. At certain times it shows the CSS properly, but after I refresh it, the text becomes much smaller. Yet, some other text on the page that uses the exact same CSS does not change at all.
Note that the following CSS property is only applied to a mobile phone screen size. I use the CSS Media Queries to do so.
Here's the CSS I am applying:
.list {
color: white;
padding: none;
display: block;
margin-left: 0px;
margin-right: 10px;
text-align: left;
font-family: Segoe, "Segoe UI", "DejaVu Sans", "Trebuchet MS", Verdana, sans-serif;
font-size: 100%;
}
It also happens with some other CSS on the page. It keeps on changing upon refreshing the page.
Added information:
This is what it is suppose to look like.
This is how it looks like most of the time.
Both list uses the exact same CSS properties.
Please do provide me with some help. Thank you.
The main reason is that you are using % try rem. You may need to do mobile queries for font sizes on other screen types.
font-size: 100%;
change to:
font-size: 1.8rem;
This could be too big
Because you're using a percentage for font size, it's based on the size of the parent container. A better approach is to use rem or px. Here's a nice article explaining all of your options
I am trying to rebuild this website in Polymer: http://qprogrammers-mockup.webflow.io/. So I can extend it easily in the future. I have everything down and I am using the same font, font-weight, font-size and I checked this with a chrome extension whatfont?.
But the fonts seems different. The example website is still much sharper. I read the css, but I cannot find out why. I also added:
body {
background-color: e8e8e8;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing:grayscale;
font-family: 'Open Sans', sans-serif;
font-weight: 300;
}
Given your example, I cannot tell how much more CSS you have. But this may just be a case of you not invoking the webfont Open Sans and your browser is reverting to whichever sans-serif it is using. You could add the following line to the top of your CSS and see if it makes a difference:
#import url(https://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,600,600italic,700,700italic,800,800italic);
Finally, you are missing a '#' on your background color property:
background-color: #e8e8e8;
I'm experiencing the following issue in both Safari and Chrome.
body {
font-size: 15px;
line-height: 1.2;
}
body, .same-font {
font-family: Helvetica, sans-serif;
}
code {
font-family: Courier New, sans-serif;
}
<ul>
<li>Without any code - 18px height.</li>
<li>With <code>code</code> - 20px height.</li>
<li>With <code class="same-font">code.same-font</code> - 18px height.</li>
</ul>
Run the above snippet and the inspector. You can notice that the code element doesn't have anything modifying its font-size or line-height except body which it's inheriting from.
It's not adhering to that inherit though, because the height of its containing li is 20px, not 18 like the others... I'm not sure where that height is coming from, because the code element itself has a height of 17px (which is also of unknown origin).
When the normal/body is applied to the code element (like on the third list item), it goes back to 18px like normal. To me this means it's not any other properties that the user agent has imposed on the code element affecting the height - solely the font-family.
EDIT: For reference, something in StackOverflow's styles prevent this behaviour. The following list items all have the same height:
One
two
Three
EDIT 2: Apparently not.. if you change their monospace font to Courier New then the same problem would persist.
How can this change in size be prevented? i.e. How can you specify a line height that will be used even if the fonts within that line continue to change?
An example use case would be in a design with vertical rhythm - each line's height and the total height used by an element should be a multiple of 18px (i.e., if using that grid size) - a 20px line throws off the rhythm.
I ended up solving my own problem (to an acceptable extent) by simply tweaking with the font family and size until it worked for me:
body {
font-size: 15px;
line-height: 1.2;
}
body, .same-font {
font-family: Helvetica, sans-serif;
}
code {
font-family: Menlo, Courier New, sans-serif;
font-size: 0.9333em; /* 14/15 */
line-height: 1.28571; /* 18/14 */
}
<ul>
<li>Without any code - 18px height.</li>
<li>With <code>code</code> - 18px height.</li>
<li>With <code class="same-font">code.same-font</code> - 18px height.</li>
</ul>
Why Menlo?
I noticed that StackOverflow used Menlo and that didn't have this problem. When I tried it, it also solved the problem, however the font isn't built in on Windows.
So simply using Menlo solved the problem on Mac and didn't change anything on Windows.
Why the different font-size?
The different size changed nothing (except the font size...) when Menlo is in use - it still adhered to the line height, so Mac is all good.
However this font-size in combination with the Courier New fallback on Windows somehow got it adhering to the line height there too!
If I used 14px instead of 0.9333em it'd still work fine, but if I used 18px for the line-height instead of 1.28571, it wouldn't work. That doesn't bother me as I use relative values in my designs anyway.
So...
The Menlo font in combination with a Courier New fallback with a different font-size worked to solve my problem to a good-enough extent on Mac (Safari and Chrome) and Windows (Chrome).
My situation is lenient - a pixel difference wouldn't break my design, but just my rhythm. In cases where pixel perfection is required, I wouldn't feel safe with this voodoo method of playing with fonts and sizes...
If anybody can still explain where all of these numbers are coming from and what makes the actual difference here, that'd be great.
I've been playing around with the simple alt examples here -https://github.com/goatslacker/alt/tree/master/examples/todomvc
I can't figure out how to resize it though - I've tried amending all the likely looking candidates within the css files but nothing seems to do the trick. What am I missing?
thanks
Adjusting the size and layout is done in base.css file. So in this app React does not know much about layout and sizing (I like a lot this approach). It is up to the style sheet to decide how to present a given component. There are some other strategies to use style tag for React where your component layout will be somehow more attached to your React environment (personally I don't like that).
On the other hand, the overall design on this todomvc application is not great. First of all, it not responsive. And I believe there is a lot of fixed positing, which makes it harder to customize.
To fix your issue and ajust the width of your application, open base.css and change the body style width:
body {
font: 14px 'Helvetica Neue', Helvetica, Arial, sans-serif;
line-height: 1.4em;
background: #eaeaea url('bg.png');
color: #4d4d4d;
//this is the property you need to change to adjust the width
width: 1000px;
margin: 0 auto;
-webkit-font-smoothing: antialiased;
-moz-font-smoothing: antialiased;
-ms-font-smoothing: antialiased;
-o-font-smoothing: antialiased;
font-smoothing: antialiased;
}
Generally speaking I would not use this css as a reference implementation, but only the alt code. I would create a new css implementation based on flexbox.
I ask this because when I try to create a CSS font stack for multi-language content, such as English and Chinese, the final rendering is affected by the first font in the stack (usually Latin ones, since most Chinese font comes with Latin support).
See this Codepen, for example.
div.a p {
overflow: hidden;
}
p {
background-color: red;
border: 1px solid black;
display: inline-block;
}
.chinese-only {
font-family: "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.english-chinese {
font-family: "Avenir Next", "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.chinese-english {
font-family: "Hiragino Sans GB", "Avenir Next", sans-serif;
font-size: 24px;
line-height: 48px;
}
What I am seeing:
Since Chinese glyphs only appear in the Hiragino Sans GB, I expect all Chinese blocks to use the same line height. But they are apparently affected by adding the Avenir Next font at the top of the stack.
Since both Firefox and Chrome on OSX renders my example the same, I wonder if the CSS specification mentions anything about this. CSS 2.1 fonts spec doesn't appear to state what to do with line height when you fallback on missing glyphs.
Updated: Safari does render differently, but unfortunately the difference is due to overflow: hidden, not glyph fallback. My updated example may show this a bit clearer.
On Chrome and Firefox
On Safari
And if you are really into font-related headaches, try this example showing different font stacks, and see how they differ on each browser.
This is pretty much going to come down to the user agents. Any time the CSS specification says, “not defined by this specification”, that’s code for “we’ll let browsers do whatever they think is best and then try to get them all to behave consistently after a few years of doing it differently”.
Furthermore, the latest CSS Inline Layout Module states right at the top of Section 1 (Line Heights and Baseline Alignment):
This section is being rewritten. Refer to section 10.8 of [CSS21] for the normative CSS definition or the 2002 Working Draft if you want pretty pictures. (But ignore the old text, half of it’s wrong. We’re not specifying which half, that’s to be determined.)
That’s from last month. So, you know, good luck and Godspeed, basically.
Interestingly, I see a different result in Safari 6.2.2 than you posted:
If there’s a difference between that and the latest Safari, you might be able to track down a bugfix between the two versions that explains why it changed.