Best Practices | Monolith Design

Best Practices

Best Practices for Web Developers

Here are some best practices for designing and building Web sites.

  • Validate your code: HTML, CSS, and Javascript.
  • Specify Doctype, Character Sets, and Character Encoding.
  • Design for Cross-Browser Consistency:
    Where Web Developers Spend Their Time

    • Always use strict doctype and standards-compliant HTML/CSS.
    • Always use a reset at the start of your CSS.
    • Use Analytics. Whether you use Google Analytics or something else, instrument your Web site so that you can see where your traffic is coming from, how people are finding your site, and what they are doing when they reach it.
    • Move CSS and Javascript to external files; avoid inline code.
    • Never resize images in the CSS or HTML.
    • Check font rendering in every browser.
    • Choose the overall font sizes; don’t take defaults. Size text as a percentage in the body, and as em’s throughout. Alternative approach: set the base font size in BODY, then use percentages for everything else.
    • All layout DIVs that are floated should include display:inline and overflow:hidden. All floated elements (except images) must have a width specified.
    • Containers should have overflow:auto and trigger hasLayout via a width or height.
    • Don’t use any fancy CSS3 selectors.
    • Don’t use transparent PNGs unless you made adjustments in Internet Explorer.
    • PositionIsEverything.net is the best site for learning about cross-browser bugs. The most comprehensive bug list is here.
  • Test everything! Are the fonts right? Are the colors consistent? Are elements positioned properly? Is the text large enough? Too large? Are you using the right bullets for lists? Do your links work? Do your links stand out from normal text? “Seek and ye shall find” is a terrible design principle!
  • Keep It Simple, Stupid! (the KISS principle): make your page navigation incredibly obvious to your intended audience. Make it easy to see or find out where you are in a site. Ensure that embedded links in text are easily distinguished from the surrounding text—don’t hide your links!
  • Test on multiple browsers.
  • Use graphics properly: the right format, size, optimization, matting, transparency, etc.
  • Name your classes and IDs according to their function, not by their appearance or location. You may change the color or the location from one side to another, but it doesn’t change the function of the element.
  • Put an ID or CLASS on <BODY>. This allows your code to highlight the current page or section, among other things. For example, this is done in the navigation for the CIS86 site.
  • No heights! You should rarely need to specify the height of an HTML element, and you should avoid doing so unless absolutely necessary. One of the typical requirements is with a page header or footer of fixed size. Most other page elements should be allowed to expand vertically to take whatever space they need.
  • Performance: here are some ways to improve page load times.
    • Pack/minify. There are tools for reducing the size of your HTML and CSS by squeezing out all the spaces and non-essential characters.
    • Avoid spurious PHP calls. Dynamically-generated pages often use standard PHP to insert things that do not change for a single site. You can hardcode someof those results to mimimize processing time needed on the Web server.
    • Minimize HTTP calls: each HTTP call for a file costs overhead beyond just the size of the file. Combine Javascript and CSS files where feasible to mimize the connections needed to display a page.
    • CSS Sprites: this is a great technique for minimizing HTTP calls. Instead of having 3 graphics for the states of a menu button (active, inactive, hovering), you can embed all three graphics in a single file, and use CSS positioning to place the background graphic to display the correct version. This only works with background-images.
    • Use Ajax to spread out loads. Instead of loading everything in a big rush at the start, you can postpone the loading of some parts that are optional. When a visitor requests one of those pieces, use an Ajax call to load the file’s contents directly into the page. Optional chunks that are never needed do not get loaded at all. In programming, this is called lazy evaluation.
    • Load libraries from elsewhere. Google Code supplies a bunch of different code libraries, such as jQuery. You can load jQuery from there instead of from your Web server, thereby spreading the load around a bit more.
  • Use Comments in HTML Pages and CSS Stylesheets: You are encouraged to use comments liberally in your HTML and CSS files. This will be a big help as you make changes on your sites, and it is invaluable when you return to it after time has passed. If you ever have to pick up someone else’s code, you will love them if they put in comments, and hate them if they did not. You must use different groups of characters to denote comments, depending on where the comment appears:
    • <!–This is a terminated (single-line only) comment in an HTML file.–>
    • /* This is a terminated comment in a CSS file or a Javascript file. The comment
      can span multiple lines. */
    • // A single-line Javascript comment, and it does not have to be terminated.

      A great use of comments is to embed your color palette information at the top of your CSS file. This is really helpful during development, but especially valuable when you return to something months later and can’t remember anything.

      /* Color Scheme
      Main Bg – #fff7f5
      Box Bg – #ffffff
      Main Text – #333333
      Links/Headers – #6c1d31
      Borders – #ececec
      */


QR Code Business Card