Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I want to get smarter in AJAX, but not sure which way to go. I have done some DHTML programming back in the day - like 8 years ago!, before it was called AJAX. I used emacs and hand-coded all the javascript, debugged via "Alert".
At this point I think there are frameworks out there that make things nicer and easier, but which ones? Where to start? Recommendations?
is jQuery indispensable? Just nice to have?
What about project SACK?
Firebug?
any other free libraries or frameworks you recommend? or disrecommend?
for a very simple project I found tons of pitfalls with FF vs IE compat. Without getting into a religious debate about who is right and who is wrong, what are some tips for navigating that minefield to produce apps that work and look mostly similar on any browser. One guy had a tip: insert * {padding:0; margin:0;} at the top of his .css stack, because FF and IE both have different default padding and margins for elements like UL OL etc. Is there a list of tips like this? Guidance?
I don't have a Mac and really don't wanna incur the test cost of IE, FF, Opera, Safari, Chrome, across all the myriad versions and platforms. Hints? Is there a 80% solution here? Like if I test on FF & IE, can I guess it will work on the others?
tips on tutorial sites, getting started? There's tons of info out there, which are the good places to go. In particular, because DHTML was around 10 yrs ago, my google searches are turning up some really stale information.
Debugging and development tools? I found an xpath just-in-time evaluator on the web on zvon.org. It was good but not as flexible as i wanted it to be. This is something I think would be invaluable. xsl and xpath have got to be the most opaque languages I have ever used. When I started with regex, there were just-in-time regex tools available, like Expresso, etc. Those were invaluable for developing and learning regex in the early days. Last night I spent waaaay too long fiddling with an xpath expression, and I'm wondering if there are similar JIT tools for xpath. And what about debugging and developing Javascript itself?
Mostly I am interested in the client-side aspects. I am not so much interested in integrated client+server approaches like ASP.NET AJAX, for now. If you told me about a client AJAX framework or development tool that worked only with Ruby, I wouldn't be interested.
Thanks!
EDIT: why did I get voted down? Is this a bad question to ask? It seemed perfectly reasonable to me? is it impolite?
it's usually even easier than the ajax() function above. mostly i just do ....
$('#mydiv').load('http://getsomehtml.php?op=loadmeup');
once in awhile add a callback
document.body.style.cursor = "wait";
$('#mydiv').load('http://getsomehtml.php?op=loadmeup', function() {
document.body.style.cursor = "default";
});
and I agree jQuery is indispensable. or something like it .. using raw javascript is a minefield of problems with all the browsers these days. I like visualjquery.com as a handy reference (but I wish Remy would update it to 1.3.2)
And I could not do my job w/o Firebug so that's totally required.
I run xampplite on a PC for testing. And I use NotePad++ or Eclipse PDT 2.0 for editing (esp for server-side PHP) and CVS and i'm good to go...
The way I do multi-browser testing is via a VM. I use Sun's VirtualBox and an XP virtual machine with all the browsers loaded up. I regularly use FF3 and IE7, so my VM has in it IE6, FF2, Chrome, Opera, and Safari. I sometimes use a Ubuntu 8.10 image but not really all that often.
For Regex get a copy of RegexBuddy - easily worth the $40
Personally I think jQuery is indispensable. There are a lot of browser differences with XMLHttpRequest. jQuery simplifies all that. Here is an example:
$.ajax({
url: 'document.xml',
type: 'GET',
dataType: 'xml',
timeout: 1000,
error: function(){
alert('Error loading XML document');
},
success: function(xml){
// do something with xml
}
});
You can easily change this to return JSON, HTML, etcj.
Also there are wrapper methods for this that greatly reduce the number of parameters like $.load(), $.post() and so on.
In reference to browser differences, I strongly suggest you start with a CSS reset like Yahoo's reset CSS (there are others).
In terms of development, Firefox is the standard, combined with Firebug (and typically YSlow). HttpFox and Web Developer are popular plug-ins too.
jQuery isn't indispensable, but it's very helpful.
never heard about it
I think one js framework is enough. So i recommend jQuery.
CSS reset is not going to fix all compatibility issues, but it can help significantly. For ultimate css reset see Eric Meyer's CSS reset.
Try http://browsershots.org/
I don't have any recommendation here.
For debugging javascript - firebug (firefox extension). You can also want to try fiddler to check what's passed between server and client.
For making Ajax requests, I use http://www.prototypejs.org/
For everything else, I write my own JavaScript. Even if it matter of fading a div, I still prefer to do it my way as a way of learning.
As to getting started, here is my quick tutorial:
new Ajax.Updater(domId, urlToAPage);
Where:
domId = anything on your html page that has an id, as long as it is not an input object.
urlToAPage = could be the page to contact and get the data from.
You can make the request more complex:
new Ajax.Updater(domId, urlToAPage, {method: 'post', parameters: pars} );
You can change method from 'post' to 'get'.
Pars can be anything. Further more, it looks same for post request. So if you want to make a request to a file called hello.php and send a post parameter with two arguments, then place the response into a div called 'hello':
var domId = 'hello';
var urltoPage = 'hello.php';
var pars = 'hello=1&name=hsbsitez';
read more: http://www.prototypejs.org/learn/introduction-to-ajax
I also would highly recomend using JQuery. It makes life so much easier.
One thing I learned about JS though is never to trust that it works. Just because you use JQuery and it works in a few browsers doesnt mean it works in the others.
You have to try it in as many borwsers on as many systems as you can.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I am working on my first project that requires me to worry about cross browser compatibility. Since this is my first time doing so, I dont know how to go about completing the project. I am specifically worried about IE. Should I complete my project in a more graceful browser then hack it to work in IE, or should I simultaneously build my program up in both environments?
Design your site to work in standards complaint browsers first. I always start with Firefox, even when developing on my company Intranet (where everyone uses IE). Doing so will let you focus on getting your markup and CSS correct. This is what is most important.
The important thing to note is that you'll want to "future proof" your site, and concentrating on a standards compliant browser will help you do that.
Then, once you're confident your site is looking correct (validators are your friend!), try it out in the versions of IE you want to support. In order to get your layout to look OK in IE, I strongly suggest using different stylesheets for each version of IE, using conditional comments.
Also, you should note that many others have been in the same scenario as yourself, and there is quite a bit of help available. One popular method of forcing IE to behave is the ie-7.js project.
Lastly, be mindful of the top IE bugs, such as:
IE6 Box Model Bug
IE6 transparent PNG images (I have used this fix in the past)
A few tips:
Code to Standards — Start by ensuring that what you've just developed works in Firefox and Chrome, and then verify it in IE. I'll usually then check it out in Safari. It's always better to make sure your markup/code works in a more standards compliant browser first.
Validate Early, Validate Often — You don't want your design to look perfect in one browser, find out that it's broken in another, discover that to fix the broken layout you needed to correct some invalid HTML/CSS, only to find that now the first browser looks wrong.
Progressive enhancement — will be your friend. Start basic, with simple HTML and simple CSS, and no JavaScript whatsoever. Repeat tips #1 and #2, then move on to more complex styles and layout. Contiue this iterative process until you are happy with the design in all browsers. Only then should you consider JavaScript to polish the site.
Check each browser often — Don't develop the entire website in a single, compliant browser like Firefox, and then decide to "see what's broken" in IE. If you've got a complex, dynamic website, there could be MANY problems in Internet Explorer. Trying to decipher each one when they are compounding on each other is a nightmare.
Reset Stylesheet — As #Eir mentioned in the comments, find a good reset stylesheet. Although, they have fallen out of favor for some people, I find putting every browser on the same footing from the start helps tremendously.
Use a Framework — I find CSS Frameworks to be excessive, but some people swear by them, so to each his own. On the other hand, as soon as you have made it to the JavaScript phase of development, I highly recommended using jQuery or MooTools. They are very focused on circumventing cross-browser inconsistencies.
Let JSLint hurt your feelings — Even when using a JavaScript framework, there are certain standards of coding to which JSLint will help you conform. Some of the options are a bit overly strict, but I promise that if you clean your scripts through this tool often enough during development, you will almost never encounter those strange times when everything seems to work in all browsers except IE.
And some great tools! Everything in the above list you should consider mandatory practice. The following can spice it up for you in a pinch, but is optional:
CSS Browser Selector — it is rare that you will need this, but if all else fails, it's way cooler than using a separate stylesheet just for one browser (I despise conditional comments). It basically adds classes to your <html> tag, so you can do things like the following in your main stylesheet: .ie7 #header {/*stylese here for IE7 only*/}. It supports a lot of browsers on many operating systems. And it's fast.
Browsershots — Nothing beats the real thing, but if you can't install a suite of browsers, this and other tools like it can help.
IE6 CSS Fixer — I outright refuse to debug my designs in IE6. I coerced my company (via many chagrin-filled meetings with IT and management) to drop support for it (thank god). It's just counter-productive to waste so much time forcing this pile-of-ahem... Anyway, if you aren't like me and need to support IE6, this tool can help.
Also you should focus on resetting css like this
OOoooo, good question:
here's my take:
Decide which browsers you are supporting. I suggest IE 7 + 8, FF, Chrome and Safari as in order of importance. (only support IE6 if you absolutely have to!). It helps if you know your userbase here.
Use a css reset. Different browsers have different default styles. a css reset gives you a consistent base.
Keep your markup as simple as possible. Follow Standards (and see progressive enhancement on Stephen's answer).
Test every step of the way on your target browsers. That way you can correct problems right away. http://crossbrowsertesting.com/ is the best resource for this, but there are free ones for screenshots as well.
Avoid Hacks as much as possible. Most cross-browser issues these days can be solved without resorting to hacks.
Ask questions here when you get stuck. If this is your first project dealing with browsers, you will get bewildered by inconsistencies. We all face these issues, and are glad to help.
Be ok with the fact that webpages are not going to look exactly the same in all browsers. (once again, see progressive enhancement).
Good luck coding!
I develop for Firefox first, and then work out the IE buggery. Rarely do I "hack" it, rather find something that works in both, or at worst use IE conditional comments. Just one coder's preference. Always a good idea to test with Safari, too.
Two big advantages of Firefox are: the Error Console, and the Firebug plugin.
there is alot of greate tools that makes life alot easier for you there is for example a
css framework called blueprint you could use, it has already everything set for every specific browser so that you get the same outcome in all browsers. And using jquery as your javascript framework does add an extra insurance that you'll have it working in most browser.
but remeber there is no such thing as 100% cross browser compatibility for all the browsers and all the versions in world.
In theory would be best to develop for all browsers at once, always testing for every browser...
Realistically, that rarely happens... I typically develop/test with firefox. when I introduce complex javascript or css, I check in ie... this tool is incredibly handy for checking all versions at once... google ie tester.
By checking all browsers at regular intervals, and when you make complex changes, you ensure that major features are compatable :)
Also, ensuring that all of your code is valid is not only good practice, but helps identify cross browser issues.. google w3schools validator :)
Using javascript libraries such as jquery also aid in cross browser compatability, and some even come with css libraries as well. These libraries are purpose built for quick, reliable features that are typically cross browser guaranteed.
Finally, before launching, use launchlist to check that all works: http://lite.launchlist.net/
Hope all that makes sense and helps with your first project :)
During the past few months, I've been working on a large web application. Repeatedly, we've written code that, according to DOM & JS specifications, should work perfectly, but still manages to completely kill one or more of our test browsers -- recently, we produced pure JavaScript code that should have been harmless but causes General Protection Faults in IE8, other pieces of code that completely freeze Safari, etc.
Well, we'll solve each issue, item by item, with as much blood, sweat and code as it takes. But the question I have in mind is the following: is there a knowledge base on such browser frailties? Something comparable to quirksmode.org, but with guidelines on how to code stuff to avoid killing our browsers?
Thanks.
edit Precision: not that it changes anything to the question, but we're using jQuery.
You've probably already been down this road, but most of the major libraries like jQuery, Prototype, YUI, Closure, or any of several others are going to have run into most of these issues and coded around them for you already.
If you are writing manual DOM/JS, please use a library as T.J. Crowder mentioned. These libraries solve nearly all the common inconsistencies between DOM libraries and make a usable sugar sweet API layer on top.
I have listed a bunch of websites that document cross-browser bugs in a previous answer.
This question already has answers here:
Why is jQuery not integrated within the browser
(7 answers)
Closed 4 years ago.
It seems like a good idea to me. or add the additional features to Javascript itself?
Because it's just one library of many. It may be popular but it's far from being the only choice. And it would also cause it to freeze at a particular version and make improvements much slower.
Plus there is little advantage anyway. It's fairly small and you can set it to be cachable indefinably by the brower so it will only be downloaded once anyway - if you have a new version it will have a new filename, so there is no harm in making it never expire.
I think this question should be a bigger discussion, but these answers are all bogus.
This is also 2 years later of course.
"it's just one library of many" - include the top 11 then.
"couldn't agree on common standard" - Kind of making jQuery a standard of it's own at this point.
"updated more often than browsers" or "make improvements slower" - So the browser won't have jQuery-1.9.x until next browser update, just don't put it in your project yet.
"Cache anyway" - Sure, it's still a transfer that doesn't have to happen, and there are a lot of people that haven't done a lot of surfing on their new device that you still want your site fast for and so on.
The thing is it is totally doable and would be better for the internet load; by how much is debatable. I could really see chrome at least replacing any net transfer to their CDN with a local copy, but I'm sure there is some legal, security or net neutrality issues with that. Just like I'm sure the main reason has something more to do with such matters and not these lame technical excuses that are obviously not thought through.
This could benefit other libraries too if developers could rely on the speed and availability of a complete library of tools like dojo, and not have to pick and choose just to cut weight. And also as most libraries have adopted the AMD or requireJS approach to package their projects, I believe there is a good argument for the enabling the browser to at least be informed of it's dependencies.
jQuery exists just because they (browser makers) couldn't agree on common standard.
You can consider jQuery to be a JavaScript plug-in. And browsers do not ship with plug-ins, otherwise the purpose of plug-ins would be irrelevant.
Plugins get updated more often than browsers - within a week the browser version of jQuery would be out of date :)
There's also the issue of versioning. Certain sites and extensions of jQuery require a certain version of jQuery. Right now it's up to the application to decide which version to use.
Probably because browsers are hard to update. Some freature of JQuery may eventually make their way into javascript, and I believe some of it has just recently. (well the idea's anyways) It takes years to add a feature to something like javascript, where the JQuery library can just release a new version.
There is actually a firebug or firefox plug in that allows you to inject JQuery into the page.. but thats just a development tool
Adding jQuery [type] functionality to the browser's in-built JS implementation (or making it a 1st-class plug-in) would overcome one basic problem:
As many have said, jQuery is a JS library - meaning, in case the penny didn't drop - that it is written in JS and has to be interpreted at run-time.
Embedding it would mean that it could be written in native code for the OS, making it much more performant.
This website that I use has a WYSIWYG that ONLY works in IE. And I refuse to use IE or to tell my non-tech team to use IE.
I was wondering if there is a user script or browser plugin that would enable anyone to inject a WYSIWYG such as CKeditor.com onto any site textarea?
Edit: I would also be willing to work on it myself if anyone wants to help or give advice. We could then post it on userscripts or something ...
Since you don't have access to the code, anything you do will be a hack.
With that in mind, I would start looking at Greasemonkey. It is a firefox plugin that allows you to inject javascript code into any web page on your machine. Its a long road, but that's probably your first step.
One word of warning however: While I share in your dislike of IE, it sounds like your hatred has grown to the point where it is being counterproductive. Seriously consider whether what you are about to do is worth the effort.
You can use this extension in Firefox as long as you get at least a textarea in that CMS: https://addons.mozilla.org/en-US/firefox/addon/6147/
Would a Firefox extension that displays websites as if they were in IE do the trick?
I like Stargazer712's answer (look into Greasemonkey), but there is another option.
Suck it up and use IE for just this site.
Hey, I hate IE6 and 7 as much as the next Web developer. I advise non-techies to stay away from it, and to use Firefox or Chrome. My answer isn't meant to be flip or funny.
Sometimes, if you need to get the job done, you choose the best tool for the job (even if you don't like using the tool) to get the work done in the most efficient manner possible. In this case, it sounds like using IE to access this particular Web site takes care of the problem without a single line of code or documentation written on your part.
The alternative is spending hours finding (and testing -- because you won't be the only user) an alternative...or worse, spending hours or days developing (and, again, testing) your own code to fix the problem that, at the end of the day, is really only caused by your strong dislike of the one software application that works.
There is a particular website I must use for work which is absolutely heinous and despised by all who must use it. In particular, the site's Javascript is fundamentally broken and works only in IE, which pretty much makes it the only site I must use outside my preferred browsers.
So, to the question. If I could 'patch' the javascript after loading the website in such a fashion as to 'do the right thing', I could then use the website without IE.
( Just to cut out some of the superfluous answers: I have already tried masking both browsers as IE, which has no effect because the issue is with the javascript, not browser detection on the server. )
I would prefer solutions which are for Opera, though I'm not opposed to Firefox answers. Also, I would rather not have to view the site though a proxy, though I will entertain such answers.
For Opera, you want User JavaScript. Similar to Greasemonkey, but built-in to Opera. Built to be used for exactly the sort of situation you're in: fixing sites that are broken in Opera...
For Firefox, you could use the Greasemonkey addon to do this.
You could probably use the Greasemonkey addon for firefox to do this. It would let you write javascript to run in their page, and could probably use that to do a "patch" at runtime. I've never written a greasemonkey script before, so I don't know how easy it would be to get something working, but it might be worth a look.
Greasemonkey is exactly what you want for this. I have extensively hacked some sites using it and there are a plethora of good examples at www.greasespot.net. Although this page is about Opera it has some good examples that are applicable to Greasemonkey in firefox too. I also noticed that the Greasemonkey wikipedia article has information about using Greasemonkey or equivalents in other browsers too.
You can use also a proxy (I used Proxomitron a long time ago, there are more modern equivalences) which alters the page on the fly before they reach the browser... Thus you can remove all original JavaScript, and add your own, by this way, or with Greasemonkey or user scripts.
I'm not sure that GreaseMonkey will be much good for patching.
GM scripts run after the page has loaded and all native scripts have run so anything that was going to break will already have broken.