I have just found something very weird while developing a website. While trying to get a div element to display across the top of the screen, I noticed that I wasn't achieving a desired result in any browser except for old versions of IE. In order to test some different code, instead of deleting the faulty line, I used '//' to comment it out (I'm not really even sure if that works in css) but what happened was, the compatible browsers used the uncommented code, while IE used the code marked by '//'. here is the code:
#ban-menu-div{
position:fixed;top:0;
//position:relative; //<-- IE keeps the banner with rel pos while the other
display:block; // browsers used fixed
margin:auto;
padding:0px;
width:100%;
text-align:center;
background:black;
}
so basically, it seems as though // can be used to instruct newer browsers to ignore specific lines of code, and instruct older versions of IE to use it? If this is common practice someone please let me know. it sure makes developing for older browsers a hell of a lot easier
// is not a valid CSS comment.
Browsers that parse CSS properly will ignore //position because //position is not a valid property name (details are here, property -> IDENT S* -> follow it through).
This only works in IE7 due to its well known bug of accepting properties with junk prepended to them.
It's not just // that works. IE7 will have red text here:
body {
!/!*//color: red;
}
This is most typically exploited with *, for example *display: inline; as part of the display: inline-block workaround for IE7.
Don't fall into the temptation of commenting out single lines or blocks and not using the correct /* */ couple. A customer who has access to the website folder just chose by himself to comment out a single line using this:
//* comment here *//
Actually, Chrome and Safari will ignore ANYTHING that follows this line. I would call it a "css killer". :D
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..
My skin has the following CSS:
dl.definition dd:last-child {
margin-bottom: 0;
}
/* IE class */
dl.definition dd.last-child {
margin-bottom: 0;
}
Is it possible to combine these into one even though the second is just for IE ?
Thanks everyone for the answers but I am not sure anyone really said if I could just do this:
dl.definition dd:last-child,
dl.definition dd.last-child {
margin-bottom: 0;
}
Your hoped-for solution won't work:
dl.definition dd:last-child,
dl.definition dd.last-child {
margin-bottom: 0;
}
The reason this won't work is because as far as old versions of IE are concerned, dd:last-child is an invalid selector, and thus it will throw away the whole block. It doesn't matter that it also contains a valid selector; the whole thing is thrown away because of the invalid one.
A few options on how to improve things, and save yourself the hassle of duplicated code all over the place...
Upgrde IE. There are javascript libraries available such as Selectivizr or ie7.js/ie8.js/ie9.js which patch IE to make it support more CSS selectors. :last-child is included in pretty much all these libraries.
Downgrade your CSS. You're already writing the .last-child class into your code to support old IE versions, so just use that for everything and forget about using the :last-child selector. Then you only need one selector for all browsers.
Graceful degradation. Drop the IE-specific code, and just allow Old IE users to see a slightly broken page. As long as it doesn't affect usability, it may not be a big deal. You may not have that many old IE users (and the numbers will continue to fall), and those people who are still using old IE are used to seeing sites that are slightly broken (or worse) these days.
Re-arrange your layout to use :first-child instead of :last-child. :first-child has much better support (it goes back to IE7, though there are bugs with it in old IEs).
Use a CSS compiler like SASS or Less, so you can write your CSS in a more logical and structured form, before converting it to real CSS code when you deploy it to the site.
Hopefully one of those solutions will work for you. My suggestion would be the Selectivizr library, but any of the above should provide a workable solution for you.
In the HTML add
<!--[if IE]>
<style>
dl.definition dd.last-child {
margin-bottom: 0;
}
</style>
<![endif]-->
Not an exact answer to your question but a workaround for IE6 & IE7 can be found here which tells that you can use properties in single css file.
This gives again a more sophisticated solution.
And again you can use multiple properties in single css file and browsers will ignore it if it does not understand it. Cheers to growing smartness of browsers. :-)
Conditional comments for IE. You can specify verion of IE, for that you want to select CSS
Is it necessary to have valid CSS? I am using Twitter Bootstrap for rapid web development and after running the two main Bootstrap style sheets through the W3C CSS Validator, I noticed about 600 errors.
My question is, my site looks good so why is it so important for the CSS to be valid?
Yes, it is absolutely necessary to have valid CSS. CSS is a programming language and as such, you must follow its language rules. Just because browsers tend to accept invalid HTML and try to render it, it doesn't make generating ill-formatted HTML a good practice. The same is true to CSS, although - fortunately - CSS rules are quite a bit stricter than HTML rules.
Another reason is that valid CSS has guaranteed behavior - if you write a rule, you can expect that rule to behave a certain way. (Buggy browsers, like all versions of IE aside.) If your CSS is invalid, any behavior you get is undefined and it may break when a patch release is issued for any of the browsers that you use for testing. Your CSS won't necessarily break but when you write invalid CSS, you get no guarantees of any behavior - you simply get some behavior that may seem correct to you but that may change any time.
If you have correct CSS mixed in with incorrect CSS, browsers tend to ignore the invalid parts (just how the specification tells them to) but each browser does it slightly differently. Similarly, while many people advise to use CSS hacks, I'd say not to, for the above reasons.
The CSS doesn't have to be valid to work. Browsers simply ignore the CSS that they don't understand.
Validating the CSS is a method to test if it follows the specification. If it does, any browser that is up to date with the specification used will understand the CSS.
It's somewhat of a debated topic really. The W3C tools are certainly good to use, but they tend to not account for a lot of modern code. Naturally, it's difficult for them to not only advance standards, but also make sure the tools they offer are accountable to new and inventive code.
In order to get websites to look good in all browser and across all platforms requires people to maybe stretch outside of the norms that otherwise would be "valid". It's tough to argue against a site that works perfect cross browser and platform even if the CSS isn't 100% spotless. That's my two cents.
Your CSS doesn't need to be valid (depending on who you ask), but if it is invalid, you should have a reason for the invalidity:
audio,
canvas,
video {
display: inline-block;
*display: inline;
*zoom: 1;
}
The validator has a parse error here because of the asterisk at the beginning of property. This is a obscure but recognized hack for targeting Internet Explorer. Other browsers will ignore the properties that it won't recognize but IE6/7 will read properties with asterisks.
input:-moz-placeholder,
textarea:-moz-placeholder {
color: #999999;
}
input:-ms-input-placeholder,
textarea:-ms-input-placeholder {
color: #999999;
}
input::-webkit-input-placeholder,
textarea::-webkit-input-placeholder {
color: #999999;
}
The validator error here is a result of vendor-specific pseudo-classes. Note than unlike unrecognized properties, if a browser doesn't recognize the selector the entire rule will be ignored so the vendor placeholder extensions need to be separate rules. This happens even when using the comma operator so:
input::-moz-placeholder,
input::-ms-input-placeholder,
input::-webkit-input-placeholder, {
color: #999999;
}
would be ignored in all browsers unless they recognized all three vendor prefixes.
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fffbb450', endColorstr='#fff89406', GradientType=0);
This is the old-style IE extension for gradients. It ripples and causes a number of errors in the validator even though IE follows it and other browsers will not quietly ignore it.
width: auto\9;
The \9 is another IE hack that targets IE<=8
The bottom line is that if you are doing something non-standard, make sure you know why you are doing it.
Now a days there are different number of browsers with different number of versions.Some supports lot but some are not.So when you include styles it is always not possible to fit 100 % perfect.If your style works without any problem ok.But when it goes to different browsers if you get problem related CSS , You have to take care otherwise no problem.
yes its important, most of browsers follows the w3c standard when they load the html page. if your page don't have the valid css, in different browser it might appear different ways. Old internet explorers didn't followed the W3c standards which cost alot to the developers result in developer need always extra css for the IE to display page properly.
I am facing issues with text box size when veiwing in Fire Fox 3.6.
< input class="dat" type="text" name="rejection_reason" size="51" maxlength="70" onchange="on_change();">
style is as:
.dat {
font-family : verdana,arial,helvetica;
font-size : 8pt;
font-weight : bold;
text-align : left;
vertical-align : middle;
background-color : White;
}
Text box size in Fire Fox is bit smaller than IE6.
Not sure why IE6 and FireFox displaying text box of diff size.
Normal problem when developing for different web-browser engines.
Note that you maybe should develop for FireFox 3.6 rather than IE6 because IE6 have set to "old browser" that microsoft is not supporting anymore. Change your code to work good in FireFox, IE, Chrome, Opera.
look for more info at:
https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site
Try specifying the width in your css. If that remains broken, you can append an asterisk to the front of the width word as a second entry and it will apply only in IE6.
.dat
{
width: 100px;
*width: 105px; -- or whatever makes it look correct
}
EDIT: Thanks for the update on the special character.
With a more full explanation, which I just had to give to a manager;
IE6 was built around 2000, and ignored several significant web standards at the time. IE6 was somewhat of a "lesson learned"; IE7 is better about following those standards, and IE8 is better still.
Firefox was built around Netscape/Mozilla, and importantly, they followed the public standard as much as they could. Firefox largely behaves like Safari, Chrome, Opera, and the tons of tiny-marketshare browsers out there.
Businessperson asks:
So, why support the standard, instead of IE, which is the big kid on the block? Almost all of our customers use IE!
Answer:
Because IE is slowly moving towards the standard, too. If we support Firefox, IE8 is easy, and we probably get IE7 as well with almost no changes. IE6 is the fly in the ointment here.
If we support IE6 - the original proposal - then IE7 is a special case, IE8 is another special case, Firefox is a special case, and so on.
If we can encourage users to move away from IE6, that's our best case scenario. I believe Microsoft officially ended all support - including security patches - for IE6 when Server 2003 SP1 left support, April 2009. Google has stopped supporting IE6 entirely, for example, politely letting users know they need to upgrade "for the full site experience". Sites like IE6NoMore offer a pretty slick CSS popup for those running IE6, giving them a few upgrade options.
But in the meanwhile, since customers do use it, IE6 is here to stay, and it's easiest - and most maintainable - to build to the standards, and hack our way back to IE6 until it's done.
You have not specified its width just that you want it to take 51 charecters via the size attribute. I would suggest removing the Size="51" attribute and adding a style of width:666px;
EDIT: after your comment
Firstly just because you can does not mean you should. The corret way of solving this is changing all of your <input type="text"> to use a css class or css width to define their width.
However the following jQuery will add a width style to every input type=text which has a size attribute
jQuery( // on Document load
function($){ // run this function
$('input[type=text][size]') // find all input type=text with a size attr
.each( // for each element found
function(index, Element){ // run this function
var size = $(this).attr('size'); // get size attrubte value
$(this).width((size * 0.6)+"em"); // set the css width property to
}); // a nasty huristic
}
);
Now since this only effects inputs with size specified, as you touch each page you can remove the size attr and replace it with Css size, so eventuly you will not need this script.
The #size attribute gives a size in characters. However, unless you are using monospaced fonts, the size of a character itself is not something that is well-defined. In addition, different rendering engines may use different rules for character spacing and/or kerning. So, at the end, the attribute is no more than a vague hint to the browser.
Have you tried something like style = "width:51em;" instead? Haven't tested it, but the width property is well-supported, so I'd hope this would work. You can also use absolute (pixel) units if you want a more exact size.
Hope this helps.