I have a CSS rule which is working in all browsers but IE. When I check it in the IE inspector I can see that the rule is not being applied.
.wrapper:after {
content: '';
display: table;
clear: both;
}
Any idea why this rule is not being applied in IE?
I'm testing on IE 11, 10 & 9. I'm working on a Magento app.
I was able to solve this issue by re-writing the css rule to:
.wrapper:after {
visibility: hidden;
display: block;
font-size: 0;
content: " ";
clear: both;
height: 0;
}
I don't understand why the previous rule did not work on IE, while it worked in all other browsers. The previous rule was being inherited from the Magento RWD theme.
Also, it seems that the IE inspector crosses out all :after rules, which is misleading as some of them are actually working on the page.
Related
Chrome on macOS and Chromium on Linux don’t sensibly position the caret when clicking inside an editable area for larger line heights.
In this example, we set a value for line-height for <span> elements. Leaving it off and inheriting from the parent element is not possible because of other app requirements, mainly the use of Quill.js rich text editor. There may be multiple <span> per line with differing font sizes, but no nested elements.
p {
display: inline-block;
margin: 0;
background: lightgrey;
}
span {
line-height: 2.5;
font-size: 50px;
background: lightblue;
}
span.small {
font-size: 25px;
}
<p contenteditable><span>some </span><span class="small">text</span><br/><span>some text</span></p>
In Firefox, if you click into the gray area (marking the <p> element), the caret will always be positioned at the nearest character. If you click between lines, the caret also positions sensibly.
In Chrome, the caret positions at the nearest character only if you click inside the blue area (marking the element). In the grey area, the caret ends up at the start of the next line, or at the end of the last line if you click below the last span.
How can you replicate the Firefox behavior with Chrome?
Note: giving the spans a display: inline-block as recommended here does not solve the problem.
As you already know, it has to do with Chrome and how it deals with line height.
Although, I have written a workaround that seems to work well on Linux (Chrome, Firefox) as well as Windows (Chrome, Firefox, Edge).
With vertical-align: text-bottom, all lines seem to work as intended except for the first one. So the idea is to add a line break (and negate it afterwards with font-size: 0)
p::before {
content: "\A";
white-space: pre;
display: inline;
}
p::first-line {
font-size: 0px;
}
This works pretty well on Chrome (both Linux and Windows), but on Firefox I didn't manage to negate the extra line break. So, since it was initially working nice in the first place I used a firefox-only rule to hide the extra line break.
So, we have our workaround working on Chrome and Firefox (both Windows and Linux) but Edge had some difficulties with vertical-align so (once again) I used an ms only rule to unset the vertical-align.
Result (working on Chrome Windows/Linux, Firefox Windows/Linux, Edge Windows)
p {
display: inline-block;
margin: 0;
background: lightgrey;
}
span {
line-height: 2.5;
font-size: 30px;
background: lightblue;
vertical-align: text-bottom;
}
p::before {
content: "\A";
white-space: pre;
display: inline;
}
p::first-line {
font-size: 0px;
}
/* Firefox only */
#-moz-document url-prefix() {
p::before {
display: none;
}
}
/* Edge only */
#supports (-ms-ime-align:auto) {
span {
vertical-align: unset;
}
}
<p contenteditable><span>some text</span><br/><span>some text</span></p>
UPDATE
At the updated testcase, that you have multiple font sizes per line, you will need to skip vertical-align: bottom|text-bottom and compromise with having the extra space "allocated" to the line below (only in Chrome - Linux).
Note that you will still need the aforementioned "hack" for the first line in order to have a consistent behavior between all lines.
Have a look at this codepen for the updated testcase.
I've created a simple church directory in which I edited the CSS to change one of the default Map Markers to one of my own. The issue that I am having is that the Map marker is displayed correctly on Chrome and Safari but not Firefox IE or Edge.
copticchurch-directory.org
Code
/*
Theme Name: Listify Child
Theme URI: http://astoundify.com/themes/listify
Template: listify
Version: 1.0
*/
.job_listing-rating-wrapper,
.map-marker-info .rating,
.single-comment-rating,
.star-rating-wrapper {
display: none !important;
}
.type-job_listing.style-grid .job_listing-entry-footer {
display: none;
}
.ion-information-circled
{
content: url(http://copticchurch-directory.org/wp-content/uploads/2016/08/Map-Marker1.svg);
}
.ion-ios.information-circled
{
content: url(http://copticchurch-directory.org/wp-content/uploads/2016/08/Map-Marker1.svg);
}
.ion.md.information-circled
{
content: url(http://copticchurch-directory.org/wp-content/uploads/2016/08/Map-Marker1.svg);
}
The problem is with the use of the content property on regular elements. Use instead the background property, which will have better cross-browser support.
Change the following:
.ion-information-circled {
content: url(...);
}
Into this:
.map-marker .ion-information-circled::before {
content: "";
background: url(...)
}
https://jsfiddle.net/eyvetdz4/2/
For my input, which can either have classname="half" or "half.not-placeholder-value", Firebug shows both inputs to have a set, fixed width of 25em.
input.half, input.half.not-placeholder-value {
max-width: 25em;
}
Yet, according to Developer Tools, IE8 doesn't seem to use this particular max-width attribute. I say "doesn't seem to use" since Firefox's behavior differs with IE8 with respect to this attribute.
But the MDN docs say that IE7 supports max-width. Am I missing something?
This is not really an IE8 issue since IE8 does support the max-width attribute but only when given a defined width first.
input.half, input.half.not-placeholder-value {
width: 100%;
max-width: 25em;
}
Use IE8 css with width? First part targets IE, second part undoes it for IE9+.
input.half, input.half.not-placeholder-value {
max-width: 25em;
width:25em\9; /* IE 8 */
}
:root input.half, input.half.not-placeholder-value {
width:inherit\9; /* IE 9+ */
}
I've been scratching my head looking for a solution to this "common gap problem".
Here's what the page's like in Chrome & how the page is like in IE9 https://dl.dropbox.com/u/3788693/Work/example.jpg
Here's my HTML file: https://dl.dropbox.com/u/3788693/Work/01index.html
I've read lots about using and applying
Setting position:relative on the header block.
Setting position:absolute; top:0; right:0
#header img { display: block }
But it just doesn't seem to show any change in IE. Perhaps i'm applying the wrong things in the wrong place? Anyhow, why is it different in IE in the first place?
In your conditional comment for IE you're using
<!--[if IE]>
<style type="text/css">
/* place css fixes for all versions of IE in this conditional comment */
.twoColElsLtHdr #sidebar1 { padding-top: 30px; }
.twoColElsLtHdr #mainContent { zoom: 1; padding-top: 15px; }
/* the above proprietary zoom property gives IE the hasLayout it needs to avoid several bugs */
</style>
<![endif]-->
Removing padding-top: 30px from .twoColElsLtHdr #sidebar1 and padding-top: 15px from .twoColElsLtHdr #sidebar1 will take care of the gap you're seeing.
I am having cross browser problems with this site, can someone explain to me why it's not working in Firefox but does in google chrome please?
When an image is clicked, the text is not positioned correctly in Firefox
http://dl.dropbox.com/u/2306276/problem/index.html
I think it has something to do with
display: table;
but I do not know why.
thanks
Change these bits of your CSS:
div.container {
height: 215px;
line-height: 215px;
width: 215px;
text-align: center;
}
div.child {
display: inline-block;
margin: 0;
position: relative;
vertical-align: middle;
}
It's normally safer to avoid display: table-* where possible.
You're seeing https://bugzilla.mozilla.org/show_bug.cgi?id=10209
It's also fixed in Firefox nightlies; the fix will ship in Firefox 10.
try to set "position:relative" it may work