HTML, XHTML, & CSS All-in-One For Dummies®, 2nd Edition
Table of Contents
Introduction
No Experience Necessary
Great for Advanced Folks, Too!
Use Any Computer
Don’t Buy Any Software
How This Book Is Organized
New for the Second Edition
Icons Used in This Book
What’s Next?
Book I: Creating the HTML/XHTML Foundation
Book I: Chapter 1: Sound HTML Foundations
Creating a Basic Page
Understanding the HTML in the Basic Page
Meeting Your New Friends, the Tags
Setting Up Your System
Displaying file extensions
Setting up your software
Book I: Chapter 2: It’s All about Validation
Somebody Stop the HTML Madness!
XHTML to the rescue
There’s XHTML and there’s good XHTML
Building an XHTML Document
Don’t memorize all this!
The DOCTYPE tag
The xmlns attribute
The meta tag
You validate me
Validating Your Page
Aesop visits W3C
Showing off your mad skillz
Using Tidy to repair pages
Book I: Chapter 3: Choosing Your Tools
What’s Wrong with the Big Boys?
Alternative Web Development Tools
The features you need on your computer
Building a basic toolbox
Picking a Text Editor
Tools to avoid unless you have nothing else
A noteworthy editor: Notepad++
The old standards: VI and Emacs
Other text editors
The Web Developer’s Browser
A little ancient history
Overview of the prominent browsers
Other notable browsers
The bottom line in browsers
Tricking Out Firefox
Validating your pages with HTML Validator
Using the Web Developer toolbar
Using Firebug
Using a Full-Blown IDE
Introducing Aptana
Customizing Aptana
Introducing Komodo Edit
Book I: Chapter 4: Managing Information with Lists and Tables
Making a List and Checking It Twice
Creating an unordered list
Creating ordered lists
Making nested lists
Building the definition list
Building Tables
Defining the table
Spanning rows and columns
Avoiding the table-based layout trap
Book I: Chapter 5: Making Connections with Links
Making Your Text Hyper
Introducing the anchor tag
Comparing block-level and inline elements
Analyzing an anchor
Introducing URLs
Making Lists of Links
Working with Absolute and Relative References
Understanding absolute references
Introducing relative references
Book I: Chapter 6: Adding Images
Adding Images to Your Pages
Adding links to images
Adding inline images using the <img> tag
Choosing an Image Manipulation Tool
An image is worth 3.4 million words!
Introducing IrfanView
Choosing an Image Format
BMP
JPG/JPEG
GIF
PNG
Summary of Web image formats
Manipulating Your Images
Changing formats in IrfanView
Resizing your images
Enhancing image colors
Using built-in effects
Other effects you can use
Batch processing
Using Images as Links
Creating thumbnail images
Creating a thumbnail-based image directory
Book I: Chapter 7: Creating Forms
You Have Great Form
Forms must have some form
Organizing a form with fieldsets and labels
Building Text-Style Inputs
Making a standard text field
Building a password field
Making multi-line text input
Creating Multiple Selection Elements
Making selections
Building check boxes
Creating radio buttons
Pressing Your Buttons
Making input-style buttons
Building a Submit button
It’s a do-over: The Reset button
Introducing the <button> tag
Book I: Chapter 8: The Future of HTML: HTML 5
Can’t We Just Stick with XHTML?
Using the HTML 5 doctype
Browser support for HTML 5
Validating HTML 5
Semantic Elements
Using New Form Elements
Using Embedded Fonts
Audio and Video Tags
The Canvas Tag
Other Promising Features
Limitations of HTML 5
Book II: Styling with CSS
Book II: Chapter 1: Coloring Your World
Now You Have an Element of Style
Setting up a style sheet
Changing the colors
Specifying Colors in CSS
Using color names
Putting a hex on your colors
Coloring by number
Hex education
Using the Web-safe color palette
Choosing Your Colors
Starting with Web-safe colors
Modifying your colors
Doing it on your own pages
Changing CSS on the fly
Creating Your Own Color Scheme
Understanding hue, saturation, and value
Using the Color Scheme Designer
Selecting a base hue
Picking a color scheme
Book II: Chapter 2: Styling Text
Setting the Font Family
Applying the font-family style attribute
Using generic fonts
Making a list of fonts
The Curse of Web-Based Fonts
Understanding the problem
Examining possible solutions
Using images for headlines
Specifying the Font Size
Size is only a suggestion!
Using the font-size style attribute
Absolute measurement units
Relative measurement units
Determining Other Font Characteristics
Using font-style for italics
Using font-weight for bold
Using text-decoration
Using text-align for basic alignment
Other text attributes
Using the font shortcut
Working with subscripts and superscripts
Book II: Chapter 3: Selectors, Class, and Style
Selecting Particular Segments
Defining more than one kind of paragraph
Styling identified paragraphs
Using Emphasis and Strong Emphasis
Adding emphasis to the page
Modifying the display of em and strong
Defining Classes
Adding classes to the page
Combining classes
Introducing div and span
Organizing the page by meaning
Why not make a table?
Using Pseudo-Classes to Style Links
Styling a standard link
Styling the link states
Best link practices
Selecting in Context
Defining Multiple Styles at Once
Book II: Chapter 4: Borders and Backgrounds
Joining the Border Patrol
Using the border attributes
Defining border styles
Using the border shortcut
Creating partial borders
Introducing the Box Model
Borders, margin, and padding
Positioning elements with margins and padding
Changing the Background Image
Getting a background check
Solutions to the background conundrum
Manipulating Background Images
Turning off the repeat
Making effective gradients with repeat-x and repeat-y
Using Images in Lists
Book II: Chapter 5: Levels of CSS
Managing Levels of Style
Using local styles
Using an external style sheet
Understanding the Cascading Part of Cascading Style Sheets
Inheriting styles
Hierarchy of styles
Overriding styles
Precedence of style definitions
Using Conditional Comments
Coping with incompatibility
Making Internet Explorer–specific code
Using a conditional comment with CSS
Checking the Internet Explorer version
Book III: Using Positional CSS
Book III: Chapter 1: Fun with the Fabulous Float
Avoiding Old-School Layout Pitfalls
Problems with frames
Problems with tables
Problems with huge images
Problems with Flash
Introducing the Floating Layout Mechanism
Using float with images
Adding the float property
Using Float with Block-Level Elements
Floating a paragraph
Adjusting the width
Setting the next margin
Using Float to Style Forms
Using float to beautify the form
Adjusting the fieldset width
Using the clear attribute to control page layout
Book III: Chapter 2: Building Floating Page Layouts
Creating a Basic Two-Column Design
Designing the page
Building the XHTML
Adding preliminary CSS
Using temporary borders
Setting up the floating columns
Tuning up the borders
Advantages of a fluid layout
Building a Three-Column Design
Styling the three-column page
Problems with the floating layout
Specifying a min-height
Building a Fixed-Width Layout
Setting up the XHTML
Using an image to simulate true columns
Building a Centered Fixed-Width Layout
Making a surrogate body with an all div
How the jello layout works
Limitations of the jello layout
Book III: Chapter 3: Styling Lists and Menus
Revisiting List Styles
Defining navigation as a list of links
Turning links into buttons
Building horizontal lists
Creating Dynamic Lists
Building a nested list
Hiding the inner lists
Getting the inner lists to appear on cue
Building a Basic Menu System
Building a vertical menu with CSS
Building a horizontal menu
Book III: Chapter 4: Using Alternative Positioning
Working with Absolute Positioning
Setting up the HTML
Adding position guidelines
Making absolute positioning work
Managing z-index
Handling depth
Working with z-index
Building a Page Layout with Absolute Positioning
Overview of absolute layout
Writing the XHTML
Adding the CSS
Creating a More Flexible Layout
Designing with percentages
Building the layout
Exploring Other Types of Positioning
Creating a fixed menu system
Setting up the XHTML
Setting the CSS values
Determining Your Layout Scheme
Book IV: Client-Side Programming with JavaScript
Book IV: Chapter 1: Getting Started with JavaScript
Working in JavaScript
Choosing a JavaScript editor
Picking your test browser
Writing Your First JavaScript Program
Embedding your JavaScript code
Creating comments
Using the alert() method for output
Adding the semicolon
Introducing Variables
Creating a variable for data storage
Asking the user for information
Responding to the user
Using Concatenation to Build Better Greetings
Comparing literals and variables
Including spaces in your concatenated phrases
Understanding the String Object
Introducing object-based programming (and cows)
Investigating the length of a string
Using string methods to manipulate text
Understanding Variable Types
Adding numbers
Adding the user’s numbers
The trouble with dynamic data
The pesky plus sign
Changing Variables to the Desired Type
Using variable conversion tools
Fixing the addInput code
Book IV: Chapter 2: Making Decisions with Conditions
Working with Random Numbers
Creating an integer within a range
Building a program that rolls dice
Using if to Control Flow
The basic if statement
All about conditions
Comparison operators
Using the else Clause
Using if-else for more complex interaction
Solving the mystery of the unnecessary else
Using switch for More Complex Branches
Creating an expression
Switching with style
Nesting if Statements
Building the nested conditions
Making sense of nested ifs
Book IV: Chapter 3: Loops and Debugging
Building Counting Loops with for
Building a standard for loop
Counting backward
Counting by 5
Looping for a while
Creating a basic while loop
Avoiding loop mistakes
Introducing Bad Loops
Managing the reluctant loop
Managing the obsessive loop
Debugging Your Code
Letting Aptana help
Debugging JavaScript on Internet Explorer
Finding errors in Firefox
Finding errors with Firebug
Catching Logic Errors
Logging to the console with Firebug
Looking at console output
Using the Interactive Debug Mode
Setting up the Firebug debugger
Setting a breakpoint
Adding a debugger directive
Examining debug mode
Debugging your code
Book IV: Chapter 4: Functions, Arrays, and Objects
Breaking Code into Functions
Thinking about structure
Building the antsFunction.html program
Passing Data to and from Functions
Examining the main code
Looking at the chorus
Handling the verses
Managing Scope
Introducing local and global variables
Examining variable scope
Building a Basic Array
Accessing array data
Using arrays with for loops
Revisiting the ants song
Working with Two-Dimension Arrays
Setting up the arrays
Getting a city
Creating a main() function
Creating Your Own Objects
Building a basic object
Adding methods to an object
Building a reusable object
Using your shiny new objects
Introducing JSON
Storing data in JSON format
Building a more complex JSON structure
Book IV: Chapter 5: Talking to the Page
Understanding the Document Object Model
Navigating the DOM
Changing DOM properties with Firebug
Examining the document object
Harnessing the DOM through JavaScript
Getting the blues, JavaScript-style
Writing JavaScript code to change colors
Managing Button Events
Embedding quotes within quotes
Writing the changeColor function
Managing Text Input and Output
Introducing event-driven programming
Creating the XHTML form
Using GetElementById to get access to the page
Manipulating the text fields
Writing to the Document
Preparing the HTML framework
Writing the JavaScript
Finding your innerHTML
Working with Other Text Elements
Building the form
Writing the function
Understanding generated source
Book IV: Chapter 6: Getting Valid Input
Getting Input from a Drop-Down List
Building the form
Reading the list box
Managing Multiple Selections
Coding a multiple selection select object
Writing the JavaScript code
Check, Please: Reading Check Boxes
Building the check box page
Responding to the check boxes
Working with Radio Buttons
Interpreting radio buttons
Working with Regular Expressions
Introducing regular expressions
Using characters in regular expressions
Marking the beginning and end of the line
Working with special characters
Conducting repetition operations
Working with pattern memory
Book IV: Chapter 7: Animating Your Pages
Making Things Move
Looking over the HTML
Getting an overview of the JavaScript
Creating global variables
Initializing
Moving the sprite
Checking the boundaries
Reading Input from the Keyboard
Building the keyboard page
Overwriting the init() function
Setting up an event handler
Responding to keystrokes
Deciphering the mystery of key codes
Following the Mouse
Looking over the HTML
Initializing the code
Building the mouse listener
Creating Automatic Motion
Creating a setInterval() call
Building Image-Swapping Animation
Preparing the images
Building the page
Building the global variables
Setting up the interval
Animating the sprite
Preloading Your Images
Movement and swapping
Building the code
Defining global variables
Initializing your data
Preloading the images
Animating and updating the image
Moving the sprite
Book V: Server-Side Programming with PHP
Book V: Chapter 1: Getting Started on the Server
Introducing Server-Side Programming
Programming on the server
Serving your programs
Picking a language
Installing Your Web Server
Inspecting phpinfo()
Building XHTML with PHP
Coding with Quotation Marks
Working with Variables PHP-Style
Concatenation
Interpolating variables into text
Building XHTML Output
Using double quote interpolation
Generating output with heredocs
Switching from PHP to XHTML
Book V: Chapter 2: PHP and XHTML Forms
Exploring the Relationship between PHP and XHTML
Embedding PHP inside XHTML
Viewing the results
Sending Data to a PHP Program
Creating a form for PHP processing
Receiving data in PHP
Choosing the Method of Your Madness
Using get to send data
Using the post method to transmit form data
Getting data from the form
Retrieving Data from Other Form Elements
Building a form with complex elements
Responding to a complex form
Book V: Chapter 3: Control Structures
Introducing Conditions (Again)
Building the Classic if Statement
Rolling dice the PHP way
Checking your six
Understanding comparison operators
Taking the middle road
Building a program that makes its own form
Making a switch
Looping with for
Looping with while
Book V: Chapter 4: Working with Arrays
Using One-Dimensional Arrays
Creating an array
Filling an array
Viewing the elements of an array
Preloading an array
Using Loops with Arrays
Simplifying loops with foreach
Arrays and HTML
Introducing Associative Arrays
Using foreach with associative arrays
Introducing Multidimensional Arrays
We’re going on a trip
Looking up the distance
Breaking a String into an Array
Creating arrays with explode
Creating arrays with preg_split
Book V: Chapter 5: Using Functions and Session Variables
Creating Your Own Functions
Rolling dice the old-fashioned way
Improving code with functions
Managing variable scope
Returning data from functions
Managing Persistence with Session Variables
Understanding session variables
Adding session variables to your code
Book V: Chapter 6: Working with Files and Directories
Text File Manipulation
Writing text to files
Writing a basic text file
Reading from the file
Using Delimited Data
Storing data in a CSV file
Viewing CSV data directly
Reading the CSV data in PHP
Working with File and Directory Functions
opendir()
readdir()
chdir()
Generating the list of file links
Book V: Chapter 7: Connecting to a MySQL Database
Retrieving Data from a Database
Understanding data connections
Building a connection
Passing a query to the database
Processing the results
Extracting the rows
Extracting fields from a row
Printing the data
Improving the Output Format
Building definition lists
Using XHTML tables for output
Allowing User Interaction
Building an XHTML search form
Responding to the search request
Breaking the code into functions
Processing the input
Generating the output
Book VI: Managing Data with MySQL
Book VI: Chapter 1: Getting Started with Data
Examining the Basic Structure of Data
Determining the fields in a record
Introducing SQL data types
Specifying the length of a record
Defining a primary key
Defining the table structure
Introducing MySQL
Why use MySQL?
Understanding the three-tier architecture
Practicing with MySQL
Setting Up phpMyAdmin
Changing the root password
Adding a user
Using phpMyAdmin on a remote server
Making a Database with phpMyAdmin
Book VI: Chapter 2: Managing Data with SQL
Writing SQL Code by Hand
Understanding SQL syntax rules
Examining the buildContact.sql script
Dropping a table
Creating a table
Adding records to the table
Viewing the sample data
Running a Script with phpMyAdmin
Using AUTO_INCREMENT for Primary Keys
Selecting Data from Your Tables
Selecting only a few fields
Selecting a subset of records
Searching with partial information
Searching for the ending value of a field
Searching for any text in a field
Searching with regular expressions
Sorting your responses
Editing Records
Updating a record
Deleting a record
Exporting Your Data and Structure
Exporting SQL code
Creating XML data
Book VI: Chapter 3: Normalizing Your Data
Recognizing Problems with Single-Table Data
The identity crisis
The listed powers
Repetition and reliability
Fields that change
Deletion problems
Introducing Entity-Relationship Diagrams
Using MySQL Workbench to draw ER diagrams
Creating a table definition in Workbench
Introducing Normalization
First normal form
Second normal form
Third normal form
Identifying Relationships in Your Data
Book VI: Chapter 4: Putting Data Together with Joins
Calculating Virtual Fields
Introducing SQL Functions
Knowing when to calculate virtual fields
Calculating Date Values
Using DATEDIFF to determine age
Adding a calculation to get years
Converting the days integer into a date
Using YEAR() and MONTH() to get readable values
Concatenating to make one field
Creating a View
Using an Inner Join to Combine Tables
Building a Cartesian join and an inner join
Enforcing one-to-many relationships
Counting the advantages of inner joins
Building a view to encapsulate the join
Managing Many-to-Many Joins
Understanding link tables
Using link tables to make many-to-many joins
Book VII: Into the Future with AJAX
Book VII: Chapter 1: AJAX Essentials
AJAX Spelled Out
A is for asynchronous
J is for JavaScript
A is for . . . and?
And X is for . . . data
Making a Basic AJAX Connection
Building the HTML form
Creating an XMLHttpRequest object
Opening a connection to the server
Sending the request and parameters
Checking the status
All Together Now — Making the Connection Asynchronous
Setting up the program
Building the getAJAX() function
Reading the response
Book VII: Chapter 2: Improving JavaScript and AJAX with jQuery
Introducing jQuery
Installing jQuery
Importing jQuery from Google
Your First jQuery App
Setting up the page
Meet the jQuery node object
Creating an Initialization Function
Using $(document).ready()
Alternatives to document.ready
Investigating the jQuery Object
Changing the style of an element
Selecting jQuery objects
Modifying the style
Adding Events to Objects
Adding a hover event
Changing classes on the fly
Making an AJAX Request with jQuery
Including a text file with AJAX
Building a poor man’s CMS with AJAX
Book VII: Chapter 3: Animating jQuery
Playing Hide and Seek
Getting transition support
Writing the HTML and CSS foundation
Initializing the page
Hiding and showing the content
Toggling visibility
Sliding an element
Fading an element in and out
Changing Position with jQuery
Creating the framework
Setting up the events
Don’t go chaining . . . okay, do it all you want
Building the move() function with chaining
Building time-based animation with animate()
Move a little bit: Relative motion
Modifying Elements on the Fly
Building the basic page
Initializing the code
Adding text
Attack of the clones
It’s a wrap
Alternating styles
Resetting the page
More fun with selectors and filters
Book VII: Chapter 4: Using the jQuery User Interface Toolkit
What the jQuery User Interface Brings to the Table
It’s a theme park
Using the themeRoller to get an overview of jQuery
Wanna drag? Making components draggable
Downloading the library
Writing the program
Resizing on a Theme
Examining the HTML and standard CSS
Importing the files
Making a resizable element
Adding themes to your elements
Adding an icon
Dragging, Dropping, and Calling Back
Building the basic page
Initializing the page
Handling the drop
Beauty school dropout events
Cloning the elements
Book VII: Chapter 5: Improving Usability with jQuery
Multi-element Designs
Playing the accordion widget
Building a tabbed interface
Using tabs with AJAX
Improving Usability
Playing the dating game
Picking numbers with the slider
Selectable elements
Building a sortable list
Creating a custom dialog box
Book VII: Chapter 6: Working with AJAX Data
Sending Requests AJAX Style
Sending the data
Simplifying PHP for AJAX
Building a Multipass Application
Setting up the HTML framework
Loading the select element
Writing the loadList.php program
Responding to selections
Writing the showHero.php script
Working with XML Data
Review of XML
Manipulating XML with jQuery
Creating the HTML
Retrieving the data
Processing the results
Printing the pet name
Working with JSON Data
Knowing JSON’s pros
Reading JSON data with jQuery
Managing the framework
Retrieving the JSON data
Processing the results
Book VIII: Moving from Pages to Sites
Book VIII: Chapter 1: Managing Your Servers
Understanding Clients and Servers
Parts of a client-side development system
Parts of a server-side system
Creating Your Own Server with XAMPP
Running XAMPP
Testing your XAMPP configuration
Adding your own files
Setting the security level
Compromising between functionality and security
Choosing a Web Host
Finding a hosting service
Connecting to a hosting service
Managing a Remote Site
Using Web-based file tools
Understanding file permissions
Using FTP to manage your site
Naming Your Site
Understanding domain names
Registering a domain name
Managing Data Remotely
Creating your database
Finding the MySQL server name
Book VIII: Chapter 2: Planning Your Sites
Creating a Multipage Web Site
Planning a Larger Site
Understanding the Client
Ensuring that the client’s expectations are clear
Delineating the tasks
Understanding the Audience
Determining whom you want to reach
Finding out the user’s technical expertise
Building a Site Plan
Creating a site overview
Building the site diagram
Creating Page Templates
Sketching the page design
Building the XHTML template framework
Creating page styles
Building a data framework
Fleshing Out the Project
Making the site live
Contemplating efficiency
Book VIII: Chapter 3: Introducing Content Management Systems
Overview of Content Management Systems
Previewing Common CMSs
Moodle
WordPress
Drupal
Building a CMS site with Website Baker
Installing your CMS
Getting an overview of Website Baker
Adding your content
Using the WYSIWYG editor
Changing the template
Adding additional templates
Adding new functionality
Building Custom Themes
Starting with a prebuilt template
Changing the info.php file
Modifying index.php
Modifying the CSS files
Packaging your template
Book VIII: Chapter 4: Editing Graphics
Using a Graphic Editor
Choosing an editor
Introducing Gimp
Creating an image
Painting tools
Selection tools
Modification tools
Managing tool options
Utilities
Understanding Layers
Introducing Filters
Solving Common Web Graphics Problems
Changing a color
Building a banner graphic
Building a tiled background
Book VIII: Chapter 5: Taking Control of Content
Building a “Poor Man’s CMS” with Your Own Code
Using Server-Side Includes (SSIs)
Using AJAX and jQuery for client-side inclusion
Building a page with PHP includes
Creating Your Own Data-Based CMS
Using a database to manage content
Writing a PHP page to read from the table
Allowing user-generated content
Adding a new block
Improving the dbCMS design
Appendix A: What’s on the CD
Author-created material
Aptana Studio 2.0
Dia 0.97.1
FileZilla 3.3.1
Firefox 3.6 and Extensions
GIMP 2.6
HTML Tidy
IrfanView 4.25
IZArc 4.1
jEdit
jQuery 1.4
Komodo Edit
KompoZer 0.7.10
Notepad++
SQLite 3.6.22
WebsiteBaker 2.8.1
XAMPP 1.7.3
XnView 1.97
Customer Care
HTML, XHTML, & CSS All-in-One For Dummies®, 2nd Edition
by Andy Harris
HTML, XHTML, & CSS All-in-One For Dummies®, 2nd Edition
Published by
Wiley Publishing, Inc.
111 River Street
Hoboken, NJ 07030-5774
www.wiley.com
Copyright © 2011 by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002.
For technical support, please visit www.wiley.com/techsupport.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.
Library of Congress Control Number: 2010937814
ISBN: 978-0-470-53755-8
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
About the Author
Andy Harris began his teaching life as a special education teacher. As he was teaching young adults with severe disabilities, he taught himself enough computer programming to support his teaching habit with freelance programming. Those were the exciting days when computers started to have hard drives, and some computers began communicating with each other over an arcane mechanism some were calling the Internet.
All this time Andy was teaching computer science part time. He joined the faculty of the Indiana University-Purdue University Indianapolis Computer Science department in 1995. He serves as a Senior Lecturer, teaching the introductory courses to freshmen as well as numerous courses on Web development, general programming, and game programming. As manager of the Streaming Media Laboratory, he developed a number of online video-based courses, and worked on a number of international distance education projects including helping to start a computer science program in Tetevo, Macedonia FYR.
Andy is the author of several other computing books including JavaScript For Dummies, Flash Game Programming For Dummies, and Game Programming: the L Line. He invites your comments and questions at [email protected]. You can visit his main site and find a blog, forum, and links to other books at http://www.aharrisbooks.net.
Dedication
I dedicate this book to Jesus Christ, my personal savior, and to Heather, the joy in my life. I also dedicate this project to Elizabeth, Matthew, Jacob, and Benjamin. I love each of you.
Author’s Acknowledgments
Thank you first to Heather. Even though I type all the words, this book is a real partnership, like the rest of our life. Thanks for being my best friend and companion. Thanks also for doing all the work it takes for us to sustain a family when I’m in writing mode.
Thank you to Mark Enochs. It’s great to have an editor who gets me, and who’s willing to get excited about a project. I really enjoy working with you.
Thanks very much to Katie Feltman. It’s fun to see how far a few wacky ideas have gone. Thanks for continuing to believe in me, and for helping me to always find an interesting new project.
Thank you to the copy editors: first and foremost, I thank Brian Walls for his all his hard work in making this edition presentable. Thanks also go to Teresa Artman, John Edwards, and Melba Hopper for their help. I appreciate your efforts to make my geeky mush turn into something readable. Thanks for improving my writing.
A special thanks to Jeff Noble for his technical editing. I appreciate your vigilance. You have helped to make this book as technically accurate as possible.
Thank you to the many people at Wiley who contribute to a project like this. The author only gets to meet a few people, but so many more are involved in the process. Thank you very much for all you’ve done to help make this project a reality.
Thanks to Chris McCulloh for all you did on the first edition, and I thank you for your continued friendship.
A big thank you to the open source community which has created so many incredible tools and made them available to all. I’d especially like to thank the creators of Firefox, Firebug, Aptana, HTML Validator, the Web Developer toolbar, Ubuntu and the Linux community, Notepad++, PHP, Apache, jQuery, and the various jQuery plugins. This is an amazing and generous community effort.
I’d finally like to thank the IUPUI computer science family for years of support on various projects. Thank you especially to all my students, current and past. I’ve learned far more from you than the small amount I’ve taught. Thank you for letting me be a part of your education.
Publisher’s Acknowledgments
We’re proud of this book; please send us your comments through our online registration form located at www.dummies.com/register/.
Some of the people who helped bring this book to market include the following:
Acquisitions, Editorial, and Media Development
Senior Project Editor: Mark Enochs
Senior Acquisitions Editor: Katie Feltman
Copy Editors: Brian Walls, Teresa Artman, John Edwards, Melba Hopper
Technical Editor: Jeff Noble
Editorial Manager: Leah Cameron
Media Development Project Manager: Laura Moss-Hollister
Media Development Assistant Project Manager: Jenny Swisher
Media Development Assistant Producer: Shawn Patrick
Editorial Assistant: Amanda Graham
Sr. Editorial Assistant: Cherie Case
Cartoons: Rich Tennant (www.the5thwave.com)
Composition Services
Project Coordinators: Katherine Crocker, Lynsey Stanford
Layout and Graphics: Carl Byers, Timothy C. Detrick
Proofreaders: Lauren Mandelbaum, Christine Sabooni
Indexer: BIM Indexing & Proofreading Services
Special Help
Tonya Cupp, Colleen Totz Diamond
Publishing and Editorial for Technology Dummies
Richard Swadley, Vice President and Executive Group Publisher
Andy Cummings, Vice President and Publisher
Mary Bednarek, Executive Acquisitions Director
Mary C. Corder, Editorial Director
Publishing for Consumer Dummies
Diane Graves Steele, Vice President and Publisher
Joyce Pepple, Acquisitions Director
Composition Services
Debbie Stailey, Director of Composition Services
Introduction
I love the Internet, and if you picked up this book, you probably do, too. The Internet is dynamic, chaotic, exciting, interesting, and useful, all at the same time. The Web is pretty fun from a user’s point of view, but that’s only part of the story. Perhaps the best part of the Internet is how participatory it is. You can build your own content — free! It’s really amazing. There’s never been a form of communication like this before. Anyone with access to a minimal PC and a little bit of knowledge can create his or her own homestead in one of the most exciting platforms in the history of communication.
The real question is how to get there. A lot of Web development books are really about how to use some sort of software you have to buy. That’s okay, but it isn’t necessary. Many software packages have evolved that purport to make Web development easier — and some work pretty well — but regardless what software package you use, there’s still a need to know what’s really going on under the surface. That’s where this book comes in.
You’ll find out exactly how the Web works in this book. You’ll figure out how to use various tools, but, more importantly, you’ll create your piece of the Web. You’ll discover:
♦ How Web pages are created: You’ll figure out the basic structure of Web pages. You’ll understand the structure well because you build pages yourself. No mysteries here.
♦ How to separate content and style: You’ll understand the foundation of modern thinking about the Internet — that style should be separate from content.
♦ How to use Web standards: The Web is pretty messy, but, finally, some standards have arisen from the confusion. You’ll discover how these standards work and how you can use them.
♦ How to create great-looking Web pages: Of course, you want a terrific-looking Web site. With this book, you’ll find out how to use layout, style, color, and images.
♦ How to build modern layouts: Many Web pages feature columns, menus, and other fancy features. You’ll figure out how to build all these things.
♦ How to add interactivity: Adding forms to your pages, validating form data, and creating animations are all possible with the JavaScript language.
♦ How to write programs on the server: Today’s Web is powered by programs on Web servers. You’ll discover the powerful PHP language and figure out how to use it to create powerful and effective sites.
♦ How to harness the power of data: Every Web developer eventually needs to interact with data. You’ll read about how to create databases that work. You’ll also discover how to connect databases to your Web pages and how to create effective and useful interfaces.
♦ How AJAX is changing everything: The hottest Web technology on the horizon is AJAX (Asynchronous JavaScript and XML). You’ll figure out how to harness this way of working and use it to create even more powerful and interesting applications.
No Experience Necessary
I’m not assuming anything in this book. If you’ve never built a Web page before, you’re in the right hands. You don’t need any experience, and you don’t have to know anything about HTML, programming, or databases. I discuss everything you need.
If you’re reasonably comfortable with a computer (you can navigate the Web and use a word processor), you have all the skills you need.
Great for Advanced Folks, Too!
If you’ve been around Web development for a while, you’ll still find this book handy.
If you’ve used HTML but not XHTML, see how things have changed and discover the powerful combination of XHTML and CSS.
If you’re still using table-based layouts, you’ll definitely want to read about newer ways of thinking. After you get over the difference, you’ll be amazed at the power, the flexibility, and the simplicity of CSS-based layout and design.
If you’re already comfortable with XHTML and CSS, you’re ready to add JavaScript functionality for form validation and animation. If you’ve never used a programming language before, JavaScript is a really great place to start.
If you’re starting to get serious about Web development, you’ve probably already realized that you’ll need to work with a server at some point. PHP is a really powerful, free, and easy language that’s extremely prominent on the Web landscape. You’ll use this to have programs send e-mails, store and load information from files, and work with databases.
If you’re messing with commercial development, you’ll definitely need to know more about databases. I get e-mails every week from companies looking for people who can create a solid relational database and connect it to a Web site with PHP.
If you’re curious about AJAX, you can read about what it is, how it works, and how to use it to add functionality to your site. You’ll also read about a very powerful and easy AJAX library that can add tremendous functionality to your bag of tricks.
I wrote this book as the reference I wish I had. If you have only one Web development book on your shelf, this should be the one. Wherever you are in your Web development journey, you can find something interesting and new in this book.
Use Any Computer
One of the great things about Web development is how accessible it can be. You don’t need a high-end machine to build Web sites. Whatever you’re using now will probably do fine. I built most of the examples in this book with Windows XP and Ubuntu Linux, but a Mac is perfectly fine, too. Most of the software I use in the book is available free for all major platforms. Similar alternatives for all platforms are available in the few cases when this isn’t true.
Don’t Buy Any Software
Everything you need for Web development is on the CD-ROM. I’ve used only open-source software for this book. The CD contains a ton of tools and helpful programs. See Appendix A in the back of this book for a complete listing. Following are the highlights:
♦ Aptana: A full-featured programmer’s editor that greatly simplifies creating Web pages, CSS documents, and code in multiple languages.
♦ Firefox extensions: I’ve included several extensions to the Firefox Web browser that turn it into a thoroughbred Web development platform. The Web Developer toolbar adds all kinds of features for creating and testing pages; the HTML Validator checks your pages for standards compliance; and the Firebug extension adds incredible features for JavaScript and AJAX debugging.
♦ XAMPP: When you’re ready to move to the server, XAMPP is a complete server package that’s easy to install and incredibly powerful. This includes the incredible Apache Web server, the PHP programming language, the MySQL database manager, and tons of useful utilities.
♦ Useful tools: Every time I use a tool (such as a data mapper, a diagram tool, or an image editor) in this book, I make it available on the CD-ROM.
There’s no need to buy any expensive Web development tools. Everything you need is here and no harder than the more expensive Web editors.
How This Book Is Organized
Web development is about solving a series of connected but different problems. This book is organized into eight minibooks based on specific technologies. You can read them in any order you wish, but you’ll find that the later books tend to rely on topics described in the earlier books. (For example, JavaScript doesn’t make much sense without XHTML because it’s usually embedded in a Web page.) The following describes these eight minibooks:
♦ Book I: Creating the HTML/XHTML Foundation — Web development incorporates a lot of languages and technologies, but HTML is the foundation. Here I show you XHTML, the latest incarnation of HTML, and describe how it’s used to form the basic skeleton of your pages. I also preview the upcoming HTML 5 standard.
♦ Book II: Styling with CSS — In the old days, HTML had a few tags to spruce up your pages, but they weren’t nearly powerful enough. Today, developers use Cascading Style Sheets (CSS) to add color and formatting to your pages.
♦ Book III: Using Positional CSS — Discover the best ways to set up layouts with floating elements, fixed positioning, and absolute positioning. Figure out how to build various multicolumn page layouts and how to create dynamic buttons and menus.
♦ Book IV: Client-Side Programming with JavaScript — Figure out essential programming skills with the easy and powerful JavaScript language — even if you’ve never programmed before. Manipulate data in Web forms and use powerful regular expression technology to validate form entries. Also discover how to create animations with JavaScript.
♦ Book V: Server-Side Programming with PHP — Move your code to the server and take advantage of this powerful language. Figure out how to respond to Web requests; work with conditions, functions, objects, and text files; and connect to databases.
♦ Book VI: Managing Data with MySQL — Most serious Web projects are eventually about data. Figure out how databases are created, how to set up a secure data server, the basics of data normalization, and how to create a reliable and trustworthy data back end for your site.
♦ Book VII: Into the Future with AJAX — Look forward to the technology that has the Web abuzz. AJAX isn’t really a language but rather a new way of thinking about Web development. Get the skinny on what’s going on here, build an AJAX connection or two by hand, and use the really cool jQuery library for adding advanced features and functionality to your pages.
♦ Book VIII: Moving from Pages to Sites — This minibook ties together many of the threads throughout the rest of the book. Discover how to create your own complete Web server solution or pick a Web host. Walk through the process of designing a complex multipage Web site. Build graphics for your Web site. Discover how to use content management systems to simplify complex Web sites and, finally, to build your own content management system with skills taught throughout the book.
New for the Second Edition
This second edition keeps the organization and content of the first edition. I have made a few changes to keep up with advances in technology:
♦ Preview of HTML 5: HTML 5 and CSS 3 offer promising new features. While it may be too early to incorporate these features into every page, it’s time to learn what’s coming. Book I, Chapter 8 highlights these welcome new advances.
♦ Improved PHP coverage: I greatly enhanced and streamlined the PHP content, making it easier to follow. You’ll see these improvements throughout Book V.
♦ Enhanced jQuery coverage: The jQuery AJAX library has improved dramatically since the first edition. I provide much more detailed coverage including full support for jQuery UI and numerous cool widgets and tools. Book VII is much longer and more detailed than it was in the first edition.
♦ A new graphics chapter: A number of readers asked for more coverage of graphics tools, especially Gimp. I added a new chapter to Book VIII describing how to use Gimp to enhance your Web pages.
♦ Support for the Website Baker CMS: I use this CMS quite a bit in my Web business, and I find it especially easy to modify. I changed Book VIII, Chapter 3 to explain how to use and modify this excellent CMS.
♦ Various tweaks and improvements: No book is perfect (though I really try). There were a few passages in the previous edition that readers found difficult. I tried hard to clean up each of these areas. Many thanks to those who provided feedback!
Icons Used in This Book
This is a For Dummies book, so you have to expect some snazzy icons, right? I don’t disappoint. Here’s what you’ll see:
This is where I pass along any small insights I may have gleaned in my travels.
I can’t really help being geeky once in a while. Every so often, I want to explain something a little deeper. Read this to impress people at your next computer science cocktail party or skip it if you really don’t need the details.
A lot of details are here. I point out something important that’s easy to forget with this icon.
Watch out! Anything I mark with this icon is a place where things have blown up for me or my students. I point out any potential problems with this icon.
What’s Next?
Well, that’s really up to you. I sincerely believe you can use this book to turn into a top-notch Web developer. That’s my goal for you.
Although this is a massive book, there’s still more to figure out. If you have questions or just want to chat, feel free to e-mail me at [email protected]. You can also visit my Web site at www.aharrisbooks.net for code examples, updates, and other good stuff. (You can also visit www.dummies.com/go/htmlxhtmlandcssaiofd2e for code examples from the book.)
I try hard to answer all reader e-mails but sometimes I get behind. Please be patient with me, and I’ll do my best to help.
I can’t wait to hear from you and see the incredible Web sites you develop. Have a great time, discover a lot, and stay in touch!
Please note that some special symbols used in this eBook may not display properly on all eReader devices. If you have trouble determining any symbol, please call Wiley Product Technical Support at 800-762-2974. Outside of the United States, please call 317-572-3993. You can also contact Wiley Product Technical Support at www.wiley.com/techsupport.
Book I
Creating the HTML/XHTML Foundation
Chapter 1: Sound HTML Foundations
In This Chapter
Creating a basic Web page
Understanding the most critical HTML tags
Setting up your system to work with HTML
Viewing your pages
This chapter is your introduction to building Web pages. Before this slim chapter is finished, you’ll have your first page up and running. Creating a basic page isn’t difficult, but building pages that can grow and expand while you discover more sophisticated techniques takes a little foresight. Most of this book uses the XHTML standard. In this first chapter, I show part of an older standard called HTML. HTML is a little bit easier to start with, and everything I show in this chapter translates perfectly to the XHTML you use throughout the book.
In this minibook, you discover the modern form of Web design using XHTML. Your Web pages will be designed from the ground up, which makes them easy to modify and customize. While you figure out more advanced techniques throughout this book, you’ll take the humble pages you discover in this chapter and make them do all kinds of exciting things.
Creating a Basic Page
Here’s the great news: The most important Web technology you need is also the easiest. You don’t need any expensive or complicated software, and you don’t need a powerful computer. You probably have everything you need to get started already.
No more talking! Fire up a computer and let’s build a Web page!
1. Open a text editor.
You can use any text editor you want, as long as it lets you save files as plain text. If you’re using Windows, Notepad is fine for now. (Later, I show you some other free alternatives, but start with something you already know.)
2. Type the following code.
Really. Type it in your text editor so you get some experience writing the actual code. I explain very soon what all this means, but type it now to get a feel for it:
<html>
<head>
<!-- myFirst.html -->
<title>My very first web page!</title>
</head>
<body>
<h1>This is my first web page!</h1>
<p>
This is the first web page I’ve ever made,
and I’m extremely proud of it.
It is so cool!
</p>
</body>
</html>
3. Save the file as myFirst.html.
It’s important that your filename has no spaces and ends with the .html extension. Spaces cause problems on the Internet (which is, of course, where all good pages go to live), and the .html extension is how most computers know that this file is an HTML file (which is another name for a Web page). It doesn’t matter where you save the file, as long as you can find it in the next step.
4. Open your Web browser.
The Web browser is the program used to look at pages. After you post your page on a Web server somewhere, your Great Aunt Gertrude can use her Web browser to view your page. You also need one (a browser, not a Great Aunt Gertrude) to test your page. For now, use whatever browser you ordinarily use. Most Windows users already have Internet Explorer installed. If you’re a Mac user, you probably have Safari. Linux folks generally have Firefox. Any of these are fine. In Chapter 3 of this minibook, I explain why you probably need more than one browser and how to configure them for maximum usefulness.
5. Load your page into the browser.
You can do this a number of ways. You can use the browser’s File menu to open a local file, or you can simply drag the file from your Desktop (or wherever) to the open browser window.
6. Bask in your newfound genius.
Your simple text file is transformed! If all went well, it looks like Figure 1-1.
Figure 1-1: Congratula-tions! You’re now a Web developer!
Understanding the HTML in the Basic Page
The page you create in the previous section uses an extremely simple notation — HTML (HyperText Markup Language), which has been around since the beginning of the Web. HTML is a terrific technology for several reasons:
♦ It uses plain text. Most document systems (like word processors) use special binary encoding schemes that incorporate formatting directly into the computer’s internal language, which locks a document into a particular computer or software. That is, a document stored in Word format can’t be read without a program that understands Word formatting. HTML gets past this problem by storing everything in plain text.
♦ It works on all computers. The main point of HTML is to have a universal format. Any computer should be able to read and write it. The plain-text formatting aids in this.
♦ It describes what documents mean. HTML isn’t really designed to indicate how a page or its elements look. HTML is about describing the meaning of various elements (more on that very soon). This has some distinct advantages when you figure out how to use HTML properly.
♦ It doesn’t describe how documents look. This one seems strange. Of course, when you look at Figure 1-1, you can see that the appearance of the text on the Web page has changed from the way the text looked in your text editor. Formatting a document in HTML does cause the document’s appearance to change. That’s not the point of HTML, though. You discover in Book II and Book III how to use another powerful technology — CSS — to change the appearance of a page after you define its meaning. This separation of meaning from layout is one of the best features of HTML.
♦ It’s easy to write. Sure, HTML gets a little more complicated than this first example, but you can easily figure out how to write HTML without any specialized editors. You only have to know a handful of elements, and they’re pretty straightforward.
♦ It’s free. HTML doesn’t cost anything to use, primarily because it isn’t owned by anyone. No corporation has control of it (although a couple have tried), and nobody has a patent on it. The fact that this technology is freely available to anyone is a huge advantage.
Meeting Your New Friends, the Tags
The key to writing HTML code is the special text inside angle braces (<>). These special elements are tags. They aren’t meant to be displayed on the Web page but offer instructions to the Web browser about the meaning of the text. The tags are meant to be embedded into each other to indicate the organization of the page. This basic page introduces you to all the major tags you’ll encounter. (There are more, but they can wait for a chapter or two.) Each tag has a beginning and an end tag. The end tag is just like the beginning tag, except the end tag has a slash (/):
♦ <html></html>: The <html> tag is the foundation of the entire Web page. The tag begins the page. Likewise, </html> ends the page. For example, the page begins with <html> and ends with </html>. The <html></html> combination indicates that everything in the page is defined as HTML code.
♦ <head></head>: These tags define a special part of the Web page called the head (or sometimes header). This part of the Web page reminds me of the engine compartment of a car. This is where you put some great stuff later, but it’s not where the main document lives. For now, the only thing you’ll put in the header is the document’s title. Later, you’ll add styling information and programming code to make your pages sing and dance.
♦ <!-- -->: This tag indicates a comment, which is ignored by the browser. However, a comment is used to describe what’s going on in a particular part of the code.
♦ <title></title>: This tag is used to determine the page’s title. The title usually contains ordinary text. Whatever you define as the title will appear in some special ways. Many browsers put the title text in the browser’s title bar. Search engines often use the title to describe the page.
Throughout this book, I use the filename of the HTML code as the title. That way, you can match any figure or code listing to the corresponding file on the Web site that accompanies this book. Typically, you’ll use something more descriptive, but this is a useful technique for a book like this.
♦ <body></body>: The page’s main content is contained within these tags. Most of the HTML code and the stuff the user sees are in the body area. If the header area is the engine compartment, the body is where the passengers go.
♦ <h1></h1>: H1 stands for heading level one. Any text contained within this markup is treated as a prominent headline. By default, most browsers add special formatting to anything defined as H1, but there’s no guarantee. An H1 heading doesn’t really specify any particular font or formatting, just the meaning of the text as a level one heading. When you find out how to use CSS in Book II, you’ll discover that you can make your headline look however you want. In this first minibook, keep all the default layouts for now and make sure you understand that HTML is about semantic meaning, not about layout or design. There are other levels of headings, of course, through <h6> where <h2> indicates a heading slightly less important than <h1>, <h3> is less important than <h2>, and so on.
A few notes about the basic page
Be proud of this first page. It may be simple, but it’s the foundation of greater things to come. Before moving on, take a moment to ponder some important HTML/XHTML principles shown in this humble page you’ve created:
All tags are lowercase. Although HTML does allow uppercase tags, the XHTML variation you’ll be using throughout most of this book requires only lowercase tags.
Tag pairs are containers, with a beginning and an end. Tags contain other tags or text.
Some elements can be repeated. There’s only one <html>, <title>, and <body> tag per page, but a lot of the other elements (<h1> and <p>) can be repeated as many times as you like.
Carriage returns are ignored. In the Notepad document, there are a number of carriage returns. The formatting of the original document has no effect on the HTML output. The markup tags indicate how the output looks.
♦ <p></p>: In HTML, p stands for the paragraph tag. In your Web pages, you should enclose each standard paragraph in a <p></p> pair. You might notice that HTML doesn’t preserve the carriage returns or white space in your HTML document. That is, if you press Enter in your code to move text to a new line, that new line isn’t necessarily preserved in the final Web page.
The <p></p> structure is one easy way to manage spacing before and after each paragraph in your document.
Setting Up Your System
You don’t need much to make Web pages. Your plain text editor and a Web browser are about all you need. Still, some things can make your life easier as a Web developer.
Displaying file extensions
The method discussed in this section is mainly for Windows users, but it’s a big one. Windows uses the extension (the part of the filename after the period) to determine what type of file you’re dealing with. This is very important in Web development. The files you create are simple text files, but if you store them with the ordinary .txt extension, your browser can’t read them properly. What’s worse, the default Windows setting hides these extensions from you, so you have only the icons to tell you what type of file you’re dealing with, which causes all kinds of problems. I recommend you have Windows explicitly describe your file extensions. Here’s how to set that up:
1. Open the file manager (My Computer in XP or Computer in Vista and Windows 7).
Use the My Computer window to open a directory on your hard drive. It doesn’t matter which directory you’re looking at. You just need the tool open.
2. Choose Tools⇒Folder Options.
The Folder Options dialog box appears.
3. Select the View tab.
You see the Folder Options dialog box.
4. Don’t hide extensions.
By default, Windows likes to hide the extensions for known file types. However, you’re a programmer now, so you deserve to see these things. Uncheck the Hide Extensions for Known File Types box, as shown in Figure 1-2.
5. Show the path and hidden folders.
I like to see my hidden files and folders (after all, they’re mine, right?) and I like to list the full path. Click the appropriate check boxes to enable these features. You’ll often find them to be helpful.
6. Apply these change to all the folders on your computer by clicking the Apply to All Folders button.
This causes the file extensions to appear everywhere, including the Desktop.
Figure 1-2: Don’t hide file extensions (deselect that last check box).
Setting up your software
You’ll write a lot of Web pages, so it makes sense to set up your system to make that process as easy as possible. I talk a lot more about some software you should use in Chapter 3 of this minibook, but for now, here are a couple of easy suggestions:
♦ Put a Notepad icon on your Desktop. You’ll edit a lot of text files, so it’s helpful to have an icon for Notepad (or whatever other text editor you use) available directly on the Desktop. That way, you can quickly edit any Web page by dragging it to the Desktop. When you use more sophisticated editors than Notepad, you’ll want links to them, too.
♦ Get another Web browser. You may just love your Web browser, and that’s fine, but you can’t assume that everybody likes the same browser you do. You need to know how other browsers will interpret your code. Firefox is an incredibly powerful browser, and it’s completely free. If you don’t have them already, I suggest having links to at least two browsers directly on your Desktop.
Understanding the magic
Most of the problems people have with the Web are from misunderstandings about how this medium really works. Most people are comfortable with word processors, and we know how to make a document look how we want. Modern applications use WYSIWYG technology, promising that what you see is what you get. That’s a reasonable promise when it comes to print documents, but it doesn’t work that way on the Web.
How a Web page looks depends on a lot of things that you don’t control. The user may read your pages on a smaller or larger screen than you. She may use a different operating system than you. She may have a dialup connection or may turn off the graphics for speed. She may be blind and use screen-reader technology to navigate Web pages. She may be reading your page on a PDA or a cellphone. You can’t make a document that looks the same in all these situations.
A good compromise is to make a document that clearly indicates how the information fits together and makes suggestions about the visual design. The user and her browser can determine how much of those suggestions to use.
You get control of the visual design but never complete control, which is okay because you’re trading total control for accessibility. People with devices you’ve never heard of can visit your page.
Practice a few times until you can easily build a page without looking anything up. Soon enough, you’re ready for the next step — building pages like the pros.
Chapter 2: It’s All about Validation
In This Chapter
Introducing the concept of valid pages
Using a doctype
Introducing XHTML 1.0 Strict
Setting the character set
Meeting the W3C validator
Fixing things when they go wrong
Using HTML Tidy to clean your pages
Web development is undergoing a revolution. As the Web matures and becomes a greater part of everyday life XX, it’s important to ensure that Web pages perform properly—thus, a call for Web developers to follow voluntary standards of Web development.
Somebody Stop the HTML Madness!
In the bad old days, the Web was an informal affair. People wrote HTML pages any way they wanted. Although this was easy, it led to a lot of problems:
♦ Browser manufacturers added features that didn’t work on all browsers. People wanted prettier Web pages with colors, fonts, and doodads, but there wasn’t a standard way to do these things. Every browser had a different set of tags that supported enhanced features. As a developer, you had no real idea if your Web page would work on all the browsers out there. If you wanted to use some neat feature, you had to ensure your users had the right browser.
♦ The distinction between meaning and layout was blurred. People expected to have some kind of design control of their Web pages, so all kinds of new tags popped up that blurred the distinction between describing and decorating a page.
♦ Table-based layout was used as a hack. HTML didn’t have a good way to handle layout, so clever Web developers started using tables as a layout mechanism. This worked, after a fashion, but it wasn’t easy or elegant.
♦ People started using tools to write pages. Web pages soon became so ugly that people began to believe that they couldn’t do HTML by hand anymore and that some kind of editor was necessary to handle all that complexity for them. Although these editing programs introduced new features that made things easier upfront, these tools also made code almost impossible to change without the original editor. Web developers began thinking they couldn’t design Web pages without a tool from a major corporation.
♦ The nature of the Web was changing. At the same time, these factors were making ordinary Web development more challenging. Innovators were recognizing that the Web wasn’t really about documents but was about applications that could dynamically create documents. Many of the most interesting Web pages you visit aren’t Web pages at all but programs that produce Web pages dynamically every time you visit. This meant that developers had to make Web pages readable by programs, as well as humans.
In short, the world of HTML was a real mess.
XHTML to the rescue
In 2000, the World Wide Web Consortium (usually abbreviated as W3C) got together and proposed some fixes for HTML. The basic plan was to create a new form of HTML that complied with a stricter form of markup, or eXtensible Markup Language (XML). The details are long and boring, but essentially, they came up with some agreements about how Web pages are standardized. Here are some of those standards:
♦ All tags have endings. Every tag comes with a beginning and an end tag. (Well, a few exceptions come with their own ending built in. I’ll explain when you encounter the first such tag in Chapter 6 of this minibook.) This was a new development because end tags were considered optional in old-school HTML, and many tags didn’t even have end tags.
♦ Tags can’t be overlapped. In HTML, sometimes people had the tendency to be sloppy and overlap tags, like this: <a><b>my stuff</a></b>. That’s not allowed in XHTML, which is a good thing because it confuses the browser. If a tag is opened inside some container tag, the tag must be closed before that container is closed.
♦ Everything’s lowercase. Some people wrote HTML in uppercase, some in lowercase, and some just did what they felt like. It was inconsistent and made it harder to write browsers that could read all the variations.
♦ Attributes must be in quotes. If you’ve already done some HTML, you know that quotes used to be optional — not anymore. (Turn to Chapter 4 for more about attributes.)
♦ Layout must be separate from markup. Old-school HTML had a bunch of tags (like <font> and <center>) that were more about formatting than markup. These were useful, but they didn’t go far enough. XHTML (at least the Strict version covered here) eliminates all these tags. Don’t worry, though; CSS gives you all the features of these tags and a lot more.
This sounds more like strict librarian rules. Really, they aren’t restricting at all because most of the good HTML coders were already following these guidelines or something similar.
There’s XHTML and there’s good XHTML
In old-style HTML, you never really knew how your pages would look on various browsers. In fact, you never really knew if your page was even written properly. Some mistakes would look fine on one browser but cause another browser to blow up.
The idea of validation is to take away some of the uncertainty of HTML. It’s like a spell checker for your code. My regular spell checker makes me feel a little stupid sometimes because I make mistakes. I like it, though, because I’m the only one who sees the errors. I can fix the spelling errors before I pass the document on to you, so I look smart. (Well, maybe.)
It’d be cool if you could have a special kind of checker that does the same things for your Web pages. Instead of checking your spelling, it’d test your page for errors and let you know if you made any mistakes. It’d be even cooler if you could have some sort of certification that your page follows a standard of excellence.
That’s how page validation works. You can designate that your page will follow a particular standard and use a software tool to ensure that your page meets that standard’s specifications. The software tool is a validator. I show you two different validators in the upcoming “Validating Your Page” section.
The browsers also promise to follow a particular standard. If your page validates to a given standard, any browser that validates to that same standard can reproduce your document correctly, which is a big deal.
XHTML isn’t perfect
While XHTML is the standard emphasized in this book, it has a few problems of its own. Not all browsers read it the same way, and it’s a bit wordier than it needs to be. It looks like the next generation will go back to a form of HTML (HTML 5). However, proper HTML 5 coding will resemble XHTML more than HTML 4. In this edition, I focus on XHTML Strict. See Chapter 8 of this minibook for a complete overview of this important standard.
Building an XHTML Document
You create an XHTML document the same way you build ordinary HTML. You can still use an ordinary text editor, but the code is slightly more involved. Look at the following code (template.html on this book’s CD-ROM) to see a bare-bones XHTML document:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8” />
<title></title>
</head>
<body>
<h1></h1>
<p>
</p>
</body>
</html>
At first, this new document looks a lot more complicated than the HTML you see in Chapter 1 of this minibook, but it isn’t as bad as it seems.
Don’t memorize all this!
Before you freak out, don’t feel you have to memorize this nonsense. Even people who write books about Web development (um, like me) don’t have this stuff memorized because it’s too awkward and too likely to change.
Keep a copy of template.html on your local drive (I keep a copy on my Desktop) and begin all your new pages with this template. When you start to use a more complex editor (see Chapter 3 of this minibook), you can often customize the editor so that it automatically starts with the framework you want.
You don’t have to have all this stuff down cold, but you should understand the basics of what’s going on, so the following is a quick tour.
The DOCTYPE tag
The scariest looking XHTML feature is the <!DOCTYPE> tag. This monster is ugly, no doubt, but it does serve a purpose. Officially, it’s a document type definition. Your doctype declares to the world what particular flavor of HTML or XHTML you’re using. When you begin your page with the doctype that I suggest here, you’re telling the browser: “Hey, browser, my page follows the XHTML Strict guidelines, and if you aren’t sure what that is, go to this Web site to get it.”
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
Many doctypes are available, but it’s really a lot simpler than it seems. In this book, I show you XHTML 1.0 Strict, which is the primary doctype you need today. The other variations you might find on the Web (HTML 4.0, Frameset, and Transitional doctypes) are really designed for backwards compatibility. If you’re going to go the standards-compliant route, you might as well go whole hog. (And, until Microsoft supports HTML 5, it’s not a meaningful option for real development.)
Even though standards will change, the techniques you learn with XHTML Strict will serve you well as you move to other standards.
The xmlns attribute
The html tag looks a little different from the one in Chapter 1 of this minibook. It has the term xmlns after it, which stands for XML NameSpace. This acronym helps clarify the definitions of the tags in your document:
<html xmlns=”http://www.w3.org/1999/xhtml”>
Truthfully, not all validators require this part, but it doesn’t hurt to add it.
The meta tag
The last tag is the funky meta tag, which has been part of HTML for a long time. They allow you to describe various characteristics of a Web page:
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8” />
The particular form of the meta tag you see here defines the character set to use. The utf character set handles a number of Western languages well.
The truth is, if you start with this framework, you’ll have everything you need to make official XHTML pages that validate properly.
You validate me
All this doctype and xmlns nonsense is worth it because of a nifty program — a validator. The most important validator is the W3C validator at http://validator.w3.org, as shown in Figure 2-1.
Figure 2-1: The W3C validator page isn’t exciting, but it sure is useful.
A validator is actually the front end of a piece of software that checks pages for validity. It looks at your Web page’s doctype and sees if the page conforms to the rules of that doctype. If not, it tells you what might have gone wrong.
You can submit code to a validator in three ways:
♦ Validate by URL. This option is used when a page is hosted on a Web server. Files stored on local computers can’t be checked with this technique. Book VIII describes all you need to know about working with Web servers, including how to create your own.
♦ Validate by File Upload. This technique works fine with files you haven’t posted to a Web server. It works great for pages you write on your computer but you haven’t made visible to the world. This is the most common type of validation for beginners.
♦ Validate by Direct Input. The validator page has a text box you can simply paste your code into. It works, but I usually prefer to use the other methods because they’re easier.
Validation might sound like a big hassle, but it’s really a wonderful tool because sloppy HTML code can cause lots of problems. Worse, you might think everything’s okay until somebody else looks at your page, and suddenly, the page doesn’t display correctly.
Validating Your Page
To explain all this, I created a Web page the way Aesop might have done in ancient Greece. Okay, maybe Aesop didn’t write his famous fables as Web pages, but if he had, they might have looked like the following code listing:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1” />
<!-- oxWheels1.html -->
<!-- note this page has deliberate errors! Please see the text
and oxWheelsCorrect.html for a corrected version.
-->
</head>
<body>
<title>The Oxen and the Wheels</title>
<h1>The Oxen and the Wheels
<h2></h1>From Aesop’s Fables</h2>
<p>
A pair of Oxen were drawing a heavily loaded wagon along a
miry country road. They had to use all their strength to pull
the wagon, but they did not complain.
<p>
<p>
The Wheels of the wagon were of a different sort. Though the
task they had to do was very light compared with that of the
Oxen, they creaked and groaned at every turn. The poor Oxen,
pulling with all their might to draw the wagon through the
deep mud, had their ears filled with the loud complaining of
the Wheels. And this, you may well know, made their work so
much the harder to endure.
</p>
<p>
“Silence!” the Oxen cried at last, out of patience. “What have
you Wheels to complain about so loudly? We are drawing all the
weight, not you, and we are keeping still about it besides.”
</p>
<h2>
They complain most who suffer least.
</h2>
</body>
</html>
The code looks okay, but actually has a number of problems. Aesop may have been a great storyteller, but from this example, it appears he was a sloppy coder. The mistakes can be hard to see, but trust me, they’re there. The question is how do you find the problems before your users do?
You might think that the problems would be evident if you viewed the page in a Web browser. The Firefox and Internet Explorer Web browsers seem to handle the page decently, even if they don’t display it in an identical way. Figure 2-2 shows oxWheels1.html in Firefox, and Figure 2-3 shows it in Internet Explorer.
Firefox appears to handle the page pretty well, but From Aesop’s Fables is supposed to be a headline level two, or H2, and it appears as plain text. Other than that, there’s very little indication that something is wrong.
Microsoft Internet Explorer also tries to display the page, and it does a decent job. Notice that From Aesop’s Fables appears to be a level one header, or H1. That’s odd. Still, the page looks pretty good in both browsers, so you might assume everything’s just fine. That gets you into trouble.
Figure 2-2: oxWheels1.html in Firefox.
Figure 2-3: oxWheels1.html in Internet Explorer.
If it looks fine, who cares if it’s exactly right? You might wonder why we care if there are mistakes in the underlying code, as long as everything works okay. After all, who’s going to look at the code if the page displays properly?
The problem is, you don’t know if it’ll display properly, and mistakes in your code will eventually come back to haunt you. If possible, you want to know immediately what parts of your code are problematic so you can fix them and not worry.
Aesop visits W3C
To find out what’s going on with this page, pay a visit to the W3C validator at http://validator.w3.org. Figure 2-4 shows me visiting this site and uploading a copy of oxWheels1.html to it.
Hold your breath and hit the Check button. You might be surprised at the results shown in Figure 2-5.
The validator is a picky beast, and it doesn’t seem to like this page at all. The validator does return some useful information and gives enough hints that you can decode things soon enough.
Figure 2-4:
I’m checking the oxWheels page to look for any problems.
Figure 2-5: Twelve errors? That can’t be right!
Examining the overview
Before you look at the specific complaints, take a quick look at the Web page the validator sends you. The Web page is chock-full of handy information. The top of the page tells you a lot of useful things:
♦ Result: This is really the important thing. You’ll know the number of errors remaining by looking at this line. Don’t panic, though. The errors in the document are probably fewer than the number you see here.
♦ File: The name of the file you’re working on.
♦ Encoding: The text encoding you’ve set. If you didn’t explicitly set text encoding, you may see a warning here.
♦ Doctype: This is the doctype extracted from your document. It indicates the rules that the validator is using to check your page. This should usually say XHTML 1.0 Strict.
♦ Root Namespace: If you use the template I give you, you always see the same namespace, and you don’t have any surprises.
♦ The dreaded red banner: Experienced Web developers don’t even have to read the results page to know if there is a problem. If everything goes well, there’s a green congratulatory banner. If there are problems, the banner is red. It doesn’t look good, Aesop.
Validating the page
The validator doesn’t always tell you everything you need to know, but it does give you some pretty good clues. Page validation is tedious but not as difficult as it might seem at first. Here are some strategies for working through page validation:
♦ Focus only on the first error. Sure, 100 errors might be on the page, but solve them one at a time. The only error that matters is the first one on the list. Don’t worry at all about other errors until you’ve solved the first one.
♦ Note where the first error is. The most helpful information you get is the line and column information about where the validator recognized the error. This isn’t always where the error is, but it does give you some clues.
♦ Look at the error message. It’s usually good for a laugh. The error messages are sometimes helpful and sometimes downright mysterious.
♦ Look at the verbose text. Unlike most programming debuggers, the W3C validator tries to explain what went wrong in something like English. It still doesn’t always make sense, but sometimes the text gives you a hint.
♦ Scan the next couple of errors. Sometimes, one mistake shows up as more than one error. Look over the next couple of errors, as well, to see if they provide any more insight; sometimes, they do.
♦ Revalidate. Check the page again after you save it. If the first error is now at a later line number than the previous one, you’ve succeeded.
♦ Don’t worry if the number of errors goes up. The number of perceived errors will sometimes go up rather than down after you successfully fix a problem. This is okay. Sometimes, fixing one error uncovers errors that were previously hidden. More often, fixing one error clears up many more. Just concentrate on clearing errors from the beginning to the end of the document.
♦ Lather, rinse, and repeat. Look at the new top error and get it straightened out. Keep going until you get the coveted Green Banner of Validation. (If I ever write an XHTML adventure game, the Green Banner of Validation will be one of the most powerful talismans.)
Examining the first error
Look again at the results for the oxWheels1.html page. The first error message looks like Figure 2-6.
Figure 2-6:
It doesn’t like the end of the head?
Figure 2-6 shows the first two error messages. The first complains about where the </head> tag is. The second message complains about the <title> tag. Look at the source code, and you see that the relevant code looks like this:
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1” />
<!-- oxWheels1.html -->
<!-- note this page has deliberate errors! Please see the text
and oxWheelsCorrect.html for a corrected version.
-->
</head>
<body>
<title>The Oxen and the Wheels</title>
<h1>The Oxen and the Wheels
Look carefully at the head and title tag pairs, and review the notes in the error messages, and you’ll probably see the problem. The <title> element is supposed to be in the heading, but I accidentally put it in the body! (Okay, it wasn’t accidental; I made this mistake deliberately here to show you what happens. However, I have made this mistake for real in the past.)
Fixing the title
If the title tag is the problem, a quick change in the HTML should fix this problem. oxWheels2.html shows another form of the page with my proposed fix:
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1” />
<!-- oxWheels2.html -->
<!-- Moved the title tag inside the header -->
<title>The Oxen and the Wheels</title>
</head>
<body>
Note: I’m only showing the parts of the page that I changed. The entire page is available on this book’s CD-ROM.
The fix for this problem is pretty easy:
1. Move the title inside the head.
I think the problem here is having the <title> element inside the body, rather than in the head where it belongs. If I move the title to the body, the error should be eliminated.
2. Change the comments to reflect the page’s status.
It’s important that the comments reflect what changes I make.
3. Save the changes.
Normally, you simply make a change to the same document, but I’ve elected to change the filename so you can see an archive of my changes as the page improves. This can actually be a good idea because you then have a complete history of your document’s changes, and you can always revert to an older version if you accidentally make something worse.
4. Note the current first error position.
Before you submit the modified page to the validator, make a mental note of the position of the current first error. Right now, the validator’s first complaint is on line 13, column 6. I want the first mistake to be somewhere later in the document.
5. Revalidate by running the validator again on the modified page.
6. Review the results and do a happy dance.
It’s likely you still have errors, but that’s not a failure! Figure 2-7 shows the result of my revalidation. The new first error is on line 16, and it appears to be very different from the last error. I solved it!
Figure 2-7: Document type does not allow element “h2” here.
Solving the next error
One down, but more to go. The next error (refer to Figure 2-7) looks strange, but it’s one you see a lot.
The document type does not allow error is very common. What it usually means is you forgot to close something or you put something in the wrong place. The error message indicates a problem in line 16. The next error is line 16, too. See if you can find the problem here in the relevant code:
<body>
<h1>The Oxen and the Wheels
<h2></h1>From Aesop’s Fables</h2>
After you know where to look, the problem becomes a bit easier to spot. I got sloppy and started the <h2> tag before I finished the <h1>. In many cases, one tag can be completely embedded inside another, but you can’t have tag definitions overlap as I’ve done here. The <h1> has to close before I can start the <h2> tag.
This explains why the two main browsers displayed From Aesop’s Fables differently. It isn’t clear whether this code should be displayed in H1 or H2 format, or perhaps with no special formatting at all. It’s much better to know the problem and fix it than to remain ignorant until something goes wrong.
The third version — oxWheels3.html — fixes this part of the program:
<!-- oxWheels3.html -->
<!-- sort out the h1 and h2 tags at the top -->
<title>The Oxen and the Wheels</title>
</head>
<body>
<h1>The Oxen and the Wheels</h1>
<h2>From Aesop’s Fables</h2>
Checking the headline repair
The heading tags look a lot better, and a quick check of the validator confirms this fact, as shown in Figure 2-8, which now shows only six errors.
Here’s another form of that document type does not allow error. This one seems strange because surely <p> tags are allowed in the body! The secret to this particular problem is to look carefully at the error message. This document has a lot of <p> tags in it. Which one is it complaining about?
A pair of Oxen were drawing a heavily loaded wagon along a
miry country road. They had to use all their strength to pull
the wagon, but they did not complain.
<p>
<p>
The Wheels of the wagon were of a different sort. Though the
task they had to do was very light compared with that of the
Oxen, they creaked and groaned at every turn. The poor Oxen,
pulling with all their might to draw the wagon through the
deep mud, had their ears filled with the loud complaining of
the Wheels. And this, you may well know, made their work so
much the harder to endure.
</p>
Aha! Line 22 is supposed to be the end of the paragraph, but I somehow forgot the slash character, so the validator thinks I’m beginning a new paragraph inside the previous one, which isn’t allowed. This causes a bunch of other errors, too. Because the validator can’t see the end of this paragraph, it thinks that all the rest of the code is inside this first paragraph. Try changing the <p> of line 22 into a </p> and see if it works better:
<p>
A pair of Oxen were drawing a heavily loaded wagon along a
miry country road. They had to use all their strength to pull
the wagon, but they did not complain.
</p>
Figure 2-8: Document type doesn’t allow “p” here. That’s odd.
The complaint is about the <p> tag on line 22. Unfortunately, Notepad doesn’t have an easy way to know which line you’re on, so you just have to count until I show you some better options in Chapter 3 of this minibook. To make things easier, I’ve reproduced the key part of the code here and highlighted line 22. Try to find the problem before I explain it to you:
<h1>The Oxen and the Wheels</h1>
<h2>From Aesop’s Fables</h2>
<p>
Figure 2-9 shows the validation results for oxWheels4.html.
Showing off your mad skillz
Sometimes, that green bar makes little tears of joy run down my cheeks. Congratulations! It’s only the second chapter in this minibook, and you’re already writing better Web pages than many professionals.
Seriously, a Web page that validates to XHTML Strict is a big deal, and you deserve to be proud of your efforts. The W3C is so proud of you that they offer you a little badge of honor you can put on your page.
Figure 2-10 shows more of the page you get when your page finally validates correctly. You can see a little button and some crazy-looking HTML code.
Figure 2-9: Hooray! We have a valid page!
Figure 2-10: The validator gives you a little virtual badge of honor to show how cool you are.
If you want, you can copy and paste that code into your page. oxWheels5.html has that special code added at the end of the body, shown in Figure 2-11.
Figure 2-11: Look, I have a medal from the W3C!
Is validation really that big a deal?
I can hear the angry e-mails coming in. “Andy, I’ve been writing Web pages since 1998, and I never used a validator.” Okay, it’s true. A lot of people, even some professional Web developers, work without validating their code. Some of my older Web pages don’t validate at all. (You can run the W3C validator on any page you want, not just one you wrote. This can be a source of great joy if you like feeling superior to sloppy coders.) When I became more proficient and more prolific in my Web development, I found that those little errors often caused a whole lot of grief down the road. I really believe you should validate every single page you write. Get into the habit now, and it’ll pay huge dividends. When you’re figuring out this stuff for the first time, do it right.
If you already know some HTML, you’re gonna hate the validator for a while because it rejects coding habits that you might think are perfectly fine. Unlearning a habit is a lot harder than learning a new practice, so I feel your pain. It’s still worth it.
After you discipline yourself to validate your pages, you’ll find you’ve picked up good habits, and validation becomes a lot less painful. Experienced programmers actually like the validation process because it becomes much easier and prevents problems that could cause lots of grief later.
This little code snippet does a bunch of neat things, such as
♦ Establishing your coding prowess: Any page that has this image on it has been tested and found compliant to XHTML Strict standards. When you see pages with this marker, you can be confident of the skill and professionalism of the author.
♦ Placing a cool image on the page: You’ll read how to add your own images in Chapter 6 of this minibook, but it’s nice to see one already. This particular image is hosted at the W3C site.
♦ Letting users check the page for themselves: When the user clicks the image, they’re taken directly to the W3C validator to prove that the page is in fact valid XHTML Strict. Unfortunately, this link works only on pages that are posted to a Web server, so it doesn’t work correctly on a page just sitting on your computer. Scope out Book VIII for suggestions on finding and using a server.
Using Tidy to repair pages
The W3C validator isn’t the only game in town. Another great resource — HTML Tidy — can be used to fix your pages. You can download Tidy or just use the online version at http://infohound.net/tidy. Figure 2-12 illustrates the online version with oxWheels1.html being loaded.
Figure 2-12: HTML Tidy is an alternative to the W3C validator.
Unlike W3C’s validator, Tidy actually attempts to fix your page. Figure 2-13 displays how Tidy suggests the oxWheels.html page be fixed.
Figure 2-13: Tidy fixes the page, but the fix is a little awkward.
Tidy examines the page for a number of common errors and does its best to fix the errors. However, the result is not quite perfect:
♦ Tidy adds a new meta tag, indicating the page was created by Tidy. I always get nervous when a program I didn’t write starts messing with my pages.
♦ Tidy tends to choose a sloppier doctype. If you don’t specify otherwise, Tidy checks against XHTML 1.0 Transitional, rather than Strict. This definition isn’t as stringent. You can (and should) specify the Strict doctype manually in the submission form.
♦ Tidy got confused by the title. Tidy correctly diagnosed the title in the wrong place, but it added a blank title, as well as the intended one.
♦ Sometimes, the indentation is off. I set Tidy to indent every element, so it is easy to see how tag pairs are matched up. If I don’t set up the indentation explicitly, I find Tidy code very difficult to read.
♦ The changes aren’t permanent. Anything Tidy does is just a suggestion. If you want to keep the changes, you need to save the results in your editor.
I sometimes use Tidy when I’m stumped because I find the error messages are easier to understand than the W3C validator. However, I never trust it completely. There’s really no substitute for good old detective skills and the official W3C validator.
Chapter 3: Choosing Your Tools
In This Chapter
Choosing a text editor
Using a dedicated HTML editor
Comparing common browsers
Introducing Integrated Development Environments (IDEs)
Adding important Firefox extensions
Web development is a big job. You don’t go to a construction site without a belt full of tools (and a cool hat), and the same thing is true with Web development (except you don’t normally need a hard hat for Web development). An entire industry has evolved trying to sell tools that help make Web development easier. The funny thing is that the tools you need might not be the ones that people are trying to sell you. Some of the very best Web development tools are free, and some of the most expensive tools aren’t that helpful.
This chapter tells you what you need and how to set up your workshop with great programs that simplify Web development.
What’s Wrong with the Big Boys?
Many Web development books are really books about how to use a particular type of software. Microsoft’s FrontPage/Expression Web and Macromedia/Adobe Dreamweaver are the two primary applications in this category. These tools are powerful and offer some seemingly great features:
♦ WYSIWYG editing: What you see is what you get is an idea borrowed from word processors. You can create a Web page much like a word-processing document and use menus, as well as tools, to handle all the formatting. The theory is that you don’t have to know any icky codes.
♦ Templates: You can create a template that stays the same and build several pages from that template. If you need to change the template, everything else changes automatically.
♦ Site management: The interaction between the various pages on your site can be maintained automatically.
These sound like pretty good features, and they are. The tools (and the newer replacements, like Microsoft’s Expression suite) are very powerful and can be an important part of your Web development toolkit. However, the same powerful programs introduce problems, such as the following:
♦ Code maintenance: The commercial editors that concentrate on visual design tend to create pretty unmanageable code. If you find there’s something you need to change by hand, it’s pretty hard to fix the code.
♦ Vendor lock-in: These tools are written by corporations that want you to buy other tools from them. If you’re using Dreamweaver, you’ll find it easy to integrate with other Adobe applications (like ColdFusion), but it’s not as simple to connect to non-Adobe technology. Likewise, Microsoft’s offerings are designed to work best with other Microsoft technologies.
♦ Cost: The cost of these software packages keeps going up. Expression Web (Microsoft’s replacement for FrontPage) costs about $300, and Dreamweaver weighs in at $400. Both companies encourage you to buy the software as part of a package, which can easily cost more than $500.
♦ Complexity: They’re complicated. You can take a full class or buy a huge book on how to use only one of these technologies. If it’s that hard to figure out, is it really saving you any effort?
♦ Code: You still need to understand it. No matter how great your platform is, at some point, you have to dig into your code. After you plunk down all that money and spend all that time figuring out an application, you still have to understand how the underlying code works because things still go wrong. For example, if your page fails to work with Safari, you’ll have to find out why and fix the problem yourself.
♦ Spotty standards compliance: The tools are getting better here, but if you want your pages to comply with the latest standards, you have to edit them heavily after the tool is finished.
♦ Display variations: WYSIWYG is a lie. This is really the big problem. WYSIWYG works for word processors because it’s possible to make the screen look like the printed page. After a page is printed, it stays the same. You don’t know what a Web page will look like because that depends on the browser. What if the user loads your page on a cellphone or handheld device? The editors tend to perpetuate the myth that you can treat a Web page like a printed document when, in truth, it’s a very different kind of beast.
♦ Incompatibility with other tools: Web development is now moving toward content management systems (CMS) — programs which create Web sites dynamically. Generally, CMS systems provide the same ease-of-use as a visual editor but with other benefits. However, transitioning code created in a commercial editor to a CMS is very difficult. I describe CMS systems in detail in Book VIII, Chapter 3.
Alternative Web Development Tools
For Web development, all you really need is a text editor and a Web browser. You probably already have a basic set of tools on your computer. If you read Chapters 1 and 2 of this minibook, you’ve already written a couple of Web pages. However, the very basic tools that come with every computer might not be enough for serious work. Web development requires a specialized kind of text editor, and a number of tools have evolved that make the job easier.
The features you need on your computer
Here are a few features your text editor and browser might not have that you need:
♦ Line numbers: Notepad doesn’t have an easy way to figure out what line you’re on. And counting lines every time you want to find a problem noted by the validator is pretty tedious.
♦ Help features: Having an editor help with your code is ideal. Some tools can recognize HTML code, help with indentation, and warn you when something is wrong.
♦ Macros: You type the same code many times. A program that can record and play keyboard macros can save a huge amount of time.
♦ Testing and validation: Testing your code in one or more browsers should be simple, and there should be an easy way to check your code for standards.
♦ Multiple browsers: An Internet user having only one browser is fine, but a Web developer needs to know how things look in a couple different environments.
♦ Browser features: You can customize some browsers (especially Firefox) to help you a lot. With the right attachments, the browser can point out errors and help you see the structure of your page.
♦ Free and open tools: The Web is exciting because it’s free and open technology. If you can find tools that follow the same philosophy, all the better.
Building a basic toolbox
I’ve found uses for five types of programs in Web development:
♦ Enhanced text editors: These tools are text editors, but they’re souped-up with all kinds of fancy features, like syntax checkers, code-coloring tools, macro tools, and multiple document interfaces.
♦ Browsers and plugins: The browser you use can make a huge difference. You can also install free add-ons that can turn your browser into a powerful Web development tool.
♦ Integrated Development Environments (IDE): Programmers generally use IDEs, which combine text editing, visual layout, code testing, and debugging tools.
♦ Programming technologies: This book covers all pertinent info about incorporating other technologies, like Apache, PHP, and MySQL. I show you how to install everything you need for these technologies in Book VIII, Chapter 1. You don’t need to worry about these things yet, but you should develop habits that are compatible with these enhanced technologies from the beginning.
♦ Multimedia tools: If you want various multimedia elements on your page, you’ll need tools to manage them, as well. These could involve graphics and audio editors, as well as full-blown multimedia technologies, like Flash.
Picking a Text Editor
As a programmer, you come to see your text editor as a faithful companion. You spend a lot of time with this tool, so use one that works with you.
A text editor should save plain text without any formatting at all. You don’t want anything that saves colors, font choices, or other text formatting because these things don’t automatically translate to HTML.
Fortunately, you have several choices, as the following sections reveal.
Tools to avoid unless you have nothing else
A text editor may be a simple program, but that doesn’t mean they’re all the same. Some programs have a history of causing problems for beginners (and experienced developers, too). There’s usually no need to use some of these weaker choices.
Microsoft Word
Windows Notepad
Notepad is everywhere, and it’s free. That’s the good news. However, Notepad doesn’t have a lot of the features you might need, such as line numbers, multiple documents, or macros. Use it if you’re on an unfamiliar machine, but try something else if you can. Many people begin with Notepad, but it won’t be long until you outgrow its limitations.
Mac TextEdit
Mac has a simple text editor built in — TextEdit — that’s similar to Notepad, but closer to a word processor than a programmer’s text editor. TextEdit saves files in a number of formats. If you want to use it to write Web pages, you must save your files in plain-text format, and you must not use any of TextEdit’s formatting features. It’s probably best not to use TextEdit unless you really have to.
A noteworthy editor: Notepad++
A number of developers have come up with good text editors. Some of the best are free, such as Notepad++ by Don Ho. Notepad++ is designed for text editing, especially in programming languages. Figure 3-1 shows Notepad++ with an HTML file loaded.
Figure 3-1: Notepad++ has many of the features you need in a text editor.
Notepad++ has a lot of interesting features. Here are a few highlights:
♦ Syntax highlighting: Notepad++ can recognize key HTML terms and put different types of terms in different colors. For example, all HTML tags are rendered blue, and text is black, making it easy to tell if you’ve made certain kinds of mistakes, such as forgetting to end a tag. Note that the colors aren’t saved in the document. The coloring features are there to help you understand the code.
♦ Multiple files: You’ll often want to edit more than one document at a time. You can have several different documents in memory at the same time.
♦ Multi-language support: Currently, your pages consist of nothing but XHTML. Soon enough, you’ll use some other languages, like SQL, CSS, and PHP. Notepad++ is smart enough to recognize these languages, too.
♦ Macros: Whenever you find yourself doing something over and over, consider writing a keyboard macro. Notepad++ has a terrific macro feature. Macros are easy to record and play back a series of keystrokes, which can save you a lot of work.
♦ Page preview: When you write a page, test it. Notepad++ has shortcut keys built in to let you quickly view your page in Internet Explorer (Ctrl+Alt+Shift+I) and Firefox (Ctrl+Alt+Shift+X).
♦ TextFX: The open-source design of Notepad++ makes it easy to add features. The TextFX extension (built into Notepad++) allows you to do all sorts of interesting things. One especially handy set of tools runs HTML Tidy on your page and fixes any problems.
The old standards: VI and Emacs
No discussion of text editors is complete without a mention of the venerable UNIX editors that were the core of the early Internet experience. Most of the pioneering work on the Web was done in the UNIX and Linux operating systems, and these environments had two extremely popular text-editor families. Both might seem obscure and difficult to modern sensibilities, but they still have passionate adherents, even in the Windows community. (Besides, Linux is more popular than ever!)
VI and VIM
VI stands for VIsual Editor. That name seems strange now because most developers can’t imagine an editor that’s not visual. Back in the day, it was a very big deal that VI could use the entire screen for editing text. Before that time, line-oriented editors were the main way to edit text files. Trust me, you have it good now. Figure 3-2 shows a variant of VI (called VIM) in action.
Figure 3-2:
VI isn’t pretty, but after you know it, it’s very powerful.
VI is a modal editor, which means that the same key sometimes has more than one job, depending on the editor’s current mode. For example, the I key is used to indicate where you want to insert text. The D key is used to delete text, and so on. Of course, when you’re inserting text, the keys have their normal meanings. This multimode behavior is baffling to modern users, but it can be amazingly efficient after you get used to it. Skilled VI users swear by it and often use nothing else.
VI is a little too obscure for some users, so a number of variants are floating around, such as VIM, or VI Improved. (Yeah, it should be VII but maybe they were afraid people would call it the Roman numeral seven.) VIM is a little friendlier than VI. It tells you which mode it’s in and includes such modern features as mouse support, menus, and icons. Even with these features, VIM is not intuitive for most people.
Versions of VI are available for nearly any operating system being used. If you already know VI, you might enjoy using it for Web page development because it has all the features you might need. If you don’t already know VI, it’s probably more efficient for you to start with a more standard text editor, such as Notepad++.
Emacs
The other popular editor from the UNIX world is Emacs. Like VI, you probably don’t need this tool if you never use Linux or UNIX. Also like VI, if you know it already, you probably don’t need anything else. Emacs has been a programmer’s editor for a very long time (it has been in continuous development since 1976) and has nearly every feature you can think of.
Emacs has very powerful customization and macro features and allows you to view and edit more than one file at a time. Emacs also has the ability to view and manipulate the local file system, manage remote files, access the local operating system (OS) shell, and even browse the Web or check e-mail without leaving the program. If you’re willing to invest in a program that takes some effort to understand, you’ll have an incredibly powerful tool in your kit. Versions of Emacs are available for most major operating systems. Emacs is one of the first programs I install on any new computer because it’s so powerful. A version of Emacs is shown in Figure 3-3.
Figure 3-3: Emacs is powerful but somewhat eccentric.
An enhanced version — XEmacs — uses standard menus and icons like modern programs, so it’s reasonably easy to get started with.
Other text editors
Many other text editors are used in Web development. The most important thing is to find one that matches the way you work. If you don’t like any of the editors I’ve suggested so far, here are a few more you might want to try:
♦ SynEdit: Much like Notepad++ and very popular with Web developers
♦ Scintilla: Primarily a programming editor, but has nice support for XHTML coding
♦ jEdit: A popular text editor written in Java with nice features, but some developers consider it slower than the other choices
The Web Developer’s Browser
Web pages are meant to display in a browser; so, of course, you need browsers for testing. Not all browsers are the same, though, so you need more than one. As of this writing, there are two major browsers and a number of other significant players in the browser world. It’s important to know a little about the major browsers, which I discuss later in this section.
A little ancient history
You’ve probably already noticed that browsers are inconsistent in the way they display and handle Web pages. It’s useful to understand how we got into this mess.
Mosaic/Netscape — the killer application
In the beginning, browsers were written by small teams. The most important early browser was Mosaic, written by a team based at the National Center for Supercomputing Applications (NCSA) in Champaign–Urbana, Illinois.
Several members of that NCSA team decided to create a completely commercial Web browser. Netscape was born, and it quickly became the most prominent and important browser, with 97 percent market share at the peak of its popularity.
Microsoft enters (and wins) the battle
Microsoft came onto the scene with Internet Explorer (IE). A bitter fight (sometimes called the Browser Wars) ensued between Microsoft and Netscape. Each browser added new features regularly. Eventually, entire sets of tags evolved, so a Web page written for IE would not always work in Netscape and vice versa. Developers had three bad choices: pick only one browser to support, write two versions of the page, or stick with the more limited set of features common to both browsers.
Netscape 6.0 was a technical disappointment, and Microsoft capitalized, earning a nearly complete lock on the browser market. Microsoft’s version of standards became the only standards because there was virtually no competition. After Microsoft won the fight, there was a period of stability but very little innovation.
Firefox shakes up the world
A new browser rose from the ashes of Netscape (in fact, its original name was Firebird, after the mythical birds that rise from their own ashes). The name was later changed to Firefox, and it breathed new life into the Web. Firefox has several new features that are very appealing to Web developers:
♦ Solid compliance to standards: Firefox followed the W3C standards almost perfectly.
♦ Tabbed browsing: One browser window can have several panels, each with its own page.
♦ Easy customization: Firefox developers encouraged people to add improvements and extensions to Firefox. This led to hundreds of interesting add-ons.
♦ Improved security: By this time, a number of security loopholes in IE were publicized. Although Firefox has many of the same problems, it has a much better reputation for openness and quick solutions.
Overview of the prominent browsers
The browser is the primary tool of the Web. All your users view your page with one browser or another, so you need to know a little about each of them.
Microsoft Internet Explorer 7 and 8
Microsoft Internet Explorer (MSIE or simply IE) is the most popular browser on the planet. Before Firefox came along, a vast majority of Web users used IE. Explorer is still extremely prevalent because it comes installed with Microsoft Windows. Of course, it also works exclusively with Microsoft Windows. Mac and Linux aren’t supported (users don’t seem too upset about it, though).
IE7 featured some welcome additions, including tabbed browsing and improved compliance with the W3C standards. Cynics have suggested these improvements were a response to Firefox. IE7 was quickly replaced with the most recent version, Internet Explorer 8. IE8 has much improved speed and standards-compliance, but it still lags behind the other major browsers in these regards.
If you write your code to XHTML 1.0 Strict standards, it almost always displays as expected in IE7/8.
IE versions 7 and 8 do not fully support HTML 5. If you want to experience these features, you need to use one of the other modern browsers described in this chapter.
Older versions of Internet Explorer
The earlier versions of IE are still extremely important because so many computers out there don’t have IE7 or IE8 installed yet.
Microsoft made a version of IE available for programmers to embed in their own software; therefore, many custom browsers are actually IE with a different skin. Most of the custom browsers that are installed with the various broadband services are simply dressed up forms of IE. Therefore, IE is even more common than you might guess because people might be using a version of it while thinking it’s something else.
IE6 and earlier versions used Microsoft’s own variation of standards. They display old-style HTML well, but these browsers don’t comply perfectly with all the W3C standards. Having a version of one of these older browsers around is important so you can see how your pages display in them. If you write standards-compliant code, you’ll find that it doesn’t work perfectly in these variations. You need to do some tweaking to make some features come out right. Don’t panic, because they’re relatively small details, and I point out the strategies you need as we go.
Checking your pages on IE6 or earlier is necessary. Unfortunately, if you have IE8 (or whatever comes next), you probably don’t have IE6 any longer. You can’t have two versions of IE running on the same machine at once (at least, not easily), so you might need to keep an older machine just for testing purposes. You can use a testing site, such as Spoon.net (www.spoon.net/browsers), to check how various browsers render your pages if you don’t want to install all the other browsers.
Mozilla Firefox
Developers writing standards-compliant code frequently test their pages in Firefox because it has a great reputation for standards compliance. Firefox has other advantages, as well, such as
♦ Better code view: If you view the HTML code of a page, you see the code in a special window. The code has syntax coloring, which makes it easy to read. IE often displays code in Notepad, which is confusing because you think you can edit the code, but you’re simply editing a copy.
♦ Better error-handling: You’ll make mistakes. Generally, Firefox does a better job of pointing out errors than IE, especially when you begin using JavaScript and other advanced technologies.
♦ Great extensions: As you see later in this chapter, Firefox has some wonderful extensions that make Web development a lot easier. These extensions allow you to modify your code on the fly, automatically validate your code, and explore the structure of your page dynamically.
Google Chrome
Google has jumped into the fray with an interesting browser called Chrome. Google sees the future of computing in browser-based applications using AJAX technologies. The Chrome browser is extremely fast, especially in the JavaScript technology that serves as the foundation to this strategy. Chrome complies quite well with common standards, so if your pages look good in Firefox, they’ll also do well in Chrome.
Other notable browsers
Firefox and IE are the big players in the browser world, but they certainly aren’t the only browsers you will encounter.
Opera
The Opera Web browser, one of the earliest standards-compliant browsers, is a technically solid browser that has never been widely used. If you design your pages with strict compliance in mind, users with Opera have no problems accessing them.
Webkit/Safari
Apple includes a Web browser in all recent versions of Mac OS. The current incarnation — Safari — is an excellent standards-compliant browser. Safari was originally designed only for the Mac, but a Windows version has been released recently. The Webkit framework, the foundation for Safari, is used in a number of other online applications, mainly on the Mac. It’s also the foundation of the browsers on the iPhone and iPad.
Mozilla
There’s still a Mozilla browser, but it has been replaced largely with Firefox. Because Mozilla uses the same underlying engine, it renders code the same way Firefox does.
Portable browsers
The Web isn’t just about desktops anymore. Lots of people browse the Web with cellphones, iPhones, and PDAs. These devices often have specialized Web browsers designed to handle the particular needs of the portable gadget. However, these devices usually have tiny screens, small memory capacity, and slower download speeds than their desktop cousins. A portable browser rarely displays a page the way it’s intended to appear on a desktop machine. Portable browsers usually do a good job of making standards-compliant code work, but they really struggle with other types of HTML (especially tables used for formatting and fixed layouts).
Text-only browsers
Some browsers that don’t display any graphics at all (such as Lynx) are intended for the old command-line interfaces. This may seem completely irrelevant today, but these browsers are incredibly fast because they don’t display graphics. Auditory browsers read the contents of Web pages. They were originally intended for people with visual disabilities, but people without any disabilities often use them as well. Fire Vox is a variant of Firefox that reads Web pages aloud.
The bottom line in browsers
Really, you need to have access to a couple browsers, but you can’t possibly have them all. I tend to do my initial development testing with Firefox. I then check pages on IE7 and IE6. I also check the built-in browser on my cellphone and PDA to see how the pages look there. Generally, if you get a page that gives you suitable results on IE6, IE7, and Firefox, you can be satisfied that it works on most browsers. However, there’s still no guarantee. If you follow the standards, your page displays on any browser, but you might not get the exact layout you expect.
Tricking Out Firefox
One of the best features of Firefox is its support for extensions. Hundreds of clever and generous programmers have written tools to improve and alter Firefox’s performance. Three of these tools — HTML Validator, Web Developer toolbar, and Firebug — are especially important to Web developers.
Validating your pages with HTML Validator
In Chapter 2 of this minibook, I explain how important Web standards are and how to use online services such as http://validator.w3.org and HTML Tidy (http://infohound.net/tidy). These are terrific services, but it would be even better to have these validators built directly into your browser. The HTML Validator extension by Marc Gueury is a tool that does exactly that: It adds both the W3C validator and HTML Tidy to your Firefox installation.
When you have the HTML Validator extension (available on this book’s CD-ROM) running, you have an error count in the footer of every page you visit. (You’ll be amazed how many errors are on the Web.) You’ll be able to tell immediately if a page has validation errors.
With the HTML Validator, your View Source tool is enhanced, as shown in Figure 3-4.
Figure 3-4: The HTML Validator explains all errors in your page.
The View Source tool becomes much more powerful when you run HTML Validator, as follows:
♦ Each error is listed in an errors panel. You see this same error list from W3C.
♦ Clicking an error highlights it in the source code listing. This makes it easy to see exactly what line of code triggers each error.
♦ Complete help is shown for every error. The HTML Validator toolbar presents much more helpful error messages than the W3C results.
♦ Automated clean-up. You can click the Clean Up link, and the HTML Validator extension automatically applies HTML Tidy to your page. This can be a very effective way to fix older pages with many errors.
The HTML Validator tool will revolutionize your Web development experience, helping you create standards-compliant sites easily and discover the compliance level of any page you visit. (It’s fun to feel superior.)
Using the Web Developer toolbar
The Web Developer toolbar by Chris Pederick provides all kinds of useful tools for Web developers. The program installs as a new toolbar in Firefox, as shown in Figure 3-5.
Figure 3-5: The Web Developer toolbar adds several features to Firefox.
Figure 3-5 shows the Wiley home page with some of the Web Developer toolbar features active. The Edit CSS frame on the left allows you to modify the look of the page in real time, and the thick outlines help visualize the page organization. (I describe these ideas in detail in Books III and IV.)
When you activate the Web Developer toolbar (use the View⇒Toolbars menu command to hide or show it), you can use it to do the following:
♦ Edit your page on the fly. The Edit HTML Entry option on the Miscellaneous drop-down menu opens a small text editor on the left side of the screen. You can make changes to your HTML here and immediately see the results in the main screen. The changes aren’t permanent, but you can save them.
♦ Validate your pages. Choosing CSS⇒Edit CSS is the command to validate your page, but the Web Developer toolbar also adds some hotkeys to Firefox so you can instantly send your page to the W3C validator. Pressing Ctrl+Shift+A contacts the W3C validator and then sends your page to it. It’s much easier than memorizing the validator address. This feature alone is worth the short download time. You can also do other kinds of validation, check your CSS, or see how well your page conforms to various guidelines for people with disabilities.
♦ Manipulate CSS code. After you define your page with XHTML, use CSS to dress it up. The CSS menu has a number of great tools for seeing how CSS is set up and experimenting with it on the fly. I explain how to use the CSS tools in Books II and III, where I describe CSS.
♦ View your page in different sizes. Not everybody has a huge flat-panel display. It’s important to see how your page looks in a number of standard screen resolutions.
♦ Get a speed report. Your Web page may load great on your broadband connection, but how does it work on Aunt Judy’s dialup? Web Developer has a tool that analyzes all the components of the page, reports how long each component takes to download over various connections, and suggests ways to improve the speed of your page downloads.
♦ Check accessibility. You can run a number of automated tests to determine how accessible your page is. Use the accessibility tests to see how your page will work for people with various disabilities and whether you pass certain required standards (for example, requirements of government sites).
The Web Developer toolbar can do a lot more, but these are some of the highlights. The toolbar is a small and fast download, and it makes Web development a lot easier. There’s really no good reason not to use it.
Using Firebug
The Firebug extension is another vital tool for Web developers. Firebug concentrates more on JavaScript development rather than pure XHTML development, but it’s also useful for XHTML beginners. Figure 3-6 shows the Firebug extension opened as a panel in Firefox.
Firebug’s Inspect mode allows you to compare the HTML code to the output. When you move your mouse over a part of the rendered page, Firebug highlights the relevant part of the code in the other panel. Likewise, you can move the mouse over a code fragment and see the affected code segment, which can be extremely handy when things aren’t working out the way you expect.
You can view the HTML code as an outline, which helps you see the overall structure of the code. You can also edit the code in the panel and see the results immediately, as you can with the Web Developer toolbar, which I discuss in the previous section. Changes you make in Firebug aren’t permanent, but you can copy them to your text editor.
Firebug really shows off when you get to more sophisticated techniques, such as CSS, DOM Manipulation, JavaScript, and AJAX. Books IV and VII show you how Firebug can be used to aid in these processes.
Figure 3-6: Firebug gives a detailed view of your page.
Using a Full-Blown IDE
You might think I hate dedicated Web page editors, but I don’t. I use them all the time for other kinds of programming. The problem is that up until recently, there weren’t any real IDEs (Integrated Development Environments) for Web development. Most of the tools try to be visual development tools that automate the design of visual pages, rather than programming environments. They have flaws because Web development is really a programming problem with visual design aspects, rather than a visual design problem with programming underneath.
A couple of IDEs have popped up recently in the open-source community. One tries to be like the commercial tools (and ends up replicating some of their flaws). Some other editors have emerged that seem to be a good compromise between helping you write solid code and growing with you while you become more sophisticated.
Introducing Aptana
My preferred editor for beginners who intend to advance is Aptana (available on this book’s CD-ROM or at www.aptana.com). Aptana Studio is a full-blown IDE, based on the popular Eclipse editor. Aptana has many features that make it a good choice for Web developers:
♦ Syntax completion: Aptana has built-in knowledge of HTML (and several other languages). When you start to type HTML code, it recognizes the code and pops up a list of suggestions. Figure 3-7 shows Aptana helping on some HTML code.
♦ Automatic ending tags: As soon as you write a beginning tag, Aptana automatically generates the corresponding end tag. This makes it much less likely that you’ll forget an ending tag — one of the most common coding errors.
♦ Automatically generated XHTML template: When you tell Aptana to create an HTML page, it can generate the page template with all the messy doctype stuff built in. (I explain how to customize this feature in the next section.)
♦ Error detection: Aptana can look at the code and detect certain errors. Although it isn’t a replacement for a validator, it can be a very handy tool, especially when you begin to write JavaScript code.
♦ File management tools: Aptana makes it easy to work with both the local file system and pages that reside on Internet servers.
♦ Page preview: You can preview your page directly within Aptana, or you can view it in your primary browser.
♦ Outline view: This panel displays the page structure as an outline to help you see the overall structure of the page. You can also use this panel as a table of contents to get to any particular part of your page in the editor quickly. Figure 3-8 shows the Outline view in action.
Figure 3-7: Aptana recognizes HTML and suggests code for you.
Figure 3-8: The Outline view acts as a table of contents for your page.
♦ Advanced features: When you’re ready to try JavaScript and AJAX, Aptana has nice support for these more advanced technologies. The syntax-highlighting features work in CSS, JavaScript, and PHP the same way they do in HTML. This means you can use the same editor for all your Web languages, which is a great thing.
Customizing Aptana
Aptana is a great editor, but I recommend you change a few settings after you install it on your system.
Getting to the HTML editor preferences
Aptana can be customized in many ways. For now, the only preferences you need to change are in the HTML editor. Choose Windows⇒Preferences, and in the Preferences dialog box, expand the Aptana link and select HTML Editor. The dialog box is shown in Figure 3-9.
Figure 3-9: Aptana’s HTML Editor Preferences dialog box.
Changing the extension
By default, Aptana saves files with the .htm extension. Because this is the extension normally used only by Microsoft servers, I prefer to save pages with the .html extension. All Web pages in this book are stored with the .html extension.
Enter .html in the Default Extension for New HTML Files (Prefix with '.') field to make this change, if you wish.
Changing the initial contents
When you create a new Web page in Aptana, a basic template appears. This is convenient, but it creates an HTML 4.0 doctype. Open template.html in a normal text editor, copy it, and paste it to the provided text area, and your pages will begin with the standard template.
Changing the view
Aptana allows you to split the screen with your code in one panel and a browser view in another. Every time you save your code, the browser view immediately updates. This is a really good tool, especially for a beginner, because you can get very quick feedback on how your page looks. In the HTML Editor Mode section in the Preferences dialog box (refer to Figure 3-9), you can indicate whether you want the browser preview to be in a separate tab, in a horizontal split screen, or in a vertical split screen. I use tabs because I like to see as much code as possible on-screen.
Aptana issues
I use Aptana quite a bit, and it’s one of my favorite tools. However, it isn’t perfect; it’s a large program that can take some time to load. I have also run into some display bugs here and there, and the debugging model doesn’t always seem to cooperate the way it should. Aptana is quite a good tool, but if these things bother you, you might want to look at the following alternative.
Introducing Komodo Edit
Komodo Edit is another very powerful Web editor (similar to Aptana) that may suit some developers more. Komodo doesn’t try to do everything that Aptana does, but it’s faster and a bit more reliable. Mainly a text editor, Komodo does have some great features. My favorite part about Komodo is how easy it is to modify.
♦ Abbreviations: Although many editors have features like this, the abbreviations tool in Komodo is especially useful. Komodo comes with a huge number of abbreviations built in, and a very easy mechanism to use them. For example, if you type xhtml and then press Ctrl-T, Komodo will replace the text with a complete XHTML framework. Creating new abbreviations is very easy, so you can quickly customize.
♦ Macros: I think one of Aptana’s biggest weaknesses is the clumsy macro features. Aptana doesn’t have an easy way to record keystroke commands and play them back. (To be fair, Aptana has an incredibly powerful scripting system, but it isn’t super easy to use.) Komodo has a really super macro-recording feature.
♦ Snippets: Komodo has a terrific built-in library of code snippets containing the code you frequently use. Adding new snippets is easy, so soon enough you’ll have most of the code you use a lot available at your fingertips.
♦ Commands: Komodo allows you to define commands you can run from within the editor. For example, you can create a DOS command to list all the files in the current directory and run the command without leaving Komodo. This can be useful if you’re writing code that creates files (as you do in Book V, Chapter 7). It’s also used to run external programs, such as compilers (if you were writing code in a language like C or Java that requires such things).
Figure 3-10 shows Komodo Edit being used to modify a Web page.
Figure 3-10: Komodo Edit has many of the same features as Aptana, but it’s a little smaller and snappier.
Chapter 4: Managing Information with Lists and Tables
In This Chapter
Understanding basic lists
Creating unordered, ordered, and nested lists
Building definition lists
Building basic tables
Using rowspan and colspan attributes
You’ll often need to present large amounts of organized information, and XHTML has some wonderful tools to manage this task. XHTML has three kinds of lists and a powerful table structure for organizing the content of your page. Figure out how these tools work, and you can manage complex information with ease.
Making a List and Checking It Twice
XHTML supports three types of lists. Unordered lists generally contain bullet points. They’re used when the order of elements in the list isn’t important. Ordered lists usually have some kind of numeric counter preceding each list item. Definition lists contain terms and their definitions.
Creating an unordered list
All the list types in XHTML are closely related. The simplest and most common kind of list is an unordered list.
Looking at an unordered list
Look at the simple page shown in Figure 4-1. In addition to a couple of headers, it has a list of information.
Figure 4-1:
An unordered list of Web browsers.
This list of browsers has some interesting visual characteristics:
♦ The items are indented. There’s some extra space between the left margin and the beginning of each list item.
♦ The list elements have bullet1s. That little dot in front of each item is a bullet1. bullet1s are commonly used in unordered lists like this one.
♦ Each item begins a new line. When a list item is displayed, it’s shown on a new line.
These characteristics help you see that you have a list, but they’re just default behaviors. Defining something as a list doesn’t force it to look a particular way; the defaults just help you see that these items are indeed part of a list.
Building an unordered list
Lists are made with two kinds of tags. One tag surrounds the entire list and indicates the general type of list. This first example demonstrates an unordered list, which is surrounded by the <ul></ul> pair.
Note: Indenting all the code inside the <ul> set is common. The unordered list can go in the main body.
Inside the <ul></ul> set is a number of list items. Each element of the list is stored between a <li> (list item) and a </li> tag. Normally, each <li></li> pair goes on its own line of the source code, although you can make a list item as long as you want.
The code for the unordered list is pretty straightforward:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>basicUL.html</title>
</head>
<body>
<h1>Basic Lists</h1>
<h2>Common Web Browsers</h2>
<ul>
<li>Firefox</li>
<li>Internet Explorer</li>
<li>Opera</li>
<li>Safari</li>
</ul>
</body>
</html>
Creating ordered lists
Ordered lists are almost exactly like unordered lists. Ordered lists traditionally have numbers rather than bullets (although you can change this through CSS if you want; see Book III, Chapter 3).
Viewing an ordered list
Figure 4-2 demonstrates a page with a basic ordered list — basicOL.html.
Figure 4-2:
A simple ordered list.
Figure 4-2 shows a list where the items are numbered. When your data is a list of steps or information with some type of numerical values, an ordered list is a good choice.
Building the ordered list
The code for basicOL.html is remarkably similar to the previous unordered list:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>basicOL.html</title>
</head>
<body>
<h1>Basic Ordered List</h1>
<h2>Top ten dog names in the USA</h2>
<ol>
<li>Max</li>
<li>Jake</li>
<li>Buddy</li>
<li>Maggie</li>
<li>Bear</li>
<li>Molly</li>
<li>Bailey</li>
<li>Shadow</li>
<li>Sam</li>
<li>Lady</li>
</ol>
<p>
data from http://www.bowwow.com.au
</p>
</body>
</html>
The only change is the list tag itself. Rather than the <ul> tag, the ordered list uses the <ol> indicator. The list items are the same <li></li> pairs used in the unordered list.
You don’t indicate the item number anywhere; it generates automatically based on the position of each item within the list. Therefore, you can change the order of the items, and the numbers are still correct.
Making nested lists
Sometimes, you’ll want to create outlines or other kinds of complex data in your pages. You can easily nest lists inside each other, if you want. Figure 4-3 shows a more complex list describing popular cat names in the U.S. and Australia.
Figure 4-3:
An ordered list inside an unordered list!
Figure 4-3 uses a combination of lists to do its work. This figure contains a list of two countries: the U.S. and Australia. Each country has an H3 heading and another (ordered) list inside it. You can nest various elements inside a list, but you have to do it carefully if you want the page to validate.
In this example, there’s an unordered list with only two elements. Each of these elements contains an <h3> heading and an ordered list. The page handles all this data in a relatively clean way and validates correctly.
Examining the nested list example
The entire code for nestedList.html is reproduced here:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>nestedList.html</title>
</head>
<body>
<h1>Nested Lists</h1>
<h2>Popular Cat Names</h2>
<ul>
<li>
<h3>USA</h3>
<ol>
<li>Tigger</li>
<li>Tiger</li>
<li>Max</li>
<li>Smokey</li>
<li>Sam</li>
</ol>
</li>
<li>
<h3>Australia</h3>
<ol>
<li>Oscar</li>
<li>Max</li>
<li>Tiger</li>
<li>Sam</li>
<li>Misty</li>
</ol>
</li>
</ul>
</body>
</html>
Here are a few things you might notice in this code listing:
♦ There’s a large <ul> set surrounding the entire main list.
♦ The main list has only two list items.
♦ Each of these items represents a country.
♦ Each country has an <h3> element, describing the country name inside the <li>.
♦ Each country also has an <ol> set with a list of names.
♦ The indentation really helps you see how things are connected.
Indenting your code
You might have noticed that I indent all the XHTML code in this book. The browsers ignore all indentation, but it’s still an important coding habit.
There are many opinions about how code should be formatted, but the standard format I use in this book will serve you well until you develop your own style.
Generally, I use the following rules to indent HTML/XHTML code:
♦ Indent each nested element. Because the <head> tag is inside the <html> element, I indent to indicate this. Likewise, the <li> elements are always indented inside <ul> or <ol> pairs.
♦ Line up your elements. If an element takes up more than one line, line up the ending tag with the beginning tag. This way, you know what ends what.
♦ Use spaces, not tabs. The tab character often causes problems in source code. Different editors format tabs differently, and a mixture of tabs and spaces can make your carefully formatted page look awful when you view it in another editor.
♦ Use two spaces. Most coders use two or four spaces per indentation level. HTML elements can be nested pretty deeply. Going seven or eight layers deep is common. If you use tabs or too many spaces, you’ll have so much white space that you can’t see the code.
♦ End at the left margin. If you finish the page and you’re not back at the left margin, you’ve forgotten to end something. Proper indentation makes seeing your page organization easy. Each element should line up with its closing tag.
Building a nested list
When you look over the code for the nested list, it can look intimidating, but it isn’t really that hard. The secret is to build the list outside in:
1. Create the outer list first.
Build the primary list (whether it’s ordered or unordered). In my example, I began with just the unordered list with the two countries in it.
2. Add list items to the outer list.
If you want text or headlines in the larger list (as I did), you can put them here. If you’re putting nothing but a list inside your primary list, you may want to put some placeholder <li> tags in there just so you can be sure everything’s working.
3. Validate before adding the next list level.
Nested lists can confuse the validator (and you). Validate your code with the outer list to make sure there are no problems before you add inner lists.
4. Add the first inner list.
After you know the basic structure is okay, add the first interior list. For my example, this was the ordered list of cat names in the U.S.
5. Repeat until finished.
Keep adding lists until your page looks right.
6. Validate frequently.
It’s much better to validate while you go than to wait until everything’s finished. Catch your mistakes early so you don’t replicate them.
Building the definition list
One more type of list — the definition list — is very useful, even if it’s used infrequently. The definition list was originally designed to format dictionary-style definitions, but it’s really useful any time you have name and value pairs. Figure 4-4 shows a sample definition list in action.
Figure 4-4:
A basic definition list.
Definition lists don’t use bullets or numbers. Instead, they have two elements. Definition terms are usually words or short phrases. In Figure 4-4, the browser names are defined as definition terms. Definition descriptions are the extended text blocks that contain the actual definition.
The standard layout of definition lists indents each definition description. Of course, you can change the layout to what you want after you understand the CSS in Books II and III.
You can use definition lists any time you want a list marked by key terms, rather than bullets or numbers. The definition list can also be useful in other situations, such as forms, figures with captions, and so on.
Here’s the code for basicDL.html:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>BasicDL.html</title>
</head>
<body>
<h1>Basic Definition List</h1>
<h2>Common Web Browsers</h2>
<dl>
<dt>Mosaic</dt>
<dd>
The mother of all modern browsers. The first widely used
visual browser.
</dd>
<dt>Netscape</dt>
<dd>
The commercial successor to Mosaic. Widely popular, but
eventually eclipsed by Internet Explorer
</dd>
<dt>IE</dt>
<dd>
Microsoft’s entry into the browser market, and a dominant
player.
</dd>
<dt>Firefox</dt>
<dd>
An open-source browser that has shaken up the world.
</dd>
</dl>
</body>
</html>
As you can see, the definition list uses three tag pairs:
♦ <dl></dl> defines the entire list.
♦ <dt></dt> defines each definition term.
♦ <dd></dd> defines the definition data.
Definition lists aren’t used often, but they can be extremely useful. Any time you have a list that will be a combination of terms and values, a definition list is a good choice.
Building Tables
Sometimes, you’ll encounter data that fits best in a tabular format. XHTML supports several table tags for this kind of work. Figure 4-5 illustrates a very basic table.
Figure 4-5: Tables are useful for some data representa-tion.
Sometimes, the best way to show data in a meaningful way is to organize it in a table. XHTML defines a table with the (cleverly named) <table> tag. The table contains a number of table rows (defined with the <tr> tag). Each table row can consist of a number of table data (<td>) or table header (<th>) tags.
Compare the output in Figure 4-5 with the code for basicTable.html that creates it:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>basicTable.html</title>
</head>
<body>
<h1>A Basic Table</h1>
<h2>XHTML Super Heroes</h2>
<table border = “1“>
<tr>
<th>Hero</th>
<th>Power</th>
<th>Nemesis</th>
</tr>
<tr>
<td>The XMLator</td>
<td>Standards compliance</td>
<td>Sloppy Code Boy</td>
</tr>
<tr>
<td>Captain CSS</td>
<td>Super-layout</td>
<td>Lord Deprecated</td>
</tr>
<tr>
<td>Browser Woman</td>
<td>Mega-Compatibility</td>
<td>Ugly Code Monster</td>
</tr>
</table>
</body>
</html>
Defining the table
The XHTML table is defined with the <table></table> pair. It makes a lot of sense to indent and space your code carefully so you can see the structure of the table in the code. Just by glancing at the code, you can guess that the table consists of three rows and each row consists of three elements.
In a word processor, you typically create a blank table by defining the number of rows and columns, and then fill it in. In XHTML, you define the table row by row, and the elements in each row determine the number of columns. It’s up to you to make sure each row has the same number of elements.
By default (in most browsers, anyway), tables don’t show their borders. If you want to see basic table borders, you can turn on the table’s border attribute. (An attribute is a special modifier you can attach to some tags.)
<table border = “1”>
This tag creates a table and specifies that it will have a border of size 1. If you leave out the border = “1” business, some browsers display a border and some don’t. You can set the border value to 0 or to a larger number. The larger number makes a bigger border, as shown in Figure 4-6.
Figure 4-6:
I set the border attribute to 10.
Adding your first row
After you define a table, you need to add some rows. Each row is indicated by a <tr></tr> pair.
Inside the <tr></tr> set, you need some table data. The first row often consists of table headers. These special cells are formatted differently to indicate that they’re labels, rather than data.
Indent your headers inside the <tr> set. If your table contains three columns, your first row might begin like this:
<tr>
<th></th>
<th></th>
<th></th>
</tr>
Place the text you want shown in the table headers between the <th> and </th> elements. The contents appear in the order they’re defined.
Making your data rows
The next step is to create another row. The data rows are just like the heading row, except they use <td></td> pairs, rather than <th></th> pairs, to contain the data elements. Typically, a three-column table has blank rows that look like this:
<tr>
<td></td>
<td></td>
<td></td>
</tr>
Place the data elements inside the <td></td> segments and you’re ready to go.
Building tables in the text editor
Some people think that tables are a good reason to use WYSIWYG (what you see is what you get) editors because they think it’s hard to create tables in text mode. You have to plan a little, but it’s really quite quick and easy to build an HTML table without graphical tools if you follow this plan:
1. Plan ahead.
Know how many rows and columns will be in the table. Sketch it on paper first might be helpful. Changing the number of rows later is easy, but changing the number of columns can be a real pain after some of the code has been written.
2. Create the headings.
If you’re going to start with a standard headings-on-top table, begin by creating the heading row. Save, check, and validate. You don’t want mistakes to multiply when you add more complexity. This heading row tells how many columns you’ll need.
3. Build a sample empty row.
Make a sample row with the correct number of td elements with one <td></td> pair per line. Build one td set and use copy and paste to copy this data cell as many times as you need. Make sure the number of <td> pairs equals the number of <th> sets in the heading row.
4. Copy and paste the empty row to make as many rows as you need.
5. Save, view, and validate.
Be sure everything looks right and validates properly before you put a lot of effort into adding data.
6. Populate the table with the data you need.
Go row by row, adding the data between the <td></td> pairs.
7. Test and validate again to make sure you didn’t accidentally break something.
Spanning rows and columns
Sometimes, you need a little more flexibility in your table design. Figure 4-7 shows a page from an evil overlord’s daily planner.
Figure 4-7: Some activities take up more than one cell.
Being an evil overlord is clearly a complex business. From a code standpoint, the items that take up more than one cell are the most interesting. Designing traps takes two mornings, and improving the lair takes three. All Friday afternoon and evening are spent on world domination. Take a look at the code, and you’ll see how it works:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>tableSpan.html</title>
</head>
<body>
<h1>Using colspan and rowspan</h1>
<table border = “1“>
<caption>My Schedule</caption>
<tr>
<th></th>
<th>Monday</th>
<th>Tuesday</th>
<th>Wednesday</th>
<th>Thursday</th>
<th>Friday</th>
</tr>
<tr>
<th>Breakfast</th>
<td>In lair</td>
<td>with cronies</td>
<td>In lair</td>
<td>in lair</td>
<td>in lair</td>
</tr>
<tr>
<th>Morning</th>
<td colspan = “2“>Design traps</td>
<td colspan = “3“>Improve Hideout</td>
</tr>
<tr>
<th>Afternoon</th>
<td>train minions</td>
<td>train minions</td>
<td>train minions</td>
<td>train minions</td>
<td rowspan = “2“>world domination</td>
</tr>
<tr>
<th>Evening</th>
<td>maniacal laughter</td>
<td>maniacal laughter</td>
<td>maniacal laughter</td>
<td>maniacal laughter</td>
</tr>
</table>
</body>
</html>
The secret to making cells larger than the default is two special attributes: rowspan and colspan.
Spanning multiple columns
The morning activities tend to happen over several days. Designing traps will take both Monday and Tuesday morning, and improving the hideout will occupy the remaining three mornings. Take another look at the Morning row; here’s how this is done:
<tr>
<th>Morning</th>
<td colspan = “2”>Design traps</td>
<td colspan = “3”>Improve Hideout</td>
</tr>
The Design Traps cell spans over two normal columns. The colspan attribute tells how many columns this cell will take. The Improve Hideout cell has a colspan of 3.
The Morning row still takes up six columns. The <th> is one column wide, like normal, but the Design Traps cell spans two columns and the Improve Hideout cell takes three, which totals six columns wide. If you increase the width of a cell, you need to eliminate some other cells in the row to compensate.
Spanning multiple rows
A related property — rowspan — allows a cell to take up more than one row of a table. Look back at the Friday column in Figure 4-7, and you’ll see the World Domination cell takes up two time slots. (If world domination was easy, everybody would do it.) Here’s the relevant code:
<tr>
<th>Afternoon</th>
<td>train minions</td>
<td>train minions</td>
<td>train minions</td>
<td>train minions</td>
<td rowspan = “2“>world domination</td>
</tr>
<tr>
<th>Evening</th>
<td>maniacal laughter</td>
<td>maniacal laughter</td>
<td>maniacal laughter</td>
<td>maniacal laughter</td>
</tr>
The Evening row has only five entries because the World Domination cell extends into the space that would normally be occupied by a <td> pair.
Avoiding the table-based layout trap
Tables are pretty great. They’re a terrific way to present certain kinds of data. When you add the colspan and rowspan concepts, you can use tables to create some pretty interesting layouts. In fact, because old-school HTML didn’t really have any sort of layout technology, a lot of developers came up with some pretty amazing layouts based on tables. You still see a lot of Web pages today designed with tables as the primary layout mechanism.
Using tables for layout causes some problems though, such as
♦ Tables aren’t meant for layout. Tables are designed for data presentation, not layout. To make tables work for layout, you have to do a lot of sneaky hacks, such as tables nested inside other tables or invisible images for spacing.
♦ The code becomes complicated fast. Tables involve a lot of HTML markup. If the code involves tables nested inside each other, it’s very difficult to remember which <td> element is related to which row of which table. Table-based layouts are very difficult to modify by hand.
♦ Formatting is done cell by cell. A Web page could be composed of hundreds of table cells. Making a change in the font or color often involves making changes in hundreds of cells throughout the page. This makes your page less flexible and harder to update.
♦ Presentation is tied tightly to data. A table-based layout tightly intertwines the data and its presentation. This runs counter to a primary goal of Web design — separation of data from its presentation.
♦ Table-based layouts are hard to change. After you create a layout based on tables, it’s very difficult to make modifications because all the table cells have a potential effect on other cells.
♦ Table-based layouts cause problems for screen-readers. People with visual disabilities use special software to read Web pages. These screen-readers are well adapted to read tables as they were intended (to manage tabular data), but the screen-readers have no way of knowing when the table is being used as a layout technique rather than a data presentation tool. This makes table-based layouts less compliant to accessibility standards.
Resist the temptation to use tables for layout. Use tables to do what they’re designed for: data presentation. Book III is entirely about how to use CSS to generate any kind of visual layout you might want. The CSS-based approaches are easier, more dependable, and much more flexible.
Chapter 5: Making Connections with Links
In This Chapter
Understanding hyperlinks
Building the anchor tag
Recognizing absolute and relative links
Building internal links
Creating lists of links
The basic concept of the hyperlink is common today, but it was a major breakthrough back in the day. The idea is still pretty phenomenal, if you think about it: When you click a certain piece of text (or a designated image, for that matter), your browser is instantly transported somewhere else. The new destination might be on the same computer as the initial page, or it could be literally anywhere in the world.
Any page is theoretically a threshold to any other page, and all information has the ability to be linked. This is still a profound idea. In this chapter, you discover how to add links to your pages.
Making Your Text Hyper
The hyperlink is truly a wonderful thing. Believe it or not, there was a time when you had to manually type in the address of the Web page you wanted to go to. Not so anymore. Figure 5-1 illustrates a page that describes some of my favorite Web sites.
In Figure 5-1, the underlined words are hyperlinks. Clicking a hyperlink takes you to the indicated Web site. Although this is undoubtedly familiar to you as a Web user, a few details are necessary to make this mechanism work:
♦ Something must be linkable. Some text or other element must provide a trigger for the linking behavior.
♦ Things that are links should look like links. This is actually easy to do when you write plain XHTML because all links have a standard (if ugly) appearance. Links are usually underlined blue text. When you can create color schemes, you may no longer want links to look like the default appearance, but they should still be recognizable as links.
♦ The browser needs to know where to go. When the user clicks the link, the browser is sent to some address somewhere on the Internet. Sometimes that address is visible on the page, but it doesn’t need to be.
♦ It should be possible to integrate links into text. In this example, each link is part of a sentence. It should be possible to make some things act like links without necessarily standing on their own (like heading tags do).
♦ The link’s appearance sometimes changes. Links sometimes begin as blue underlined text, but after a link has been visited, the link is shown in purple, instead. After you know CSS, you can change this behavior.
Figure 5-1: You can click the links to visit the other sites.
Introducing the anchor tag
The key to hypertext is an oddly named tag called the anchor tag. This tag is encased in an <a></a> set of tags and contains all the information needed to manage links between pages.
The code for the basicLinks.html page is shown here:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=“EN“ dir=“ltr“ xmlns=“http://www.w3.org/1999/xhtml“>
<head>
<meta http-equiv=”content-type” content=”text/xml; charset=utf-8” />
<title>basicLinks.html</title>
</head>
<body>
<h1>Some of my favorite sites</h1>
<h2>Wikipedia</h2>
<p>
One of my favorite Web sites is called
<a href = “http://www.wikipedia.org”>wikipedia.</a>
This terrific site allows ordinary users to enter
encyclopedia definitions. Over time, the entries
can be as reliable as a commercial encyclopedia,
and a lot more complete.
</p>
<h2>Dummies</h2>
<p>
You can find out a lot about upcoming and current
Dummies books at <a href = “http://www.dummies.com”>
www.dummies.com</a>. You might even find this
book mentioned there.
</p>
<h2>PopURLS</h2>
<p>
Web 2.0 is all about social networking. If you want
to know what’s happening on the Internet today,
check out <a href = “http://popurls.com”>
popurls.com</a>. This site aggregates a bunch of
social networking sites.
</p>
</body>
</html>
As you can see, the anchor tag is embedded into paragraphs. The text generally flows around an anchor, and you can see the anchor code is embedded inside the paragraphs.
Comparing block-level and inline elements
All the tags described so far in this book have been block-level tags. Block-level tags typically begin and end with carriage returns. For example, three <h1> tags occupy three lines. Each <p></p> set has implied space above and below it. Most XHTML tags are block-level.
Some tags are meant to be embedded inside block-level tags and don’t interrupt the flow of the text. The anchor tag is one such tag. Anchors never stand on their own in the HTML body. This type of tag is an inline tag. They’re meant to be embedded inside block-level tags, such as list items, paragraphs, and headings.
Analyzing an anchor
The first link shows all the main parts of an anchor in a pretty straightforward way:
<a href = “http://www.wikipedia.org”>wikipedia.</a>
♦ The anchor tag itself: The anchor tag is simply the <a></a> pair. You don’t type the entire word anchor, just the a.
♦ The hypertext reference (href) attribute: Almost all anchors contain this attribute. It’s very rare to write <a without href. The href attribute indicates a Web address will follow.
♦ A Web address in quotes: The address that the browser will follow is encased in quotes. See the next section in this chapter for more information on Web addresses. In this example, http://www.wikipedia.org is the address.
♦ The text that appears as a link: The user will typically expect to click specially formatted text. Any text that appears between the <a href> part and the </a> part is visible on the page and formatted as a link. In this example, the word wikipedia is the linked text.
♦ The </a> marker: This marker indicates that the text link is finished.
Introducing URLs
The special link addresses are a very important part of the Web. You probably already type Web addresses into the address bar of your browser (http://www.google.com), but you may not be completely aware of how they work. Web addresses are technically URLs (Uniform Resource Locators), and they have a very specific format.
A URL usually contains the following parts:
♦ Protocol: A Web protocol is a standardized agreement on how communication occurs. The Web primarily uses HTTP (hypertext transfer protocol), but occasionally, you encounter others. Most addresses begin with http:// because this is the standard on the Web. Protocols usually end with a colon and two slashes (://).
♦ Host name: It’s traditional to name your primary Web server www. There’s no requirement for this, but it’s common enough that users expect to type www right after the http:// stuff. Regardless, the text right after http:// (and up to the first period) is the name of the actual computer you’re linking to.
♦ Domain name: The last two or three characters indicate a particular type of Web server. These letters can indicate useful information about the type of organization that houses the page. Three-letter domains usually indicate the type of organization, and two-letter domains indicate a country. Sometimes, you’ll even see a combination of the two. See Table 5-1 for a list of common domain names.
♦ Subdomain: Everything between the host name (usually www) and the domain name (often .com) is the subdomain. This is used so that large organizations can have multiple servers on the same domain. For example, my department Web page is http://www.cs.iupui.edu. www is the name of the primary server, and this is the computer science department at IUPUI (Indiana University–Purdue University Indianapolis), which is an educational organization.
♦ Page name: Sometimes, an address specifies a particular document on the Web. This page name follows the address and usually ends with .html. Sometimes, the page name includes subdirectories and username information, as well. For example, my Web design course is in the N241 directory of my (aharris) space at IUPUI, so the page’s full address is http://www.cs.iupui.edu/~aharris/n241/index.html.
♦ Username: Some Web servers are set up with multiple users. Sometimes, an address will indicate a specific user’s account with a tilde (~) character. My address has ~aharris in it to indicate the page is found in my (aharris) account on the machine.
Table 5-1 Common Domain Names | |
| Domain | Explanation |
| .org | Non-profit institution |
| .com | Commercial enterprise |
| .edu | Educational institution |
| .gov | Governing body |
| .ca | Canada |
| .uk | United Kingdom |
| .tv | Tuvali |
Making Lists of Links
Many Web pages turn out to be lists of links. Because lists and links go so well together, it’s good to look at an example. Figure 5-2 illustrates a list of links to books written by a certain (cough) devilishly handsome author.
Figure 5-2: Putting links in a list is common.
This example has no new code to figure out, but the page shows some interesting components:
♦ The list: An ordinary unordered list.
♦ Links: Each list item contains a link. The link has a reference (which you can’t see immediately) and linkable text (which is marked like an ordinary link).
♦ Descriptive text: After each link is some ordinary text that describes the link. Writing some text to accompany the actual link is very common.
This code shows the way the page is organized:
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>listLinks.html</title>
</head>
<body>
<h1>Some nice programming books</h1>
<ul>
<li><a href = “http://www.aharrisbooks.net/xfd_2ed“>
HTML / XHTML / CSS AIO for Dummies</a>
A complete resource to web development</li>
<li><a href = “http://www.aharrisbooks.net/jad“>
JavaScript / AJAX for Dummies</a>
Using JavaScript, AJAX, and jQuery</li>
<li><a href=“http://www.aharrisbooks.net/pythonGame“>
Game Programming - the L Line</a>
Game development in Python</li>
<li><a href=“http://www.aharrisbooks.net/flash“>
Flash Game Programming for Dummies</a>
Game development using Flash</li>
</ul>
</body>
</html>
The indentation is interesting here. Each list item contains an anchor and some descriptive text. To keep the code organized, Web developers tend to place the anchor inside the list item. The address sometimes goes on a new line if it’s long, with the anchor text on a new line and the description on succeeding lines. I normally put the <li> tag at the end of the last line, so the beginning <li> tags look like the bullets of an unordered list. This makes it easier to find your place when editing a list later.
Working with Absolute and Relative References
There’s more than one kind of address. So far, you’ve seen only absolute references, used for links to outside pages. Another kind of reference — a relative reference — links multiple pages inside your own Web site.
Understanding absolute references
The type of link used in basicLinks.html is an absolute reference. Absolute references always begin with the protocol name (usually http://). An absolute reference is the complete address to a Web page, just as you’d use in the browser’s address bar. Absolute references are used to refer to a site somewhere else on the Internet. Even if your Web site moves (say, from your desktop machine to a Web server somewhere on the Internet), all the absolute references will work fine because they don’t rely on the current page’s position for any information.
Introducing relative references
Relative references are used when your Web site includes more than one page. You might choose to have several pages and a link mechanism for moving among them. Figure 5-3 shows a page with several links on it.
Figure 5-3: These little piggies sure get around.
The page isn’t so interesting on its own, but it isn’t meant to stand alone. When you click one of the links, you go to a brand-new page. Figure 5-4 shows what happens when you click the market link.
Figure 5-4: The market page lets you move back.
The market page is pretty simple, but it also contains a link back to the initial page. Most Web sites aren’t single pages at all, but an interconnected web of pages. The relative reference is very useful when you have a set of pages with interlacing links.
The code for pigs.html shows how relative references work:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>pigs.html</title>
</head>
<body>
<h1>Destinations of Porcine Mammals</h1>
<ul>
<li>This little pig went to
<a href = “market.html“>market</a></li>
<li>This little pig stayed
<a href = “home.html“>home</a>.</li>
<li>This little pig had
<a href = “roastBeef.html“>roast beef</a></li>
<li>This little pig had
<a href = “none.html“>none</a>.</li>
<li>This little pig went
<a href = “wee.html“>’wee wee wee’</a>
all the way home.</li>
</ul>
</body>
</html>
Most of the code is completely familiar. The only thing surprising is what’s not there. Take a closer look at one of the links:
<a href = “market.html”>home</a>.</li>
There’s no protocol (the http:// part) and no address at all, just a filename. This is a relative reference. Relative references work by assuming the address of the current page. When the user clicks market.html, the browser sees no protocol, so it assumes that market.html is in the same directory on the same server as pigs.html.
Relative references work like directions. For example, if you’re in my lab and ask where the water fountain is, I’d say, “Go out into the hallway, turn left, and turn left again at the end of the next hallway.” Those directions get you to the water fountain if you start in the right place. If you’re somewhere else and you follow the same directions, you don’t really know where you’ll end up.
Relative references work well when you have a bunch of interconnected Web pages. If you create a lot of pages about the same topic and put them in the same directory, you can use relative references between the pages. If you decide to move your pages to another server, all the links still work correctly.
If you’re referring to a page on somebody else’s site, you have to use an absolute reference. If you’re linking to another page on your site, you typically use a relative reference.
Chapter 6: Adding Images
In This Chapter
Understanding the main uses of images
Choosing an image format
Creating inline images
Using IrfanView and other image software
Changing image sizes
Modifying images with filters
You have the basics of text, but pages without images are . . . well, a little boring. Pictures do a lot for a Web page, and they’re not that hard to work with. Still, you should know some things about using pictures in your pages. In this chapter, you get all the fundamentals of adding images to your pages.
Adding Images to Your Pages
Every time you explore the Web, you’re bound to run into tons of pictures on just about every page you visit. Typically, images are used in four ways on Web pages:
♦ External link: The page has text with a link embedded in it. When the user clicks the link, the image replaces the page in the Web browser. To make an externally linked image, just make an ordinary link (as I describe in Chapter 5 of this minibook) but point toward an image file, rather than an HTML (HyperText Markup Language) file.
♦ Embedded images: The image is embedded into the page. The text of the page usually flows around the image. This is the most common type of image used on the Web.
♦ Background images: An image can be used as a background for the entire page or for a specific part of the page. Images usually require some special manipulation to make them suitable for background use.
♦ Custom bullets: With CSS, you can assign a small image to be a bullet for an ordered or unordered list. This allows you to make any kind of customized list markers you can draw.
The techniques you read about in this chapter apply to all type of images, but a couple of specific applications (such as backgrounds and bullets) use CSS. For details on using images in CSS, see Book II, Chapter 4.
Adding links to images
The easiest way to incorporate images is to link to them. Figure 6-1 shows the externalImage.html page.
The page’s code isn’t much more than a simple link:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>externalImage.html</title>
</head>
<body>
<h1>Linking to an External Image</h1>
<p>
<a href = “shipStandard.jpg“>
Susan B. Constant
</a>
</p>
</body>
</html>
Figure 6-1: This page has a link to an image.
The href points to an image file, not an HTML page. You can point to any type of file you want in an anchor tag. If the browser knows the file type (for example, HTML and standard image formats), the browser displays the file. If the browser doesn’t know the file format, the user’s computer tries to display the file using whatever program it normally uses to open that type of file.
This works fine for most images because the image is displayed directly in the browser.
Most browsers automatically resize the image to fit the browser size. This means a large image may appear to be smaller than it really is, but the user still has to wait for the entire image to download.
Because this is a relative reference, the indicated image must be in the same directory as the HTML file. When the user clicks the link, the page is replaced by the image, as shown in Figure 6-2.
Figure 6-2: The image appears in place of the page.
External links are easy to create, but they have some problems:
♦ They don’t preview the image. The user has only the text description to figure out what the picture might be.
♦ They interrupt the flow. If the page contains a series of images, the user has to keep leaving the page to view images.
♦ The user must back up to return to the main page. The image looks like a Web page, but it isn’t. No link or other explanatory text in the image indicates how to get back to the Web page. Most users know to click the browser’s Back button, but don’t assume all users know what to do.
Adding inline images using the <img> tag
The alternative to providing links to images is to embed your images into the page. Figure 6-3 displays an example of this technique.
The code shows how this image was included into the page:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>embeddedImage.html</title>
</head>
<body>
<h1>The Susan B. Constant</h1>
<p>
<img src = “shipStandard.jpg“
height = “480“
width = “640“
alt = “Susan B. Constant“ />
</p>
<p>
The <em>Susan B. Constant</em> was flagship of the
fleet of three small ships that brought settlers to Jamestown, the first
successful English Colony in the new world. This is a replica housed
near Jamestown, Virginia.
</p>
</body>
</html>
The image (img) tag is the star of this page. This tag allows you to grab an image file and incorporate it into the page directly. The image tag is a one-shot tag. It doesn’t end with </img>. Instead, use the /> characters at the end of the img definition to indicate that this tag doesn’t have content.
Figure 6-3: The ship image is embedded into the page.
The image tag has a number of important attributes, which I discuss in the following sections.
src (source)
The src attribute allows you to indicate the URL (Uniform Resource Locator) of the image. This can be an absolute or relative reference. Linking to an image in your own directory structure is generally best because you can’t be sure an external image will still be there when the user gets to the page. (For more on reference types, turn to Chapter 5 of this minibook.)
height and width
The height and width attributes are used to indicate the size of the image. The browser uses this information to indicate how much space to reserve on the page.
alt (alternate text)
The alt attribute gives you an opportunity to specify alternate text describing the image. Alternate text information is used when the user has images turned off and by screen-readers. Internet Explorer (IE) automatically creates a ToolTip (floating text) based on the alternate text.
Additionally, the <img> tag is an inline tag, so it needs to be embedded inside a block-level tag, like a <p> or <li>.
Choosing an Image Manipulation Tool
You can’t just grab any old picture off your digital camera and expect it to work on a Web page. The picture might work, but it could cause problems for your viewers. It’s important to understand that digital images (any kind of images you see on a computer or similar device) are different from the kind of images you see on paper.
An image is worth 3.4 million words!
Digital cameras and scanners are amazing these days. Even moderately priced cameras can now approach the resolution of old-school analog cameras. Scanners are also capable of taking traditional images and converting them into digital formats that computers use. In both cases, though, the default image can be in a format that causes problems. Digital images are stored as a series of dots, or pixels. In print, the dots are very close together, but computer screens have larger dots. Figure 6-4 shows how the ship image looks straight from the digital camera.
My camera handles pictures at 6 megapixels (MP). That’s a pretty good resolution, and it sounds very good in the electronics store. If I print that picture on paper, all those dots are very tiny, and I get a nice picture. If I try to show the same picture on the computer screen, I see only one corner. This actual picture came out at 2,816 pixels wide by 2,112 pixels tall. You only see a small corner of the image because the screen shots for this book are taken at 1024 x 768 pixels. Less than a quarter of the image is visible.
Figure 6-4: Wow. That doesn’t look like much.
When you look at a large image in most browsers, it’s automatically resized to fit the page. The cursor usually turns into some kind of magnifying glass, and if you click the image, you can see it in its full size or the smaller size.
Although shrinking an image so that it’s completely visible is obvious, there’s an even more compelling reason to do so. Each pixel on the screen requires 3 bytes of computer memory. (A byte is the basic unit of memory in a computer.) For comparison purposes, one character of text requires roughly 1 byte. The uncompressed image of the ship weighs a whopping 17 megabytes (MB). If you think of a word as five characters long, one picture straight from the digital camera takes up the same amount of storage space and transmission time as roughly 3,400,000 words. This image requires nearly three minutes to download on a 56K modem!
In a Web page, small images are often shown at about 320 x 240 pixels, and larger images are often 640 x 480 pixels. If I use software to resample the image to the size I actually need and use an appropriate compression algorithm, I can get the image to look like Figure 6-5.
Figure 6-5: The resized image is a lot more manageable.
The new version of the image is the size and file format I need, it looks just as good, and it weighs a much more reasonable 88 kilobytes. That’s 2 percent of the original image size.
Images are great, but keep some things in mind when you use them:
♦ Make sure the images are worth displaying. Don’t use a picture without some good reason because each picture makes your page dramatically slower to access.
♦ Use software to resize your image. Later in this chapter, I show you how to use free software to change the image to exactly the size you need.
♦ Use a compressed format. Images are almost never used in their native format on the Web because they’re just too large. Several formats have emerged that are useful for working with various types of images. I describe these formats in the section “Choosing an Image Format,” later in this chapter.
Introducing IrfanView
IrfanView, by Irfan Skiljan, is a freeware program that can handle your basic image manipulation needs and quite a bit more. I used it for all the screenshots in this book, and I use it as my primary image viewer. A copy is included on the CD-ROM that accompanies this book, or you can get a copy at www.irfanview.net. Of course, you can use any software you want, but if something’s really good and free, it’s a great place to start. In the rest of this chapter, I show you how to do the main image-processing jobs with IrfanView, but you can use any image editor you want.
A Web developer needs to have an image manipulation program to help with all these chores. Like other Web development tools, you can pay quite a bit for an image manipulation tool, but you don’t have to. Your image tool should have at least the following capabilities:
♦ Resizing: Web pages require smaller images than printing on paper. You need a tool that allows you to resize your image to a specific size for Web display.
♦ Saving to different formats: There’s a dizzying number of image formats available, but only three formats work reliably on the Web (which I discuss in the next section). You need a tool that can take images in a wide variety of formats and reliably switch it to a Web-friendly format.
♦ Cropping: You may want only a small part of the original picture. A cropping tool allows you to extract a rectangular region from an image.
♦ Filters: You may find it necessary to modify your image in some way. You may want to reduce red-eye, lighten or darken your image, or adjust the colors. Sometimes, images can be improved with sharpen or blur filters, or more artistic filters, such as canvas or oil-painting tools.
♦ Batch processing: You may have a number of images you want to work with at one time. A batch processing utility can perform an operation on a large number of images at once, as you see later in this chapter.
You may want some other capabilities, too, such as the ability to make composite images, images with transparency, and more powerful effects. You can use commercial tools or the excellent open-source program Gimp, which is included on this book’s CD-ROM. This chapter focuses on IrfanView because it’s simpler, but investigate Gimp (or its cousin GimpShop, for people used to Photoshop) for a more complete and even more powerful tool. I use IrfanView for basic processing, and I use Gimp when I need a little more power. See Book VIII, Chapter 4 for a more complete discussion of Gimp.
Here are a few free alternatives if you want some other great software to try:
♦ XnView: Similar to IrfanView, allows you to preview and modify pictures in hundreds of formats, create thumbnails, and more. It’s available for Mac and Linux. (IrfanView is Windows-only.)
♦ Pixia: A full-blown graphic editor from Japan. Very powerful.
♦ GimpShop: A version of Gimp modified to have menus like Photoshop.
♦ Paint.net: A powerful Windows-only paint program.
Use Google or another search engine to locate any of these programs.
Choosing an Image Format
Almost nobody uses raw images on the Web because they’re just too big and unwieldy. Usually, Web images are compressed to take up less space. All the types of image files you see in the computer world (BMP, JPG, GIF, and so on) are essentially different ways to make an image file smaller. Not all the formats work on the Web, and they have different characteristics, so it’s good to know a little more about them.
BMP
The BMP format is Microsoft’s standard image format. Although it’s compressed sometimes, usually it isn’t. The BMP format creates very detailed images with little to no compression, and the file is often too large to use on the Web. Many Web browsers can handle BMP images, but you shouldn’t use them. Convert to one of the other formats, instead.
JPG/JPEG
The JPG format (also called JPEG) is a relatively old format designed by the Joint Photographic Experts Group. (Get it? JPEG!) It works by throwing away data that’s less important to human perception. Every time you save an image in the JPG format, you lose a little information. This sounds terrible, but it really isn’t. The same image that came up as 13MB in its raw format is squeezed down to 1.5MB when stored as a JPG. Most people can’t tell the difference between the compressed and non-compressed version of the image by looking at them.
JPG works best on photographic-style images with a lot of color and detail. Many digital cameras save images directly as JPGs.
One part of the JPG process allows you to determine the amount of compression. When you save an image as a JPG, you can often determine the quality on a scale between accuracy and compression.
The JPG compression scheme causes some particular problems with text. JPG is not good at preserving sharp areas of high contrast (such as letters on a background). JPG is not the best format for banner images or other images with text on them. Use GIF or PNG instead.
Even if you choose 100 percent accuracy, the file is still greatly compressed. The adjustable compression operates only on a small part of the process. Compressing the file too much can cause visible square shadows, or artifacts. Experiment with your images to see how much compression they can take and still look like the original.
GIF
The GIF format was developed originally for CompuServe, way before the Web was invented. This format was a breakthrough in its time and still has some great characteristics.
GIF is a lossless algorithm so, potentially, no data is lost when converting an image to GIF (compare that to the lossy JPG format). GIF does its magic with a color palette trick and a run-length encoding trick.
The color palette works like a paint-by-number set where an image has a series of numbers printed on it, and each of the paint colors has a corresponding number. What happens in a GIF image is similar. GIF images have a list of 256 colors, automatically chosen from the image. Each of the colors is given a number. A raw (uncompressed) image requires 3 bytes of information for each pixel (1 each to determine the amount of red, green, and blue). In a GIF image, all that information is stored one time in the color palette. The image itself contains a bunch of references to the color palette.
For example, if blue is stored as color 1 in the palette, a strip of blue might look like this:
1, 1, 1, 1, 1, 1, 1, 1, 1, 1
GIF uses its other trick — run-length encoding — when it sees a list of identical colors. Rather than store the above value as 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, the GIF format can specify a list of 10 ones. That’s the general idea of run-length encoding. The ship image in this example weighs 2.92MB as a full-size GIF image.
The GIF format works best for images with a relatively small number of colors and large areas of the same color. Most drawings you make in a drawing program convert very well to the GIF format. Photos aren’t ideal because they usually have more than 256 colors in them, and the subtle changes in color mean there are very few solid blotches of color to take advantage of run-length encoding.
GIF does have a couple of great advantages that keep it popular. First, a GIF image can have a transparent color defined. Typically, you’ll choose some awful color not found in nature (kind of like choosing bridesmaid dresses) to be the transparent color. Then, when the GIF encounters a pixel that color, it displays whatever is underneath instead. This is a crude but effective form of transparency. Figure 6-6 shows an image with transparency.
Whenever you see an image on a Web page that doesn’t appear to be rectangular, there’s a good chance the image is a GIF. The image is still a rectangle, but it has transparency to make it look more organic. Typically, whatever color you set as the background color when you save a GIF becomes the transparent color.
Figure 6-6: This statue is a GIF with transparency.
Coming soon — vector formats
Here’s another form of image format that I hope will gain more prominence. All the formats described so far are raster-based image formats. This type of image stores an image as a series of dots. Vector-based image formats use formulas to store the instructions to draw an image. Certain kinds of images (especially charts and basic line art) can be far more efficient when stored as vector formats. Unfortunately, IE and Firefox support different and incompatible vector formats, so it doesn’t look like vector-based images will be a factor soon. Flash also uses vector-based techniques, but this technique requires expensive proprietary software to create vector images and a third-party plugin to use them.
The most promising new technology is the <canvas> tag in HTML 5. This tag allows programmers to draw directly on a portion of the screen using JavaScript code. If it becomes a standard, the <canvas> tag will unleash many new possibilities for Web-based graphics.
Another interesting feature of GIF is the ability to create animations. Animated GIFs are a series of images stored in the same file. You can embed information, determining the interval between images. You can create animated GIFs with Gimp, which is included on this book’s CD-ROM.
Animated GIFs were overused in the early days of the Web, and many now consider them the mark of an amateur. Nobody really thinks that animated mailbox is cute anymore.
Fortunately, it appears that the legal complications have been resolved for now. Still, you’ll see a lot of open-software advocates avoiding the GIF algorithm altogether because of this problem.
PNG
Open-source software advocates created a new image format that combines some of the best features of both JPG and GIF, with no legal problems. The resulting format is Portable Network Graphics, or PNG. This format has a number of interesting features, such as
♦ Lossless compression: Like GIF, PNG stores data without losing any information.
♦ Dynamic color palette: PNG supports as many colors as you want. You aren’t limited to 256 colors as you are with GIF.
♦ No software patents: The underlying technology of PNG is completely open source, with no worries about whether somebody will try to enforce a copyright down the road.
♦ True alpha transparency: The PNG format has a more sophisticated form of transparency than GIF. Each pixel can be stored with an alpha value. Alpha refers to the amount of transparency. The alpha can be adjusted from completely transparent to completely opaque.
With all its advantages, you might expect PNG to be the most popular image format on the Web. Surprisingly, it’s been slow to catch on. The main reason for this is spotty support for PNG in Internet Explorer (IE). Most versions of IE don’t support PNG’s alpha transparency correctly.
Summary of Web image formats
All these formats may seem overwhelming, but choosing an image format is easy because each format has its own advantages and disadvantages:
♦ GIF is best when you need transparency or animation. Avoid using GIF on photos, as you won’t get optimal compression, and you’ll lose color data.
♦ JPG is most useful for photographic images, which are best suited for the JPG compression technique. However, keep in mind that JPG isn’t suitable for images that require transparency. Text in JPG images tends to become difficult to read because of the lossy compression technique.
♦ PNG is useful in most situations, but be aware that IE (especially version 6) doesn’t handle PNG transparency correctly. (You sometimes see strange color blotches where you expect transparency.)
♦ BMP and other formats should be avoided entirely. Although you can make other formats work in certain circumstances, there’s no good reason to use any other image formats most of the time.
Manipulating Your Images
All this talk of compression algorithms and resizing images may be dandy, but how do you do it?
Fortunately, IrfanView can do nearly anything you need for free. IrfanView has nice features for all the main types of image manipulation you need.
Changing formats in IrfanView
Changing image formats with IrfanView is really easy. For example, find an image file on your computer and follow these steps:
1. Load the image into IrfanView by dragging the image into IrfanView or using the File⇒Open menu command.
2. Make any changes you may want to the image before saving.
3. Use the File⇒Save As command to save the file.
4. Pick the image format from the Save Picture As dialog box, as shown in Figure 6-7.
5. Save the file with a new filename.
Keep the original file and save any changes in a new file. That way, you don’t overwrite the original file. This is especially important if you’re converting to JPG because each successive save of a JPG causes some image loss.
Figure 6-7: IrfanView can save in all these formats.
Resizing your images
All the other image-manipulation tricks may be optional, but you should really resize your images. Although high-speed modems may have no trouble with a huge image, nothing makes a Web page inaccessible to dialup users faster than bloated image sizes.
To resize an image with IrfanView, perform the following steps:
1. Load the image into IrfanView.
You can do this by dragging the image onto the IrfanView icon, dragging into an open instance of IrfanView, or using the menus within IrfanView.
2. From the Image menu, choose Resize/Resample.
You can also use Ctrl+R for this step. Figure 6-8 shows the resulting dialog box.
Figure 6-8: IrfanView’s Resize/Resample Image dialog box.
3. Determine the new image size.
A number of standard image sizes are available. 800 x 600 pixels will create a large image in most browsers. If you want the image smaller, you need to enter a size in the text boxes. Images embedded in Web pages are often 320 pixels wide by 240 pixels tall. That’s a very good starting point. Anything smaller will be hard to see, and anything larger might take up too much screen space.
4. Preserve the aspect ratio using the provided check box.
This makes sure the ratio between height and width is maintained. Otherwise, the image may be distorted.
5. Save the resulting image as a new file.
When you make an image smaller, you lose data. That’s perfectly fine for the version you put on the Web, but you should hang on to the original large image in case you want to resize again.
6. Resample, rather than resize.
Resampling is a slower but more accurate technique for changing the image size. This is IrfanView’s default behavior, so leave it alone. It’s still quite fast on a modern computer. The default (Lanczos) filter is fine, although you can experiment with other filters to get a faster conversion, if you want.
Enhancing image colors
Sometimes, you can make improvements to an image by modifying the colors. The Enhance Colors dialog box on the Images menu gives you a wide range of options, as shown in Figure 6-9.
Figure 6-9: You can change several options in the Enhance Colors dialog box.
You can do a surprising number of helpful operations on an image with this tool:
♦ Brightness: When adjusted to a higher value, the image becomes closer to white. When adjusted to a negative value, the image becomes closer to black. This is useful when you want to make an image lighter or darker for use as a background image.
♦ Contrast: You usually use the Contrast feature in conjunction with the Brightness feature to adjust an image. Sometimes, an image can be improved with small amounts of contrast adjustments.
♦ Color Balance: Sometimes, an image has poor color balance (for example, indoor lighting sometimes creates a bluish cast). You can adjust the amount of red, green, and blue with a series of sliders. The easiest way to manage color balance is to look at a part of the image that’s supposed to be white and play with the slider until it looks truly white.
♦ Gamma Correction: This is used to correct an image that is too dark or too light. Unlike the Brightness adjustment, Gamma Correction automatically adjusts the contrast. Small adjustments to this slider can sometimes fix images that are a little too dark or too light.
♦ Saturation: When saturation is at its smallest value, the image becomes black and white. At its largest value, the colors are enhanced. Use this control to create a grayscale image or to enhance colors for artistic effect.
Using built-in effects
IrfanView has a few other effects available that can sometimes be extremely useful. These effects can be found individually on the Image menu or with the Image Effects browser on the Image menu. The Image Effects browser (as shown in Figure 6-10) is often a better choice because it gives you a little more control of most effects and provides interactive feedback on what the effect will do. Sometimes, effects are called filters because they pass the original image through a math function, which acts like a filter or processor to create the modified output.
Figure 6-10: The Image Effects browser lets you choose special effects.
Here’s a rundown of some of the effects, including when you would use them:
♦ None: Just for comparison purposes, Figure 6-11 shows the ship image without any filters turned on.
Figure 6-11: Here’s the standard ship image, at full-screen resolution.
♦ Blur: This filter reduces contrast between adjacent pixels. (Really, we could go over the math, but let’s leave that for another day, huh?) You might wonder why you’d make an image blurry on purpose. Sometimes, the Blur filter can fix graininess in an image. You can also use Blur in conjunction with Sharpen (which I cover in just a moment) to fix small flaws in an image. I applied the Blur filter to the standard ship image in Figure 6-12.
♦ Sharpen: The opposite of Blur, the Sharpen filter enhances the contrast between adjacent pixels. When used carefully, it can sometimes improve an image. The Sharpen filter is most effective in conjunction with the Blur filter to remove small artifacts. Figure 6-13 shows the ship image with the Sharpen filter applied.
Figure 6-12: The Blur filter reduces contrast.
Figure 6-13: The Sharpen filter increases contrast.
♦ Emboss: This filter creates a grayscale image that looks like embossed metal, as shown in Figure 6-14. Sometimes, embossing can convert an image into a useful background image because embossed images have low contrast. You can use the Enhance Colors dialog box to change the gray embossed image to a more appealing color.
♦ Oil Paint: This filter applies a texture reminiscent of an oil painting to an image, as shown in Figure 6-15. It can sometimes clean up a picture and give it a more artistic appearance. The higher settings make the painting more abstract.
♦ 3D Button: This feature can be used to create an image, similar to Figure 6-16, that appears to be a button on the page. This will be useful later when you figure out how to use CSS or JavaScript to swap images for virtual buttons. You can set the apparent height of the image in the filter. Normally, you apply this filter to smaller images that you intend to make into buttons the user can click.
Figure 6-14: Embossing creates a low-contrast 3D effect.
Figure 6-15: Oil Paint makes an image slightly more abstract.
Figure 6-16: The image appears to stick up from the page like a button.
♦ Red Eye Reduction: You use this filter to fix a common problem with flash photography. Sometimes, a person’s eyes appear to have a reddish tinge to them. Unlike the other filters, this one is easier to access from the Image menu. Use the mouse to select the red portion of the image and then apply the filter to turn the red areas black. It’s best not to perform this filter on the entire image because you may inadvertently turn other red things black.
Other effects you can use
Many more effects and filters are available. IrfanView has a few more built in that you can experiment with. You can also download a huge number of effects in the Adobe Photoshop 8BF format. These effects filters can often be used in IrfanView and other image-manipulation programs.
Some effects allow you to explode the image, add sparkles, map images onto 3D shapes, create old-time sepia effects, and much more.
If you want to do even more image manipulation, consider a full-blown image editor. Adobe Photoshop is the industry standard, but Gimp is an open-source alternative (included on this book’s CD-ROM) that does almost as much. See Book VIII, Chapter 4 for more about using Gimp for image processing.
Batch processing
Often, you’ll have a lot of images to modify at one time. IrfanView has a wonderful batch-processing tool that allows you to work on several images at once. I frequently use this tool to take all the images I want to use on a page and convert them to a particular size and format. The process seems a little complicated, but after you get used to it, you can modify a large number of images quickly and easily.
If you want to convert a large number of images at the same time, follow these steps:
1. Identify the original images and place them in one directory.
I find it easiest to gather all the images into one directory, whether they come from a digital camera, scanner, or other device.
2. Open the Batch Conversion dialog box by choosing File⇒Batch Conversion — Rename.
This Batch Conversion dialog box appears, as shown in Figure 6-17.
3. Find your original images by navigating the directory window in the Batch Conversion dialog box.
Figure 6-17: IrfanView has a powerful batch conversion tool.
4. Copy your images to the Input Files workspace by clicking the Add button.
Select the images you want to modify and press the Add button. The selected image names are copied to the Input Files workspace.
5. Specify the output directory.
If you want to put the new images in the same directory as the input files, click the Use This Directory as Output button. If not, choose the directory where you want the new images to go.
6. In the Work As box, choose Batch Conversion — Rename Result Files.
You can use this setting to rename your files, to do other conversions, or both. Generally, I recommend both.
7. Set the output format to the format you want.
For photos, you probably want JPG format.
8. Change renaming settings in the Batch Rename Settings area if you want to specify some other naming convention for your images.
By default, each image is called image### where ### is a three-digit number. They are numbered according to the listing in the Input Files workspace. You can use the Move Up and Move Down buttons to change the order images appear in this listing.
9. Click the Set Advanced Options button to change the image size.
This displays the Settings for All Images dialog box, as shown in Figure 6-18.
Figure 6-18: Use the Settings for All Images dialog box to resize images in batch mode.
10. Specify the new size of the image in the Resize area.
Several common sizes are preset. If you want another size, use the given options. I set my size to 320 x 240.
11. Close the Settings for All Images dialog box and then, in the Batch Conversion dialog box, press the Start button.
In a few seconds, the new images are created.
Using Images as Links
Sometimes, you’ll want to use images as links. For example, look at thumbs.html, as shown in Figure 6-19.
This page uses thumbnail images. A thumbnail is a small version of the full-size image. The thumbnail is embedded, and the user clicks it to see the full-size version in the browser.
Thumbnails are good because they allow the user to preview a small version of each image without having to wait for the full-size versions to be rendered on-screen. If the user wants to see a complete image, he can click the thumbnail to view it on its own page.
Figure 6-19: Small images can be links to larger images.
Creating thumbnail images
Thumbnails are simply scaled-down versions of ordinary images. Because this process is fairly common, IrfanView comes with a wonderful tool to automate thumbnail creation. To make a batch of thumbnails in IrfanView
1. Organize your images.
Any page that has a large number of images can get confusing. I prefer to organize everything that will be used by a particular page into its own directory. I created a thumbs directory that contains thumbs.html, all the full-size images, and all the thumbnails. I usually don’t find it helpful to have separate directories for images. It’s more helpful to organize by project or page than by media type.
2. Rename images, if necessary.
Images that come from a digital camera or scanner often have cryptic names. Your life is a lot easier if your image names are easier to understand. I named my images ship_1.jpg, ship_2.jpg, and ship_3.jpg.
3. Make any changes you want to the originals before you make the thumbnails.
Use the tips described in this chapter to clean up or improve your images before you make thumbnails, or the thumbnails won’t represent the actual images accurately.
4. Open the IrfanView Thumbnails tool by choosing File⇒Thumbnails or by pressing the T key.
The Thumbnails tool appears, as shown in Figure 6-20.
5. Select the thumbnails you want to create.
Use the mouse to select any images you want to make thumbnails from.
6. Choose Save Selected Thumbs as Individual Images from the File menu.
You have other options, but this gives the behavior you probably want. The other options create automatic contact sheets, open the batch editor, or create slide shows. These are great things, but for now, you want thumbnails.
7. Specify the output directory.
You can put the thumbnails in the same directory as the originals. The thumbnails have the same name as the originals, but the filenames end with _t.
8. Review the new thumbnail images.
You should see a new set of smaller images (default size is 80 x 80 pixels) in the directory.
Figure 6-20: IrfanView’s Thumbnails tool helps you create thumbnail images.
Creating a thumbnail-based image directory
Now, you have everything you need to build a page similar to thumbs.html. Here’s an overview of the code:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>thumbs.html</title>
</head>
<body>
<h1>Images of the <em>Susan B. Constant</em></h1>
<ul>
<li>
<h2>The Stern</h2>
<a href = “ship_1.jpg“>
<img src = “ship_1_t.jpg“
height = “80“
width = “80“
alt = “ship 1“ />
</a>
</li>
<li>
<h2>The Mast</h2>
<a href = “ship_2.jpg“>
<img src = “ship_2_t.jpg“
height = “80“
width = “80“
alt = “ship 2“ />
</a>
</li>
<li>
<h2>The Rigging</h2>
<a href = “ship_3.jpg“>
<img src = “ship_3_t.jpg“
height = “80“
width = “80“
alt = “ship 3“ />
</a>
</li>
</ul>
</body>
</html>
This code looks complicated, but it’s really just a combination of techniques described in this chapter. Look over the code and use the indentation to determine the structure.
The page is an unordered list. Each list item contains an H2 headline and an anchor. The anchor contains an image, rather than text. When you include an image inside an anchor tag, it’s outlined in blue.
The key is to use the thumbnails as inline images inside the page, and the full-size image as the href of the anchor. The user sees the small image, but this small image is also a link to the full-size version of the image. This way, the user can see the small image easily but can view the full-size image if she wishes.
Chapter 7: Creating Forms
In This Chapter
Adding form to your pages
Creating input and password text boxes
Building multi-line text inputs
Making list boxes and check boxes
Building groups of radio buttons
Creating buttons
XHTML gives you the ability to describe Web pages, but today’s Web isn’t a one-way affair. Users want to communicate through Web pages, by typing in information, making selections from drop-down lists, and interacting, rather than simply reading. In this chapter, you learn how to build these interactive elements in your pages.
You Have Great Form
There’s one more aspect to XHTML that you need to understand — the ability to make forms. Forms are the parts of the page that allow user interaction. Figure 7-1 shows a page with all the primary form elements in place.
The form demo (or formDemo.html on this book’s CD-ROM, if you’re playing along at home) exemplifies the main form elements in XHTML. In this chapter, you discover how to build all these elements.
Figure 7-1: Form elements allow user interaction.
The formDemo.html page shows the following elements:
♦ A form: A container for form elements. Although the form element itself isn’t usually a visible part of the page (like the body tag), it could be with appropriate CSS.
♦ Text boxes: These standard form elements allow the user to type text into a one-line element.
♦ Password boxes: These boxes are like text boxes, except they automatically obscure the text to discourage snooping.
♦ Text areas: These multi-line text boxes accommodate more text than the other types of text boxes. You can specify the size of the text area the user can type into.
♦ Select lists: These list boxes give the user a number of options. The user can select one element from the list. You can specify the number of rows to show or make the list drop down when activated.
♦ Check boxes: These non-text boxes can be checked or not. Check boxes act independently — more than one can be selected at a time (unlike radio buttons).
♦ Radio buttons: Usually found in a group of options, only one radio button in a group can be selected at a time. Selecting one radio button deselects the others in its group.
♦ Buttons: These elements let the user begin some kind of process. The Input button is used in JavaScript coding (which I describe in Book IV), whereas the Standard and Submit buttons are used for server-side programming (see Book V). The Reset button is special because it automatically resets all the form elements to their default configurations.
♦ Labels: Many form elements have a small text label associated with them. Although labels are not required, they can make a form easier to style with CSS and easier for the user.
♦ Fieldsets and legends: These set off parts of the form. They’re optional, but they can add a lot of visual appeal to a form.
Now that you have an overview of form elements, it’s time to start building some forms!
Forms must have some form
All the form elements must be embedded inside a <form></form> pair. The code for basicForm.html illustrates the simplest possible form:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>basicForm.html</title>
</head>
<body>
<h1>A basic form</h1>
<form action = ““>
<h2>Form elements go here</h2>
<h3>Other HTML is fine, too.</h3>
</form>
</body>
</html>
The <form></form> pair indicates a piece of the page that may contain form elements. All the other form doohickeys and doodads (buttons, select objects, and so on) must be inside a <form> pair.
The action attribute indicates what should happen when the form is submitted. This requires a programming language, so a full description of the action attribute is in Book IV. Still, you must indicate an action to validate, so for now just leave the action attribute null with a pair of quotes (“”).
Organizing a form with fieldsets and labels
Forms can contain many components, but the most important are the input elements (text boxes, buttons, drop-down lists, and the like) and the text labels that describe the elements. Traditionally, Web developers used tables to set up forms, but this isn’t really the best way to go because forms aren’t tabular information. XHTML includes some great features to help you describe the various parts of a form. Figure 7-2 shows a page with fieldsets, layouts, and basic input.
A fieldset is a special element used to supply a visual grouping to a set of form elements.
The form still doesn’t look very good, I admit, but that’s not the point. Like all XHTML tags, the form elements aren’t about describing how the form looks; they’re about what all the main elements mean. (Here I go again. . . .) You use CSS to make the form look the way you want. The XHTML tags describe the parts of the form, so you have something to hook your CSS to. It all makes sense very soon, I promise.
Here’s the code for the fieldset demo (fieldsetDemo.html on this book’s CD-ROM):
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>fieldsetDemo.html</title>
</head>
<body>
<h1>Sample Form with a Fieldset</h1>
<form action = ““>
<fieldset>
<legend>Personal Data</legend>
<p>
<label>Name</label>
<input type = “text“ />
</p>
<p>
<label>Address</label>
<input type = “text“ />
</p>
<p>
<label>Phone</label>
<input type = “text“ />
</p>
</fieldset>
</form>
</body>
</html>
Figure 7-2: This form has a legend and labels.
The form has these elements:
♦ The <form> and </form> tags: These define the form as a part of the page. Don’t forget the null action attribute.
♦ The <fieldset> pair: This pair describes the included elements as a set of fields. This element isn’t necessary, but it does give you some nice organization and layout options later when you use CSS. You can think of the fieldset as a blank canvas for adding visual design to your forms. By default, the fieldset places a border around all the contained elements.
♦ The <legend> tag: A part of the fieldset, this tag allows you to specify a legend for the entire fieldset. The legend is visible to the user.
♦ The paragraphs: I sometimes place each label and its corresponding input element in a paragraph. This provides some nice formatting capabilities and keeps each pair together.
♦ The <label> tag: This tag allows you to specify a particular chunk of text as a label. No formatting is done by default, but you can add formatting later with CSS.
♦ The <input> elements: The user types data into these elements. For now, I’m just using very basic text inputs so the form has some kind of input. In the next section, I explain how to build more complete text inputs.
Building Text-Style Inputs
Most of the form elements are variations of the same tag. The <input> tag can create single-line text boxes, password boxes, buttons, and even invisible content (such as hidden fields). Most of these objects share the same basic attributes, although the outward appearance can be different.
Making a standard text field
Figure 7-3 shows the most common form of the input element — a plain text field.
Figure 7-3: The input element is often used to make a text field.
To make a basic text input, you need a form and an input element. Adding a label so that the user knows what he’s supposed to enter into the text box is also common. Here’s the code:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>textbox.html</title>
</head>
<body>
<form action = ““>
<p>
<label>Name</label>
<input type = “text“
id = “txtName“
value = “Joe“/>
</p>
</form>
</body>
</html>
An input element has three common attributes:
♦ type: The type attribute indicates the type of input element this is. This first example sets type to text, creating a standard text box. Other types throughout this chapter create passwords, hidden fields, check boxes, and buttons.
♦ id: The id attribute creates an identifier for the field. When you use a programming language to extract data from this element, use id to specify which field you’re referring to. An id field often begins with a hint phrase to indicate the type of object it is (for instance, txt indicates a text box).
♦ value: This attribute determines the default value of the text box. If you leave this attribute out, the text field begins empty.
Text fields can also have other attributes, which aren’t used as often, such as
♦ size: This attribute determines the number of characters that are displayed.
♦ maxlength: Use this attribute to set the largest number of characters that are allowed.
There is no </input> tag. Input tags are a holdover from the days when many tags did not have ending tags. You just end the original tag with a slash character (/), as shown in the preceding sample code.
You might wonder why I added the <label> tag if it doesn’t have any effect on the appearance or behavior of the form. In this particular example, the <label> tag doesn’t have an effect, but like everything else in HTML, you can do amazing style things with it in CSS. Even though labels don’t typically have a default style, they are still useful.
Building a password field
Passwords are just like text boxes, except the text isn’t displayed. Instead, a series of asterisks appears. Figure 7-4 shows a basic password field.
Figure 7-4: Enter the secret password.
The following code reveals that passwords are almost identical to ordinary text fields:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>password.html</title>
</head>
<body>
<form action = ““>
<fieldset>
<legend>Enter a password</legend>
<p>
<label>Type password here</label>
<input type = “password“
id = “pwd“
value = “secret“ />
</p>
</fieldset>
</form>
</body>
</html>
In this example, I’ve created a password field with the ID pwd. The default value of this field is secret. The term secret won’t actually appear in the field; it will be replaced with six asterisk characters.
This example doesn’t really do anything with the password, but you’ll use other technologies for that.
Making multi-line text input
The single-line text field is a powerful feature, but sometimes, you want something with a bit more space. The essay.html program, as shown in Figure 7-5, demonstrates how you might create a page for an essay question.
Figure 7-5: This quiz might require a multi-line response.
The star of this program is a new tag — <textarea>:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>essay.html</title>
</head>
<body>
<form action = ““>
<fieldset>
<legend>Quiz</legend>
<p>
<label>Name</label>
<input type = “text“
id = “txtName“ />
</p>
<p>
<label>
Please enter the sum total of
Western thought. Be brief.
</label>
</p>
<p>
<textarea id = “txtAnswer“
rows = “10“
cols = “40“></textarea>
</p>
</fieldset>
</form>
</body>
</html>
Here are a few things to keep in mind when using the <textarea> tag:
♦ It needs an id attribute, just like an input element.
♦ You can specify the size with rows and cols attributes.
♦ The content goes between the tags. The text area can contain a lot more information than the ordinary <input> tags, so rather than placing the data in the value attribute, the content of the text goes between the <textarea> and </textarea> tags.
Creating Multiple Selection Elements
Sometimes, you want to present the user with a list of choices and then have the user pick one of these elements. XHTML has a number of interesting ways to do this.
Making selections
The drop-down list is a favorite selection tool of Web developers for the following reasons:
♦ It saves screen space. Only the current selection is showing. When the user clicks the list, a series of choices drop down and then disappear again after the selection is made.
♦ It limits input. The only things the user can choose are things you’ve put in the list. This makes it much easier to handle the potential inputs because you don’t have to worry about typing errors.
♦ The value can be different from what the user sees. This seems like an odd advantage, but it does turn out to be very useful sometimes. I show an example when I describe color values later in this chapter.
Figure 7-6 shows a simple drop-down list in action.
Figure 7-6: The user can choose from a list of colors.
The code for this simple drop-down list follows:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>basicSelect.html</title>
</head>
<body>
<form action = ““>
<p>
<label>What is your favorite color?</label>
<select id = “selColor“>
<option value = “#ff0000“>Red</option>
<option value = “#00ff00“>Green</option>
<option value = “#0000ff“>Blue</option>
<option value = “#00ffff“>Cyan</option>
<option value = “#ff00ff“>Magenta</option>
<option value = “#ffff00“>Yellow</option>
<option value = “#000000“>Black</option>
<option value = “#ffffff“>White</option>
</select>
</p>
</form>
</body>
</html>
What are those funky #ff00ff things?
If you look carefully at the code for basicSelect.html, you see that the values are all strange text with pound signs and weird characters. These are hex codes, and they’re a good way to describe colors for computers. I explain all about how these work in Book II, Chapter 1. This coding mechanism is not nearly as hard to understand as it seems. For now though, this code with both color names and hex values is a good example of wanting to show the user one thing (the name of a color in English) and send some other value (the hex code) to a program. You see this code again in Book IV, Chapter 5, where I use a list box just like this to change the background color of the form with JavaScript.
The select object is a bit different from some of the other input elements you’re used to, such as
♦ It’s surrounded by a <select></select> pair. These tags indicate the entire list.
♦ The select object has an id attribute. Although the select object has many other tags inside, typically only the select object itself has an id attribute.
♦ It contains a series of <option></option> pairs. Each individual selection is housed in an <option></option> set.
♦ Each <option> tag has a value associated with it. The value is used by code. The value isn’t necessarily what the user sees. (See the sidebar “What are those funky #ff00ff things?” for an example.)
♦ The content between <option></option> is visible to the user. The content is what the user actually sees.
Building check boxes
Check boxes are used when you want the user to turn a particular choice on or off. For example, look at Figure 7-7.
Each check box represents a true or false value that can be selected or not selected, and the status of each check box is completely independent from the others. The user can check none of the options, all of them, or any combination.
Figure 7-7: Any number of check boxes can be selected at once.
This code shows that check boxes use your old friend the <input> tag:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>checkBoxes.html</title>
</head>
<body>
<form action = ““>
<fieldset>
<legend>Please check off your life goals...</legend>
<p>
<input type = “checkbox“
id = “chkPeace“
value = “peace“ />World peace
</p>
<p>
<input type = “checkbox“
id = “chkHarmony“
value = “harmony“ />Harmony and brotherhood
</p>
<p>
<input type = “checkbox“
id = “chkCash“
value = “cash“ />Cash
</p>
</fieldset>
</form>
</body>
</html>
This all seems inconsistent
Sometimes, the value of a form element is visible to users, and sometimes it’s hidden. Sometimes, the text the user sees is inside the tag, and sometimes it isn’t. It’s a little confusing. The standards evolved over time, and they honestly could have been a little more consistent. Still, this is the set of elements you have, and they’re not really that hard to understand. Write forms a few times, and you’ll remember. You can always start by looking over my code and borrowing it as a starting place.
You’re using the same attributes of the <input> tag, but they work a bit differently than the way they do in a plain old text box:
♦ The type is checkbox. That’s how the browser knows to make a check box, rather than a text field.
♦ The checkbox still requires an ID. If you’ll be writing programming code to work with this thing (and you will, eventually), you’ll need an ID for reference.
♦ The value is hidden from the user. The user doesn’t see the actual value. That’s for the programmer (like the select object). Any text following the check box only appears to be the text associated with it.
Creating radio buttons
Radio buttons are used when you want to let the user pick only one option from a group. Figure 7-8 shows an example of a radio button group in action.
Figure 7-8: You can choose only one of these radio buttons.
Radio buttons might seem similar to check boxes, but they have some important differences:
♦ Only one can be checked at a time. The term radio button came from the old-style car radios. When you pushed the button for one station, all the other buttons popped out. I still have one of those radios. (I guess I have a Web-design car.)
♦ They have to be in a group. Radio buttons make sense only in a group context. The point of a radio button is to interact with its group.
♦ They all have the same name! Each radio button has its own ID (like other input elements), but they also have a name attribute. The name attribute indicates the group a radio button is in.
♦ You can have more than one group on a page. Just use a different name attribute for each group.
♦ One of them has to be selected. The group should always have one value and only one. Some browsers check the first element in a group by default, but just in case, you should select the element you want selected. Add the checked = “checked” attribute (developed by the Department of Redundancy Department) to the element you want selected when the page appears. In this example, I preselected the most expensive option, all in the name of good capitalistic suggestive selling.
Here’s some code that explains it all:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>radioButtons.html</title>
</head>
<body>
<form action = ““>
<fieldset>
<legend>How much do you want to spend?</legend>
<p>
<input type = “radio“
name = “radPrice“
id = “rad100“
value = “100“ />Too much
</p>
<p>
<input type = “radio“
name = “radPrice“
id = “rad200“
value = “200“ />Way too much
</p>
<p>
<input type = “radio“
name = “radPrice“
id = “rad5000“
value = “5000“
checked = “checked“ />You’ve got to be kidding.
</p>
</fieldset>
</form>
</body>
</html>
Pressing Your Buttons
XHTML also comes with several types of buttons. You use these guys to make something actually happen. Generally, the user sets up some kind of input by typing in text boxes and then selecting from lists, options, or check boxes. Then, the user clicks a button to trigger a response. Figure 7-9 demonstrates four types of buttons.
The code for this button example is shown here:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=“content-type“ content=“text/xml; charset=utf-8“ />
<title>buttons.html</title>
</head>
<body>
<h1>Button Demo</h1>
<form action = ““>
<fieldset>
<legend>
input-style buttons
</legend>
<input type = “button“
value = “input type = button“ />
<input type = “submit“ />
<input type = “reset“ />
</fieldset>
<fieldset>
<legend>button tag buttons</legend>
<button type = “button“>
button tag
</button>
<button>
<img src = “clickMe.gif“
alt = “click me“ />
</button>
</fieldset>
</form>
</body>
</html>
Figure 7-9: XHTML supports several types of buttons.
Each button type is described in this section.
Making input-style buttons
The most common form of button is just another form of your old friend, the <input> tag. If you set the input’s type attribute to “button”, you generate a basic button:
<input type = “button”
value = “input type = button” />
The ordinary Input button has a few key features:
♦ The input type is set to “button”. This makes an ordinary button.
♦ The value attribute sets the button’s caption. Change the value attribute to make a new caption. This button’s caption shows how the button was made: input type = “button”.
♦ This type of button doesn’t imply a link. Although the button appears to depress when it’s clicked, it doesn’t do anything. You have to write some JavaScript code to make it work.
♦ Later, you’ll add event-handling to the button. After you discover JavaScript in Book IV, you use a special attribute to connect the button to code.
♦ This type of button is for client-side programming. This type of code resides on the user’s computer. I discuss client-side programming with JavaScript in Book IV.
Building a Submit button
Submit buttons are usually used in server-side programming. In this form of programming, the code is on the Web server. In Book V, you use PHP to create server-side code. The <input> tag is used to make a Submit button, too!
<input type = “submit” />
Although they look the same, the Submit button is different than the ordinary button in a couple subtle ways:
♦ The value attribute is optional. If you leave it out, the button displays Submit Query. Of course, you can change the value to anything you want, and this becomes the caption of the Submit button.
♦ Clicking it causes a link. This type of button is meant for server-side programming. When you click the button, all the information in the form is gathered and sent to some other page on the Web.
♦ Right now, it goes nowhere. When you set the form’s action attribute to null (“”), you told the Submit button to just reload the current page. When you figure out real server-side programming, you change the form’s action attribute to a program that works with the data.
♦ Submit buttons aren’t for client-side. Although you can attach an event to the Submit button (just like the regular Input button), the linking behavior often causes problems. Use regular Input buttons for client-side and Submit buttons for server-side.
It’s a do-over: The Reset button
Yet another form of the versatile <input> tag creates the Reset button:
<input type = “reset” />
This button has a very specific purpose. When clicked, it resets all the elements of its form to their default values. Like the Submit button, it has a default value (“reset”), and it doesn’t require any code.
Introducing the <button> tag
The button has been a useful part of the Web for a long time, but it’s a bit boring. HTML 4.0 introduced the <button> tag, which works like this:
<button type = “button”>
button tag
</button>
The <button> tag acts more like a standard XHTML tag, but it can also act like a Submit button. Here are the highlights:
♦ The type attribute determines the style. You can set the button to ordinary (by setting its type to button), submit, or reset. If you don’t specify the type, buttons use the Submit style. The button’s type indicates its behavior, just like the Input-style buttons.
♦ The caption goes between the <button></button> pair. There’s no value attribute. Instead, just put the intended caption inside the <button> pair.
♦ You can incorporate other elements. Unlike the Input button, you can place images or styled text inside a button. This gives you some other capabilities. The second button in the buttons.html example uses a small GIF image to create a more colorful button.
Chapter 8: The Future of HTML: HTML 5
In This Chapter
Previewing HTML 5
Using new semantic markup tags
Embedding fonts
Using the new canvas tag for custom graphics
Audio and video support
Advanced features
The Web world is always changing. A new version of HTML — HTML 5 — is on the horizon, and it has some very interesting features. In this chapter, I preview the new features in HTML 5 and show you a few examples. When HTML becomes the standard, you’ll be ahead of the game.
Can’t We Just Stick with XHTML?
XHTML is great. When you add CSS to it, you can do a lot with XHTML. However, it isn’t perfect. The Web is evolving, and we’re now commonly doing things with Web pages that were once unheard of:
♦ Sophisticated structure: Web-based documents frequently have navigation elements, footer elements, page sections, and individual articles. Developers often use many variations of the <div> tag to manage these elements. HTML 5 has them built in.
♦ Multimedia: It’s now common for Web pages to incorporate audio and video, yet these elements aren’t built into HTML like image support. Instead, developers have to rely on external software, such as Flash.
♦ Vector/real-time graphics: The graphics capabilities of current browsers are fine, but they don’t allow real-time modification. Programmers often use third-party software, such as Flash or Silverlight, to bring in this capability.
♦ Enhanced programming: Developers are no longer satisfied with Web pages as documents. Today’s Web pages are the foundation of entire applications. Developers (and their customers) want advanced capabilities, such as dragging and dropping, local data storage, and geolocation (a fancy term for a browser that can tell where the device using the page is in the world).
Using the HTML 5 doctype
The XHTML doctype is remarkably ugly. I’ll be honest. I can’t code it from memory, and I write books about this stuff. My favorite part about HTML 5 might be the sensible doctype:
<!DOCTYPE html>
That’s it. No messy XMLNS business, no crazy URLs, no http-equiv nonsense. Just <!DOCTYPE html>. This replaces both the <doctype> and the <HTML> tags. It’s beautiful, in a geeky sort of way.
<meta http-equiv=”Content-Type” content=”text/html;charset=utf-8” >
It specifies the character set as a standard text encoding. Typically, the server sends this, so it isn’t really necessary, but including the line eliminates a possible validator warning that no typeface was defined.
Browser support for HTML 5
Before you get too excited about HTML 5, you have to realize it’s still experimental. All the examples in this chapter were tested in Firefox 3.5, which supports many HTML 5 features. The latest versions of Chrome, Safari, and Opera all have support for key features of HTML 5, but Microsoft Internet Explorer (at least up to version 8) does not incorporate most features of HTML 5.
Validating HTML 5
Because the final specification for HTML 5 is still under review, validating HTML 5 code is not an exact science. The W3C validator has provisional support for HTML 5, but HTML 5 validation isn’t built into Tidy or other validation tools, yet.
Still, it makes sense to validate your HTML 5 code as much as you can because validation will prevent problems down the road.
Semantic Elements
One of the key features of HTML is the support for new semantic features. HTML is supposed to be about describing the meaning of elements, yet Web pages frequently have elements without HTML tags. Look at the following example of HTML 5 code:
<!DOCTYPE html>
<head>
<title>semanticTags.html</title>
</head>
<body>
<h1>Semantic Tags Demo</h1>
<nav>
<h2>Navigation</h2>
<ul>
<li>one</li>
<li>two</li>
<li>three</li>
<li>four</li>
<li>five</li>
</ul>
</nav>
<section>
<h2>Section</h2>
<article>
<h3>Article 1</h3>
<p>
This is an article. It’s just a logical part of a page.
</p>
</article>
<article>
<h3>Article 1</h3>
<p>
This is an article. It’s just a logical part of a page.
</p>
</article>
</section>
</body>
</html>
This code validates perfectly as HTML 5, but it has several tags that were not allowed in XHTML or previous versions of HTML:
♦ <nav>: It’s very common for Web pages to have navigation sections. These often are menus or some other list of links. You can have several navigation elements on the page. The <nav></nav> tags indicate that the block contains some sort of navigation elements.
♦ <section>: This is a generic tag for a section of the page. You can have several sections if you wish. Sections are indicated by the <section></section> pair.
♦ <article>: The <article> tag is used to denote an article, say a blog posting. In my example, I put two articles inside the section.
None of these tags has any particular formatting. The tags just indicate the general layout of the page. You’ll use CSS to make these sections look exactly how you want. (I didn’t show a screen shot for this reason; you won’t see anything special.)
The semantic tags aren’t absolutely necessary. They were added because many Web developers already do something similar with the generic <div> tag. Use of these semantic tags will clarify your code and reduce some of the excessive use of divs that tends to clutter even modern XHTML designs.
Using New Form Elements
Even the earliest forms of HTML had support for user forms — tools for retrieving information from a user. The basic form elements have changed very little since the original versions of HTML. HTML 5 finally adds a few form elements to make certain kinds of data input much easier to manage. Although browsers have been slow to accept these features, they promise a much-improved user experience while the Web becomes a primary form of application development. Figure 8-1 shows a number of the new HTML 5 elements.
As with any HTML tag, the tag itself indicates a certain kind of data, not any particular appearance or behavior. Likely, these specialized input elements will make data entry easier for users.
Figure 8-1: HTML 5 supports several new variants of the input elements.
<!DOCTYPE html>
<head>
<title>formDemo.html</title>
<link rel = “stylesheet”
type = “text/css”
href = “formDemo.css” />
</head>
<body>
<h1>HTML 5 Form Demo</h1>
<form action = “”>
<label for = “email”>email</label>
<input type = “email”
id = “email”/>
<label for = “url”>url</label>
<input type = ”url”
id = ”url” />
<label for = ”number”>number</label>
<input type = ”number”
id = ”number”
min = ”0”
max = ”10”
step = ”2”
value = ”5” />
<label for = ”range”>range</label>
<input type = ”range”
id = ”range”
min = ”0”
max = ”10”
step = ”2”
value = ”5” />
<label for = ”date”>date</label>
<input type = ”date”>
<label for = ”time”>time</label>
<input type = ”time”>
</form>
</body>
</html>
Nothing surprising in these elements, but the new capabilities are interesting:
♦ E-mail: An email input element is optimized for accepting e-mail addresses. Some browsers may incorporate format-checking for this type. Mobile browsers may pop up specialized keyboards (making the @ sign more prominent, for example) when a user is entering data into an e-mail field.
♦ Url: Like an email input element, a url input element creates a field for entering links. Usually, the url input element doesn’t have any particular formatting, but it may have a specialized pop-up keyboard in mobile devices.
♦ Number: A number input element specifies a numeric field. If you designate a field a number input element, you can indicate maximum (max) and minimum (min) values as well as a step value that indicates how much the data will change. Some browsers will check to see that the data is within the given range, and some will add a visual component that allows a user to select a number with small arrow buttons.
♦ Range: A range input element is similar to a number input element, but browsers that support it often use a small scrollbar to simplify user input.
♦ Date: Dates are especially difficult to get accurately from a user. By using a date input element, a date field can show an interactive calendar when a user begins to enter a date. Figure 8-2 illustrates this field in action.
♦ Time: By using the time input element, a time field can show a small dialog simplifying the process of retrieving time information from a user.
Figure 8-2: When a user enters a date, a small calendar appears.
Using Embedded Fonts
Technically, it’s not part of HTML 5, but the new browsers have another great feature: embeddable fonts. Until now, there was no reliable way to use an arbitrary font in a Web page. You could suggest any font you wished, but that font would only work if the user already had it installed on her computer.
The current crop of browsers finally supports an embedded font technique that allows you to post a font file on your server and use that font in your page (much like the background image mechanism). This means you can finally have much better control of your typography on the Web. Figure 8-3 illustrates a page with an embedded font.
Figure 8-3: The fonts are embedded directly into the page.
The code for including a font is not difficult. Take a look at the code for embeddedFont.html to see how it’s done:
<!DOCTYPE html>
<head>
<title>EmbeddedFont</title>
<style type = “text/css”>
@font-face {
font-family: “Miama”;
src: url(“Miama.otf”);
}
@font-face {
font-family: “spray”;
src: url(“ideoma_SPRAY.otf”);
}
h1 {
font-family: Miama;
font-size: 300%;
}
h2 {
font-family: spray;
}
</style>
</head>
<body>
<h1>Embedded Font Demo</h1>
<h2>Here’s another custom font</h2>
</body>
</html>
Here’s how you do it.
1. Identify your font: Find a font file you want to use. Most commercial fonts are licensed for single-computer use, so stick with open font formats, such as the ones you’ll find at http://openfontlibrary.org.
2. Pick a font format: Unfortunately, this part of the standard is still non-standard. Most browsers that support embedded fonts use TTF (the most common font format) or OTF (a somewhat more open variant of TTF). A new standard, WOFF, is on the horizon and may be more acceptable to font developers, but it isn’t widely used yet. Internet Explorer uses only the proprietary EOT format. Look up the WEFT utility for converting fonts for use in Internet Explorer.
3. Place the font file near your code: Your Web page will need a copy of the font file somewhere on the server; put it in the same directory as your page. Remember, when you move the page to the server, you also need to make a copy of the font file on the server.
4. Build a font-face: Near the top of your CSS, designate a new font face using your custom font. This is slightly different CSS syntax than you may have used before. The @ sign indicates you are preparing a new CSS element.
5. Specify the font-family: This is the name used to designate the font in the rest of your CSS. Typically, this is similar to the font name, but easier to type.
6. Indicate where the font file can be found: The src attribute indicates where the file can be found. Typically, this is the filename of the font file in the same directory as the page. You can include several src attributes if you want to have more than one version of the file. (You might include EOT and OTF formats, for example, so the font is likely to work on any browser.)
7. Use your new font in your CSS: You now can use the font-family name in your CSS the same way you do with any other font. If the user doesn’t have that font installed, the font is used for this Web page but not installed on the client’s machine. Some fonts (like Miama in my example) may require some size adjustments to look right.
Just because you can use any font file doesn’t mean you should. Many fonts are commercial products and cannot be distributed without permission. However, many excellent free and open-source fonts are available. See the open font library at http://openfontlibrary.org to find several great fonts.
Audio and Video Tags
Multimedia has been a promise of Web technology since the beginning but isn’t integrated fully into HTML. Developers have had to rely on third-party technologies, such as plugins and the embed tag, to incorporate audio and video into Web pages. HTML 5 finally supports audio (with an <audio> tag) and video (with a <video> tag). For the first time, audio and video components can play natively in Web browsers without requiring any external technology.
This is a major breakthrough, or it will be if the browser developers cooperate. As an example, look at this code:
<!DOCTYPE html>
<head>
<title>audioDemo.html</title>
</head>
<body>
<h1>HTML 5 Audio Demo</h1>
<audio src = “Do You Know Him.ogg” controls>
This example uses the HTML 5 audio tag.
Try using Firefox 3.5 or greater.
</audio>
<p>
This song was written by a friend of mine, Daniel Rassum. He sings about
hard life and redemption.
If you like this song, I encourage you to check out his album at
<a href = “http://www.noisetrade.com”>www.noisetrade.com</a>.
It’s a “free trade” music site where you pay
what you think is fair for an artist’s work.
</p>
</body>
</html>
The only new feature is the <audio> tag. This tag pair allows you to place an audio file directly into the Web page. You can set the audio to play automatically, or you can indicate player controls. Player controls are the preferred approach because it’s considered polite to let the user choose whether audio plays when the page is loaded. If the browser does not support the <audio> tag, any text between the <audio> and </audio> tags is displayed.
Figure 8-4 illustrates audioDemo.html playing a song.
The HTML 5 specification (at the moment) does not specify any particular file format for the audio tag. The key browsers support the open-source Ogg Vorbis format and uncompressed .wav files. Browser manufacturers are having difficulty agreeing on what the standard should be. Some organizations with a stake in proprietary formats aren’t excited about supporting an unencumbered format that currently is known only to geeks.
Figure 8-4: The HTML 5 audio tag puts a simple audio player on the page.
If you remember old-school HTML, you might wonder if the <audio> tag is an improvement over the old <embed> tag. The <embed> tag was powerful but very difficult to use. If you use the <embed> tag to embed an audio file into a Web page, the client machine looks for the default player for the particular file format and attempts to embed that player into the page (which might or might not work). The developer has no control of exactly what plugin will be used, which makes it very difficult to manage or control the element’s behavior. The <audio> tag is built into the browser, and the browser manages the audio rather than some external program. This gives the developer much more control over what happens.
The <video> tag works much the same way as the audio tag but gives the Web browser native support for video. The following code shows a sample video playing in Firefox 3.5:
<!DOCTYPE html>
<head>
<title>videoDemo</title>
</head>
<body>
<h1>Video Demo</h1>
<video src = “bigBuck.ogv” controls>
Your browser does not support embedded video
through HTML 5. Try Firefox 3.5 or greater.
</video>
<p>
This video is a trailer for the incredible short move
“Big Buck Bunny.” This experiment proves that talented
volunteers can produce a high-quality professional video
using only open-source tools.
Go to <a href = “http://www.bigbuckbunny.org”>
http://www.bigbuckbunny.org</a> to see the entire video.
</p>
</body>
</html>
As with audio, the W3 standard does not specify any particular video format, so the various browser manufacturers are free to interpret this requirement differently. Most of the current browsers support the open-source Ogg Theora format. (Yep, it’s related to Ogg Vorbis.)
Video is more complex because the file format doesn’t necessarily imply a particular coding mechanism. I encoded this video with the Ogg Vorbis wrapper using the AVI codec for the video portion and MP3 for the audio portion. This approach seems to be working in the two HTML 5 browsers I access.
Figure 8-5 is an example of a page showing a fun video created with free tools.
Figure 8-5: The video tag allows you to embed videos into HTML 5 pages easily.
The actual movie I show in the example is a trailer to the excellent short movie Big Buck Bunny. This incredible cartoon shows what can be done with completely open-source tools and rivals works from commercial studios. Thanks to the Blender foundation for releasing this hilarious and impressive film under a creative commons license.
The Canvas Tag
HTML 5 offers at least one more significant new feature. The <canvas> tag allows developers to draw directly on a portion of the form using programming commands. Although this technique requires some JavaScript skills, it opens substantial new capabilities. Figure 8-6 shows a simple page illustrating the <canvas> tag.
Figure 8-6: The canvas tag allows programmers to create dynamic graphics.
The code for canvasDemo.html relies on JavaScript, so check Book IV for details on how to write this code and much more. As an overview, though, here’s the code:
<!DOCTYPE html>
<head>
<title>canvasDemo.html</title>
<script type = “text/javascript”>
//<![CDATA[
function draw(){
var myCanvas = document.getElementById(“myCanvas”);
var context = myCanvas.getContext(“2d”);
context.fillStyle = “blue”;
context.strokeStyle = “red”;
circle(context, 1, 1, 1);
for (i = 1; i <= 200; i+= 2){
circle(context, i, i, i, “blue”);
circle(context, 300-i, 200-i, i, “red”);
circle(context, 300-i, i, i, “blue”);
circle(context, i, 200-i, i, “red”);
} // end for
} // end draw
function circle(context, x, y, radius, color){
context.strokeStyle = color;
context.beginPath();
context.arc(x, y, radius, 0, Math.PI * 2, true);
context.stroke();
} // end circle
//]]>
</script>
</head>
<body>
<h1>Canvas Demo</h1>
<canvas id = “myCanvas”
width = “300”
height = “200”>
This example requires HTML 5 canvas support
</canvas>
<button type = “button”
onclick = “draw()”>
click me to see a drawing
</button>
</body>
</html>
There’s quite a bit going on in this program. The image doesn’t come from the server as most Web images do; it’s drawn on demand by a small JavaScript program.
♦ Create an HTML page with a <canvas> tag: Of course, you need the <canvas> tag in your document; the element designates a part of the page that displays a graphic. The image of a canvas element is not pulled from an external file but created with JavaScript code.
♦ Extract a drawing context from the canvas: It’s only possible to do 2D graphics with a <canvas> tag, but 3D canvases are expected in the future.
♦ Use special drawing commands to modify the context: The canvas mechanism supports a number of special JavaScript commands that allow you to draw and manipulate shapes directly on the surface. This example draws a number of circles in different colors to create an interesting pattern.
Although the <canvas> tag may not be that interesting, it’s one of the most important features of HTML 5 because it changes the way programmers think about Web development. Because the client program draws the image, the image can be modified in real time and interact with the user. Here are some examples:
♦ Dynamic graphs: A Web page describing data can have graphs that automatically change when the underlying data changes.
♦ Custom components: A programmer can create entire new widgets to replace the ordinary buttons and list boxes. This will likely lead to Web-based user interfaces as rich as those now on the desktop.
♦ Gaming and animation: Until now, online gaming has required third-party applications (such as Flash or Java). The <canvas> tag promises full graphics capability directly in the browser. Enterprising programmers have already written some very interesting games using the <canvas> tag.
♦ An entire operating system: It’s possible that high-powered Web browsers with very fast JavaScript engines will be able to recreate much of an entire operating system using the <canvas> tag as a graphical interface. A number of interesting devices are already using Web-based tools as the foundation of the GUI. It’s probably not a coincidence that the new browser and the new operating system by Google have the exact same name (Chrome).
The <canvas> tag will likely have a profound effect on Web development, but it isn’t heavily used yet. One major browser (guess which one) has decided not to implement the <canvas> tag. (Okay, I’ll tell you. It’s Internet Explorer.) Canvas is so important to the Web that Google has built a canvas plugin so canvas-based apps will work in IE.
Other Promising Features
HTML 5 offers some other very interesting capabilities. Most of the advanced tools won’t be used by beginning Web developers, but they’ll add very interesting new capabilities to the Web if they are adopted universally.
♦ Geolocation: If a device has GPS or Wi-Fi triangulation hardware built in (as many high-end cellphones, PDAs, and smartphones do), the geolocation tool will allow the programmer to determine the current position of the browser. This will have interesting consequences, as a search for gas stations can be automatically limited to gas stations within a certain radius of the current position (as one example).
♦ Local storage: Developers are working to build complete applications (replacements for word processors, spreadsheets, and other common tools) that are based on the Web browser. Of course, this won’t work when the computer is not online. HTML 5 will have mechanisms for automatically storing data locally when the machine is not online, and synchronizing it when possible.
♦ Drag-and-drop: Currently, you can implement a form of drag and drop inside the Web browser (see Book VII, Chapter 4 for an example). The next step is to allow users to drag a file from the desktop to an application running in the browser and have the browser app use that data. HTML 5 supports this mechanism.
Limitations of HTML 5
HTML 5 looks very exciting, and it points to fascinating new capabilities. However, it isn’t here yet. Most of the browser manufacturers support at least some form of HTML 5, but none support every feature. One notable developer has stayed far away from the HTML 5 specification. As of IE8, Microsoft does not support the <audio> or <video> tags, the <canvas> tag, or the semantic elements described in this chapter. To be fair, Microsoft has allowed embedded fonts for quite some time, but only using the proprietary EOT font format. Microsoft has not committed to including any HTML 5 features in IE9. If Microsoft continues to go its own way and Internet Explorer remains a dominant browser, HTML 5 technologies may never gain traction. It’s also possible that Microsoft’s refusal to abide by standards will finally erode its market share enough that they will decide to go along with developer requests and support these new standards in an open way.
HTML 5 is not yet an acknowledged standard, and one of the most prominent browsers in use doesn’t support it. For that reason, I still use XHTML 1.0 strict as my core language, and most examples in this book use that standard. However, I do highlight potential uses of HTML 5 when they occur in this book.
Book II
Styling with CSS
Change your fonts, colors, and backgrounds with CSS.
Chapter 1: Coloring Your World
In This Chapter
Introducing the style element
Adding styles to tags
Modifying your page dynamically
Specifying foreground and background colors
Understanding hex colors
Developing a color scheme
XHTML does a good job of setting up the basic design of a page, but face it: The pages it makes are pretty ugly. In the old days, developers added a lot of other tags to HTML to make it prettier, but it was a haphazard affair. Now, XHTML disallows all the tags that made pages more attractive. That sounds bad, but it isn’t really a loss. Today, XHTML is almost always written in concert with CSS (Cascading Style Sheets). It’s amazing how much you can do with CSS to beautify your XHTML pages.
CSS allows you to change the color of any image on the page, add backgrounds and borders, change the visual appearance of elements (like lists and links), as well as customize the entire layout of your page. Additionally, CSS allows you to keep your XHTML simple because all the formatting is stored in the CSS. CSS is efficient, too, because it allows you to reuse a style across multiple pages. If XHTML gives your pages structure, CSS gives them beauty.
This chapter gets you started by describing how to add color to your pages.
Now You Have an Element of Style
The secret to CSS is the style sheet, a set of rules for describing how various objects will display. For example, look at basicColors.html in Figure 1-1.
Figure 1-1: This page is in color!
Nothing in the XHTML code provides color information. What makes this page different from plain XHTML pages is a new section that I’ve stashed in the header. Take a gander at the code to see what’s going on:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html lang=”EN” dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”content-type” content=”text/xml; charset=utf-8” />
<title>basicColors.html</title>
<style type = “text/css”>
body {
color: yellow;
background-color: red;
}
h1 {
color: red;
background-color: yellow;
}
</style>
</head>
<body>
<h1>Red text on a yellow background</h1>
<p>
Yellow text on a red background
</p>
</body>
</html>
As you can see, nothing is dramatically different in the XHTML code. The body simply contains an h1 and a p. Although the text mentions the colors, nothing in the XHTML code makes the colors really happen.
The secret is the new <style></style> pair I put in the header area:
<style type = “text/css”>
body {
color: yellow;
background-color: red;
}
h1 {
color: red;
background-color: yellow;
}
</style>
The <style> tag is an HTML tag, but what it does is special: It switches languages! Inside the style elements, you’re not writing XHTML anymore. You’re in a whole new language — CSS. CSS has a different job than XHTML, but they’re made to work well together.
Setting up a style sheet
Style sheets describe presentation rules for XHTML elements. If you look at the preceding style sheet (the code inside the <style> tags), you can see that I’ve described presentation rules for two elements: the <body> and <h1> tags. Whenever the browser encounters one of these tags, it attempts to use these style rules to change that tag’s visual appearance.
Styles are simply a list of selectors (places in the page that you want to modify). For now, I use tag names (body and h1) as selectors. However, in Chapter 3 of this minibook, I show many more selectors that you can use.
Each selector can have a number of style rules. Each rule describes some attribute of the selector. To set up a style, keep the following in mind:
♦ Begin with the style tags. The type of style you’ll be working with is embedded into the page. You should describe your style in the header area.
♦ Include the style type in the header area. The style type is always “text/css”. The beginning <style> tag always looks like this:
<style type = “text/css”>
♦ Define an element. Use the element name (the tag name alone) to begin the definition of a particular element’s style. You can define styles for all the XHTML elements (and other things, too, but not today). The style rule for the body is designated like this:
body {
♦ Use braces ({}) to enclose the style rules. Each style’s rules are enclosed in a set of braces. Similar to many programming languages, braces mark off special sections of code. It’s traditional to indent inside the braces.
♦ Give a rule name. In this chapter, I’m working with two very simple rules: color and background-color. Throughout this minibook, you can read about many more CSS rules (sometimes called attributes) that you can modify. A colon (:) character always follows the rule name.
♦ Enter the rule’s value. Different rules take different values. The attribute value is followed by a semicolon. Traditionally, each name-value pair is on one line, like this:
body {
color: yellow;
background-color: red;
}
Changing the colors
In this very simple example, I just changed some colors around. Here are the two primary color attributes in CSS:
♦ color: This refers to the foreground color of any text in the element.
♦ background-color: The background color of the element. (The hyphen is a formal part of the name. If you leave it out, the browser won’t know what you’re talking about.)
With these two elements, you can specify the color of any element. For example, if you want all your paragraphs to have white text on a blue background, add the following text to your style:
p {
color: white;
background-color: blue;
}
You’ll figure out many more style elements in your travels, but they all follow the same principles illustrated by the color attributes.
Specifying Colors in CSS
Here are the two main ways to define colors in CSS. You can use color names, such as pink and fuchsia, or you can use hex values. (Later in this chapter, in the section “Creating Your Own Color Scheme,” you find out how to use special numeric designators to choose colors.) Each approach has its advantages.
Using color names
Color names seem like the easiest solution, and, for basic colors like red and yellow, they work fine. However, here are some problems with color names that make them troublesome for Web developers:
♦ Only 16 color names will validate. Although most browsers accept hundreds of color names, only 16 are guaranteed to validate in CSS and XHTML validators. See Table 1-1 for a list of those 16 colors.
♦ Color names are somewhat subjective. You’ll find different opinions on what exactly constitutes any particular color, especially when you get to the more obscure colors. (I personally wasn’t aware that PeachPuff and PapayaWhip are colors. They sound more like dessert recipes to me.)
♦ It can be difficult to modify a color. For example, what color is a tad bluer than Gainsboro? (Yeah, that’s a color name, too. I had no idea how extensive my color disability really was.)
♦ They’re hard to match. Let’s say you’re building an online shrine to your cat and you want the text to match your cat’s eye color. It’ll be hard to figure out exactly what color name corresponds to your cat’s eyes. I guess you could ask.
Table 1-1 Legal Color Names and Hex Equivalents | |
| Color | Hex Value |
| Black | #000000 |
| Silver | #C0C0C0 |
| Gray | #808080 |
| White | #FFFFFF |
| Maroon | #800000 |
| Red | #FF0000 |
| Purple | #800080 |
| Fuchsia | #FF00FF |
| Green | #008800 |
| Lime | #00FF00 |
| Olive | #808000 |
| Yellow | #FFFF00 |
| Navy | #000080 |
| Blue | #0000FF |
| Teal | #008080 |
| Aqua | #00FFFF |
The mysterious hex codes are included in this table for completeness. It’s okay if you don’t understand what they’re about. All is revealed in the next section.
Putting a hex on your colors
Colors in HTML are a strange thing. The “easy” way (with color names) turns out to have many problems. The method most Web developers really use sounds a lot harder, but it isn’t as bad as it may seem at first. The hex color scheme uses a seemingly bizarre combination of numbers and letters to determine color values. #00FFFF is aqua. #FFFF00 is yellow. It’s a scheme only a computer scientist could love. Yet, after you get used to it, you’ll find the system has its own geeky charm. (And isn’t geeky charm the best kind?)
Hex colors work by describing exactly what the computer is doing, so you have to know a little more about how computers work with color. Each dot (or pixel) on the screen is actually composed of three tiny beams of light (or LCD diodes or something similar). Each pixel has tiny red, green, and blue beams.
The light beams work kind of like stage lights. Imagine a black stage with three spotlights (red, green, and blue) trained on the same spot. If all the lights are off, the stage is completely dark. If you turn on only the red light, you see red. You can turn on combinations to get new colors. For example, turning on red and green creates a spot of yellow light. Turning on all three lights makes white.
Coloring by number
You could devise a simple system to describe colors by using 1 to represent on and 0 to represent off. In this system, three digits represent each color, with one digit each for red, green, and blue. So, red would be 100 (turn on red, but turn off green and blue), and 111 would be white (turn on all three lights).
This system produces only eight colors. In a computer system, each of the little lights can be adjusted to various levels of brightness. These values measure from 0 (all the way off) to 255 (all the way on). Therefore, you could describe red as rgb(255, 0, 0) and yellow as rgb(255, 255, 0).
The 0 to 255 range of values seems strange because you’re probably used to base 10 mathematics. The computer actually stores values in binary notation. The way a computer sees it, yellow is actually 111111111111111100000000. Ack! There has to be an easier way to handle all those binary values. That’s why we use hexadecimal notation. Read on. . . .
Hex education
All those 1s and 0s get tedious. Programmers like to convert to another format that’s easier to work with. It’s easier to convert numbers to base 16 than base 10, so that’s what programmers do. You can survive just fine without understanding base 16 (also called hexadecimal or hex) conversion, but you should understand a few key features, such as:
♦ Each hex digit is shorthand for four digits of binary. The whole reason programmers use hex is to simplify working with binary.
♦ Each digit represents a value between 0 and 15. Four digits of binary represent a value between 0 and 15.
♦ We have to invent some digits. The whole reason hex looks so weird is the inclusion of characters. This is for a simple reason: There aren’t enough numeric digits to go around! Table 1-2 illustrates the basic problem.
Table 1-2 Hex Representation of Base Ten Numbers | |
| Decimal (Base 10) | Hex (Base 16) |
| 0 | 0 |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
| 8 | 8 |
| 9 | 9 |
| 10 | A |
| 11 | B |
| 12 | C |
| 13 | D |
| 14 | E |
| 15 | F |
The ordinary digits 0–9 are the same in hex as they are in base 10, but the values from 10–15 (base ten) are represented by alphabetic characters in hexadecimal.
If all this math theory is making you dizzy, don’t worry. I show in the next section some shortcuts for creating great colors using this scheme. For now, though, here’s what you need to understand to use hex colors:
♦ A color requires six digits of hex. A pixel requires three colors, and each color uses eight digits of binary. Two digits of hex cover each color. Two digits represent red, two for green, and finally two for blue.
♦ Hex color values usually begin with a pound sign. To warn the browser that a value will be in hexadecimal, the value is usually preceded with a pound sign (#). So, yellow is #FFFF00.
Working with colors in hex may seem really crazy and difficult, but it has some important advantages:
♦ Precision: Using this system gives you a huge number of colors to work with (over 16 million, if you really want to know). There’s no way you could come up with that many color names on your own. Well, you could, but you’d be very, very old by the time you were done.
♦ Objectivity: Hex values aren’t a matter of opinion. There could be some argument about the value of burnt sienna, but hex value #666600 is unambiguous.
♦ Portability: Most graphic editors use the hex system, so you can pick any color of an image and get its hex value immediately. This would make it easy to find your cat’s eye color for that online shrine.
♦ Predictability: After you understand how it works, you can take any hex color and convert it to a value that’s a little darker, a little brighter, or that has a little more blue in it. This is difficult to do with named colors.
♦ Ease of use: This one may seem like a stretch, but after you understand the Web-safe palette, which I describe in the next section, it’s very easy to get a rough idea of a color and then tweak it to make exactly the form you’re looking for.
Using the Web-safe color palette
A long time ago, browsers couldn’t even agree on what colors they’d display reliably. Web developers responded by working within a predefined palette of colors that worked pretty much the same on every browser. Today’s browsers have no problems showing lots of colors, but the so-called Web-safe color palette is still sometimes used because it’s an easy starting point.
The basic idea of the Web-safe palette (shown in Table 1-3) is this: Each color can have only one of the following values: 00, 33, 66, 99, CC, or FF. 00 is the darkest value for each color, and FF is the brightest. The primary colors are all made of 0s and Fs: #FF0000 is red (all red, no green, no blue). A Web-safe color uses any combination of these values, so #33CC00 is Web-safe, but #112233 is not.
Table 1-3 Web-Safe Color Values | |||
| Description | Red | Green | Blue |
| Very bright | FF | FF | FF |
| CC | CC | CC | |
| 99 | 99 | 99 | |
| 66 | 66 | 66 | |
| 33 | 33 | 33 | |
| Very dark | 00 | 00 | 00 |
To pick a Web-safe value from this chart, determine how much of each color you want. A bright red will have red turned on all the way (FF) with no green (00) and no blue (00), making #FF0000. If you want a darker red, you might turn the red down a little. The next darker Web-safe red is #CC0000. If that isn’t dark enough, you might try #990000. Let’s say you like that, but you want it a little purple. Simply add a notch or two of blue: #990033 or #990066.
Choosing Your Colors
Figure 1-2 shows the colorTester.html program I added to the Web page and CD-ROM. This page lets you experiment with colors. I refer to it during this discussion.
The best way to understand colors is to do some hands-on experimentation. You can use the colorTester.html page to do some quick tests, or you can write and modify your own pages that use color.
Figure 1-2: This program lets you quickly test color combinations.
Starting with Web-safe colors
The colorTester.html program works by letting you quickly enter a Web-safe value. To make red, press the FF button in the red column. The blue and green values have the default value of 00, so the background is red.
The Web-safe colors give you a lot of room to play, and they’re very easy to work with. In fact, they’re so common that you can use a shortcut. Because the Web-safe colors are all repeated, you can write a repeated digit (FF) as a single digit (F). You can specify magenta as either #FF00FF or as #FOF and the browser understands, giving you a headache-inducing magenta.
To make a darker red, change the FF to the next smallest value, making #CC0000. If you want it darker yet, try #990000. Experiment with all the red values and see how easy it is to get several different types of red. If you want a variation of pink, raise the green and blue values together. #FF6666 is a dusty pink color; #FF9999 is a bit brighter; and #FFCCCC is a very white pink.
Modifying your colors
The Web-safe palette is convenient, but it gives you a relatively small number of colors (216, if you’re counting). Two hundred and sixteen crayons in the box are pretty nice, but you might need more. Generally, I start with Web-safe colors and then adjust as I go. If you want a lighter pink than #FFCCCC, you can jump off the Web-safe bandwagon and use #FFEEEE or any other color you wish!
In the colorTester.html program, you can use the top and bottom button in each row to fine-tune the adjustments to your color.
Doing it on your own pages
Of course, it doesn’t really matter how the colors look on my page. The point is to make things look good on your pages. To add color to your pages, do the following:
1. Define the XHTML as normal.
The XHTML shouldn’t have any relationship to the colors. Add the color strictly in CSS.
2. Add a <style> tag to the page in the header area.
Don’t forget to set the type = “text/css“ attribute.
3. Add a selector for each tag you want to modify.
You can modify any HTML tag, so if you want to change all the paragraphs, add a p { } selector. Use the tag name without the angle braces, so <h1> becomes h1{ }.
4. Add color and background-color attributes.
You’ll discover many more CSS elements you can modify throughout Books II and III but for now, stick to color and background-color.
5. Specify the color values with color names or hex color values.
Changing CSS on the fly
If you’ve installed the Web Developer toolbar to Firefox (which I describe in Book I, Chapter 3) you have some nifty CSS tools at your disposal. I really love the CSS editor. To make it work, take any page (with or without CSS) and open it in Firefox. For this example, I use a list example from Book I, Chapter 4.
Be sure the Web Developer toolbar is installed and then choose Edit CSS from the CSS menu. A new panel that looks similar to Figure 1-3 appears.
You can simply type CSS code into the little text editor, and the page updates instantly! Figure 1-4 shows the same page after I made a few changes.
Figure 1-3: The Web Developer toolbar has a great CSS feature.
Figure 1-4: The CSS changes show immediately.
I used color to make the definition list easier to view. I changed both the foreground and background colors in the heading level 1. I set the definition terms (dt) to red and added a yellow background to the definitions (dd). Check Book I, Chapter 4 if you need a refresher on definition lists in XHTML.
The Web Developer CSS editor is great because you can see the results in real time. It’s a super way to play around with your colors (and other CSS elements). You can also use it to view and modify an existing CSS document. Pull up any page you want and open the CSS editor. You can change colors all you want without making a commitment.
Creating Your Own Color Scheme
The technical side of setting colors isn’t too difficult, but deciding what colors to use can be a challenge. Entire books have been written about how to determine a color scheme. A little bit of subjectivity is in the process, but a few tools and rules can get you started.
Understanding hue, saturation, and value
The RGB color model is useful because it relates directly to how computers generate color, but it’s not perfect. It’s a bit difficult to visualize variations of a color in RGB. For that reason, other color schemes are often used. The most common variation is Hue, Saturation, and Value, or HSV. The HSV system organizes colors in a way more closely related to the color wheel.
To describe a color using HSV, you specify three characteristics of a color using numeric values:
♦ Hue: The basic color. The color wheel is broken into a series of hues. These are generally middle of the road colors that can be made brighter (closer to white) and darker (closer to black).
♦ Saturation: How pervasive the color is. A high saturation is very bright. A low saturation has very little color. If you reduce all the saturation in an image, the image is grayscale, with no color at all.
♦ Value: The brightness of the color. The easiest way to view value is to think about how the image would look when reduced to grayscale (by pulling down the saturation). All the brighter colors will be closer to white, and the darker colors will be nearly black.
The HSV model is useful because it allows you to pick colors that go well together. Use the hue property to pick the basic colors. Because there’s a mathematical relationship between the various color values, it becomes easy to predict which colors work well together. After you have all the hues worked out, you can change the saturation and value to modify the overall tone of the page. Generally, all the colors in a particular scheme have similar saturation and values.
Unfortunately, you can’t specify CSS colors in HSV mode. Instead, you have to use another tool to get the colors you want and convert them to RGB format.
Using the Color Scheme Designer
Some people have great color sense. Others (like me) struggle a little bit because it all seems a little subjective. If you’re already confident with colors, you may not need this section — although, you still might find it interesting validation of what you already know. On the other hand, if you get perplexed in a paint store, you might find it helpful to know that some really useful tools are available.
One great way to get started is with a free tool: the Color Scheme Designer, shown in Figure 1-5. This tool created by Petr Stanicek uses a variation of the HSV model to help you pick color schemes. You can find this program at http://colorschemedesigner.com.
Figure 1-5: The Color Scheme Designer helps you pick colors.
The Color Scheme Designer has several areas, such as:
♦ The color wheel: This tool may bring back fond memories of your elementary school art class. The wheel arranges the colors in a way familiar to artists. You can click the color wheel to pick a primary color for your page.
♦ The color scheme selector: You can pick from a number of color schemes. I describe these schemes a little later in this section.
♦ A preview area: This area displays the selected colors in action so you can see how the various colors work together.
♦ Hex values: The hex values for the selected colors display on the page so you can copy them to your own application.
♦ Variations: You can look at variations of the selected scheme. These variations are often useful because they show differences in the saturation and value without you doing the math.
A complete and fully updated reference for these key Web technologies
HTML, XHTML, and CSS are essential tools for creating dynamic Web sites. This friendly, all-in-one guide covers what programmers need to know about each of the technologies and how to use them together.
Like the bestselling first edition, HTML, XHTML, and CSS All-in-One For Dummies, 2nd Edition makes it easy to grasp the fundamentals and start building effective Web pages. With new information about Web 2.0 and Ajax, it’s the perfect reference as well.
Web programmers and designers will find what they most need to know in HTML, XHTML, and CSS All-in-One For Dummies, 2nd Edition, helping them create the type of Web sites that today’s market demands.