<happydayz2u@[EMAIL PROTECTED]
> wrote in message
news:1212273330_340926@[EMAIL PROTECTED]
> Announcing Downloadz Depot (www.downloadzdepot.com) - A GREAT new source
> for
> all of your software, music and digital download needs!! Be one of the
> first 100 people to register at DownloadzDepot.com and you will receive
30
> awesome mp3 downloads for FREE. Also buy 2 items and you will receive
> your
> choice of any third item for FREE.
>
> We offer hundreds of top-rated software titles for PC and Mac in every
> category:
> - business
> - music
> - entertainment
> - utilities
> - anti-virus
> - multi-media
> - meditation, sleep aids and nature sounds
> - sound effects
> - DVD burn/convert etc
>
> ....all priced from only $4 to $6!! Visit now: www.downloadzdepot.com
>
Those Cross-Browser Blues: How To Develop Web Sites For Both Internet
Explorer And FireFox
If you're trying to develop sites which will be compatible with IE,
Firefox, and Opera, watch out -- there are still a lot of speed bumps
out there. We examine six of them, and let you in on some solutions.
By Serdar Yegulalp, InformationWeek
Aug. 28, 2007
URL:
http://www.informationweek.com/story/showArticle.jhtml?articleID=201802175
It's no surprise that most of the cross-browser issues out there center
around Microsoft's Internet Explorer and the Mozilla browser family --
mainly Firefox.
Love it or hate it -- and let's face it, most of us probably either hate
it or manifest mere tolerance for it -- Internet Explorer is here to
stay, the way Windows itself is probably here to stay. According to the
most recent W3Schools re****t, IE in all its incarnations commands about
58% of the browser usage pie, down from its high of 90% or more, but
definitely still large enough to matter.
Then there's the question of which version of IE. IE 6 is still the most
widely-used version of IE (37%), but IE 7 is gaining fast -- up from 13%
at the start of 2007 to nearly 20% of the total. For developers, IE 7
can't catch on fast enough, since it fixes many things that have long
been broken in IE6.
But the introduction of IE 7 is still no cure-all. There are many IE
issues that remain outstanding; getting the majority of existing IE
users to work with IE 7 (or later) is a slow process; and existing Web
sites that are dependent on an IE-specific technology, like ActiveX
controls (about which I'll have more to say later), may have trouble
switching away to something more browser-neutral.
Against all of this, the Mozilla browser family -- first Netscape, now
Firefox -- has made serious inroads. Netscape was the first major Web
browser on the PC (aside from NCSA Mosaic, of course), but over time it
stagnated and lost out to IE's ascendancy. In only a couple of years,
Firefox has turned that situation around and carved out a significant
niche across multiple platforms -- 34.5% and climbing, according to the
aforementioned re****t. That said, as Firefox caught on it became clear
that many existing sites had been written to favor IE's interpretations
of things and didn't render correctly in Firefox.
This situation doesn't seem to be quite as dire as when, say, Firefox
was still in its 1.x incarnation. Most broadly-trafficked sites today do
render properly in both browsers, with only relatively minor variations
between them. But Web designers still have to accommodate both IE and
Firefox as elegantly as possible -- and to accommodate the smattering of
other browsers that have grown in popularity as well: Opera, Safari,
Konqueror, and Webkit.
Incidentally, while Opera doesn't command a very large stake of the
browser market, it has a fiercely devoted following. It hews most
closely to the Mozilla way of doing things as well, so coding for the
most broadly-accepted set of Web standards out there will work best for
Opera, too.
In the following pages, I look at six major issues that developers
should keep in mind when trying to create sites that work properly
across all browsers, and provide some possible solutions as well:
* Quirky Implementations Of Layout Functions
* Proprietary IE-Only HTML Tags
* JavaScript And Automation
* ActiveX
* User Interface And Keybindings
* Planning For The Future
Keep in mind that (as we all know) there are so many factors operating
when you develop a Web site that not every solution may work for every
situation. Also, these categories aren't all-inclusive or closed-ended;
something that might be in one category may also lapse slightly into
another, or there may be other things I haven't explicitly mentioned
that could be dropped into any of them.
1
Quirky Implementations Of Layout Functions
This is the most common place where people run into issues. They create
something in one browser, and then find that the way it's rendered in
another simply isn't the same because there are different unspoken
assumptions at work about how the standard is to be implemented.
Solution:
The first thing to do is find out specifically what's not implementing
correctly. If you're looking at a page in IE and text is not flowing
correctly or behaving as it's expected to within a box, such as a DIV or
SPAN, there's a chance you may be dealing with IE's quirky box model,
which handles boxes a little differently from the Mozilla method.
There's also a key difference in the way IE and Firefox handle an
overflowing box, and IE's odd handling of non-enclosed floats (another
box-related issue) is something that still persists with IE 7. The pages
I've link to here dissect the problems in detail and demonstrate a
couple of workarounds.
A great many examples of these kinds of deviations can be seen on the
QuirksMode site, but it has not been updated recently -- the
compatibility grids don't mention IE 7 at all. But you can run live
tests against many different HTML, CSS and JavaScript standards and
functions, and see how they behave (or don't behave) in any given
browser. There's also a detailed discussion of this sort of thing (from
the POV of a Firefox-friendly designer) on the Computer Gripes site. He
goes into some detail about specific sites that have caused trouble for
Firefox, and describes specific behaviors that may vary (such as
horizontal rules created with the HR tag).
2
Proprietary IE-Only HTML Tags
IE's implementation of Web standards includes a whole slew of ad hoc
additions to the HTML tag library that don't show up elsewhere. Most of
these seem to have been on the wane, but every now and then you run
across a site where they still haven't been eliminated.
Solution:
The only viable long-term solution is to move away from proprietary
tags, since the few that are really worth using often implement
functionality that can be done in a proper cross-browser fa****on anyway.
Those that aren't cross-browser are usually frivolities.
A simple example: The bgproperties attribute for the body tag allowed
you to keep a background image on a page stationary while someone
scrolls through the page. This particular method doesn't work in other
browsers other than IE, but there is a CSS style attribute --
background: fixed -- that accomplishes the same thing on both IE and
Mozilla.
Another proprietary tag I've seen used in IE, but not widely (thank
goodness), and that can and should be done away, with is the CSS font /
image filter system. This employs the filter: statement in a CSS style
declaration to add various kinds of post-processing to images and fonts
directly on a Web page. There are some examples on David J. Hark's Web
site; view this page in IE and then in Firefox to see the differences.
This is the sort of thing that can be dropped into the same trash can as
the blink tag, if only in the name of good taste.
3
JavaScript And Automation
"Fussy" is the nicest word I have for the way JavaScript can be
implemented across platforms. What works fine in one place will simply
not work at all in another, or won't work as intended. While there's a
common pool of commands that is shared by almost every browser's
implementation of JavaScript, there are a few that simply don't exist in
one browser or the other.
IE, for instance, doesn't implement the JavaScript function
getComputedStyle() or the cssRules[] array, while Firefox doesn't
implement the handy innerText function. And up until fairly recently
(version 9.2 or so), Opera didn't allow frames to be resized via
JavaScript. A small omission, sure, but it drove me up one wall and down
another, since I was using a JavaScript-resized frame to accomplish a
very specific effect that I had a hard time doing another way. (I
eventually found another way to do it, but only after the Opera behavior
had already been fixed.)
In the same vein, browsers have different ways of re****ting back the
size of a given window, which can play havoc with window manipulations.
In IE, a window's measurements include the "chrome" (scrollbars, menuing
elements, status bar, etc.), but in Mozilla, the window's measurements
don't include any of that and just run from one inner edge of the window
to the other. This makes it slightly harder to create, for instance, a
JavaScript window resize that operates reliably across both browsers
without handling each browser as a separate case. (Here's a page that
talks about the ways different browsers interpret JavaScript window size
functions.)
Solution:
Three basic solutions present themselves here:
A. Drop back to a common base of JavaScript for all browser projects.
This may only be viable if you have the time and effort to rework all
the existing JS code from scratch, as it may be a fairly major
undertaking. This means insuring that no future code uses JS that is not
sup****ted on the majority of platforms as well. On the plus side, it
means you only have one branch of the code to deal with. Sometimes you
can implement individual functions that you need by using "spot cheats",
like Scot Hanselman's way to implement the innerText function in Firefox.
B. Use browser detection and browser-specific code. This approach
requires that you maintain at least two separate branches of code (IE
vs. everything else, essentially), so it's that much more work. One way
to implement these kinds of changes in CSS itself without using
browser-detection per se is to use conditional style-sheets, which apply
patches to CSS styles that work for IE but not FF (or vice versa).
C. Use cross-browser libraries. If you want to write JavaScript that
works cross-browser every time, one way to do that is to use someone
else's JavaScript function library that's been designed to do that kind
of work for you. Consider the GNU LGPL-licensed Cross-Browser.com
libraries, which package a whole host of useful JS functions in ways
that work with pretty much every browser out there. You don't have to
include the whole gallery of functions on a given site; you can pick and
choose what's needed and keep your include files relatively small.
Yootools is another cross-browser function library with some fairly
advanced features, including a Window.Size function that helps work
around cross-browser window-size issues.
4
ActiveX
This is one part that really drives people crazy. IE-specific ActiveX
controls, as opposed to plugins that work in almost all browsers (such
as Flash or QuickTime), force people to use IE to load a given page (or
a whole site) whether they want to or not.
Sadly, this often isn't a design move that you can just undo, since it's
often rooted in other technology decisions. Consider NetFlix's Watch Now
function, which lets you watch movies streamed from NetFlix's online
library in a browser. The required plugin is IE-only, because it uses a
security wrapper and codec provided by Windows Media Player. There's no
way to change something like that without reworking the entire content
delivery mechanism.
Solution:
There are two basic ways to deal with ActiveX being an IE-only issue,
aside from mandating the user of IE:
A. Move away from ActiveX entirely. Again, this isn't always something
you can declare by fiat -- especially if the decision to use or not use
ActiveX isn't something that is in your hands. If you have the clout to
do so, suggest as many non-platform-specific alternatives as you can.
Solutions written in Flash are probably the best substitute for ActiveX
multimedia controls, and there are a great many third-party Flash
controls to choose from that offer such things.
B. Compel non-IE users to use ActiveX compatibility controls. This seems
like an interim solution at best. It is possible for Firefox users to
run ActiveX controls using a Firefox plugin, but a given user might not
be in a position to install said control, and even if they are, they may
not want to do that.
5
User Interface And Keybindings
This is a relatively minor issue, but one that became significant for me
when I tried to write an AJAX-based chat application that used it. It's
possible to bind hotkeys (Alt + a given letter key) to certain Web
controls, like form buttons, by using the accesskey attribute for the
control in question.
The problem is that the browser isn't always obliged to implement the
chosen access key, especially if it overrides an existing browser
command. The way the hotkey is invoked also varies from browser to
browser -- and even varies among iterations of a given browser. In
Firefox 1.x, the default was Alt + hotkey; in FF 2.x, it's now ****ft +
Alt + hotkey. It's possible to reset the default behavior with an
about:config hack -- change ui.key.contentaccess to 4 -- but I've found
people aren't always willing to make changes like that for the sake of a
couple of sites.
Solution:
Because of the scattershot way this feature's implemented, it's best not
to rely on it for anything, but simply to provide it as an adjunct to
existing functionality. Another way to handle it is not to use accesskey
at all, but to use cross-browser JavaScript to trap keystrokes and
implement focus changes or commands as needed.
6
Planning For The Future
Obviously, it makes sense to find and deal with any existing issues in
these categories -- but that's not going to be enough. There are too
many ways things can go wrong when developing a site; and it can take
hours to track down an issue and figure out a fix. Avoiding problems is
a lot simpler, and takes a lot less time.
Solution:
I've compiled several key pointers to stick with as you create new sites
or revamp current ones.
A. Test, test, test. The only real long-term way to deal with the
possible quirks between browsers is to vigorously and thoroughly test
any site you're responsible for in all the major browsers, side-by-side,
and see what happens. Work with your own sites across the major browsers
-- don't just passively browse, but try to actually get things done, and
see what happens.
On Windows, it's not difficult at all to get IE 7, Firefox, and Opera
all running side-by-side without stepping on each other's toes; Firefox
is even available in a ****table edition for those who want to run it
without installing it. (Opera comes in a ****table version, too.)
If you're not currently running Windows but are forced to test
compatibility with IE anyway, there are a couple of solutions. A fairly
elaborate series of hacks exist to run IE on top of Linux through the
WINE compatibility layer, although it only works for IE 6 and lower.
Another solution involves the use of a virtual-computing product like
VMware or VirtualBox to run Windows itself. Interestingly enough,
Microsoft provides a virtual hard-disk file that contains a
fully-licensed (albeit time-limited) installation of Windows XP SP2 with
either IE 6 or IE 7 available on it -- useful if you don't have, say, an
MSDN subscription.
Also be sure to validate any code you create, since browsers have
different ways of recovering from a broken piece of HTML, and you don't
want to be at the mercy of such mechanisms. While debugging an older
site, I tried to figure out why a given page wouldn't load at all in
Firefox, while IE rendered it spotlessly. A quick pass with an HTML
validator showed the problem: a table was missing its closing < /table >
tag. When I supplied the missing tag, all was well again. Apparently IE
is a bit more forgiving about tables that have missing tags, at least
when dealing with the quirks-mode formatting of most existing Web pages.
B. Pick a standard and stick with it. IE may have a big installed base,
but coding for IE first is not something you should do unless you have
been ordered to do so. My own habit has been to use Firefox as the
baseline for everything -- since more browsers tend to render like
Firefox than they do IE -- and then make any IE- or other
browser-specific fixes after that. If you're in the process of
re-centering everything on Mozilla standards, IBM has a long and
detailed do***ent in their developerWorks library about how to
transition Web docs from IE to Mozilla, including a number of general
cross-browser tips.
C. Annotate and warn. If you have implemented things you want to sup****t
but simply cannot get them to work properly across the board, at least
make sure the people accessing your site know about it or can look it up
somewhere. If you know certain functions won't work in IE, you can use a
browser-detection routine (see below) to insert a notice to the effect
that some features may be degraded in certain browsers. Better to tell
them upfront than to let them find out on their own!
D. Pick a browser and make everyone else stick with it, too. This is not
likely to make you popular with many people, but if you have specific
reasons for working on one and only one browser, it is possible to
enforce this rule. Just be prepared to get plenty of hate mail, as few
people like being bullied into using any specific browser.
Note that simply evaluating the browser's user-agent string, while
useful, will not tell you if a given browser is what it says it is,
since the browser can claim to be anything at all. Use an object test on
the client side to get a slightly more accurate picture. One
quick-and-dirty way I tested for IE vs. everything else on one of my
sites was to use a bit of JavaScript on the client end to see if
window.ActiveXObject was sup****ted by that browser. If it was, it was
probably IE. If not, it probably wasn't.
E. Keep an eye on the future. Web "standards," and especially their
implementations, aren't static things. Even a small change to the right
of the decimal point can affect the way things render or behave. Stay
abreast of those changes whenever you can, so that you can counter them
proactively instead of reactively.
http://www.informationweek.com/internet/showArticle.jhtml?articleID=201802175
|
