CSS3 Ch Unit Inconsistent Between Ie9+ and Other Browsers

CSS3 ch unit inconsistent between IE9+ and other browsers

According to caniuse.com, IE interprets 1ch as the width of the 0 glyph, without the surrounding space. This makes 1ch shorter in IE compared to any other browser.

Overlapping divs on IE 9 - working fine on IE9 and other browsers

I didn't look at your js code, but it seems that you created a wrong style when it's loaded in IE 8. Here is the first ul column in your source code.

<ul class="mcol2 li_cont1" style="width: 293px; cssfloat: left;">

Change style value from "width: 293px; cssfloat: left;" to "width: 293px; float: left;", then it will fix the layout issue.

Using em for layout causes inconsistency across different browsers

Keep em or percentanges. They do work.

However, using them for centering is probably part of your issue. Centering should be done with auto, for example:

div.page {
  margin: 0 auto;
  width: 925px;
}

rem, px, mediaqueries for browsers =IE9

I did some testing here : http://codepen.io/Olivvv/full/aGDzI

a few interpretations :

solution 1 : WRONG
html { font-size: 10px;}
prevents the permanent browser/user font-size setting to be applied. If the user has requested a bigger font-size,it should take effect.

See here with the SO website, things break a little with very big fonts, but at least the user gets the font-size increase.

solution 2: OK
body { font-size: 0.8125rem;}
is actually the same as
body { font-size: 0.8125em;}
since the can only inherit from the element "em" as the same value as "rem" ("rem" stands for root em, the em value of the root element, i.e the element)

solution 3: INTERESTING

html{font-size: 62.5%;}
body{font-size: 1.6em;}

---> 1 rem == 10px
(if the browser is set to default, i.e 16px; - (62.5/100)*16 == 10)

Now about the possible strategies :

1. rem only

html{font-size: 6.25%;}
body{font-size: 16em;}

+ only working with rem; for font-size, width, padding, margin, borders. This seems to be the easiest way to go.
Here 1 rem equates to 1px in defaut setting. It responds to user change of the default setting, so it is accessible.
When doing responsive design, the interface can be zoomed by changing the % value of the . for instance:

html

the whole interface is zoomed. Zoom is vertical and horizontal.

div.foo{
font-size: 16rem;
border: 16rem solid;
width: 350rem;
border-color: limegreen;

}

That will create a box that expands both vertically and horizontally.

Issue: What about vertical zoom ?

2. rem and em (in order to get vertical zoom)

rem -> interface elements, width essentially

em -> text (can be resized independently from interface elements (which are in rem) by changing the font-size value on the body)

px -> seperators, borders essentially

This way we achieve interfaces that respond well to both browser zoom and browser font-size setting

Some comments on ideas read on some blogs and

"just use px, if your brain works in pixel" --> Very Wrong. Font-size in px will be unreadable for some users who have explicitely requested bigger font size. (and what about dpi different from 96 ?)

"layout in em" --> average wrong, since a different user font size will make appear horizontal scrollbars or not use the full viewport space. Such behavior relates to zoom, not font size. (note that I am not considering browsers older than IE9 - just let them fall back on their default values )

Cross browser inconsistencies with margins?

It's most likely the em units you're using everywhere for widths, margins and padding. The em unit is based on font size and webkit renders fonts slightly differently than gecko (the same text in webkit and gecko will be different widths).

As a test, change your CSS widths, padding and margins to absolute px values and check if this fixes the inconsistencies.

::first-letter selector - IE11 has a different layout compared to Firefox

This is a well-known discrepancy between Firefox's treatment of floating ::first-letter pseudo-elements versus other browsers, documented in this bug report. Firefox is the only browser that follows CSS2.1 correctly here, which is ironic considering that Firefox is otherwise the browser where ::first-letter is most broken in (Chrome being a close second).

The bad news is that there is nothing you can do to work around this in other browsers without using some sort of browser hack.

The (sorta) good news is that the working group is planning to consolidate this behavior in CSS Inline Module Level 3 with the initial-letter-align property, and we can only hope that browser vendors implement it eventually.

---

Related Topics