Imagine CSS like:
.x {
background: blue none;
border-radius: 6px;
}
and HTML like:
<div>Words and <span class="x">decorated</span> words</div>
The height of the span reading 'decorated' is going to vary wildly between different browsers, and between different OSes running otherwise the same browser.
Is there any way to make it be the same height?
(I don’t want to move to inline-block or sacrifice the text using exactly the same baseline.)
My experience with avoiding of different height is setting exact line-height and font-size
Sounds like there is something else causing your problem. I just tried a basic html5 document with the snippits from your question and compared the alignment on Windows with Chrome, Safari, FF & IE. They all rendered exactly the same except for IE9 which had a 1px gap above the span only.
Granted Mac renders fonts differently from Windows, and I didn't test on linux or mac, but 9px!!!??? Here are some things I'd investigate:
First, try a basic test file if you are working in a larger project, this will limit your variables.
Second, try setting explicit fonts and ensuring they exist on all of your test machines - perhaps linux is falling back to a different font.
Third, make sure you are not zoomed in or using a custom font size browser setting on any of the browsers (I ran into this one a while back where somehow my IE was set to 105% zoom.)
Finally, if all of that fails, you might want to try using a web font (#font-face) and see if that renders more strictly.
Edit:
In lieu of the new information in your comment, another strategy would be to use JavaScript to inspect the rendered heights of some off-screen elements and then programmatically adjust styles accordingly. You'll probably get a huge FOUC, but you can use a whiteout div to minimize the shift.
Related
So this is a doozy...
Our QA department reported a bug that only exists in Chrome in Windows 8. Works fine in all other browsers on all other platforms. The bug? Text within a span element drops down well below where it should be placed, almost the entire height of the element trying to be aligned.
I was working from home when this was reported, so I actually freshly installed Windows 8 on my iMac and installed the latest Chrome -- same version tested by QA -- but could not reproduce the bug. Everything aligned perfectly. Tried every possible screen resolution available and all was great.
So I'm back in the office today, and a QA guy handed me the laptop with Windows 8 installed, and wouldn't ya know it? The text is not aligning properly. It's a Lenovo Ultrabook. The one difference, though: a touch screen. But even disabling the touch screen (and verifying through the dev console that Chrome no longer recognizes the touch screen) didn't fix the problem.
Neither Chrome installation had any add-ons.
What should I be looking for?? Here's the code:
<div id="text_container">
<span style="padding:0x;" class="textName" id="text_page">Problem Text Is Right Here</span>
</div>
Now...the "text_container" CSS consists of:
margin: 0;
padding: 0;
width: 1024px;
"textName" is defined with:
font-size: 10em;
margin-left: 1.55%;
opacity: 0.7;
position: absolute;
text-transform: uppercase
top: 0.8em;
#text_page has no CSS defined. Again, all looks PERFECT except on the one Windows 8 device on Chrome, a touchscreen laptop that doubles as a tablet.
Thanks for your help, folks. Even though the suggestions didn't help, I still appreciate the time.
Anyway, I fixed the issue, and yes, it was based on my observation that the font size was measured in "em". Now, I've been doing web site programming of some kind of another for literally twenty years, and this definitely falls under the "learn something new every day" category...
I always use "px", but again, the person who coded this wanted the font to be scalable, so "em" was the way to go. Now, what I didn't know was that "em" calculates itself based on the base font size...and since the base font size wasn't defined, I guess it's up to the browser to decide on what the base font size should be. Using the dev tools, it seems that the browsers were defaulting to 16px as the base font size...
...except for Chrome on the Windows 8 laptop we have, which was setting the base font size to 24px. Upon further examination, the laptop has a pretty freakin' high screen resolution: 3200 x 1800, so I'm guessing that had an effect on it somehow. It would also explain why I couldn't reproduce the problem on Chrome in Windows 8 on my iMac -- my iMac only goes up to something like 1920 x something, so I couldn't get nearly the screen rez.
So I went into the CSS and set the body's font-size attribute to 16px, and that fixed the problem.
May be the default value of the vertical-align property on your span tag is not set, so it is defaulting to "baseline".
According to the HTML spec, <span> is an inline element and <div> is a block element. Now that can be changed using the display CSS property but there is one issue: in terms of HTML validation, you can't put block elements inside inline elements so:
<span>...<div>foo</div>...</span>
is not strictly valid even if you change the <div> to inline or inline-block.
So, if your element is inline or inline-block use a <span>. If it's a block level element, use a <div>.
I'm having a tricky CSS issue. This is exacerbated by the fact that the CSS for the "theme" of the web site is third-party (it can't be changed, but we can override with another stylesheet), and everything on the page uses absolute positioning for layout and sizing (this cannot be changed).
Somewhere in this third-party CSS, we have this declaration:
body {
line-height: 1.3;
}
A div on the page has a font-size of 14px, making its line height 18.2px. This is fine for typical web sites. However, since everything is positioned absolutely using pixel positions, font rendering differences are coming into play. Specifically, Google Chrome in Windows is rounding this line-height down to 18px. This means that the large block of content in the div renders substantially shorter in Chrome for Windows than in any other browser. All other browsers seem to support sub-pixel line heights.
Is there any way to force Chrome for Windows to respect sub-pixel line heights so that it doesn't render so differently than other browsers?
Update
Here's a JSFiddle demonstrating the difference. If you compare the heights in Chrome for Windows and, say, Firefox for Windows, you'll see that there's a 0.2px difference per line.
What I would do is changing the line-height to something that multiplies up to a whole pixel. In your case:
line-height: 1.2857142857142857142857142857143; /* = 18 / 14 */
This changes the output only a little, and results in cross-browser compatible result.
I've tested it with your fiddle on Chrome and Firefox on Windows and it works.
I just spent an hour troubleshooting an issue I had were all my paragraph elements were shifted down.
This happened after I moved the design from jsfiddle.net to my web host.
I killed an hour before I finally realized I needed to insert
p{margin:0px;}
and all was well...well still off by 1px;
Questions:
Why did this error not occur in jsfiddle.net?
Why does FF CSS Debugger not let me know that there is a margin in there or where it came from. I don't know what is was set to but it was not 0px;
I'm trying to learn from "my mistakes" so I can know what to expect next time.
Web browsers set their own default values for rendering HTML elements. This includes margins, paddings, font sizes etc. When you create a HTML document with no CSS you can see lists, paragraphs and headings are formatted in a default way.
Debuggers tend to show the values that you have applied to the document in your CSS.
To get around these sorts of inconsistencies (browsers use different defaults) some people use a 'reset' CSS file that removes this behaviour by setting as much as possible to 0.
Take a look at http://meyerweb.com/eric/tools/css/reset/
I'm working on a table that has cells requiring a background with lowered opacity, and text on top not effected by the background. The content in the cells is dynamic.
http://jsfiddle.net/6zszm/3/
In IE9 (have not tested in other IE versions) the background is clipped at the span content. In firefox, the background runs wild and overflows to bottom right. In chrome this works like a charm.
Some similar questions that didn't quite cover it:
How to make <div> fill <td> height
Someone suggests a 1px height to the td - this did not work for me, nothing changed. I would also rather not use JS to fix this problem.
Another somewhat related issue: CSS absolute positioning bug with IE9
The strange thing is in IE9, this worked in compatibility mode, but not without.
This is indeed seemingly impossible - unless you specifically define each cell's width and height, which kind of defeats the object of using a table.
Possbile solutions...
RGBA
Assuming you are going to use background colours you can always use background-color: rgba(200,200,200,0.5) with a fallback to solid colours if it fails. Support for RGBA is in all of the top browsers, it doesn't work for IE8 and below however...
Transparent PNGs
The obvious easy one is to fallback to using transparent PNGs, but then this relies on the colours you are using being predefined and rather rigid.
Use -moz-element
Another mad solution to get FireFox to work (if you are using background images rather than colours) would be to use the background: moz-element() ability. Here you create hidden elements on your page of each different opacity that you might require and reference them as a background via id. For example:
<div id="image1" style="background: url(image1.jpg); opacity: 0.5;"></div>
Then reference that on the element you want the background to appear on:
<td style="background: -moz-element(#image1);"></td>
I'm not vouching for this method however, it's rather inelegant and browser specific. Tbh I'm quite suprised to find that this problem is indeed not fixable (esp. in FF) using plain old absolute and relative tricks.
Don't us Tables
The more browser supported solution by far would be to drop using tables and recreate a table structure using good old divs and floats. The only problem with this solution is again you'd have to define most widths and heights and you wouldn't be able to achieve vertical cell alignments unless you fallback to something even more experimental like FlexBox.
You could try working with a CSS framework, like LESS or Blueprint. Most frameworks have background code that makes your styling look the same in all browsers, even if tweaking would normally be required.
I have been working on a little photo slider. It looks slightly different in Chrome than in FF so I thought a CSS reset would make them both look the same. I used the Yahoo! YUI CSS reset model but nothing changed. It looks good in FF but in Chrome the "Resume" button on the right side sticks up too high and a thin gray line at the bottom of the big pictures gets cut off where the main buttons are located. Here is the URL:
http://www.replayground.com/slider/02.html
You can ignore the stuff below the circles. Just testing stuff down there.
Here is what I added to my 02.html file:
<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.9.0/build/reset/reset-min.css">
I'd really like advice on how to get CSS Reset working correctly. Not how to fix the specific buttons problem you see. As I add elements to the page I don't want to have to go through this each time.
A CSS reset is not designed to make all the rest of CSS cross-browser. It is designed to set all of the client default rules on all the different browsers to the same thing so that you are always working from a predictable set of CSS rules. How the browsers interpret those rules is still specific to each one.
In your case, you still need to figure out how to write CSS rules that operate the same in both Chrome and FF - the reset simply levels your starting point a little, it doesn't remove the browser rendering differences.
You may find a cross browser CSS framework (e.g. blueprintcss.org or 960.gs) to be more helpful for your current situation. They often use a reset, but also have rules that compensate for the differences in the rendering of the after-reset CSS rules.
jball is very right about the resets. They just allow you to start with a blank page, but you should still write a proper document structure and good CSS to get good and consistent results.
In your case, all elements in your page are loose in the page. This will give you trouble in the end. Some things will shift a few pixels, especially when you don't specify exact height for every item. Fonts are rendered in different heights by each browser. These may be tenths of pixes, but when they get rounded, your website is a little off between browsers.
When you use a little deeper nesting of elements, you can make better use of positioning elements (relative and absolute). If you put in a specific div for the header, and give it a fixed size, you can position each element in there very precisely, which is especially handy for headers and menu's.
I took the liberty of creating a small example, which shows just some basics of positioning. It is not perfect and uses brightly colored borders instead of images for the layout. But it's just for showing the element nesting and absolute and relative positioning, along with a negative margin trick.
http://jsfiddle.net/YwCxQ/3/