Looking for some best practice guidelines

Discussion in 'HTML' started by Mike Silva, Feb 20, 2009.

  1. Mike Silva

    Mike Silva Guest

    Hi,

    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,
    Mike
    Mike Silva, Feb 20, 2009
    #1
    1. Advertising

  2. Mike Silva

    Ari Heino Guest

    Mike Silva kirjoitti seuraavasti:
    > 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.


    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...
    anything!
    --
    Ari
    http://users.utu.fi/athein/
    Ari Heino, Feb 20, 2009
    #2
    1. Advertising

  3. Mike Silva

    Andy Dingley Guest

    On 20 Feb, 17:05, Mike Silva <> wrote:

    > 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.


    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.

    Books:
    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".

    Websites:
    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"
    tests.

    * 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.

    * XHTML

    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
    Andy Dingley, Feb 21, 2009
    #3
  4. Mike Silva

    dorayme Guest

    In article
    <>,
    Andy Dingley <> wrote:


    > 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) ...


    A nice point

    >
    > * Remember multiple monitors.
    >
    > Centring can put you right over the split.


    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.

    --
    dorayme
    dorayme, Feb 21, 2009
    #4
  5. Mike Silva

    Eric Bednarz Guest

    Andy Dingley <> writes:

    > The Head First series are good first tutorials, and they're good at
    > teaching "good practice" too.


    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.
    Eric Bednarz, Feb 21, 2009
    #5
  6. Mike Silva

    Mike Silva Guest

    Andy,

    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.

    Mike
    Mike Silva, Feb 21, 2009
    #6
  7. Mike Silva

    Andy Dingley Guest

    On 21 Feb, 01:50, Mike Silva <> wrote:
    > Thanks for taking the time to make such a
    > detailed response.


    Thankyou for the question. Some time this week I need to write a
    detalied "How to refactor 2001 nastycode to today's best practice"
    guide.
    Andy Dingley, Feb 21, 2009
    #7
  8. Mike Silva

    Andy Dingley Guest

    On 21 Feb, 01:01, dorayme <> wrote:

    > > * Remember multiple monitors.
    > > Centring can put you right over the split.

    >
    > It would the rare person indeed who had a *browser* across two monitors.


    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.
    Andy Dingley, Feb 21, 2009
    #8
  9. Mike Silva

    Andy Dingley Guest

    On 21 Feb, 01:34, Eric Bednarz <> wrote:

    > 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.


    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
    beginner.

    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.
    Andy Dingley, Feb 21, 2009
    #9
  10. Mike Silva

    Nicole Guest

    Ari Heino wrote:


    >
    > PS. You've heard right: don't use tables for layout or frames for... anything!



    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).


    Nicole
    Nicole, Feb 21, 2009
    #10
  11. Nicole wrote:
    > Ari Heino wrote:
    >
    >
    >> PS. You've heard right: don't use tables for layout or frames for... anything!

    >
    >
    > 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).


    If it is just for the page layout there have be countless, and I mean
    countless examples posted in this newsgroup.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Feb 21, 2009
    #11
  12. Mike Silva

    rf Guest

    Nicole wrote:
    > Ari Heino wrote:
    >
    >
    >>
    >> PS. You've heard right: don't use tables for layout or frames for...
    >> anything!

    >
    >
    > 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).


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

    Refer to the archives.
    rf, Feb 21, 2009
    #12
  13. Mike Silva

    Radio Man Guest

    On Feb 21, 10:45 pm, "Nicole" <Wagner> wrote:
    > Ari Heino wrote:
    >
    > > PS. You've heard right: don't use tables for layout or frames for... anything!

    >
    > 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).
    >
    > Nicole

    You have plenty of alternatives now a days, take a look at an example
    here.
    http://3rar-sa-assoc.org.au
    --
    Regards Chad. http://freewebdesignonline.org
    Radio Man, Feb 22, 2009
    #13
  14. Mike Silva

    Radio Man Guest

    On Feb 21, 4:05 am, Mike Silva <> wrote:
    > Hi,
    >
    > 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,
    > Mike

    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
    Radio Man, Feb 22, 2009
    #14
  15. Mike Silva

    Andy Dingley Guest

    On 22 Feb, 07:21, Radio Man <>
    wrote:

    > Make sure you have a good understanding of the W3C guidelines on web
    > accessibility,


    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.
    Andy Dingley, Feb 22, 2009
    #15
  16. Mike Silva

    Eric Bednarz Guest

    Andy Dingley <> writes:

    > On 21 Feb, 01:34, Eric Bednarz <> wrote:
    >
    >> 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.

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


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

    > They have their limitations:
    >
    > * You have to read them.


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

    > * They assume you're a raw beginner.


    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.

    > My pitch here is mostly at graduate recruits, or at experienced <foo>
    > coders who are making a hash of trying to write some <bar>


    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).

    > […] the accursed w3schools.


    Yay for the Head First series!
    Eric Bednarz, Feb 25, 2009
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    519
    Kevin Spencer
    Aug 16, 2005
  2. Replies:
    4
    Views:
    364
    Phlip
    Jul 31, 2003
  3. Alan Silver
    Replies:
    13
    Views:
    556
    Alan Silver
    Jun 29, 2006
  4. Harald Massa
    Replies:
    4
    Views:
    334
    Harald Massa
    Mar 12, 2005
  5. Terry
    Replies:
    14
    Views:
    196
    Thomas 'PointedEars' Lahn
    Oct 5, 2007
Loading...

Share This Page