Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

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.


In reply to HTML accessibility by rjimlad
in thread OT: Web Design - Catering to Everyone by arashi

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • 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.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2024-04-19 13:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found