In class, we were discussing the displaying of images with the <img> tag, and I talked about not changing the aspect ratio.  I want to make sure the concept is clear.

The aspect ratio is simply the ratio between the width and height of an image. Here is an image with a 1:1 aspect ratio — that means that the width and height are the same. Continue reading Don’t Touch that Aspect Ratio! →

As we were discussing what can fit on the screen, a question came up about the meaning of screen resolution.  Let me attempt a quick overview here.

The basic graphic unit for computers is the pixel (short for picture element).  What we see displayed on a monitor is composed of a grid of pixels.  The screen resolution is the dimensions of this grid.  For early computer monitors, a typical resolution was 640 x 480 — in other words, the grid was 640 pixels wide by 480 pixels high.   Continue reading Who needs resolutions? →

This semester, we’ve been learning new ways of doing things with HTML5.  As is so often the case, it takes a while with a new system to fully understand the best ways of doing things with that system.  Take a look at html5doctor.com/avoiding-common-html5-mistakes/for some good guidance.

As we discussed in class, sometimes we’re unable to accomplish exactly what we hoped, and we have to find work-arounds. If we stick with HTML 4 or XHTML plus CSS level 1, we have a lot of confidence that any browser is likely to render a page properly, but when we use HTML 5 and CSS 3, things aren’t always as straight-forward. Continue reading Bleeding Edge Blues? →

As you’ve been discovering all semester, it can be challenging to get your CSS code to do exactly what you want it to! Recently, I was looking over an interesting book, The CSS Detective Guide: Tricks for solving tough CSS mysteries by Denise R. Jacobs. A lot of good ideas here, much along the lines of what we’ve discussed in class, but with much greater detail.

And I learned something new. The book referred me to a page at W3C, validator.w3.org/docs/errors.html. This document explains, with a bit more verbosity than the default, the meaning of the various error messages put out by the HTML validator. Feeling stuck? Check it out!

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.