Although I'm not new to the idea of responsive design I have experienced a very troublesome thing...
I have decided to completely move to rem units, but I still follow 62.5% rule (I have used it with em).
So for starters:
html {
font-size: 62.5%;
}
I assume that 1rem = 10px (I know it's not always true, but hey, it's for me to ease math a little bit, for browser it's still relative right?)
Horror starts in Opera (12.12 both linux and win version, where default font-size is set to 14px and 16px respectively).
header nav ul li a span {
padding: 1.8rem 2.7rem 3rem 0;
font-family: 'sawasdeebold', sans-serif;
font-size: 2rem;
line-height: 3rem;
letter-spacing: -0.3rem;
display: block;
}
As You can see part of my navigation is let's say "pixel perfect" thanks to using rem units. Under linux page is a little bit narrower (that's no problem the font is smaller so 1rem represents less pixels). However everything in nav scales badly if default size is changed to something else than 14px... Under Windows the same is true for 16px... The whole scaling idea just doesn't work. I don't need every pixel to match, but it looks ugly...
The similar problem appears under IE9, but this time is the logotype where:
header h1 a {
margin: 1.8rem 0 0 1.6rem;
width: 46.2rem;
height: 10.1rem;
background: transparent url(../static/img/logotype.jpg) 0 0 no-repeat;
background-size: 46.2rem 20.2rem;
text-indent: -5000px;
display: block;
}
header h1 a:hover {
background-position: 0 -10.1rem;
}
Even though I set logotype's height and the exact size for its background, on hover, the background is positioned 1px too low...
Aside of these problems I have one, general question.
Is it POSSIBLE to create "pixel perfect" layouts with rem units?
I haven't even touched media queries yet and I want to know if it's worth my effort...
BIG THANKS guys!
So... I have switched back to em untits. Except few (minor) glitches in IE9 (which are well known subpixel problems) everything is perfect in ALL browsers. Moreover, as before rem issue, I have no problem with media queries which also use em units. Sadly, it seems that rem units are not yet stable enough to use them across existing web browsers. Case closed...
If you're wishing to continue use 1rem = 10px have you tried –
html {
font-size: 10px;
}
instead of
html {
font-size: 62.5%;
}
does this solve the issue?
Related
In certain situations html elements that use pixels are not always rendered as imagined, a simple example is when a person adjusts the browser zoom to about "100%", so depending on the position and zoom one element of height equal to the other seems to be a smaller pixel.
One example is the StackOverflow site menu itself, example with "175%" zoom:
Note that the third menu bar appears larger than the others and that the spacing of the first and second bars also appears larger.
This is not just about "zoom", I tested it on a colleague's notebook with Windows10 and GeForce® GTX 1050 card (of course I understand that in part modern computers render with the "integrated card") and it uses in the Windows display settings for the operating system all the value of 125%:
Using this, I realized that the same problem occurs (even with 100% zoom in the browser).
The only displays that I noticed that the problem does not occur are those of retina displays (and similar "technologies"), because they use a higher "pixel density".
But the question is NOT about monitors, displays and market technologies, the question is how to avoid the problem on normal screens when the user adjusts something (like example in Windows10 with 125% on display settings), noting that it varies with resolution and even the monitor and is "unpredictable".
I tried to work with other units of measure (em, pt, rem, %), but the problem persisted.
So here goes my question:
How to prevent pixel rendering on elements from being distorted in display settings that may vary?
An example that the problem occurs (chance adjust the source of the "OS" or the zoom):
*, ::after, ::before {
box-sizing: border-box;
}
body {
background-color: #007bff;
}
.v-navbar-toggle {
vertical-align: middle;
position: relative;
cursor: pointer;
display: inline-block;
background: none;
outline: 0;
border: none;
padding: 10px 8px;
color: #fff;
margin: 0;
}
.v-icon-bar {
background-color: currentColor;
overflow: hidden;
display: block;
width: 24px;
height: 2px;
border-radius: 1px;
}
.v-icon-bar+.v-icon-bar {
margin-top: 4px;
}
<button class="v-navbar-toggle">
<i class="v-icon-bar"></i>
<i class="v-icon-bar"></i>
<i class="v-icon-bar"></i>
</button>
Note: I also noticed that working with svg (depends on how you use it) or icon-fonts works a lot better compared html+css, but what I am trying to solve are problems with simple "html elements".
I search for a long and I can't find an answer :/
In Chrome (Internet Explorer, Konqueror, and many others) the h1 margin at bottom is added to .blue. However, Firefox respect the css rules properly.
Any suggestion?
HTML
<div class="red"><div class="blue"><h1>Hello World!</h1></div></div>
CSS
.red{
background: red;
/* All this contain margins */
float:left;
/* padding-top:1px; */
/* display: inline-block */
/* overflow: hidden */
}
.blue{
background: blue;
min-height: 60px;
}
h1{
margin: 10px 0 20px;
background: green;
}
Gecko-based: [This one is the correct, I guess]
Webkit-based, KHTML-based and Trident shell:
CODEPEN
http://codepen.io/marquex/pen/fzsIk
The margin issue you are having is related with the min-height rule in the .blue div. Replace it for a height rule if it is possible to get the same result in Chrome and Firefox.
I have no idea why that is happening when using min-height though. Maybe is some kind of Chrome's bug.
Define your fonts, this is the problem, every browser have different settings for default fonts, headings (h1...h6) respectively. So the actual height of the text in h1 will be different and this is the cause for different margins at bottom/top.
As you can see, Gecko-based browser uses a sort of Garamond-styled font, all other use by default Times New Roman, of course if user was predefined the fonts for pages, sometimes everything may look the same across all browsers, example:
h1{
margin: 10px 0 20px;
background: green;
font-family: "Your-favorite-font", Times, sans-serif;
font-size: 2em;
}
RESOLVING
After a long search I reported the issue on chromium repo. And they accept it as a bug. So, if anyone wants to know the final of this history can follow the fix process here.
Thanks anyone who try to help us, but let me add that I did not believe that Stackoverflow can be able to not see an error of this magnitude. I am a little less stackoverflowita.
I'm using em units in my site's CSS. When I load a page of the site in Chrome, all the text will load in a very large font size. If I resize the browser window or load the developer console, the font size will then revert back to the 'correct' size. Sometimes if I flick through pages on the site, it will do the same or behave erratically (starting off large, sometimes starting off normal size).
I cannot replicate this in Safari or Firefox, so thinking it must be an issue in the way Chrome is interpreting my CSS or my em units.
Any ideas on why this is happening? If I remove all the em units and use px then it works fine (which perhaps is a solution but doesn't help me understand em).
(Using: Chrome 32, Macbook Air, OS 10.8.5, a custom Wordpress theme).
Some CSS:
body {
margin: 0 auto;
color: #404040;
font-family: sans-serif;
font-size: 1.6rem;
line-height: 1.5;
padding: 1em; }
(if I use font-size:16px here it will work fine, but then what's the point of em / rem)
I had the same problem as you actually. I recently started using rem instead of em and it is much better since you don't have to worry about nested elements, such as list items, multiplying the value. However, I noticed that the font was loading too large and then resizing.
In my CSS, I originally had reset the font using this:
html {
font-size: 62.5%;
}
You're probably already aware why, but this just means that 1em would equal 10px. I then had font-size: 1.4rem in the body to set the base font size to 14px.
To fix the issue you mentioned:
Try setting your html font-size to 10px, not a percentage value, and then use rem from then on. Seems to be working for me anyway.
CSS3 introduces a few new units, including the rem unit, which stands
for "root em".
The em unit is relative to the font-size of the parent, which causes
the compounding issue. The rem unit is relative to the root—or the
html—element. That means that we can define a single font size on the
html element and define all rem units to be a percentage of that.
You can try font-size: 1.6em; /* EM not REM */ but anyway it might not works as far as 1em is equal to the current font size.
You might use px instead or set px in body and use em after.
Needs more info. A live URL would be appreciated.
Can not reproduce using just this code:
body {
margin: 0 auto;
color: #404040;
font-family: sans-serif;
font-size: 1.6rem;
line-height: 1.5;
padding: 1em; }
http://jsfiddle.net/wZD4n/
The filter bar on my site - http://grailed.com is rendering differently in Chrome on Windows and Mac even though Chrome says the height is 31px on both.
Here is an image of the Mac rendering. This is how I want it to show up.
Here is an image of the PC rendering. Zoomed in on the offending area.
On top of that the globe icon and the dollar sign are at differing heights. I have no idea where to start with this issue, any tips would be appreciated!
Let's take a glimpse at your CSS (after being run through an un-minimizer, and using some of the DOM inspection tools of different browsers):
.filterhead {
text-align: center;
cursor: pointer;
background-color: #e1e1e1;
padding-top: 10px;
}
...
h3 {
font-family: "SackersGothicStd-Heavy";
text-transform: uppercase;
font-size: 13px;
letter-spacing: 6px;
padding-bottom: 5px;
padding-top: 4px;
color: black;
font-weight: normal;
}
The majority of the height of your header is defined by the the "padding-top: 10px" setting as specified by the filterhead class. Padding-bottom is 5px as specified by h3. And the font size is effectively 16px. (10+5+16 == 31).
Change the padding-top attribute of .filterhead from 10px to 5px and it starts to look like what originally showed in the pic representing the Mac rendering. That should probably do it for you.
But no matter what, I'll never be able to rock that $500 dress shirt with the hearts printed on it that you have for sale on your website. That takes some serious stylin' to pull that look off.
http://assets3.grailed.com/uploads/photo/image/11138/display_upload_2F1393376651400-xu5dk1ezfx-b4c0f2f9854185bc01c09e5a9b232221_2F
Try using CSS to specify the size an margins.
Here is a link to the page that is giving me trouble:
http://youtube.thegoblin.net/layoutfix/
If you view the website in firefox and chrome you can see that the spacing is different. The way it looks in chrome is the way I meant it to look.
I have tried linking in the YUI 2: Reset CSS as it as suggested in another question, but I cannot seem to get it to work.
Here's the stylesheet link: http://youtube.thegoblin.net/layoutfix/styles/style.css
You should change line-height on some elements that contains text. These are line-heights for some (maybe all) elements you need to change:
#title: 56px
.yoText: 46px
#buttonTitle: 68px
#buttonText: 34px
Looks like browsers count differently line height for font you choose, so defiantly line-height could make it better.
Just short example, not full fix:
#dl-button #buttonTitle {
color: #37590B;
float: right;
font-family: "TallDark";
font-size: 600%;
line-height: 0.7;
margin-right: 60px;
margin-top: 20px;
text-shadow: 1px 1px #BDF277;
}
makes green button much better, so you may play around with others the same way.