Netscape fails to read a lot of jQuery written. What steps do you take to overcome these, and how much of the market do netscape users take up?
Steps I would take:
Let it fail
Wait for Netscape users to notice they are using a long dead browser with security holes in it
The market share for Netscape is as close to zero as makes no matter.
Umm, 0%?
Having said that, I have to admit that jquery fails on a lot of sites while prototype works, in my ancient Konqueror 3.5.10, so maybe there's a pattern here.
Although I grew up on Netscape ;-) ...its no longer maintained (R.I.P)
Thus as much as I'm all for the "support all browsers" mantra - supporting users of a now "dead" technology seems like a tall task.
IIRC, the jQuery support matrix is based on supporting the latest supported major version of a major browser (and 1 level previous). Netscape 7 and 8 are both excluded from this list.
I would suggest a simple "Please Upgrade" notice for the site... and since the users are on Netscape, Firefox would be a very compatible path to upgrade on since the concepts and layout are very similar (e.g. bookmarks, context menu options, etc.)
Thus providing a Download link for Firefox 3 would provide users a smooth guided path to upgrade.
Maybe just a simple iframe with this would work well.
Related
There are many tools to work around browser prefixes, be it IDE auto-expansion for troublesome properties or making mixins with precompilers, but why exactly do browser manufacturers NEED to implement prefixes. From what I've heard it's so they can implement their own implementation of something, but what prevents them from doing so without a prefix. Nowadays especially almost all browsers try to follow the W3 specifications, so I doubt Safari would make, say box-shadow, draw a rainbow inside an element.
Isn't it better to leave their "solution" although maybe a bit buggy or lacking in functionality, unprefixed, so when they actually roll out a working version that meets all criteria, sites written using that style of JavaScript property can function as intended? I just really can't see how everyone decided that it's a good idea to implement them.
The idea was that authors who wanted to "try" out these experimental features locally could do so with the prefixed properties on shipping browsers, rather than having to deal with nightly builds or even downloading and compiling the source manually, because shipping buggy behavior unprefixed was akin to shipping beta software as production-quality.
What the vendors didn't see coming was that authors would take the prefixed properties, put them on production sites, and encourage other authors to do the same. As a result the prefixes spread like wildfire to the point where vendors were too afraid to break sites by removing the prefixes after shipping stable, unprefix implementations as originally intended. I mean, just look at what happened when Mozilla dropped support for -moz-opacity, a prefixed property that was relatively little used compared to today's -webkit- properties, less than 4 years ago. For perspective, -moz-opacity was unprefixed in Firefox 0.9, almost 12 years ago.
Another unfortunate result of this prefix fiasco? Opera, Microsoft, and finally Mozilla, have all reluctantly changed their CSS implementations to recognize -webkit- prefixes because WebKit was making its way into practically every mobile device and every niche browser, and authors were under the impression that WebKit was the One True Layout Engine™, and so they coded for WebKit and nothing else. Clearly we haven't learned from the IE/Netscape browser wars.
And this is why vendors have agreed not to use prefixes for experimental implementations of upcoming standards anymore going forward. New CSS features will ship unprefixed, but not made available by default. For example, Firefox hides these features behind special about:config options and switches them on by default at a later date, while Chrome hides them in about:flags in a similar fashion.
Let's say I outsource the development of an HTML/JS/CSS/AJAX web app targeting ONLY modern browsers. If it matters, assume there are 20 unique templates used in creating the application (to give an idea of the size of this application). My understanding is that much time/money is spent hand tweaking the code to make it consistent among browsers. I'm interested in ways to minimize this expense.
As of June 2011, Google Chrome Frame is advertised to not require administrator privileges for the user to download and install for IE 6-9, which essentially runs Chrome as a plug-in inside IE to avoid browser incompatibility issues with IE (substituting potential compatibility problems with Chrome, which should be much less than IE).
If I were to direct the developers to target only modern browsers minus IE, requiring all IE users to download Chrome Frame instead, would this path translate into any significant development cost/time savings? (My users are engineers and may be willing to accept this tradeoff since this application is not offered elsewhere.) I just don't have a feel for how much effort is made for IE versus other (modern) browsers, and wondered if anyone with experience could comment whether this makes cents (pun intended) or is simply crazy.
Also, any downside to doing this?
You will save time and money. I have done something similar for our in-house application. The site runs only on webkit browsers (chrome and safary).
We save a log of time, because the css and JavaScript can be more efficient, and most importantly, we do not have to test every change on 6 different browsers. This is very liberating.
If your users allow you to exclude IE, i recommend it.
It all depends on your application and developers. With enough knowledge it's possible to write code without even checking in IE until the end but only keeping it in mind and have 99% of things as expected in ie8-9, 80% in ie6-7.
If your users are engineers I can hardly imagine them using ie in the first place and even if so definitely not ie6/7.
Even if you don't go with Chrome-frame, given above points, if you're willing to go with slight to mild visual design degradation you can get away without specifically targeting ie...
Here's a little ie9 promo for ya :)
http://varonasf.com/ie69/
(only works in decent browsers)
This is the design decision behind Google Frame. You always have the choice of either designing for the lowest common denominator, i.e. IE6, and having a limited function site, or designing for a reasonable HTML 5 standard and forcing users to upgrade.
...allowing users to access modern web technologies like HTML5 on
legacy browsers.
http://blog.chromium.org/2010/09/google-chrome-frame-stable-and-speedy.html
as I am getting more and more into Android PhoneGap app development, I can see more and more nuances and little details between built-in Android browsers throughout the versions. I searched for some official or fan document, which would deal with these browser version differences. But I can't find anything useful.
It's a lot frustrating, because you have to test everything on all versions of Android emulator and if app grows big, it's A LOT of work to test all the features in all versions.
Everyone is excited about HTML5, I was too, but only to the point when I moved to doing the real thing. I realized that there is so many problems when dealing with different versions of Android behaving sometimes a lot differently.
If anyone has some good resource to share, I would be very happy. Thanks
EDIT: Added example of different behaviour betweeen Android browser versions ( but there is many of them):
This works in Android browser in 1.6, 2.2, 2.3 and 2.3.3. But it failes (application crashes or stops JS execution) in Android 2.1:
Object.keys(var).length
You asked a pretty general question. The general purpose answer is that any sort of cross browser development (even cross versions of the same browser) requires that you develop a familiarity with what features are safe across the targeted browsers, which features are not safe across the targeted browsers and which ones must be used only with careful testing or feature detection with fallback.
While one wouldn't exactly expect the type of difference you saw with the one example you referenced, it is clear that that is a fairly new feature in ECMAScript and it's not consistently implemented across normal browsers so I would put it in the category where it is not safe to assume that it works on all versions of Android, even if you've seen it some versions of Android. That means to me that you should only use it if you've explicitly tested that it's reliable in all the browser versions you are targeting or devise a feature test and only use it when you know it's present and reliable or develop a safer work-around.
As I think has been mentioned previously, this thread has a bunch of proposed work-arounds for the specific issue you mentioned.
I am not aware of any detailed written material that would document in advance for you the details of the differences between different Android browser versions. Since it's open source, there are probably developer checkin notes and some level of release notes, but that will probably be like looking for a needle in a haystack and may not even contain what you want. It is rare for any developers to produce such detailed information. We don't generally get that level of detail from any of the existing desktop browsers or iOS browsers and, even if you were on the development team itself, you probably would only see part of this info. I don't think you're going to find official documentation that covers what you want.
You're going to have to learn to treat is as more of an unknown and learn what areas are "safe", what areas require extensive testing before using and what areas are just too risky. Even when doing that, you'll find Android bugs in some version that trip you up. That's just the nature of building on someone else's platform. At least the Android set of browsers are a much simpler target than trying to target all desktop browsers from IE6 to IE9, Firefox 3 to 5, Safari 3 to 5, Opera 9 to 11, Chrome 9 to 12, all Android, all iOS and use HTML5 when available which is what I'm working on.
Once you've been through this wringer a couple times, you will realize that if the newer language/library feature carries any risk, you shouldn't use it at all unless it's absolutely central to what you're trying to accomplish and then you will have to test the hell out of it. If it's something like getting the length of the associative array which is just a programmer's convenience, then it's probably simpler to stick with a work-around that is guaranteed to be safe and just not spend your time dealing with any browser-support risk.
The only official documentation I am aware of is part of the Android developer documentation. If I were a betting man, I would bet that it only covers a subset of what you are seeking.
The general idea behind cross browser Javascript is inline feature testing (at least how I've come to accept it.) I don't know exactly what "features" you are specifically looking for but it's generally wise to test for the existence of a feature set then use it and have a fallback if that doesn't exist. (Even if the fallback is, "This site requires a browser that supports 'foo'")
Since you didn't give any examples, I'll pick on Ajax. It's always best to check for the existence of window.XMLHttpRequest, then act upon it. Of course, this is not performant if you are doing it for every instance of need so you could write a check procedure or a wrapper to accept your list of necessity let your wrapper cache/call the appropriate methods to perform that task.
Without examples of "features" that you are talking about being different from browser to browser though, it's hard to give any concrete advice on direction.
I've been lucky to develop websites for the past 3 years for companies that don't need to support IE 6 in any way.
I've just accepted a development job with a company that works exclusively with IE 6 customers in the financial field. These people may be hemmed in by corporate IT departments or haven't upgraded, or whatever the reason is, we have to support IE 6 (and JUST IE 6).
I have no background in supporting this browser and I used to happily skip over SO questions that dealt with IE lte selectors and all of that. But now that it's going to pay the bills, I want to know as mch as I can about the CSS selectors that work/don't work, how JS may be quirky, and anything else that may help me catch up in the new job.
Is there a good respository of the "quirks" that make up the lovable IE 6 experience, or is it spread piecemeal across the 'tubes?
Is there a good respository of the "quirks" that make up the lovable IE 6 experience
quirksmode.org is an excellent resource for browser compatibility questions. It has great, nicely designed compatibility tables that give you almost everything you need to know. Be sure to take a look.
At hasLayout is an excellent overview of all known IE CSS bugs, most of them complete with solutions. This site is imo better overviewable, a real bug repository. All is summarized in short instead of spread over 100s pages like Quirksmode, which in turn is however excellent as a general reference.
My clients use IE6. The repositories listed above may mention these, but nevertheless I write them here.
If you use https, avoid mixed content messages by avoiding javascript:void(0) and similar constructs.
If you use https, avoid mixed content messages by ensuring all iframes have a valid src attribute.
Find a copy of Microsoft Script Debugger and learn to love it. It stinks, but it seems to be the only game in town.
Ask your company to let you develop using FF and FireBug (I did), develop using these, and test very often in IE6.
I use the following URL to dump the DOM:
javascript:'<xmp>%20+%20window.document.body.outerHTML%20+%20</xmp>'
Quirksmode is an invaluable source of information for this sort of thing.
In particular, take a look at the compatibility tables.
"QuirksMode.org is the prime source for browser compatibility information on the Internet." Specifically, to your question visit the CSS2 page there, and look at the IE6 column on the table.
This is a nice article about the 9 most common IE bugs and how to fix them.
Good suggestions... a couple of things that might help:
"Microsoft Visual Web Developer 2008 Express Edition" is much better than the old "Microsoft Script Debugger": http://www.microsoft.com/express/Web/
There's also Firebug Lite: http://getfirebug.com/firebuglite
A compatibility library for browsers that lack full support for JavaScript 1.6: http://en.wikipedia.org/wiki/MediaWiki:Gadget-JSL.js
MSDN will help too: http://msdn.microsoft.com/en-us/default.aspx
It's the year 2009. Internet Explorer 8 has finally been released, and Firefox is coming up to 3.5. Many of the large browsers are starting to integrate features from CSS3 and HTML 5, or have been doing that for quite a while now. Still, I find myself developing web pages exactly the same way I did back in 2005.
A lot of progress has been made since then, and I think the reason that I haven't started taking advantage of these new possibilities is that it's so hard to know which of the new features that work in all major browsers. Since I'm mostly a backend developer I just don't have the time to keep up these developments anymore. Still, I feel like I'm missing out on a lot of cool stuff that actually would make my life a lot easier.
How can I quickly determine if a feature of CSS3 or HTML5 is supported by all major modern browsers?
Can I Use is a website which tracks browser support for current and upcoming web standards. Check it out if you would like to know whether or not a given feature is widely supported.
Font embedding through CSS, using #font-face. Webkit/Safari has been supporting it since version 3.1, Microsoft since IE4, Mozilla since Firefox 3.5 (browser support overview).
Also, the varied implementations of the Selectors API, which provides a browser-native CSS selector engine for use in DOM scripting.
For other examples, When Can I Use... seems to be a very good reference.
I would say display:table and a range of CSS2.1 selectors are the big wins for designers. display:table solves some unsolvable or difficult layouts like 100% height and inside borders without breaking semantics and using actual tables.
Multiple classes (.c1.c2)
I use min/max-width/height a lot.
Also working :hover and !important are awesome.
I would have liked to add SVG support to that list but naturally Microsoft messed that up.
BTW, big warning to those getting excited about HTML5 features. There is no official date for the adoption of this spec. It's even been implied it could take another 10 years (though I doubt that). The point is anything you do with HTML5 now is subject to breakage when the official spec does arrive and in the meantime you can expect plenty of browser inconsistencies, bugs and API changes (not to mention browsers that don't support the features at all).
Browser support for local storage should enable a bunch of new ideas now that some content can be saved on a user's machine.
Reference docs:
Mozilla Firefox
Internet Explorer