I am using Foundation 5 that working fine with all browser except IE8. I have also try with polyfill but still css issues exist on IE8.
Any other solution for this.
For some businesses it is not a viable option to drop support for IE8. I had to get a Foundation 5 site working in IE8 and here are the steps I took to get it working.
Breakdown:
Use jQuery v1.x and not v2.x
Include IE8 grid support CSS
Include shims in HEAD after your CSS
cdnjs.cloudflare.com/ajax/libs/html5shiv/3.6.2/html5shiv.js
s3.amazonaws.com/nwapi/nwmatcher/nwmatcher-1.2.5-min.js
html5base.googlecode.com/svn-history/r38/trunk/js/selectivizr-1.0.3b.js
cdnjs.cloudflare.com/ajax/libs/respond.js/1.1.0/respond.min.js
github.com/es-shims/es5-shim - shim.js
Include Foundation js fix before initiating foundation
Include REM shim at very bottom of page
For a more in depth look at how to do this check out the link below:
https://kyco.io/blog/getting-foundation-5-to-work-in-ie8
According to http://foundation.zurb.com/learn/faq.html and http://foundation.zurb.com/docs/compatibility.html:
Why doesn't Foundation support IE7 or IE8? Or: why we don't support a dying species.
This is probably the biggest question we get. Consider this: most of
today's popular browsers automatically upgrade themselves including
Chrome, Firefox and Explorer (starting with 9). IE 8 is the last IE
supported on Windows XP, which Microsoft will officially stop
supporting next year. That played a part in our decision.
Besides that, since Foundation 4, our framework is built mobile-first,
meaning it relies on media queries to layer in more complex layouts
and components. Browsers or devices that don't support media queries
will be restricted to a simple, single-column layout. In some ways,
Foundation 4 better supports IE6-7 insomuch as it provides a mobile
but not entirely broken experience. If IE8 support is important for
your users / customers, you can use Foundation 3.2, which supports
IE8. It's not mobile first but it's good stuff.
Related
I've been using -webkit and -moz for quite a few times now until this struck me. Aside from defining specific properties based on browsers and certain properties such as break-inside which are not widely supported,
Wouldn't
border-radius: 5px;
makes it shorter for
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px;
There are lots of other features which have been standardized but several examples still utilize the vendor prefixes and what are their purposes for doing so?
The former is supported by latest browsers but can we not assume almost everybody is using almost-latest browsers (especially NOT older versions of IE which certain rules apply)? (Even if people do not update their browsers, they are only left behind by just a few versions considering no one takes out a Nokia-old phone from a chest and started browsing)
Why should we use them? Why should we specify older IE specific rules or just older browser rules?
How much diving into older version would be enough? IE8?
Here are my thoughts - before going into detail I have to say that I am a freak when it comes to browser support.
Up until a couple of years back I was trying to support from IE8 and upwards. The reason behind this logic was that people where "trapped" with Windows XP and IE8 was the latest version supported by Windows XP. By trapped I mean that they were cases like government pcs that were too costly to upgrade.
After Windows 7 has matured enough and Windows XP usage dropped, I tried to support IE9 and upwards. This essentially meant that even after useful properties came out (like flexbox) it took me a long time to migrate - so I was building layouts with tables for best browser support, etc.
However, Javascript Frameworks started dropping support for older browsers (including IE9), then CSS frameworks started dropping support. If you consider it for a while, MS itself has dropped support quite some time back. Major mobile companies drop support for their 2-year devices, so why should we support older browsers? As stated in in other answers, it depends on the audience - imagine the CEO of your best client-company having a laptop with Windows XP or other outdated device - wouldn't matter if anyone else used modern browsers..
So, it came down to a point a couple of years back that you have to select between following the stream and being modern or supporting older devices. I am all up for consistency and uniformity of content, so supporting modern features for a few select browsers and dropping them for others would be a no go for me. Flexbox was one of those properties that pushed me to skip older browser support - it vastly helped me reduced markup - thus making maintenance easier. At the same time, even Bootstrap decided to drop support for older browsers, so, must upgrade to keep pace with the competition.
Needless to say, the problem isn't just IE, but was also Android which took up to v4.4 in order for the stock browser to support specific properties - vh, flexbox wrapping, etc
These said, let me give you a straight answer:
Don't bother with support for IE9 - not even 10. IE10 could be upgraded to 11 on the same OS, so it should be upgraded anyway for security reasons. IE9 is not supported by JS frameworks (eg Ember), lacks CSS3 transitions and other useful properties, like flexbox. Without these your designs would have to take many steps back if you were aiming for design consistency.
As a sidenote IE10 started supporting their own interpretation of flexbox (sorry about all this persistence with flexbox, but it's one of the most useful properties). This means, that in order to support it properly, you would have to write a lot of CSS. Imagine adding 30kb of minified CSS to support just one browser that is fairly uncommon. Is it worth it?
Some webkit browsers (like Opera) might still require vendor-specific prefixes for browser versions released 4 years ago -eg for CSS3 transforms. Tbh more important things are broken on such browsers (Opera included) that I would worry about other stuff more. Personally I only use the -webkit- prefix in select cases (eg flexbox properties that have matured quite lately).
There might be some cases where browser-specific prefixes might come handy even in modern browsers, eg styling a range input or a scrollbar where you have to mess with browser-specific properties to achieve consistency. In such cases specific CSS hacks with vendor prefixes might be required.
As a final note, I would avoid any bleeding-edge properties, eg grid; learn what it does and how it works, but don't use it just yet. You should give a look at https://caniuse.com/ in order to have an idea about CSS properties and browser support.
However, it is up to you to decide and you should make your selection based on the requirements of your project. Two years back I would tell you to support as old as you can... back then you would be able to achieve the same things with different effort, but this is not the case any more. From a point onwards... older browsers can't keep pace.
Well... This is a really big topic so its hard to answer all of it but there are best practices that you should/could follow.
First - Everything is based on YOUR SPECIFIC Audience. Look at your analytics and see what browsers are being used. The data might surprise you especially if you have US Health care or government users. Tools like Stylelint will help you find unsupported rules in your CSS.
Next, It's best practice to utilize feature detection instead of targeting specific browsers. You can implement that by using #supports in conditional code that works like a media query. This way your code is only being applied if the browser can use it. You can do similar detection in javascript using Modernizr.
Finally, I personally recommend using a CSS post processor or build script so you can stop worrying about prefixing (plus it will speed up your development with optional plugins). I tend to like a combo of PostCSS and Prefixfree (several Webpack customizations come with those included) but there are many similar options.
The main benefit is that the library tracks what needs prefixes and what doesn't so you write the non-prefixed version and the rest is taken care of.
There are no hard and fast rules but you should try to support your users' devices instead of pushing for upgrades. The nice thing about the above practices is that your resulting code will be easier to maintain, future proof and targeted to your users.
You should not worry about browsers older than IE 8. These browsers are barely used anymore and they do not support a lot of things. Please, refer to these to websites:
https://imagebox.com/industry/why-your-website-doesnt-look-the-same-in-every-browser/
http://dowebsitesneedtolookexactlythesameineverybrowser.com/.
In terms of the various border-radius commands, make sure to use them all. I've found that if you don't include webkit and mozilla, you lose a lot of traffic. In my website, I usually include every variation of a command so I know for sure my website works. Better to have a large and ugly CSS code than a broken website.
Feel free to comment on this answer if you need more clarification.
We will still be relying on IE 8 and IE 9 in my company (too large to switch rapidly), so this stays. We have been trying to use bootstrap for the new internal site designs (with all the recommended quirks).
I noticed that the SB Admin v1 & v2 consistently break on these two browsers - both the official sites, and when we try to use these libraries locally. It still renders crazy, and code appears to be working differently on these two browsers compared to Chrome and IE11.
It is possible we're trying to use wrong frameworks, which were meant to target chiefly handheld device browsers?
Has anyone had luck adapting bootstrap to run with IE8? And if you gave up, what did you use instead?
Skeleton is made to scale to also fit mobile browsers, following the principles of responsive web design. Does Bootstrap offer the same?
Not yet - http://groups.google.com/group/twitter-bootstrap/browse_thread/thread/6db57d09f654a326?pli=1
But it will be, at some point. The Roadmap has this in for version 2.0. It's lightweight enough that in my experience you can add in your own media queries without much trouble.
EDIT - As of 1 Feb 2012, version 2.0 is out, which is responsive down to mobile out of the box.
EDIT - As of 19 Aug 2013, version 3.0 is out, which is not only responsive but takes a mobile-first approach:
With Bootstrap 2, we added optional mobile friendly styles for key aspects of the framework. With Bootstrap 3, we've rewritten the project to be mobile friendly from the start. Instead of adding on optional mobile styles, they're baked right into the core. In fact, Bootstrap is mobile first. Mobile first styles can be found throughout the entire library instead of in separate files.
Apparently it should support it now.
Originally built with only modern browsers in mind, Bootstrap has
evolved to include support for all major browsers (even IE7!) and,
with Bootstrap 2, tablets and smartphones, too.
Source: http://twitter.github.com/bootstrap/#grid-system
If you go to the site and resize your browser, you will se it's fitting nicely.
Yes Twitter Bootstrap's 2.0 version is based on responsive web design. look at their website: http://twitter.github.com/bootstrap/. You will have to play around with it when you download, cause the download version does not have it. You will have to rename the responsive css, best option is to look at their website and try to reverse engineer it.
Mobile-friendly has many meanings. Bootstrap is responsive, which is a mobile-friendly attribute. It's also extremely heavy (it's designed for applications) - which is not mobile-friendly, especially for websites.
The Yahoo Pure framework is about 1/10th the weight, and provides the same feature set for websites. I'd suggest something similar over Bootstrap for a mobile website.
I have just started doing webdesigning I use photoshop and dreamweaver. I have seen that professional websites carry different css for ie 6 and ie 7 and one for all others. Why? what are the different things I should keep in mind while designing for internet explorer 6 and 7 and how is it different from designing for other web browsers. Are there any other web browsers that like ie 6 or 7 which require different css ??
can you give a link where i can read more about it
basically internet explorer renders websites differently in a bad way. internet explorer 6, 7, 8 all have their little quirks. For the most part other browsers like opera, firefox and safari render sites in a similar fashion.
then main gripe is that internet explorer has a different box model. you can read about common issues with IE here:
http://css-tricks.com/482-ie-css-bugs-thatll-get-you-every-time/
http://haslayout.net/css/
there are however lots of scripts/tools that can help you out:
http://code.google.com/p/ie7-js/
http://www.findmebyip.com/litmus/#target-selector
on a side note please don't support ie6, it is by far the worst browser to work with and many companies have stopped supporting it.
I have personally stopped caring about IE6/7 and even glitches in IE8. I couldn't care less. But most of my development is either for customers who I make that clear to, or to my non-profit sports/groups that I belong to (free web dev / design).
Its just too much of a hassle to hand hold these older browsers. Thats where IE6/7 notifiers come in handy (JS that pops up and says "your browser is too old, please update").
Example site:
http://ie6update.com/
Different Style sheets for different browsers is an excellent practice but very expensive.
The main reason is because the CSS version supported by the browsers changes from Browser version to version:
http://www.thescube.com/blog/ie6-vs-ie7-vs-ie8-css-property/
For a quick diagram about what CSS features work in what browser check out http://www.quirksmode.org/. How you then beat every browser in submission is of course a different question all-together…
While making CSS for the website it is painful when sometimes it works on some browsers and some don't.
I wonder if there any place I can find the existing problem which has been noted with experience developers. So I can have a list of noted problem while developing.
What are the tricks?
Where Can I find it ?
How to solve it if possible?
The most problematic browser is Internet Explorer (especially 6 and below, 7 is not so bad, and 8 is a huge step in the right direction).
Even if IE holds the majority of the market, develop for a standard compliant browser such as Firefox or Webkit (Chrome and Safari) using an XHTML doctype, then fix the discrepancies on IE at a later stage. That way you will achieve the maximum compatibility with little or no efforts (if it works in the Gecko or Webkit engine, you are pretty close to being guaranteed that it will work for most browsers [except IE, but in most cases you'll be very close to perfect]).
Most of the problems you'll run into with IE are well documented on the Internet and are rather easy to fix if your page is standard compliant.
If you develop for IE first (especially IE6) then try to make your page work with the rest of the browsers, that will be problematic as your changes will probably end up breaking IE rendering.
Also, an other thing that is important to note is that font availability and rendering is different from platform to platform. Verdana on Windows may not be smoothed the same than on a Mac, and the font might not even be present on *nix.
QuirksMode has a comprehensive list of features supported on a given browser:
Compatibility Master Table (quirksmode.org)
Personally, my biggest peeve with IE6 is its poor support for PNG-24's with transparency. It requires a filter to somewhat support it.