As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We are working on a web application which only supports "modern" browsers (basically IE9 and up, and any other browser which has roughly the same amount of modern features).
Our web application will also work on mobile devices like tablets and smartphones.
Since this is a web application (as opposed to a normal website), we are okay with some users being left out in the cold for some of the advanced features which rely on modern features (i.e., older browsers).
However, we want to at least display a message letting them know.
We want to maintain basically two lists: "supported browsers" and "unsupported browsers", with a third implicit list "not supported browsers" (i.e., browsers that are on neither least).
If the browser was on the supported list, we wouldn't show anything.
If it is on the "unsupported" list, it will always show a message which says "This browser is unsupported, please upgrade blah blah".
If the browser is not in either, it will display a message (which can be almost-permanently dismissed) which says something like "This browser isn't tested directly against our site and some features may not function as intended. If you experience any issues, please report them blah blah".
Building this and what not isn't an issue. However, I was wondering if there was some site/service out there with an API that already did this sort of thing, or at least maintained lists of browsers which I could pull from. (If not, I just plan to use manual testing combined with info from sites like "Can I use..." and Modernizr).
Any ideas?
Poking around online all the resources I've looked at say that you should essentially never use browser detect. It's better to test for features you know DO NOT exist in the browsers you can't support instead of trying to look at the user-agent string.
http://www.quirksmode.org/js/support.html (If you want to know whether the browser that views your page supports certain objects you want to use in your code, you should never EVER use a browser detect. )
http://api.jquery.com/jQuery.support/ (Rather than using $.browser to detect the current user agent and alter the page presentation based on which browser is running, it is a good practice to use feature detection.)
So I think your approach with modernizer is probably the best.
You don't need a service.
The 'supported' list contains only those browser/device/OS combinations that you actually test.
The 'unsupported' list contains those browser/device/OS combinations that you know don't work (i.e, they failed your tests)
The 'might work' list is implicit as you've mentioned.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am new to JavaScript. I am referring to a page on JavaScript framework: What is a JavaScript framework?
I know JavaScript is for the web client side. It is a object-oriented script language. The link above writes:
Using JavaScript, however, is not an easy task, primarily due to the complications that arise when trying to provide support for multiple Web browsers.
Like HTML and CSS, different browsers have separate implementations of JavaScript, and it can be a nightmare to ensure that your JavaScript code is cross-browser compatible.
The second part says different browsers has different implementations. Why?
Since JavaScript is just a language like Java, C etc. Why do different browsers need different implementations?
As long as the JavaScript language specification is released, each browser should follow the language requirement. So why they have different implementations?
What does the implementation here mean?
EDIT:
JavaScript is NOT a object-oriented language! It is a language based on objects!
"Implementation" here is the engine that was implemented by a browser vendor according to ECMAScript specification.
As long as the java script language specification is released, each browser should follow the language requirement
And they do
So why they have different implementations?
Because they follow the same specification but build their own engine.
That's just the way it is. Not every browser uses the same JavaScript engine, click the link if you want to read some interesting history.
They all try to be the fastest. And yes they should all follow the exact same specification, and I'm sure they have followed the exact same specification, but there are still people involved, and they might interpret the specification slightly differently.
These engines are being developed in parallel (at the same time), as none of their developers have time to wait for the others to develop something first, and then check to see if they can comply with the exact same interpretation of the specification as their competitors.
JavaScript is an ECMA standard programming language and does not need to run in a browser. The browser has a JavaScript enginge that runs the script for you but not all browsers run it the same way.
Notabley is the way IE and other browsers handle events and new features are sometimes not supported. IE implemented things like innerHTML wich was not ECMA standard but because of it's popularity other browsers adopted it. It might be part of the standard now but I'm not sure.
The reason for this is that when NetScape came with JavaScript support IE implemented it as well but with other (extra) features. Since they both try to compete to be the "better" browser they didn't work together on making a standard.
A good source for JavaScript usage in browsers is MDN It usually shows you browser support for JS methods and properties as well as some code to add some support for browsers that don't support certain features (like DOMParser parsing text/html)
In the last couple of years IE has made a move to be more ECMA complient so hopefully in the future we would have to rely on less and less feature detection in our JavaScript code.
You still have a problem that JavaScript is a still evolving language and more and more features are added. When they are new than browers will still implement it differently or not implement all featueres (like webcrt). You might also have to support browsers that are a couple of years old and a lot of things change in a couple of years.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Hello cool so I think I have a good question for a bit of a debate. I am currently looking for a good method for displaying something important - terms and conditions for a product - so when a client comes to a page in order for them to access to any functionality they need to agree with the terms and conditions. now I know there are some disadvantages with pop-ups like:
If scripting is disabled, or if the browser does not support JavaScript, the pop-up will not work
Search engines cannot follow links to pop-up windows (scripted elements are always ignored)
Pop-ups present accessibility problems
Site management tools (e.g. DreamWeaver) cannot update links to pop-ups if you move the destination page to another section of your site
Many people have pop-up killers running that close the window the moment it’s opened
In Mozilla, there is an option to stop pop-ups opening in the first place
Not the thing I am worried about is that lightbox might not be compatible withsome of the older browsers. here in africa people are not super up-to date I have seen people using ie-4 (shivers down the spine). but we are only really concerned from ie-7 up. has anyone used lightbox before? or have any suggestions for something of this nature? I am use there must be a lot of use case for a feature like this.
What do you think?
as a webdeveloper myself i suggest you to use lightbox over popup anytime.
Your concern are right but i would rather focus on a couple:
rarely javascript is disabled nowaday, if it is often it's becouse of
company firewall and they wouldn't let the employers access
your site in first place. Yes, some people is still using old browser but it's diminishing overtime, if you are really concerned about it you can, with some more work, create both a popup and a lightbox and drive it trough the meta user agent check.
popup are incredibly annoying for the people becouse:
a) you have to click or to "tab-dance" on a different window that the one currently
active. b) as you stated most of the browser now block popup as a
default feature, so there are high chance that people won't even go
through the step of allowing the popup of www.mycoolsite.org to
work. c)it can kill any google analytics tracement (if you want any)
while lightboxes it's a normal html element in the page and thus
traceable via javascript event bind.
lightbox is amazingly easy to use and customize, offering you the
chance to develop your idea without compromise.
In your situation and technical requirements (IE4, no-javascript), you shouldn't use either.
Put a page in front of product access where the user needs to agree to terms.
That is the most pragmatic approach, business value before eye candy.
In fact, I would even go as far as to say that for required terms agreements, both lightbox and popup are anti-patterns, they just needlessly complicate matters for both developers and end users.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Recently, I discovered that Internet Explorer flat-out doesn't support certain selectors in jQuery (see Why can't Internet Explorer run this simple jQuery?). My question is: how can I know that my code will actually work while I'm writing it? Since I'm on Linux, my options are really just Chrome and Firefox. Is there a tool which emulates the functionality of major browsers for testing compatibility for a given site? My entire script mentioned in the above post failed for a few reasons but largely because the selector didn't get anything.
I initially thought that jQuery was cross-browser compliant, but it seems that selectors vary from browser to browser. Is there a way of testing for this?
Being a Linux user doesn't mean that you cannot use Internet Explorer. Create and start a Virtual Machine, such as VirtualBox, and simulate Windows + Internet Explorer.
The indexOf function has nothing to do with jQuery. It's an array function. The selectors work just fine, it's just that the code you're using to process the results is not cross-browser compatible.
Yea, cross-browser testing is simply a PITA. There's no real good way around it. As was mentioned, setting up virtual machines with various OS configurations is a good approach. However, there are several "cloud" services online that allow you to "rent" boxes you can TS into and debug. One such example I found with a quick Google search was: http://www.cloudtesting.com/
Though jQuery is a cross-platform library, it doesn't mean there doesn't exist bugs on certain browsers or certain versions of different browsers. jQuery is an open-source project, and if you find bugs in their platform you're welcome to fix them or at least report them so that they can be addressed.
For specific IE bugs, there are usually some work-arounds. For example, if Array doesn't support indexOf, you can always implement it yourself by modifying the Array.prototype
Good luck!
You can use browsershots to get a screenshot in a LOT of browers.
Sometimes you have to wait a long time before you get the screenshot, and the code has to accessible to any computer. But it's not like you are publishing it to everyone.
I know that sometimes, a screenshot wont cut it. But it is better than nothing.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
From searching SO, this question was already asked, almost a year ago now.
So now with the new FF, Opera, IE, is it finally time to start developing sites with HTML5 or is it still a little premature and will cause compatibility issues?
Is using HTML5 just going to require us to use more and more JS on websites to 'trick' older browsers into working properly?
It's a great idea if used in a "Progressive Enhancement" way. ie. Code your website to work in "standard" HTML 4.01 mode, and then add some fancy HTML 5 bits to give it some extra flourishes in browsers that support HTML 5
If you add nice features to your site, it is possible it will be talked about and reach the news sites for some free publicity.
Aside from that, It would make a good beta site and give you a head start for when it becomes the new technology. However, until HTML 5 enabled browsers are widespread (at least 20% of the market, possibly 50%) it makes little sense to alienate nearly the whole internet.
If there is a feature in HTML 5 would be useful for the project you are working on, then it is worth considering using it.
You will need to weigh the benefits against the possibility of the specification changing, the less mature testing tools available for HTML5 validation and the probability that you will need to use JavaScript to fake support in older browsers (of course, the HTML 5 spec gives a roadmap that someone else may have already followed in writing such JS).
If HTML 4.01 gives you everything you need — stick with that.
Assess your target audience. Are they likely to be early-adopters? Is it critical that all visitors to your site are catered for? Or will a few not mind being met with an inconvenient, yet polite "please upgrade your browser" message?
For business sites I'd say no. Not yet, anyway. You probably can't afford to lose users of older browsers.
For a personal website or project, why not? It'll be great experience learning the latest HTML5 features, and you'll be ahead of the curve when it does become mainstream. Besides, more people writing sites conforming to HTML5 means more pressure on users of older browsers to upgrade, benefitting all of us in the long run.
The answer is most certainly YES. Firefox, Safari, Chrome and Opera make up more than 30% of the market and they support many HTML5 standards:
Audio & video tag
New tags (footer, header, section, etc)
Canvas
HTML5 doctype (<!DOCTYPE html>)
validator.w3.org supports HTML5 validation (it's experimental, but it seems stable)
For IE you can use these things to make some HTML5 elements work:
HTML5 shiv: http://ejohn.org/blog/html5-shiv/ , this allows you to style new tags in IE
Fallbacks for IE when using the video tag: http://hacks.mozilla.org/2009/06/html5-video-fallbacks-markup/
ExplorerCanvas: http://code.google.com/p/explorercanvas/ , allows the use of canvas in IE
And IE supports the HTML5 doctype, it simply renders in strict mode, which is fine.
Hope that helps, and gets you started using HTML5!
Bruce Lawson of Opera gave an interesting presentation on this at OSCON, see his slides; the verbal conclusion was that it's OK, though there was some debate. Of course that's from somebody working for a browser maker so they're going to be less worried about older browsers (since everybody upgrading is to their advantage;-). The more you need to worry about older browsers, the worse your life is in general of course, but html 5 wouldn't help you there, sigh!-(
I have begun developing pages with the new HTML5 DOCTYPE:
<! DOCTYPE html>
This new DOCTYPE essentially puts the browser into a sorta "standards-based mode." Obviously this is all pretty new to most browsers but creating pages under this DOCTYPE will allow sites to last longer than ever. This also degrades gracefully within every browser I have tested in and no noticeable HTML or CSS downsides.
W3C has began using an experimental validator for HTML5 which can be used the exact same way as all of their other validation engines. An intersting side note: According to the W3C validator, you do not need to close the BODY or HTML tag at the end of the page; allowing for very minimal load time decreases.
As HTML5 continues to make its way to the forefront, I plan to begin implementing more advancements that just the DOCTYPE. For now that seems to be all that is new and widely supported.
Hope this helps.
-B
This site has a pretty good HTML5 shiv for IE. Just include it on you page and you can then style the HTML5 elements.
http://html5.adamhunter.me/examples/html-shiv
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As users, we love the power of Greasemonkey. As developers, it can complicate things.
Some people advocate defensively disabling user scripts; others are willing to die to defend them.
Is there a middle ground? How can we reduce the threat of an evolutionary arms race between users and unscrupulous advertisers?
Any control you think you have over which user agents your site visitors use is illusory. However, the vast majority will be using vanilla IE/Firefox/Safari. But, if you've a site where the audience has adopted a Greasemonkey script en masse, then treat that as a strong vote from your users that the site needs to change!
If your users are using a Greasemonkey script and coming back, take it as good fortune: there's something they need that you're not giving them, and they haven't left yet.
If they didn't have Greasemonkey, they'd be gone. What can you do to keep them?
If someone uses a browser plugin or modification of any kind, you shouldn't attempt to block them or disable it- that's just likely to result in more problems.
On the other hand, you shouldn't support them either; if it works, let it work, if it breaks, let it break.
Lots of people use dodgy browser add-ons, sometimes unintentionally and occasionally without any choice (Corporate IT imposes some dodgy IE modification on them). Try to play nicely with everyone.
I agree with MarkR (+1, by the way).
The application is on the client side...
So whatever web designers will try to do to stop some feature, they will either anger their users, have them hack away another solution, or move away to friendlier sites.
(I hate it when some broken down site needs me opening my Firefox debugger to enable me to complete my correct for just because some braindead developer forgot to declare his i loop variable and thus, making it a global... And I did it again less than two days ago)
As online apps should never rely on client-side controls and protections (i.e. testing the date value on client is a cool bonus, but testing it anyway and always on the server is the thing to do).
To the worst thing that could happen would be for the app to break on the GM user because of some faulty script. But from the server viewpoint, it should remain pristine.
... Thus, the client should be held responsible...
That means that whatever hack the user adds to his browser, the user is then on his own. At the very best, he/she could discover some hidden bug and report it. On the worst side, the site won't work properly
...Now, does it means client/server cooperation, too?
Most people using GM or whatever to enhance a site is showing that the site does not suit exactly is tastes. The good thing, like Rich wrote down, is that they are still on your site, and not elsewhere.
Either the "enhancement" is for his/her own very personal taste, and, hey, what's the problem if he/she wants to see your black-on-white web page with yellow-on-blue? Or perhaps the "enhancement" adds a lot of value to your site. In this case, I guess that what you want is to either offer the same features for everyone (thanking the author of the GM for his idea could be a good idea), or perhaps support it as an optional feature ("click here for advanced experience") or... an GreaseMonkey script?
I don't see why developers should hate it?
Advertisers? Nowadays, I doubt people write GM scripts to get rid of ads, they use AdBlock [Plus] instead...
In general, I write GM scripts to improve something lacking in the sites where I go frequently, so if you try and take measures to disable GM, I would be very upset and might boycott the site.
Beside, I guess that the number of people knowledgeable enough to install GM (even those using pre-made scripts) is quite small with regard to total number of visitors.
We've got accept the reality of our platform: once your website is in the (computer) memory of the viewer, they're able to do whatever they want with it, without your permission. Popular sites that try to dictate their own viewing terms to their audience often suffer immediate and angry backlash - instead of trying to do it your way, let the users do what they want, embrace it, and you'll end up providing a better service, which your users will appreciate and reward.