Looking for some best practice guidelines

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I'm a longtime programmer looking to try some web design - eventually
using PHP and MySQL, but I realize (with some help) that I need to get
grounded in HTML and CSS first.  I've got some HTML/CSS books lying
around, but since they're a few years old, I want to make sure I
ignore those parts that are no longer considered best practice.

So, would you folks mind specifying briefly those aspects of HTML and/
or CSS design that may have been popular in the past, but should be
avoided now.  Or, if you prefer, just a list of those aspects that
should be used in a modern design.

For example, it seems that I've read disparaging things about the
misuse of tables, and something about frames.  Sorry I can't be more
specific, but if these are big issues I'm sure they'll ring a bell.

Many thanks,

Re: Looking for some best practice guidelines

Mike Silva kirjoitti seuraavasti:
Quoted text here. Click to load it

Check out htmldog.com, it is considered a good tutorial and reference.

PS. You've heard right: don't use tables for layout or frames for...
http://users.utu.fi/athein /

Re: Looking for some best practice guidelines

Ari Heino wrote:

Quoted text here. Click to load it

I agree with the frames thing.

But why not using tables? I heard that before, but there is no really a =
fine alternative for some purposes (e.g. double columns).


Re: Looking for some best practice guidelines

Nicole wrote:
Quoted text here. Click to load it

There are many and varied alternatives, particularly for "double columns" or
even "triple columns".

Refer to the archives.

Re: Looking for some best practice guidelines

On Feb 21, 10:45=A0pm, "Nicole" <Wagner> wrote:
Quoted text here. Click to load it
You have plenty of alternatives now a days, take a look at an example
Regards Chad. http://freewebdesignonline.org

Re: Looking for some best practice guidelines

Quoted text here. Click to load it

Not many really - mostly things were avoided because they didn't work
in the '90s, then weren't understood in the early '00s. Post Firefox
and after IE5 disappeared it's a lot easier to use these features, but
old habits still die hard.

The Head First series are good first tutorials, and they're good at
teaching "good practice" too. "Head First HTML with CSS & XHTML" is my
favourite HTML book and their JavaScript and Web Design are worth
reading too. As a CSS desk reference, I still like Lie & Bos'
"Cascading Style Sheets".

HTMLDog   Not perfect, but the best I know
http://brainjar.com/css/positioning /
http://glish.com for some well-done worked examples
Joe Clarks' accessibility book is free on-line

Best practice techniques:

* Fluid design.
This is IMHO the biggie.  You don't know how big the user's window is
and you shouldn't try to control it. Fit your content into what they
have made available to you.

* Independence of screen size
Forget this "Best viewed at 800x600" business

* Independence of window size
You don't know how big their screen is, so you certainly

* Using text-based size units to define sizes of boxes and margins.
If you use ems for dimensions (sometimes pixels around images) then
you'll get fluid behaviours naturally.

* Accessibility
Read the Joe Clark text

* Standards compliance
Code according to the standards (HTML & CSS) and validate every time
you view a page. he standard is well-defined and objective, so you can
hope to meet it in a way you just can't for "browser compatibility"

* Device independence
They might be reading your page on their phone, or even their fridge.
Be fluid, follow the standards.

* Browser independence
It should work well on any browser. All current browsers are good, the
bad browsers aren't the nightmare they were in 2000

* Rational fluid design
Your page needs to work at any size, but it doesn't have to use every
last pixel it's given.

Suppose your page needs 800 pixels to work great. If you view it in a
2000 pixel window it doesn't need to do anything more than this. You
(as a designer) should _know_ how it will behave and make sure that it
doesn't fail, but fluid design doesn't mean that every available space
gets as much content rammed into it as will fit.

* Sensible whitespace

What happens in a window wider than expected?  Usability studies show
that text lines of more than 15 words become hard to read, so it's OK
to limit their length to just this (try 55ems as a starting point, for
English).  Use text-based units (ems) though, not pixels, or else
fluidity suffers, If the page is viewed in a super-wide window, where
will the whitespace go? Is this sensible? It's often better to throw
it to the right rather than centring no matter what. Expanding the
content width without end is rarely good.

* Avoid horizontal scrolling.

Rarely needed these days.

* Strongly avoid two dimensional scrolling

The problem with horizontal scrolling isn't that it's horizontal so
much as there being two dimensions of scrolling in play
simultaneously. A purely horizontal site might be OK (although a
little surprising, thus confusing) but a page that needs two-axis
scrolling is nasty,

* Remember multiple monitors.

Centring can put you right over the split.

* Floated boxes

Remember the simple thumbnail gallery. A linear series of floated
<div> is a much more fluid implementation than a <table>. It might
look just like a rectilinear grid, but how many columns are there? Is
this the same for all window sizes?  Floating boxes is an easy way to
gain a nicely fluid layout, even when all you need is a grid but you
don't know how big a grid.

* Appropriate JavaScript

It should almost never be _essential_

It should _add_ function to a page, You should know what the
JavaScript is for, The page with JavaScript should work _better_ than
a page without. A surprising number of JavaScript image zooms are
quite restrictive for the user, but they "look cool".

* HTML 4.01 Strict

* HTML 4.01

This is still the best version of HTML to use

* Strict HTML doctype

There is no reason to use the other doctypes.

Techniques to avoid:

* Frames. If you need to re-cycle menus between pages, either generate
them dynamically or use SSI.

* Tables for layout.
They were a hack, and they tended to be pixel-sized and thus non-
fluid. Learn better techniques.

* CSS over-enthusiasm
Use <table> whenever you _need_ a grid.  It didn't become the "wrong"
way to do something (although it's no longer needed in some cases that
weren't strictly grids to begin with).

* Firefox compatibility
If you have a single-browser only site and you want to support other
browsers, do this by aiming for the _standard_, not another browser.
It doesn't work if you try to "add support for" another browser one-by-
one. Standards are objective, browsers aren't.

* Browser sniffing
Don't make your page vary its behaviour according to the browser in
use. Just get it right according to the standard. Besides which, this
technique is brittle for new browsers you haven't yet encountered.

You _may_ use "feature sniffing" in JavaScript, but sniff on the
availability of a feature, not by identifying the browser's name and
then assuming its feature support.

* The "paper web"
The web isn't paper. Don't pretend it is, you'll make bad websites.
Even if you're a magazine publisher.

There's a lot you can't control on the web, so get used to it. You
can't enforce sizes. You can't usefully suggest exciting new fonts.
You certainly can't add huge backgrounds with large-scale graphic
elements on them and expect things to align.

The web is also a fluid medium, viewed through windows of varying
size. Don't read any of the fashionable texts on "layout grids" and
expect those to work on the web. If they do, they can only do so by
breaking fluid design (and that's much more valuable).

* PSD design

Don't design web pages ion PotatoShop first. This is the antithesis of
prototyping: it doesn't tell you what you need (broad design) quickly
enough, but it does restrict you to unimportant trivial details (was
that 4 or 5 pixels wide?) for ever more. Use crayons, or at least some
paper-based sketching.


Fashion fad, but it doesn't work with IE and so isn't safe to be used.
It's better to stick with HTML 4.01 than it is to wade into the XHTML
C kludges and work-rounds.

* HTML 5
Crazy people

Re: Looking for some best practice guidelines

In article

Quoted text here. Click to load it

A nice point

Quoted text here. Click to load it

It would the rare person indeed who had a *browser* across two monitors.
I run multiple monitors as one desktop but no browser fires up in the
middle. One can place the browser there. On rare occasions I have done
this for special purposes. At least on a Mac. Plus, on a Mac, the
maximize command goes for one screen, never the whole desktop. Its a
sort of intelligent max-zoom. Perhaps in Windows and other OSs the
maximise literally takes the whole desktop, perhaps you are talking this.


Re: Looking for some best practice guidelines

Quoted text here. Click to load it

This is mostly a problem for JavaScript and alert().  This used to be
ugly, now it's _really_ ugly.

I can configure my day-job Windows desktop so that "full screen" goes
to either full screen or full desktop. There are some internal web
apps (big reporting stuff) where I do show them full desk.

Re: Looking for some best practice guidelines

Quoted text here. Click to load it

The Head First series is generally the silliest attempt of ‘become a
ninja (anything) by watching tel-sell over night’ I’ve seen to date.

Maybe that’s the same as ‘good first tutorial’ at the other side of the
channel, all this cultural differences are reasonably hard to sort out.

Re: Looking for some best practice guidelines

Quoted text here. Click to load it

Yes, they're really silly. However they're also effective at teaching,
and they teach good practices that almost no other books do.

They have their limitations:

* You have to read them. Not just dip into them, but actually sit down
for at least a chapter at a time and follow their tutorial course
material exactly as intended.  Once you've completed the course, pass
them on.

* They assume you're a raw beginner. Great if you are, not bad if you
aren't, but not good if you refuse to read them as if you were a raw

My pitch here is mostly at graduate recruits, or at experienced <foo>
coders who are making a hash of trying to write some <bar>, I need
some good-practice material that fixes the bad habits they pick up
from reading the web tutorials and the accursed w3schools.

Re: Looking for some best practice guidelines

Quoted text here. Click to load it

The “effective at” seems arguable. Most instruction books incredibly
suck, so you might be right.

Quoted text here. Click to load it

I have a lot of books with that limitation. :)

Quoted text here. Click to load it

I don’t really know what that is. I read a few chapters on a subject I
am not familiar with. But after a few chapters I expect to learn some
stuff, not the nth iteration of why what is about to come soon will be
really exceptional on any cognitive level. Back then, I had read that
already in the previous (n-1) chapters. Learning by repetition
sometimes works for me, marketing by repetition never.

Quoted text here. Click to load it

OK. In the previous paragraph, I was a <foo> coder trying some <bar>.

I just think it’s a love or hate thing, and I always strongly recommend
renting one before buying any (I personally know more people who really
hate it).

Quoted text here. Click to load it

Yay for the Head First series!

Re: Looking for some best practice guidelines


Such an embarrassment of riches!  It'll take me some time to ponder
all that you wrote.  Thanks for taking the time to make such a
detailed response.


Re: Looking for some best practice guidelines

Quoted text here. Click to load it

Thankyou for the question. Some time this week I need to write a
detalied "How to refactor 2001 nastycode to today's best practice"

Re: Looking for some best practice guidelines

Quoted text here. Click to load it
Hi Mike. I think that everyone else has covered a lot of this main
issues. One thing that I should point out though it that, while
testing your pages for accessibility you should use an actually screen
reader or magnification program to test your pages, or get someone to
carry out of proper audit of your pages, if you have the money to do
so. As it can give you a good grounding on what you need to do to make
your pages accessible.
Make sure you have a good understanding of the W3C guidelines on web
accessibility, as that is what the agencies will use to determine if
your site is accessible, at least here in Australia anyway.
You can find the guidelines at:
http://www.w3.org/TR/WCAG20 /
Regards Chad. http://freewebdesignonline.org

Re: Looking for some best practice guidelines


Quoted text here. Click to load it

I'd suggest ignoring them completely!  Maybe read the "WCAG Samurai"
pages instead. The W3C has utterly failed to give useful leadership
with the WCAG content.

Site Timeline