I'm using the DOMParser to manipulate AJAX-loaded html content before injecting it into the DOM. caniuse state that current support is good, but doesn't go that far back - for IE with only partial support until version 10 and for iOS only full support in Mobile Safari from version 8.1. But in this post the claim is made that it will work all the way back to IE6 (no mention here about mobile browsers). So, my question is: If one uses window.DOMParser or the ActiveX version Microsoft.XMLDOM what kind of coverage will one have? Will it cover IE back to IE6 as claimed in the linked post or is that too optimistic; and roughly what proportion of mobile browser users would one exclude requiring DOMParser support - pur in another way: is the mobile platform ready for DOMParser-supported applications?
If you use something in the spirit of
try { Microsoft.XMLDOM } else {window.DOMParser}
You will be good as far back as IE 6. But three years later I hope you do not need that support anymore :)
Related
I just checked my web app in a first-generation iPad with Safari 4.0.4. I
noticed a lot of styles were not working properly:
border-radius
opacity
image height & width (if only one property is declared in the css)
etc...
I am thinking whether to make necessary css adjustments to make my web app render properly on Safari 4.0.4. While the global usage for IE6 and 7 are quite moderate. At the moment we are fine with not showing full support for these browser versions, due to their lack of css support.
Could this same consensus apply for Safari 4.0.4?
IE7's last release was on 2007 (http://en.wikipedia.org/wiki/Internet_Explorer_7). Safari 4 was on 2010 (http://en.wikipedia.org/wiki/Safari_version_history)
If any other frontend developers faced a similar scenario. Would appreciate to hear from you.
I think iOS can be considered sufficiently deprecated at this point to ignore it. The iPhone 4 came with iOS 4 and the iPhone 3GS has had several updates available for it for so long that an incredibly small percentage of users would be expected to still use iOS 3.x. Further, since most mobile platforms push you to update as soon as a new version is released, there is even less of a chance anyone is using anything but the most recent 2 or 3 versions.
You can see a breakdown of iOS version usage here: http://david-smith.org/iosversionstats/
Also, your link goes to information about safari desktop versions. For iOS, go here: http://en.wikipedia.org/wiki/IOS_version_history
As a general rule, our company uses the 2 versions back rule, 3 for IE, unless there is a specific need for further backward compatibility per the client.
I have decided not to support older browsers (IE6 & Before) and alternatively providing a page that forces the user to upgrade their browser. The demographic I am targeting are generally technologically savvy and very few users will encounter this page. What I am hoping to do is not support any browsers older than 5 - 6 years. What would be the best way about to achieve this? Would it be better to ONLY eliminate IE6 and below? What about early versions of Firefox, etc.?
You can read the browser version from the User-Agent string passed by the browser. You want to do a RegEx match on it. Depending on how harsh you want to be you could put a big banner at the top of the page with what you have detected their browser to be and a link for them to upgrade.
You should be able to find libraries in your chosen server-side language to do the parsing for you, save the hard work. An ultra-quick Google returned: https://github.com/tobie/ua-parser
I am in the process of updating my business website and I've decided to use HTML5/CSS3 (with some PHP) for the whole thing and it works fantastic in every new browser (IE9, FF6, O11, S5, C13) with or without JS.
Now I am not sure what I should do about every other browser version. I imagine I have a small amount of leeway with most of the browsers (atleast the previous version) except IE8 (I have the IE shiv, but it doesn't cover non-js browsers.). Most of the features degrade nicely, but there will always be issues with older browsers.
I know nonJS browsers are probably a minority, but it would be nice
to cover them as well
This list is ordered in the order of current preference to cover the
largest number of browsers(nonJS/JS) but time to implement hasn't been
considered.
Only considering web-browsers, plan is for a mobile site for mobile browsers
Here is the list:
Build a really dodge version of the site using tables^, etc. and redirect the users there if they have an old version of the browser (server-side) and have a warning on there about upgrading.
Use Javascript to fix up the bits they don't work (like the shiv). This doesn't really cover the nonJS browsers which as stated are probably a minority.
Build a static old browser page to redirect the old browser users to a page with links to upgrade download links. This is a real copout solutions, but is quick to implement
Assume the only users that have old browsers are IE users, and use conditional comments to implement one of the previous options. Assumptions are always bad
Pretend users have the most upto date browsers and make no attempt to fix the site at all. Not really a practical option
Rebuild the website for HTML4 and use it accross the site. Bit of a waste of current work. As well as it looks a bit dissappointing if a webdeveloper has a site using old technologies, which was the driving force for the upgrade
What are your thoughts/solutions to the HTML4/5 limbo? Is there anything you've done in current projects to combat this?
Cheers,
Steve.
P.S. Being a member of the 'I hate IE6 and don't care for it's existance' club, I'm pretending that IE6 (or less) never existed.
Update (to clarify)
^ - by tables, I mean are really slapped together version of the current website, using either a table/non-table based layout. But something that may not look pretty when the source is viewed, it's really just there to fill the compatibility void.
It's perfectly acceptable to have features in some browsers and no features for an older browser. See Here.
However, it should be noted that whenever a fix is doable, you should have it. Unless a website is a JavaScript based app, it should be working without JavaScript, note that working != working perfectly.
if you have a hover state with a cool transition, which Chrome 23423 will support, but IE7 won't, then you can either emulate it using Modernizr and jQuery, or leave it as is, and IE7 won't enjoy the goodness. BooHoo.
You must however, give older browser users a message to encourage them to upgrade to a better ones, especially talking about IE<=7.
You built the website in the wrong direction.
If you want to support older versions, instead of building a cutting edge website and then trying to get it to work in older browsers, you need to build a basic site that works everywhere, then use advanced CSS and Javascript feature detection to add features for the newest browsers.
Like the title says I'm just wondering the current support for canvas.toDataUrl? I have it working in Firefox 4 but haven't really tried it in any other browers. When I look it up on Google most of the results are pretty scattered as some are from a year ago. It says its only supported with webkit nightly builds. (which I assume now are the actual releases)
I'd also like to know the support for mobile devices as well.
I personally prefer using caniuse.com for finding out the current browser support. Caniuse covers various major releases of each browser, as well as some mobile browsers. However, I always recommend that with anything mission critical, you test in all browsers just to be on the safe side.
If you take a look again at caniuse.com you will see that the support tables are all color-coded and they tell you whether a browser fully-supports, partially-supports, does not support, or does not support (but a polyfill exists). The canvas.toDataUrl, property would fall under the category of "basic support", which shows that the canvas api (or rather the current working draft for it) is fully supported in all major browsers, and there is a polyfill available for IE.
So while it doesn't go into great detail about the specific properties browsers support, it stands to reason if a browser "fully-supports" the basic canvas API, you can safely assume that includes toDataUrl. Once again, if you dont want to leave things to chance, or if you for some reason do not trust caniuse.com, your best bet is to build a test-suite and personally test your app against all browsers.
Actually it's currently broken in the webkit nightly build, a minor security bug I found a couple days ago:
http://code.google.com/p/chromium/issues/detail?id=91016
But in general in the stable release of Chrome it works just fine. In IE9 it works just fine too.
If you had to choose a browser (just one) to be the primarily supported browser for a company jumping into HTML5 (CSS3).. Which one would be your safest bet on the middle-long term?
Chrome, FireFox, Safari, IE?
I'm looking for an objective recommendation based on standards driven/compliant, developer tools, fast & correct feature implementations, memory footprint, etc.
UserBase/MarketShare would not be an issue because it would be on a closed environment in which we control the clients (which are basically big machines with a Web interface).
Thanks!
I would say a webkit based browser. That would be the best balance of speed/stability and HTML5/CSS3 features.
However I believe that Opera has the most implemented features.
Opera has always been in the lead, but they've also always had weird bugs. Right now, Chrome is in an interesting position: Google just bought an internet video protocol company (On2), and so they have the power to end the H.264 vs. Ogg Theora battle by releasing this great new codec they've bought as open source.
HTML5 itself isn't anything new: it's just new elements that display differently. Think of it like this: if HTML5 was the first to introduce the <blink> tag, developers would be a little iffy about it because you can just use CSS to set text-decoration:blink or use some Javascript to make the blinking happen.
With HTML5, things aren't that different. Most of the new elements are just extensions of <div>. For the ones that aren't (<video>, <audio>, <canvas>, etc.), there are either already strong implementations (pretty much across the board) or the implementations as complete as the HTML5 spec is.
Will there be a best browser for HTML5? Probably not. It's all just a matter of how the browsers position themselves (like I mentioned with Chrome above).
If you control the environment I would say pick one based on that has features your app can exploit to make your job easier. Otherwise, lower-common-denominator is a widely used approach for a small team.
I would say Gecko (firefox and friends) or webkit (safari, chrome and friends). I wouldn't go with IE nor Opera. Here is a HTML5/CSS3 comparison table that pretty much supports my views.
Safari’s pushing CSS animations and transitions, if they’re a big draw for you.
If you want to make a HTML5 app/site that focuses on one browser, then you might as well use HTML 4 and JavaScript. For the next many many years most HTML5 sites will have to function in non-HTML5 mode.
See HTML5 features as glacing on the cake, to add benefits to the browsers that can take advantage of it.
All the modern versions of browser support HTML 5. But recently launched internet explorer 9 specifically designed by keeping in mind future web technology needs and incorporated latest features that give rich and interactive web experience. Latest browser Internet explorer 9 has more support for Cascading Style Sheet than previous versions of Microsoft browser. It supports CSS3 and more emerging SVG2 markup standards. IE 9 includes new java script engine that designed to take advantage of multi core processor and give maximum performance.