Label: Hover Attribute Triggers Incorrect Element in Ie10 and Ie11

Label :hover attribute triggers incorrect element in IE10 and IE11

I'm going to note before you read this answer that I am an engineer on the Internet Explorer team.

First of all, this is a really cool discovery. What you've stumbled upon is actually a "feature" (quite possibly a bug) of Internet Explorer that doesn't appear to exist in Chrome or Firefox. Let me try to break down an understanding of what is happening, why this is kind of cool, and what you can do to avoid complications with it:

Labels and input elements can become intrinsically related by way of the [for] attribute on a label pointing to the [id] attribute on an input element. As a result, when you click on a label, it can toggle a checkbox, or apply focus to an input field. This feature is often times leveraged to create progressively-enhanced radio buttons and more.

On a related note, when you hover over a label, the associated input element is also hovered. This is the case with Internet Explorer, Firefox, Chrome, and just about everybody else. But what Internet Explorer does differently is apply the hover bi-directional. So if you hover the associated input control, Internet Explorer also invokes :hover on the related label.

This is where things get cool. This allows us to create relationships like the one seen below:

Note here that the relationship is bi-directional, meaning any hover on an input is not simply a hover on itself and its ancestral tree, but also a hover on its associated label. And any hover on a label is a hover on itself, its ancestral tree, and its associated input. This brings us one step closer to understanding what's at play in your demo, and why you're seeing such bizarre results.

When you hover an element, you are covering its parents too. As an example, suppose we had a div with a button inside of it. Any hover on the button is inherently a hover on the parent div as well. You can't get to the children without first going through the parents as far as a cursor is concerned. The same rule applies here; when a label or input is hovered, so too are its parents.

In your demo you have a series of div elements with select elements and label elements inside. You're basing styles for the select elements on the hover pseudo-class of their parent div. So when you hover the select, it invokes the hover of its associated label, which causes the hover of its parent, which affects the styles of any nested select.

Subsequent Suggestion

While the [for] attribute allows you to place label elements just about anywhere, you should proceed in doing so only with special awareness to how this will affect selectors operating off of :hover propagation up the ancestral tree.

Before a complete solution can be given, I must ask why you are putting an empty label in a seemingly arbitrary location in the first place. What visual effect are you trying to achieve? I suspect we could accomplish the same visual layout with different markup.

Following Up from Here

I'm going to open a bug against this in our Internal database, because I get the feeling that this isn't entirely intentional on our part. Our aim, I believe, is to treat the behavior the same bi-directionally, rather than handling the two routes differently.

BUG - close IE10 or IE11 is inpossible with onbeforeunload and closing tab

I have answer from Microsoft: "This issue appears to be fixed in MS Edge".
You can read it here:
https://connect.microsoft.com/IE/feedback/details/1112178/bug-in-ie10-and-ie11-with-onbeforeunload-and-closing

CSS issue: a:hover not working with IE (css Ninja needed)

First thing I'd do is double check that the order of the psuedo selectors is correct.

It should be-

a:link {color:#FF0000} /* unvisited link */  
a:visited {color:#00FF00} /* visited link */  
a:hover {color:#FF00FF} /* mouse over link */  
a:active {color:#0000FF} /* selected link */  

The only specific IE hover issue I remember relates to non-link elements so I don't think that is your issue. http://www.bernzilla.com/item.php?id=762 - Just in case.

If that doesn't answer your question do you mind posting the related block of css?

---

GAH- That was a hard one!

It looks like IE is breaking because the links don't have an associated Href element. Fix that and you should be fine.

--Breaking News - I may be an idiot- That was the last thing I changed on my test page and that fixed it but when I put it all back together it broke everywhere... so take what I just posted with a grain of salt. I'm backing up to see what happened.

ie10, ie11 issue with skewX (double use causes rendering issues)

Don't know if you are still looking for a solution, but i found a "fix" for ie10 and ie11.

Replace the child div style by :

.wrapper {
  -moz-transform: skewX(20.01deg);
  -ms-transform: skewX(20.01deg);
  -webkit-transform: skewX(20.01deg);
  transform: skewX(20.01deg);
}

Looks like ie have issue rendering the double skew when values are the same. (Didn't dig it up to see why, yet)
I tried changing them, and having two different values seems to do the trick.

The + .01deg allows you to keep a skew almost identical (if not identical) to the 20deg skew from before.

How can I work around this IE11 layout bug related to table-cell, text-decoration, and padding?

Again a IE11 problem that seems so unusual. I see that the percentage padding is not even calculated and is not applied in the layout. However the text is still padded according to the padding percentage. So i would assume the text is positioned with the padding but after the positioning the percentage padding is "disabled".

I can't tell you why this happens. But if you really want to fix these you might want to use these quick fixes.

---

Use margin

Because the percentage bug only occurs on the padding of a table-cell, you can actually use a margin on the span itself.

span 
{
    margin-left: 10%;
}

and ofcourse reset the padding of the sides:

div.table-cell {
    display: table-cell;
    padding: 20px 0;
}

This "solution" is not as dynamic as with percentage padding on the table-cell itself.

Why not?

It's because the percentage takes is value from it's parent element, the table-cell. Where as the table-cell did take it's percentage value based on the tabel. Now when you would just use left-margin: 5%;. It would be half of the space as it should be. This is because it take the 10% on the table-cell width. Where the table-cell width is table width devided by its cells(table width / table cell).

So to fix that i did 5 times the amount of cells (5 * 2 in this case), which would result in the right percentage.

However this is not dynamic when you want to add more cells.

jsFiddle

---

Use border

Use border which its position is "reserved" before the padding is resetted.

Reserved border

span 
{
     border-bottom: 1px solid transparent;   
}

Change property that doesn't need re-calculation of position; color

div.table-cell-bug:hover span 
{
    border-bottom-color: black; 
}

Now note that there will still be no padding in the layout. As soon as a property is assigned which has not been calculated before the padding did reset(the same time the text position is determed) the positions will be re-calculated.

jsFiddle

---

I hope one of these quick fixes work for you.

I see you sended a bug report to MS. Keep us up-to-date when you get a reply, i would appreciate it :)

How to remove/ignore :hover css style on touch devices

2020 Solution - CSS only - No Javascript

Use media hover with media pointer will help you resolve this issue. Tested on chrome Web and android mobile. I known this old question but I didn't find any solution like this.

@media (hover: hover) and (pointer: fine) {
  a:hover { color: red; }
}

<a href="#" >Some Link</a>

---

Related Topics