Checkbox tick displays as dots in Edge browser - css

I have a checkbox styled like so:
input[type="checkbox"] {
position:relative;
top:0.5em;
-webkit-appearance: none;
height: 1.25em;
width: 1.25em;
margin-right: 5px;
vertical-align: top;
}
input {
margin:0 0 0.2em 0;
border-radius:0.1em;
border:1px solid #d2d2d2;
padding:0.8em;
box-sizing:border-box;
font-size:16px;
color:black;
}
input[type="checkbox"]:checked::before{
content: "\f00c";
font-family:"FontAwesome";
position: absolute;
font-size: 1em;
left: 0.15em;
top:0.3em;
text-align: center;
width: 1.25em;
color: #678b4f;
}
Jsfiddle here.
It appears nicely in most browsers and until now, it seems to at least fall back to something useable in more awkward browsers that ignore -webkit-appearance.
However, in Edge, the checked version of the checkbox appears as a very small dot (rather than font awesome tick) that is barely visible. If I remove -webkit-appearance, that displays something useable but that then breaks it in the webkit browsers.
Anyone know how I can fix/get around this?

It is actually not a dot, its a super teeny tiny checkbox, because of the padding on the input. If you change it from 0.8em to 0.1em, you will see what i mean.
Moving the padding from the input element to the input[type="checkbox"]:checked::before selector it will work in all browsers the same.

The problem is that Edge actually supports -webkit properties, but the behavior of -webkit-appearance is unexpected (probably a bug). It seems that adding this property allows you to style the checkbox to a certain degree, but the original checkbox is rendered nonetheless. Interestingly despite setting the value to none the DOM inspector shows that it remains checkbox:
Microsoft's documentation says the following about -webkit-appearance: none:
Default. The appearance of an element is not changed.
Note that it says "not changed" when you would expect "not rendered". The docs seem to be about IE, so I'm not sure if it's relevant for Edge as well or at all.
One possible workaround is a hack, that only targets Webkit browsers. Add the selector body:not(*:root) before the actual selector:
body:not(*:root) input[type="checkbox"] {

You can try this
#supports (-ms-ime-align: auto) {
input[type="checkbox"] {
width:51px;height:51px;
}
input[type=checkbox]::-ms-check{
color:red;
border:0;
background:rgba(0,0,0,0);
}
}
This is for IE Edge #supports (-ms-ime-align: auto)
This is for checkbox when checked input[type=checkbox]::-ms-check

Related

Control pseudo-element style on element:hover [duplicate]

I'm re-asking this question because its answers didn't work in my case.
In my stylesheet for printed media I want to append the url after every link using the :after pseudo-class.
a:after {
content: " <" attr(href) ">";
text-decoration: none;
color: #000000;
}
In Firefox (and probably Chrome but not IE8), text-decoration: none is ignored, and the underline stretches unattractively across the bottom of the url. The color however is correctly set to black for the url. Is there a way to make the text-decoration work?
The original question appended fixed size images instead of variable width text. Its answers use padding and background images to avoid having to use the text-decoration property. I'm still looking for a solution when the content is variable width text.
If you use display: inline-block on the :after pseudo, the text-decoration declaration will work.
Tested in Chrome 25, Firefox 19
IE8's implementation of the :before and :after pseudo-elements is incorrect. Firefox, Chrome and Safari all implement it according to the CSS 2.1 specification.
5.12.3 The :before and :after pseudo-elements
The ':before' and ':after'
pseudo-elements can be used to insert
generated content before or after an
element's content. They are explained
in the section on generated text.
...
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification
The specification indicates that the content should be inserted before or after the element's content, not the element (i.e. <element>content:before content content:after</element>). Thus in Firefox and Chrome the text-decoration you're encountering is not on the inserted content but rather on the parent anchor element that contains the inserted content.
I think your options are going to be using the background-image/padding technique suggested in your previous question or possibly wrapping your anchor elements in span elements and applying the pseudo-elements to the span elements instead.
I had the same problem and my solution was to set height and overflow:hidden
http://jsfiddle.net/r45L7/
a {
text-decoration: underline;
}
a:after {
content: "»";
display: inline-block;
text-decoration: none;
height:16px;
overflow: hidden;
padding-left: 10px;
}
It works on IE, FF, Chrome.
As an alternative, you can use a bottom border rather than a text-decoration.
This assumes that you know the color of the background
a {
text-decoration: none;
border-bottom: 1px solid blue;
}
a:after {
content: "foo";
border-bottom: 1px solid white; /* same color as the background */
}
1)
:after{
position: absolute;
}
is not perfect, because element content will not wrap
2)
:after{
display: inline-block;
}
is not perfect, because sometimes we wish after content should always wrap with last word of element content.
For now, I could not find find a perfect solution fits all 3 conditions(1. content could auto-wrap if it's too long 2.after content should wrap with element content, which means after content should not occupy single by it self. 3.text-decoration should only apply on element condition not apply to after content.)
I thoughts for now is using other way to mimic text-decoration.
What I do is I add a span inside the a element, like this :
<span>link text</span>
Then in your CSS file :
a::after{
content:" <" attr(href) "> ";
color: #000000;
}
a {
text-decoration:none;
}
a span {
text-decoration: underline;
}
The only thing that worked for me was declaring a separate repeated selector with the same text-decoration property that it was inheriting from its parent, then in the main selector, setting text-decoration to none.
IE apparently does not know what to do when you set text-decoration: none on a pseudo element without that element having the text-decoration property declared (which by default, it has nothing declared by default). This makes little sense because it is obviously being inherited from the parent, but alas, now we have modern browsers.
span.my-text {
color: black;
font-size: 12px;
text-decoration: underline;
}
span.my-text:after {
text-decoration: underline; // Have to set text-decoration here so IE knows it can be overwritten below
}
span.my-text:after {
color: red;
text-decoration: none; // In the same repeated selector, we can now overwrite text-decoration in our pseudo element.
}
I realise this isn't answering the question you're asking, but is there a reason you can't use the following (background-based approach):
a.file_pdf {
background-image: url(images/pdf.png);
background-position: center right;
background-repeat: no-repeat;
padding-right: 15px; /* or whatever size your .png image is plus a small margin */
}
As far as I know, the Firefox implementation of :after observes the property of the selector's class, not the psuedo-class. It might be worth experimenting with different doctypes, though? The transitional, rather than strict, sometimes allows for different results (albeit not always better results...).
Edit:
It appears that using
a:after {
content: " <" attr(href) ">";
text-decoration: none;
color: #000000;
background-color: #fff; /* or whatever colour you prefer */
}
overrides, or at least hides, the text-decoration. This doesn't really provide any kind of answer, but at least offers a workaround of sorts.
You can autoselect links to pdf-files by:
a[href$=".pdf"]:after { content: ... }
IE less than 8 can be enabled to work properly by implementing this link in the head of the html-file:
<!--[if lt IE 8]><script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE8.js" type="text/javascript"></script><![endif]-->
It works also very good in al IE versions when you use the after-before-content-thing for dosplaying quotation marks.
Position the content absolutely as follow:
a {
position: relative;
margin: 0 .5em;
font-weight: bold;
color: #c00;
}
a:before,
a:after {
position: absolute;
color: #000;
}
a:before {
content: '<';
left: -.5em;
}
a:after {
content: '>';
right: -.5em;
}
This works for me in Firefox 3.6, not tested in any other browsers though, best of luck!
Hi I was also having trouble with this as well and happened to stumble across a workaround.
To get around it, I wrapped the URL in div and used something like this.
.next_page:before {
content: '(';
}
.next_page:after {
content: ')';
}

IE11 not rendering CSS properly

Chrome and Opera render my page properly without issue, however IE11 and Edge do not.
I am using pure CSS to expand/collapse 3 section headings. It was my understanding IE 11 had more support for CSS3/webkit and I definitely thought Edge would of stepped up it's game.
https://jsfiddle.net/x0c5fsqh/
CSS Snippet
summary::-webkit-details-marker {
background: url(/images/toggle-expand.png) center no-repeat;
color: transparent;
font-size: 125%;
margin-right: 2px;
}
details[open] summary::-webkit-details-marker {
background: url(/images/toggle.png) center no-repeat;
color: transparent;
}
summary:focus {
outline-style: none;
}
article > details > summary {
font-size: 28px;
margin-top: 16px;
}
details > p {
margin-left: 24px;
}
details details {
margin-left: 36px;
}
details details summary {
font-size: 16px;
}
Rendered Properly
How IE/Edge renders it
All of the headings overlap in to the content of the previous sections that should be hidden and the toggle images do not appear at all. Just looks like the above CSS is completely ignored.
Any ideas?
From what I can see the <details> and <summary> elements are not supported in IE and Edge. It has nothing to do with supporting CSS3 features. It looks like those elements are part of the HTML5.1 spec.
Reference: MDN, WebPlatform, caniuse.com.
Take a look at the Resources tab on caniuse.com. There's a few links pointing to some polyfills.
As others have noted, CSS properties prefixed with -webkit- won't work in IE/Edge. Just as -o- or -ms- wouldn't work in Chrome.

Why is a button without a border in Firefox two pixel higher than line-height?

I've a Button with the following super simple css:
button {
background: #005eb8;
border: 0;
padding: 0;
color: white;
line-height: 50px;
}
"line-hight" is set to 50px. But the button is (in Firefox) 52px - I expected it to be 50. Is there any reason for that? In chrome the height is 50 as expected...
Code at JSBIN:
http://jsbin.com/jagiviyima/9?html,output
button::-moz-focus-inner,
input[type="reset"]::-moz-focus-inner,
input[type="button"]::-moz-focus-inner,
input[type="submit"]::-moz-focus-inner {
border: none;
padding:0;
}
Add such css rule.
You ask - is there some reason for that - I believe it is. I don't have Firefox at hand now, but you are using button html element and buttons typically have some default css rules applied to them across the browsers (these are obviously browser specific). My guess is FF is adding some default padding, margin, border or something of that kind to your own defined style. Try setting these to 0 explicitly.
A bit of googling yielded this SO answer which exlains the issue in a more detail, proposed resolution is:
button::-moz-focus-inner,
input[type="button"]::-moz-focus-inner {
padding: 0 !important;
border: 0 none !important;
}

1 pixel line height difference between Firefox and Chrome

Working on a new site design in asp.net with master pages. Header of the page is a 35px tall "menu bar" which contains an asp menu control rendered as an unordered list.
The selected menu item is styled with a differenct colored background and 2px border around the left top and right sides. The bottom of the selected menu item should line up with the bottom of the menu bar so the selected "tab" looks as if it flows into the content beneath. Looks fine in firefox and IE but in chrome the "tab" seems to be 1 pixel higher than the bottom of the menu bar.
Just wondering if there is some sort of bug I dont know about.
I realize that you will most likely need code to help with this problem so ill post up the css as soon as possible.
EDIT:
here is the css for the menu...
div.hideSkiplink
{
width:40%;
float:right;
height:35px;
}
div.menu
{
padding: 0px 0px 0px 0px;
display:inline;
}
div.menu ul
{
list-style: none;
}
div.menu ul li
{
margin:0px 4px 0px 0px;
}
div.menu ul li a, div.menu ul li a:visited
{
color: #ffffff;
display: block;
margin-top:0px;
line-height: 17px;
padding: 1px 20px;
text-decoration: none;
white-space: nowrap;
}
div.menu ul li a:hover
{
color: #ffffff;
text-decoration: none;
border-top: 1px solid #fff;
border-right: 1px solid #fff;
border-bottom: none;
border-left: 1px solid #fff;
}
div.menu ul li a:active
{
background:#ffffff !important;
border-top:2px solid #a10000;
border-right:2px solid #a10000;
border-bottom: none;
border-left:2px solid #a10000;
color: #000000 !important;
font-weight:bold;
}
div.menu ul a.selected
{
color: #000000 !important;
font-weight:bold;
}
div.menu ul li.selected
{
background:#ffffff !important;
border-top:2px solid #a10000;
border-right:2px solid #a10000;
border-bottom: none;
border-left:2px solid #a10000;
}
div.menu ul li.selected a:hover
{
border: none;
}
The selected classes are added to the li and a elements via jquery...
Here is a screenshot of the problem...
The chrome example is on the top and u can see 1px of red border below the tab.
On the bottom is the firefox image where everything looks OK.
EDIT:
After playing around with this a bit more, I have discovered that it is actually the "header" div itself that is growing by 1px in chrome... This seems very strange to me.
None of these answers solve the problem.
Set:
line-height: 1;
padding-top: 2px;
Because webkit & mozilla rendering engines implement line height differently do not use this it to manipulate measurement for single line items.
For items like menus, buttons and especially really small notification bubbles, reset the line-height to normal and use padding or margins to make them behave the same.
Here's a JSFiddle illustrating this issue:
http://jsfiddle.net/mahalie/BSMZe/6/
I just had this same problem, and I solved it by explicitly setting the line height and font size in <li> element that contains the <a> elements that are the tab links. Hope this helps someone in the future.
(edited html links)
This is a common issue I run into on some of my sites... when it's IE having the pixel difference, I can usually just add a pixel of margin/padding in my IE stylesheet. But when it's Safari/FireFox/Chrome, I usually just live with the pixel and make the FireFox crowd happy (for now—until Webkit rules the web!), even though it looks a little strange in the opposite browser.
However, you might also want to check out the line-height values (or add a value, if there isn't one already) on the containing ul or div element. Tinkering with that allowed me to get the padding exactly the same in FireFox, Chrome and IE.
Here is the solution that I found in this page :
button::-moz-focus-inner {
border: 0;
padding: 0;
}
I have been fighting with this problem for a little while now, and almost gave up on the pixel. However it's come to me in one of those eurika moments: if you get the tab lined up perfectly in Chrome (which leaves an overlap in Firefox), set the ul height to the height of the li (including any padding), you can remove the offending pixels in Firefox by setting overflow to hidden on the ul.
Hope this helps someone out there!
I had the same problem with my main tabs displaying them in Chrome, they were one pixel off in height and there for leaving an ugly slit between the tabs and the white background of the mainframe.
I solved the problem by giving the tab div an upper margin with a floated value. First tried margin-top:0.1px nothing then 0.2 etc. until with an upper margin of 0.5 everything displayed fine over all the major browsers.
I had the exact same issue, turns out chrome had zoom set to 110% and that was breaking the menu. I noticed it when I fired up chrome on another computer and it looked fine.
I had a similar issue and it was due to using ems for font sizes, margins and padding. The browsers were rounding the ems differently and causing intermittent off-by-1px issues all over the site depending on the length of content. Once I changed everything to pixel measurements my problems went away.
Hope this helps!
I've come across this problem in relation to text with transparent backgrounds.
I couldn't get any of the above solutions to work consistently so I ended up using a webkit hack to give those browsers a different line-height. Like so:
#media screen and (-webkit-min-device-pixel-ratio:0) {
.your-class {
line-height:20px;
}
}
Eww, hacky! I try to avoid CSS hacks but I just couldn't find another way. I hope that helps someone.
I managed to solve this issue with a web font I was working with by setting the following:
.some-class {
display: inline-table;
vertical-align: middle;
}
Granted it's a bit hacky but does the job. It does mean though you will have target styles specifically for Internet Explorer
try using display:block with the a element"
eg...
<li>Link</li>
css:
li{line-height:20px;}/*example only*/
li a{display:block;}
I guess this is the only way , use different styles for different browsers the problematic sections
/* FOR MOZILLA */
#-moz-document url-prefix() {
.selector {
color:lime;
}
}
/* FOR CHROME */
#media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari and Chrome, if Chrome rule needed */
.container {
margin-top:100px;
}
/* Safari 5+ ONLY */
::i-block-chrome, .container {
margin-top:0px;
}``
if line-height is used for vertically aligning text in a container (which it shouldn't), then consistent behaviour across browsers can be enforced like this:
line-height: 75px
height: 75px
overflow: hidden
you can also make different css for mozila:
-moz-height:2em;
one can also use:
#-moz-document url-prefix{
// your css
}
It's important to realize that web pages will always render differently in different browsers. Acheiving pixel perfection is futile, and nowadays I try to explain to my clients what kind of cost is involved to make every browser render the site exactly alike. More often now, they understand that IE6 and FF4 won't ever render any page the same way. We must try to make our clients understand and embrace the dynamics of the web.
Progressive enhancement and graceful degradation. Peace.
I might be a beginner in CSS, but I found the same problem in W3Cschools.com, in one of their examples.
http://www.w3schools.com/css/tryit.asp?filename=trycss_sprites_hover_nav
this example is about image sprites. You can see in this example, in Chrome, the home icon and prev icon have the 1px divider line, which is not the case in Firefox.
It seems that in Chrome the pixel count is 1pixel different to that of Firefox.

“text-decoration” and the “:after” pseudo-element, revisited

I'm re-asking this question because its answers didn't work in my case.
In my stylesheet for printed media I want to append the url after every link using the :after pseudo-class.
a:after {
content: " <" attr(href) ">";
text-decoration: none;
color: #000000;
}
In Firefox (and probably Chrome but not IE8), text-decoration: none is ignored, and the underline stretches unattractively across the bottom of the url. The color however is correctly set to black for the url. Is there a way to make the text-decoration work?
The original question appended fixed size images instead of variable width text. Its answers use padding and background images to avoid having to use the text-decoration property. I'm still looking for a solution when the content is variable width text.
If you use display: inline-block on the :after pseudo, the text-decoration declaration will work.
Tested in Chrome 25, Firefox 19
IE8's implementation of the :before and :after pseudo-elements is incorrect. Firefox, Chrome and Safari all implement it according to the CSS 2.1 specification.
5.12.3 The :before and :after pseudo-elements
The ':before' and ':after'
pseudo-elements can be used to insert
generated content before or after an
element's content. They are explained
in the section on generated text.
...
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification
The specification indicates that the content should be inserted before or after the element's content, not the element (i.e. <element>content:before content content:after</element>). Thus in Firefox and Chrome the text-decoration you're encountering is not on the inserted content but rather on the parent anchor element that contains the inserted content.
I think your options are going to be using the background-image/padding technique suggested in your previous question or possibly wrapping your anchor elements in span elements and applying the pseudo-elements to the span elements instead.
I had the same problem and my solution was to set height and overflow:hidden
http://jsfiddle.net/r45L7/
a {
text-decoration: underline;
}
a:after {
content: "»";
display: inline-block;
text-decoration: none;
height:16px;
overflow: hidden;
padding-left: 10px;
}
It works on IE, FF, Chrome.
As an alternative, you can use a bottom border rather than a text-decoration.
This assumes that you know the color of the background
a {
text-decoration: none;
border-bottom: 1px solid blue;
}
a:after {
content: "foo";
border-bottom: 1px solid white; /* same color as the background */
}
1)
:after{
position: absolute;
}
is not perfect, because element content will not wrap
2)
:after{
display: inline-block;
}
is not perfect, because sometimes we wish after content should always wrap with last word of element content.
For now, I could not find find a perfect solution fits all 3 conditions(1. content could auto-wrap if it's too long 2.after content should wrap with element content, which means after content should not occupy single by it self. 3.text-decoration should only apply on element condition not apply to after content.)
I thoughts for now is using other way to mimic text-decoration.
What I do is I add a span inside the a element, like this :
<span>link text</span>
Then in your CSS file :
a::after{
content:" <" attr(href) "> ";
color: #000000;
}
a {
text-decoration:none;
}
a span {
text-decoration: underline;
}
The only thing that worked for me was declaring a separate repeated selector with the same text-decoration property that it was inheriting from its parent, then in the main selector, setting text-decoration to none.
IE apparently does not know what to do when you set text-decoration: none on a pseudo element without that element having the text-decoration property declared (which by default, it has nothing declared by default). This makes little sense because it is obviously being inherited from the parent, but alas, now we have modern browsers.
span.my-text {
color: black;
font-size: 12px;
text-decoration: underline;
}
span.my-text:after {
text-decoration: underline; // Have to set text-decoration here so IE knows it can be overwritten below
}
span.my-text:after {
color: red;
text-decoration: none; // In the same repeated selector, we can now overwrite text-decoration in our pseudo element.
}
I realise this isn't answering the question you're asking, but is there a reason you can't use the following (background-based approach):
a.file_pdf {
background-image: url(images/pdf.png);
background-position: center right;
background-repeat: no-repeat;
padding-right: 15px; /* or whatever size your .png image is plus a small margin */
}
As far as I know, the Firefox implementation of :after observes the property of the selector's class, not the psuedo-class. It might be worth experimenting with different doctypes, though? The transitional, rather than strict, sometimes allows for different results (albeit not always better results...).
Edit:
It appears that using
a:after {
content: " <" attr(href) ">";
text-decoration: none;
color: #000000;
background-color: #fff; /* or whatever colour you prefer */
}
overrides, or at least hides, the text-decoration. This doesn't really provide any kind of answer, but at least offers a workaround of sorts.
You can autoselect links to pdf-files by:
a[href$=".pdf"]:after { content: ... }
IE less than 8 can be enabled to work properly by implementing this link in the head of the html-file:
<!--[if lt IE 8]><script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE8.js" type="text/javascript"></script><![endif]-->
It works also very good in al IE versions when you use the after-before-content-thing for dosplaying quotation marks.
Position the content absolutely as follow:
a {
position: relative;
margin: 0 .5em;
font-weight: bold;
color: #c00;
}
a:before,
a:after {
position: absolute;
color: #000;
}
a:before {
content: '<';
left: -.5em;
}
a:after {
content: '>';
right: -.5em;
}
This works for me in Firefox 3.6, not tested in any other browsers though, best of luck!
Hi I was also having trouble with this as well and happened to stumble across a workaround.
To get around it, I wrapped the URL in div and used something like this.
.next_page:before {
content: '(';
}
.next_page:after {
content: ')';
}

Resources