We noticed on our website that the CSS was broken with IE11, while it worked fine with IE10. After a look at the CSS source, it turns out that IE11 (it seems) has dropped its support for attributes matchers: we tried on our VM, we tried on BrowserStack, and the result is that these rules...
img[src$='separator.png'] { display: none; }
a[href="javascript:addBookemart()"] { text-decoration: none; }
... do work on IE10, but not anymore on IE11. I find it hard to believe that the support for this feature would've been dropped... plus, I can't find anyone talking about such a thing over the interwebs. Might there be anything else causing this issue?
Here's a pen for testing purposes:
http://codepen.io/anon/pen/GJNyJW
In my experience, IE11 is picky about [attr="value"] having double quotes around the value.
I found I was having this issue and it turned out that IE11 was case sensitive with the attribute values.
Related
We are working on redesigning our web-based application’s Front-end. We started with a PoC based on Extjs 6 and we are facing few compatibility issues.
These compatibility issues are related to IE8 and CSS, while it is mentioned on your website that Extjs6 is fully compliant with IE8.
CSS classes work perfectly with all Major Web Browsers (Firefox, IE11, Chrome...) but some do not on IE8.
This is an example of CSS not working properly under IE8:
Ext.create('Ext.button.Button',{
text:'Button Test',
cls: 'btnColor',
renderTo: Ext.getBody(),
});
.btnColor {
background-color: green;
border-color:green;
}
Works on IE11 :
But not on IE8 :
We would like to know if this is a known issue and is there a specific processing which allows us to handle this kind of needs.
Thank you in advance.
The element in your comment above is the wrong element - that's the inner element for the button; you want the class with an id something like button-1009 (it's going to be an anchor or div tag a few elements up in the hierarchy).
And as to why it's not working - there are going to be multiple CSS selectors that define the background colour. The default one, from ExtJS, is going to be x-btn-default-large. The full CSS class for the attribute is going to be something like x-btn buttonCls x-unselectable x-btn-default-large x-border-box.
Done like that, both the buttonCls and x-btn-default-large are equally valid choices - the browser must pick one to use. IE8 is picking the last one; other browsers are picking the first one. Neither is wrong - the ambiguity is in your code.
To fix it, make your CSS selector more specific. Try:
.x-btn.buttonCls {
background-color: green;
border-color:green;
}
This applies to buttons (which will be the only things that have the x-btn componentCls attribute) that have the buttonCls cls attribute.
The problem is JavaScript syntax.
IE8 and earlier are strict about trailing commas on arrays and objects.
Your line renderTo: Ext.getBody(), ends in a comma, but is the last item in the object. In IE8, this will fail to compile.
The solution is simply to remove that comma.
You can keep an eye open for theses kinds of things by running your code through a linting tool like JSHint or ESLint, which will flag this kind if thing up.
The answer of Sencha support team:
https://www.sencha.com/forum/showthread.php?305980-CSS-compatibility-issues-on-IE-8.&p=1118734#post1118734
This clarified a lot for me, it might help you :)
What is the use of this CSS hack in Safari?
/* CSS Hack Safari */
#dummy {;# }
I found it in this page:
http://jscroller2.markusbordihn.de/example/endless/
After doing some Googling, I was able to find something pertaining to Safari and browser hacks..
Apparently, older versions of Safari would ignore CSS declarations that were preceded by a hashtags. For instance:
h1 {
font-size:24px;
font-size:30px;#
}
If Safari were to come across something similar to this, it would make h1 24px, and completely ignore the 30px.. However, say IE, or Chrome were to see this, they would read the declaration and make the fontsize 30px because of the fact that they don't take the hashtag into consideration. To my knowledge this little 'hack' no longer works on newer versions of Safari.. Here is my reference.
Now back to the question:
#dummy {;#}
This doesn't particularly do anything, so I don't really see why this was in their code.
However, I am assuming that something was originally placed in there, and later removed due to the fact that this hack no longer works..
This is a rather interesting source on browser hacks..
Is it a bug that Firefox doesn't seem to support background-image swapping in pseudo-classes or is it that the other browsers are doing more than they should be?
I'm trying to figure out if I'm doing something wrong... this works in Opera and Chrome (haven't tested in IE yet)...
.myClass{
background-image:url('off.jpg');
}
.myClass:hover{
background-image:url('on.jpg');
}
However firefox just ignores this. I was hoping to avoid writing a javascript roll-over... this seemed like such an elegant solution, but I'm starting to suspect that I'm hosed.
Your page is in quirks mode, presumably, and :hover has some weird behavior in terms of when it applies or not in quirks mode. I suggest putting your web page in standards mode if you want browsers to actually behave compatibly on it, instead of explicitly asking them for buggy backwards-compatible behavior.
What version of FF are you using? A quick search revealed this possible issue similar to yours: http://support.mozilla.com/en-US/questions/746770
Try this to see if it works:
.myClass{
background-image:url('off.jpg');
}
.myClass:hover{
background-image:url('on.jpg');
}
[class="myClass"]:hover{ /* firefox fix */
background-image:url('on.jpg');
}
I am having trouble with cursors not being pulled through in WebKit browsers. Surprsingly IE and Opera work as I expect them to. Here's the CSS
.olControlDrawFeatureActive {
cursor: url(<DOMAIN>/common/images/cursors/draw.png), crosshair, default;
}
It quite simply changes the cursor to either the Draw png or, if it doesn't accept custom cursors or PNGs (like IE or Opera) then it should default to the crosshair. Works fine in IE and Opera, it goes to the crosshair as I want it to, FireFox, Safari and Chrome on the other hand refuse to return any css for this at all. Looking at the returned CSS in Firebug I just get.
.olControlDrawFeatureActive {
}
Empty, and utterly useless. I have tried replacing the URL with it's full path and relative path and (and this is the most confusing bit for me) I have tried removing the custom cursor entirely so it should default to the crosshair, but still it just returns an empty CSS rule! It's been bugging me for a while now because it originally worked fine in Webkit but not in IE, got it working in IE and now WebKit decides to not play ball! Am I doing something really obvious wrong? Any help or pointers would be hugely appreciated as it is driving me bananas
The problem seemed to lay in the fact that I had specified 3 levels of cursors i.e. The Custom one, the Crosshair and the Default cursor. There was no need to have the default one in there anyway as Crosshair is accepted by all browsers. Removing this seemed to make it work.
This seems strange though, does CSS only allow for two levels of cursors? If so then why did Opera and IE accept it, do they just ignore the first one?
Fixed CSS
.olControlDrawFeatureActive
{
cursor:url(<DOMAIN>/common/images/cursors/draw.png),crosshair;
}
I'm new in this area and I wrote a div style which didn't work properly for firefox 4, opera 11.1 and for ie 8.0 but worked for chrome 11. The code which was a style for a div was the following only with a different order
#info_text
{
background:#fdf6cc;
width: 650px;
margin-left:1px;
padding-left: 30px;
padding-right: 263;
min-height: 90px;
}
After changing it this way it worked for all the browsers except for the Internet Explorer 8.0.
Can I do something to make it work or it's the problem of the browser?
Does it metter the order in this case?
The order doesn't matter in this case.
You are missing units for the padding-right property. Running your code through a validator will flag errors like this.
Welcome to world of web development! All browsers interpret CSS differently, particular old versions of IE (try the above in IE6 for some fun!)
To understand exactly what problems you're having we need to see a working web page with the above.
The order of the CSS doesn't particularly matter to be honest, though obviously later CSS overrides earlier CSS and this something which is used commonly in the industry.
try opening "developer options" under "tools" in ie, if there is a more specific class, it may be overwriting something, or if something is formatted poorly, IE may be excluding it all together. Another option is "firebug lite", firebug is a very useful tool for getting started with css, javascript, and page structure. Without a link to the page that you are having the problem on, it's very hard to determine the cause, I copied your css and tried it myself, but got the expected result in all browsers