My approach is with features that they really should have had in the first place (eg HTML 4.01, CSS1 compliance), make no compromises - if they have an old browser, then they'll *see* that they need to upgrade. It's much easier to say "What? You can't see that? Oh yes, that's because your browser doesn't fully support HTML 4.0" than tell people that you don't want to support them.
As for features which they don't necessarily have to have - eg frames, javascript, images, embedded sounds, shockwave - I make sure there's always a valid fallback for compatibility reasons. For example:
- You might use the content of an 'object' tag to provide similar functionality (or provide a link to somewhere that does) to whatever the <object> tag refers to (eg, a sound, swf, an image).
- You could set the 'alt' attribute of any <img> tags to something descriptive (ie, not "") and set background colours of the surrounding element (wrap it in a
if you need to) to match an approximation of the image.
- Set CSS attributes to be as compatible as you can without compromising the style they describe, and use HTML style attributes to take up the slack if possible/necessary
- If you require javascript for navigation, add in an HTML equivalent (eg, a form with drop-down menus and a submit button), and use body.onload to hide (or empty) it for those that do support javascript; also provide both href and onclick attributes for javascript popups - compliant browsers should hit 'onclick' first.
- Use <noframes> and <noscript>.
- Test your site in different text sizes. Consider specifying everything's size in 'em' not 'px'.
And of course there are a handful of near-zero-impact workarounds for minor lack of capabilities, eg provide XHTML files as text/html and don't include any <?xml ?> type tags.
...all of which largely covers accessibility rather than compatibility. It's not too important that your project be compatible; it is critical that your project be accessible. On the same subject, see the W3Cs take on accessibility
Saying all that, I have in the past compromised on certain bugs in *current* browsers, eg MSIE6s mishandling of <button>, 'fixed' by on-the-fly conversion to an <input type='hidden'><input type='submit' onclick=''> pair. I really hate browser bugs.
In any case never, ever compromise on standards or you'll quickly find that others (browsers) aren't supporting you (your site) any more.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|