After 8-1/2 chapters of starting web pages with
  <?xml version=”1.0″ encoding=”UTF-8″?>,
the author suddenly springs a new version on us on page 359:
  <?xml version=”1.0″ encoding=”iso-8859-1″?>!

I don’t know why she did that — presumably it’s a mistake.  But the good news is that it doesn’t
matter:  you can expect to get similar results with either character set specified.

Hmmm, another language, different syntax, more attributes to remember.  The good news is that in the long run, Cascading Style Sheets make it easier to create and maintain attractive, consistent-looking web pages.  As I’ve mentioned in class, the W3C has a CSS Validator, which works similarly to the XHTML Validator.  (One warning:  your code must successfully pass XHTML validation before the CSS validator will run.)

There are likely to be times  when the styles are not being applied as you expected, and you’ll feel like banging your head against the wall.  In general, head-banging doesn’t solve coding problems, but there are some tools which might help you.  If you prefer working in Firefox, you’ll want to install the Web Developer and Firebug extensions;  for Opera, install the Web Developer Tools.  You find links to all three on the class Tools page.  The download pages include documentation for using the tools.  Questions?  Bring them to class and we’ll try to answer them together.

Happy coding!

If I were a frog, I guess I’d be singing the greens, but either way, it’s sometimes a challenge to get code validated — partly because of our own mistakes, but partly because of tag attributes that are non-standard.  I know that some of you have run into issues trying to validate the chapter 5 case study.  As we’ve discussed in class, sometimes it’s easiest to just look at the standard to see what it says is allowed.

Sitting on a shelf right over my head is “HTML & XHTML: The Complete Reference”.
(See the  class Tools page for bibliographic details.)  I use it a lot to answer such questions, but sometimes I do bite the bullet and read the DTDs at w3.org.  The one for framesets is at www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Frameset. If you look there, you’ll find just which attributes are allowed for both frameset and frame tags. Today, I’ll save you the effort. For frameset, the only valid attributes are rows and cols — sorry, no frameborder. For frame, there are several valid attributes, including name, src, noresize, scrolling, marginheight, marginwidth, and YES, frameborder. Note that the valid values for frameborder are 0 and 1 (that’s not pixels, but rather signifying “no” or “yes”).

Happy coding.

It’s very frustrating when you try to validate an XHTML file and either the validator says it can’t make sense of your file and gives up or it gives you dozens upon dozens of error messages.  Fortunately, the problems are usually solved pretty easily.  Here are some of the most common reasons for problems:

• Prolog problems.  The validator relies on the prolog to know exactly which flavor of (X)HTML to validate your code against.  If there’s a problem with the prolog, the validator can’t do its thing.  So make sure all three lines (the XML and Doctype declaratations and the html tag with xmlns) are exactly correct.  A single mistyped character is enough to throw the whole thing off!  In particular, be careful of case-sensitivity, and with the word xhtml1, make sure you’re clear about what’s an “L” and what’s the digit ONE.
• Embedded spaces.  Space characters are never valid within a URL, so make sure that you don’t use spaces in the names of any of your HTML files or bookmark anchors.  I generally prefer to keep file names and anchor names short, but if you feel that you need a long one, name it like one of these:  FileWithALongFilename.htm or file_with_a_long_filename.htm or file-with-a-long-filename.htm.
• Invalid characters.  If the validator sees a character that is not part of the encoding character set (probably specified in your xml declaration, otherwise maybe defaulting to “UTF-8”), it will reject the entire file — but it will give you the line and column number of the offending character.   If you need to use foreign accented characters, be sure to code them with the proper HTML character entities.  Also, be careful if you copy-and-paste from another source — programs such as MS Word will convert your typed apostrophes and quotation marks into “smart quotes”, which are invalid characters to the validator.
• Use of the font tag.  Remember that the font tag is an inline element.  The validator doesn’t like to see an inline element wrapped around block-level elements (such as heading, p, ul tags).  So if you want to change the font for everything within an ordered list, for example, put a <font> ... </font> pair inside each <li> ... </li> pair.  Yeah, it’s a nuisance, which is why they developed Cascading Style Sheets as a better alternative.

Remember that we talked about the general process of validation at our third class session.  You might want to review my slides at www.nvcc.edu/home/tgutnick/itd110/slides/03c-Validation.pdf and your own notes.  You did take notes while I talked, didn’t you?

Happy validating.

Yesterday, a student asked me about problems validating a web page that included the bordercolor attribute in a table tag. As the textbook notes (page 89), this attribute was never part of the official HTML standard, so it’s not even deprecated. If you want your code to validate, you’ll have to leave it out. But as an alternative, you can sneak in some formatting using Cascading Style Sheets (which we’ll be covering later in the semester). You can do this something like this:

<table style="border-width: 1px; border-color: #999999" ... >

During the 13 September class, we looked at some of the capabilities of XHTML tables.  The basics are pretty simple:  a table contains rows (<tr>), and row contain cells (<td>).  The cells contain content — usually text (paragraphs, lists, etc.) or images.  Where things start getting complex is with tables that have cells that span multiple rows or columns, or with nested tables.

I’ve posted some code samples on the class web site at the slides page. A few samples are very simple demonstrations of row and column spanning; you might want to play with these to experiment with different combinations.  I’ve also posted a solution to the “Nova Gazette” problem we worked on.
Remember that this was a complex layout, designed to look like a newspaper. This file contains two possible extreme solutions: one done completely without nested tables, relying strictly on row and column spanning; and the other one done with multiple nested tables but no spanning. Which is best? Probably something in between.