How much of a browser
compatibility issue is there with perl?
Short answer: as much as you print out.
Perl is a server-side language, JavaScript is a client-side
language. That being said, a client doesn't care
what generates the content it requests, be it Perl or
PHP - just as long as it starts with a valid HEADER.
I have written CGI scripts that were implemented
in Perl that created JavaScript code embedded in HTML 'code.'
If the JavaScript
code is non-compatible across different browsers, it's
not Perl's fault - it's MicroSoft's^Wthe browser's fault.
Just remember that the problem is on the client's side.
Luckily though, a Perl CGI script can detect what browser
was used when it gets a request by checking the value
of $ENV{'HTTP_USER_AGENT'}. Here's a real world example:
my $browser = $ENV{'HTTP_USER_AGENT'};
my $explode = ($browser =~ /MSIE (\d+(?:\.\d+)?)/ && $1 >= 5);
if ($explode) {
# print out IE5 compliant javascript code
print "
document.form.select.options.remove(0);
";
}
else {
# print out standard (i wish) javascript code
print "
document.form.select.options[0] = null;
";
}
Jeff
happy happy joy joy happy happy joy joy
| [reply]
[d/l] |
Is browser compatibility something you should really worry about as an newbie trying to learn perl?
Unfortunately, yes, if you are using perl to output HTML or javascript to create a web page. Anytime you deal with HTML alone, you will have to check your output on multiple platforms/browser if formatting and/or layout is part of your site. In addition, if you are going to do CGI programming, such as with file uploads, then browser compatibility, as well as platform and webserver definitely becomes an issue.
jeffa explained well (above) the fact that Perl is a server-side language. This is why we love Perl - as long as you are in control of your server (i.e. allowed to execute a perl script), with a server-side language you can be 100% sure that any data processing will have the same output regardless of who receives it. It is when the client-side languages come into play - java, javascript, html,xml, etc. - that you can't be sure things are going to work the way you want it to on the other end (although ironically the basis of a client-side language is supposed to be compatibility).
In other words, if you have a simple site that allows a user to enter some information into a form, and the site processes the data in perl and returns it, no problem - the site will work as planned on all browsers. Add some formatting, layout, and graphics and you gotta start checking multiple browsers. Redo your site so that the form and data processing are done in javascript, and you pretty much restricted your users to IE for windows. And for some people, both IE and windows are the last choice they would ever use.
That's why you should complain to, for example, your bank, if their web banking site is written in javascript, forcing you to use a particular platform/browser. The bank is definitely in control of their server, and they should use a server-side language such as perl, python, whatever, to assure multi-platform/browser compatibility. Because there are very few things that javascript can do (such as opening a window to a specific size and controlling another window) that perl can't somehow do, at least in terms of a banking site.
Just to give you an example of the annoying compatibility issues that may surface, assuming that you are not even going to touch javascript:
even simple tables won't work right (usually in netscape) even after you checked all your tags.text will go beyond the border of the table, or the table will go beyond the border of the screen, even if there is no reason for it to do so.
a small font in one browser1 could be unreadable in broswer2, if you enlarge the font for browser2 it becomes huge in browser1.
a color of red on system1 may appear bright yellow-green on system2
Cascading style sheets, or even embedded style tags could be completely ignored or followed to the standard.
graphics may not be displayed the same - for example, if you use the GD module to create pngs, one browser may display the png's transparancy, but the other broswer won't
Throw in javascript, and if it's heavy enough, you may as well tell your users that they can't use linux or mac. (mac IE will probably work, but a lot of sites just check if your browser is a mac and not allow you to proceed). | [reply] |
As jeffa and fpi have already pointed out, browsers may
interpret content differently, whether that content is HTML,
JavaScript, XML, CSS or anything else.
Browsers also interpret HTTP
responses differently, so you should be aware of the
bugs
that exist in certain Web browsers.
Aside from browser compatibility issues, it's worth getting
to grips with HTTP if you're writing CGI scripts, because
you can use headers such as Expires, Content-Length
and Last-Modified to make your site appear faster
to users. The Issuing
Correct HTTP headers section of the mod_perl guide is
the best reference I know of for this. The examples are
specific to mod_perl, but the principles can be applied to
CGI, JSP, ASP or any other server-side Web programming.
| [reply] |