I'm adding .css files with javascript to the head and order them with the highest priority last and the least prioritized first.
Like:
base.css
theme.css
responsive.css
And this works fine with every browser I've tried apart from IE (I've tested IE8,9 and 10) but If I reverse the order:
responsive.css
theme.css
base.css
It works in IE(8,9,10) but that doesn't work in every modern browser.
Is there any IE priority bug? If I statically add the files without the problem, so it seams to be a javascript problem but just for IE.
Anyone know about this problem or even a solution?
One solution is first check with javascript what kind of browser there's used.
BrowserDetect.browser
And after that use an if-else statement..
if(IE){
responsive.css
theme.css
base.css
}
else{
base.css
theme.css
responsive.css
}
It's because older versions of IE don't understand media queries, which are used in the responsive design, I guess in your responsive.css you have things like #media screen and (min-width: 960px).
Normally conditional comments are used to detect if the current browser is IE (and it's version) and load a css file or not.
Personally I like the mobile first philosophy when doing responsive design, there's a sample tutorial: http://gomakethings.com/mobile-first-and-internet-explorer/
This is called Progressive Enhancement. Doing the css for the simplest platform first, and adding up things for the newer browser.
If you want options there is another practice called Graceful Degradation, which is the opposite, having the full featured CSS and ignoring / removing those features for the older browsers.
You should google a bit about both those practices to understand them better if you really want to do clean and good responsive design
There must be another problem somewhere, because IE and other browsers do not differ in the way they cascade style sheets. Please create a JSfiddle.
Related
I'm writing my own site as a hobby (any html/css/js I know is self taught), but I've run into a issue that I can't seem to really understand (and thus I don't know how to fix it). I can't handle/fix this by myself unfortunately.
I tried taking away as much unneeded code as I could, reducing the site to the bare minimum where it still exhibits the unwanted behavior. I'm sorry for amateurish/hacky code, I'm not doing this professionally after all.
Here is a jsfiddle showing the code. It exhibits my wanted behavior: Click on any of the "Folders" and it expands and shows the "content". So far, so good.
If I now load the exact same code onto a site (I'm using netlify here), it still behaves as I want it to: Netlify link
If however I access it on a mobile browser (for reference I tried it on Google Chrome, Firefox and Brave browsers, all on Android) I get some behavior that I don't want:
If I expand one Folder, it works as intended, but if I expand the second folder as well the Folder name and its contents seem to change font size (they get noticeably bigger). If I close the normal one and reopen it it also changes size. For reference,
this is what it looks like.
It almost seems like me switching the display property to block changes the font size to something else, but I only defined one font size in the whole css.
I really don't know why this happens and I'd appreciate any help that explains it or points me in the right direction.
Thanks.
Edit: I managed to contact a third party who tried the site on their phone (iOS) and there the site did not exhibit the same weird/unwanted behavior. I'm not sure what exactly to do with that information.
I might have finally found a working solution to this weird and unexpected behavior. In your CSS, in the body section, add the following rules:
font-size-adjust: none;
text-size-adjust: none;
-webkit-text-size-adjust: none;
Those rules do not really have wide-spread support, apparently, and might change or their support get dropped at some point. One works only for Firefox, the other only for Chromium-based browsers, and yet another seems necessary for legacy Chromium-based. See:
https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust
https://caniuse.com/?search=font-size-adjust
https://caniuse.com/?search=text-size-adjust
Only with all three of those rules did I successfully prevent this font scaling for mobile Chromium, mobile Firefox Quantum (the old Firefox <=68 was not affected), both on Android, and for Chromium mobile mode on a Linux desktop. At least as far as my tests indicate.
Although I still fail to understand how and why such a rule would even be necessary: There definitely is no other conflicting rule in your example to affect rendered font size. My very wild guess would be that, under certain circumstances, some mobile browsers do not apply font-size rules correctly to hidden elements, causing this obscure cascaded font scaling.
Not at all the answer, but the described behavior can be reproduced even on a computer (Ubuntu Linux in my case; non-android device) using the given netlify link in Chromium, when using the mobile mode in Chromium DevTools. Maybe by reproducing it this way, somebody gets behind the cause of this behavior.
Upon opening the second folder, the font-size is indeed set to something 42.073px or something similar, depending on the responsive mode selected in the mobile mode. This is only shown in the "Computed" tab of DevTools, but there is no rule for this size in the "Styles" tab. I don't see any apparent cause for this text size change, sorry.
A few notes, however, on your HTML code (though none of the below seems to solve your problem):
Better put the <script> tag inside the <body> tag, right before the closing </body>. Or put it inside the <head>, but then make sure it get executed after page load. Outside <body> or <head>, your <script> is somewhat in limbo – unexpected side-effects included.
Similar goes for your <meta> tag. Put it inside the <head>.
For valid code and to reduce and even avoid unexpected side effects, surround your complete HTML code with an <html> tag, and define a doctype, e.g. <!doctype html> at the beginning of your HTML. Validate your HTML, for example here: https://validator.w3.org/#validate_by_input
I have some content on a web page that uses funny fonts to display correctly by using #font-face to use some custom fonts. I include a warning that it might not display correctly on all browsers. The content isn't really essential to the page, so what I'd really like to do instead is simply not show it if the browser isn't going to do it, due to browser version, script blocking, or whatever. Is there a way to do that?
Modernizr has this built-in. Here's a link to a build that just checks for #font-face support.
http://modernizr.com/download/#-fontface-shiv-cssclasses-teststyles-load
Then you can check in JS for Modernizr.fontface or in the css for .fontface { }.
Here's a fancy explanation of how to do it:
http://paulirish.com/2009/font-face-feature-detection/
To be clear you can pretty much support every browser with #font-face, except for some versions of Android.
http://caniuse.com/#search=font
Your bigger problem with #font-face isn't the basic support for #font-face, but support for the specific font file type, which is more limited. I personally suggest to use WOFF, which works in IE9+. Alternatively, if you use Typekit or Font-Squirrel you can pretty much support all browsers out of the box.
I'm writing some code that involves CSS tabs, but IE doesn't support the :target css3 attribute. I have a work around by checking the hash value in an interval (ew), but I want to only have that code run when :target is not supported. I would do the regular IE check, except early versions of Firefox do not support it, nor does early Safari or Opera. Does anyone know how to test for :target support?
You can test for CSS support by adding a rule like #someid:target { visibility:hidden; color:#abcdef; } and then setting the target to #someid, reading if the color is #abcdef, and then reseting the hash.
This will, however, generate entries in the browser history: 1 for when you navigate to the id, and 1 for when you reset it to whatever it was before. It may also create a flicker in your tabs, so that may not be ideal - but I don't know what you can get away with.
Ideally, tabs should ideally read and write the hash for bookmarkability. But I don't think that :target is the ideal solution to creating tabs. I know it looks appealing to begin with (did to me). Given the poor support of the selector, how badly it scales with nested or multiple tabs, and how volatile it becomes with other markup (someone adds a #skip-to link on the page), it is less headache to implement with good old clicks.
If I have a CSS solution for all browsers except IE then what should be chosen for IE?
CSS expression in IE conditional comments
or
JavaScript in IE conditional comments
or
jQuery + plugin in IE conditional comments
Which will be less slow in rendering speed?
CSS expressions only work in Internet Explorer only, so you'll have to use Javascript in some form, for complex styles. Firefox, Safari and Chrome recognise a lot of CSS3 so if you're trying to do something like rounded corners or multiple backgrounds you could use that and look for an expression equivalent for IE.
However, I would recommend using jQuery. It's built to be cross-browser, and your code will likely end up simpler than using combinations of expressions/browser-specific styles.
jQuery plugin, if I'm already using jQuery.
I don't think I ever used CSS expression, not even as a hack.
As for a non-jQuery JavaScript library - I'd have to learn it from scratch, it might re-implement some of jQuery's features (so doesn't benefit from jQuery's engine, cross browser, etc), and it may not be written in the convenient style of jQuery, like chaining and liberal null checks.
You should avoid CSS expressions.
As for JavaScript vs. jQuery, that depends. If I can do it in just a few lines of JS without cross-browser issues, and I'm not already using jQuery for other stuff, there's no reason to load the entire jQuery library. Anything much more complicated than a few document.getElementById or alert calls, though, and I'm likely to want jQuery available, and at that point I might as well be using jQuery plugins
Do not use CSS expressions.
The reason:
CSS expressions can be evaluated many hundreds of times per second. Especially considering that IE is not the fastest horse in the race, don't do that to the poor old browser.
The average IE CSS expression is evaluated over one thousand times in the time the person views the page.
What's more, it is just Javascript - it doesn't work if JS is off, creates the same garbage global variables, et al. So the gain is nill, the loss is high.
Do not include JQuery just for this.
But if it (or Mootools etc.) is included, use them by all means.
Creating your function without JQ is simple and straightforward.
Just have it run on page load and resize (http://www.devarticles.com/c/a/JavaScript/OnReset-OnResize-and-Other-JavaScript-Events/1/) and that should do the trick.
Use IE conditional comments and you are even valid.
<!--[if IE]>
<script>
var dumbIE = function (){
//your stuff
}
onload=onresize=dumbIE;
</script>
<![endif]-->
Although I strongly disrecommend using CSS expressions (is there really no "normal" CSS hack for the particular problem? doublecheck it, twice, if necessary ask question here), I would go ahead with it. This removes the risk that the your application breaks in case that the user has JS disabled. JS is at its best when used unobtrisively and in your case it is clearly not the solution.
Updated to new focus: If you've got it looking good in everything but IE (an all too common situation...) then you need some method of writing code that only IE sees/executes. You can do this with browser sniffing in JavaScript, conditional comments in CSS and HTML. IE CSS bugs (anyone else have some good links?)
(Old answer:)
CSS expressions: Internet Explorer only shortcut.
JavaScript: Have to code every stinking thing yourself. Works "cross browser", but you still need to test in all the browsers to make sure it's doing what you want.
jQuery: cross browser, easy, simple. :D
Wait for Microsoft to improve IE.. haha.
Ignore IE -> Encourage your web-visitors/users yo download/use a different browser (IMHO, firefox is a really, really good choice, if not the best)
There are ways of making IE 'compatible' with modern, css-stylized websites (such as the well-known comment <!--[if lte IE 6]>...<[endif]--> and so on.. but anyway, it's up to you.
so i've been working on a website now for like a couple months and i test it on chrome mainly. but before i release anything big i always check it on firefox 3.something and IE7. Now i've received some complaints that that it doesn't look very good in IE6 and when i do check it... well ya it doesn't look like its supposed to. Is there any quick fix that i can add to my HTML to make it look the same in IE6 as it does every where else?
At the risk of downvotes: have you tried adding IE6 to your test matrix? If you have a significant number of users complaining that it looks bad on IE6, you clearly have a significant number of users using IE6 to use it, so it seems like it would be worth your while to just add it to the set of browsers you check before release. Just sayin'.
A really good start is http://code.google.com/p/ie7-js/ Just place it in conditional comment tags in the head of your document and it will make ie6 'standards-compliant'. After that make sure you have seperate css documents for each version of IE, and make sure all of your code is valid with w3's validator. Also declaring a doctype can fix many issues, but it MUST be on the very first line that the browser sees.
Edit: also, for png transparency, I've found that this http://www.twinhelix.com/test/ (IE PNGFIX 2.0 Alpha) works best.
There is no quick trick to getting everything to work. Pretty much have to examine each element that looks different.
That said, you might try looking at a CSS reset file.
Yahoo has one.
And if you search google I'm sure you can find others.
Read this: Internet Exporer box model bug. Also try using YUI reset or Eric Meyer's resetReloaded to set a baseline for all your styles.
And stop developing in Chrome! Try Firefox with Firebug.
How badly does your website 'break' in IE6? If it's minor, then I wouldn't worry about it.
How critical is it that it works in IE6? It's share of the market is slowly but surely declining (Looking at my own logs from a Government website also shows that IE6 is definitely going away). Can you display a message on your website letting users know if they use IE6 and advising that they upgrade?
There are many reasons to upgrade, and educating your users as to why they should upgrade might also be worthwhile?
Uhm... if there is a simple solution I really want to know it. :)
But you can anyway use this good Microsoft tool to cross-test your pages.
It can be usefull for compare the final render of a website.
CSS resets will probably do nothing if it looks fine in IE7. Things like double margins when floating and overflow:auto bugs are things that need to be manually added for each occurance. I'd suggest adding the following line to your head tag:
<!--[if lt IE 7]><style type="text/css">#import "/stylesheets/ie6.css";</style><![endif]-->
and then writing an ie6.css file to fix all the bugs (yes, one at a time)
Probably not what you wanted to hear, but it is why everyone hates IE6 so much
you can check version of client browser and include css fixing for that browser. but most simple solution is to show an alert or notification to client that his browser is outdated and provide links to download latest browser
here are some way to show that notification
http://garmahis.com/tools/ie6-update-warning/
i like this solution
http://www.browser-update.org/