This page is the online technical companion to the VisiBone HTML Card and HTML Foldouts, including elaboration of the bugs and clashes indicated on the card as well as errata and updates (by page number, below). Contributions and feedback are most welcome! stein@visibone.com
Index to this page:
Clashes
Bugs (coming)
Color coding
Examples (page 1)
Elements (tags) and Attributes (page 2)
CSS (Cascading Style Sheet) Properties (page 3)
Special Characters (page 4)
W3.org
Microsoft
URL's
XHTML
Pontifications
References
<img align=middle> |
Suggest using <img align=absmiddle> instead. Consistently across all browsers, align=absmiddle vertically aligns the middle of the image with the middle of the surrounding text. (It was used on the crossed-swords icon in the header of this section.)
About align=middle:
By the way, neither browser documents align=center but both seem to support it, and treat it exactly like align=middle, in all its rich tapestry. |
<frameset border framespacing frameborder> |
Suggest always setting all three to 0 for seamless frames. The gory details:
By the way, confounding efforts to experiment with these factors:
|
<li type> |
If used, suggest using on every <li> item in the list |
<table bgcolor> or <body |
Avoid by either not using <table bgcolor> (as was done in this table) or setting cellspacing= 0 for seamless table cells. (Cellpadding on the other hand consistently follows <td bgcolor> if specified or <table bgcolor> or the surrounding bgcolor.) |
<table bordercolor> |
A rather athletic (strenuous and risky) workaround is to use IE-only bordercolorlight and bordercolordark attributes to simulate the Netscape 3D look. For solid borders, set border=0 and embed the table in a 1-cell table whose bgcolor serves as that border (and whose cellpadding serves as its width). |
<textarea wrap> |
Always explicitly specify wrap=soft. (Thanks to Marie for pointing this out.) This attribute used to be known as wrap=virtual. (Thanks to Sizzling HTML Jalfrezi for this factoid.) |
<wbr> |
Suggest using only when you don't mind it not working. |
The color coding is roughly (screen & print colors may differ):
Netscape only
IE only
W3.org only
Not Netscape
Not IE
Not W3.org
The colors reflect the latest released versions, so Netscape-only and Not-Netscape colorations apply to Netscape 4.73. IE colorations to 5.5 and W3C to HTML 4.01 and XHTML 1.0. Some supported and unsupported features of Netscape 6 are indicated by (N6) and (N6). Netscape 6-PR2 (Preview Release 2) was the latest available when the HTML Card went to press (11 Sep 2000).
Example HTML Page. Here's the "Laurel's Web Project Outline" page from the front cover of the HTML Card. And here's the Example CSS. Laurel is a real person who's pontification on the the Webdesign-L mailing list inspired me to make up this fictional page.
Meta keywords and descriptions. For more on what search engines like and don't like (and timely seasoned guidance on what webmasters can automate and what they must think very hard about), check out the incomparable, the indispensable Web Position GOLD.
Space Engineering: moving spaces inside the tags. "There are other reasons" I say airily in one of the help bubbles on page 1 of the HTML Card "to eliminate white space, or to move it inside a tag." Thanks to Adam Bell for helping me remember the other reasons: Netscape table cells might show some of the white space in them. So instead of:
<td> <img src="button.gif" /> </td>
you may code:
<td><img src="button.gif" /></td>
or, though ugly:
<td ><img src="button.gif" /></td>
Space inside tags doesn't count.
Border Hover-Hints: Nils Devine reports that the example style-sheet red-border hover-hint works in IE5.5 but not in IE5.0. We don't know whether it's a:hover, border, margin:-1px or a combination that does not work.
a:hover { border:red solid 1px; margin:-1px; }
Color errata: email entry box attribute value should be color-coded as it's a pivotal attribute value:
<input type="text" ... > (is)
<input type="text" ... > (should be)
(This item applies to edition 1, the September 2000 edition, of the HTML Card)
<img alt>, <area alt> and the title attribute. HTML 4.01 describes the alt attribute as a "short description" or "alternate text to serve as content when the element cannot be rendered normally". In IE4-5 and Netscape 4 it specifies the content of tool tips (hover hints), but this is a legacy association. The title attribute appears the most likely to be used to control tool tips in future browsers. In IE5.5 at least either will work. Thanks to Patrick Woolsey of Bare Bones.
<del> (N6) Appears as strike-through in Netscape 6, as it does in IE. Thanks, Maki. (This item applies to edition 1, the September 2000 edition, of the HTML Card)
<iframe> (N6) Included frames work in Netscape 6, at least as of Preview Release 2, my mistake. Thanks to Maki for pointing this out. (edition 1)
<input type="image"> RDW thoughtfully reports Netscape (though not IE 5.5) displays the name attribute as a hover hint, contrary to the HTML Card's characterization of the name being invisible to the user. (In any case, the name is always submitted to the server in name=value pairs.) (edition 1)
<ins> (N6) Appears as underline in Netscape 6, as it does in IE. Thanks, Maki. (edition 1)
<layer> <ilayer> <nolayer> (N6) Thanks to Maki for pointing out that layers are NOT supported at all in Netscape 6! So it is only supported in Netscape 4. Netscape has helpful explanations and suggestions. (edition 1)
<meta name="ROBOTS" content="NOARCHIVE"> Thanks to MarketPosition newsletter for reporting that this syntax prevents Google from caching your page. (WebCrawler seems to have pioneered a standard for the robot meta-tag but it doesn't appear to have changed since the big bang, i.e. 1994.) (edition 1)
<pre><font face="Arial">
<pre style="font-family:Arial"> Thanks to John Bedard's questions & experiments on webdesign-L for bringing out that this technique can be used to control line breaks. John was controlling the hover-hint text inside this outline of Montana. John actually used Style Scheme 4 ("#id" style and <div id=id><pre> tags) to do this.
<table> ... </table> Kathie Kellog of CCNow thoughtfully mentioned how often she sees pages go blank in Netscape because the end-tag was left off of a table element. I remember being confounded by that too.
<td valign> Thanks to Keely for pointing out that the top|middle|baseline|bottom options here are identical to those of the {vertical-align} style sheet property.
<td bgcolor> Thanks to Jim Bills for pointing out a table cell must have something substantial in it for Netscape 4 to render its background color. Insert a or a 1x1 pixel transparent GIF if nothing else. More space engineering.
HTML Color: And thanks to alert webdesign-L member Joe C. for pointing out that bgcolor="" shows up black for Netscape 4. And Beth S. for discovering that Netscape 4 can do very unnatural things with unrecognized color names: "inherit" is bright green, "foo" is red, "foobar" is fuschia. Many other names are just black. Just like Netscape 4 does with CSS colors.
<td width="100%"> appears to include 100% of the frame it's in, not the containing block, at least in IE5.5.
<tr align> versus <td align> author Deborah Shadovitz thoughtfully reported she recalls some fundamental conflict here, like HTML wants <tr> to have precedence and CSS wants <td> to have precedence (possibly through the equivalent property {text-align}). When in doubt, specify alignment on all cells and no rows
<title> Gareth Bramley helped to discover (and Justin Kramer also pointed out) that a slash / in the title is automatically translated into a dash - in IE when added to favorites (bookmarked).
Style Attribute id: XHTML 1.0 mentions using name and id with the same value for forward and backward compatibility (sections 4.10 and C.8) for the <a> anchor tag. The HTML Card says XHTML recommends both (in the Style Attributes section on page 2) and that's inaccurate, it's more of a suggestion. Also, I may have taken too much license extrapolating that practice to all elements. I believe a similar double-entry issue exists with some other elements, such as <object> and form field elements (<input> <textarea> <select> etc.). A JavaScript program can manipulate almost any HTML element by its id attribute. That's clearly the way things are headed. But JavaScript in some semi-stale browsers may need to use the name attribute. I haven't tested this. Clearly I should for the future JavaScript/DOM card. Thanks to Patrick Woolsey of Bare Bones Software for his thinking along these lines. (edition 1)
On quoted attribute values, Patrick Woolsey offers: HTML requires attribute values be quoted when containing anything other than: letters, numbers, hyphen, underscore, or colon. Not only for a value containing spaces. For example <a href=file?search> is invalid in HTML 4: <a href="file?search">. (edition 1)
{border} and its ilk appear unsupported in IE4 and buggy under IE5 (thanks to ltodd for pointing this out). (This item applies to edition 1, the September 2000 edition, of the HTML Card)
While I would not suggest this at a stylish dinner party, at the websmithy I would: nested tables. This rough-and-ready application of Dave Raggett's eminently versatile element is used twice in the example HTML on page 1 of the HTML Card:
<table border="0" cellspacing="0" cellpadding="1"><tr><td bgcolor=my-border-color> <table border="0" cellspacing="0" cellpadding="5"><tr><td bgcolor=my-background-color> ... ... </td></tr></table> </td></tr></table>
This gives you a 1-pixel border and 5 pixels of "padding" (room inside border, around content). Drawback is the tables are block-elements and will not flow inside text. I used this technique in the HTML Card feature list under "Border color indicates lone unsupport".
Joe Gillespie of www.wpdfd.com has settled on a minimum reasonably readable {font- size} (MRRFS) of 11px. He uses Verdana, Geneva, Arial, sans-serif.
{color:unknown-name} In Netscape 4 this can give very strange results, as if the color name were forced through some twisted kind of hexadecimal conversion. Have seen "ButtonFace" show up magenta and "inherit" show up bright green. Thanks to alert webdesign-L member Beth S. for reporting this fascinating phenomenon. She discovered the same strangeness seems to happen with HTML Colors.
{filter:progid:DXImageTransform.Microsoft.whatever} The references erroneously leave out the DX part so Image → DXImage.
{padding} This style is a mess. If you specify it, check things on lots of browser window sizes and lots of browser brands (tip: browsercam.com). Netscape 4 has major quirks. Seems to amplify the padding at whim, perhaps when filling out a wide table? Also there always seems to be a 3-pixel gap between the background color and the border. If this is supposed to be the padding, it's always the same size and always the same color as the margin. Also, when applied using <span> (perhaps not a good idea) an increase in padding without a border causes overlap. Yet more, increasing the padding can cause extra white space after a line or paragraph with nonzero padding. Finally, increasing the padding can increase line-height in Netscape 4, while IE will overlap the text above, and requires extra line-height to avoid it. But Netscape 6 will add extra text background-color above and below (with Netscape 4 its the page background color). The indentation of an unordered list item (<li> inside <ul>) can be reduced by lowering the padding in Netscape 6-7, but not IE or Netscape 4. One more tip: when changing padding or margin, always change the other. Fore example: ul {margin-left:15px;padding-left:0px} This seems to get some compatibility issues in line.
{vertical-align} The values top|middle|baseline|bottom can be used in place of the <td valign> attribute. These and some others appear to be usable in place of the <img align> attribute. Thanks to Keely for revealing the need for more study here.
VisiBone's Online Curious Web Character Reference
All 65535 Unicode characters as they appear on your system, zoomed in or out. Numeric or alphabetical order. All 256 Web ASCII character codes, single byte 0-255.
Numeric Character References
Walter Ian Kaye has an excellent online character reference. He set me straight on Numeric Character References like ™ or ™ or They are supposed to always be from ISO-8859-1 or Unicode and never windows-1252, even though all the major browsers are entrenched otherwise for codes 130-159. So it's more in line with the future to encode an em-dash as a single decimal 151 byte in a web page and call the character set for the page "windows-1252" than it is to use the sequence — and rely on browser momentum to render it an em-dash. This explains at last the propensity in Microsoft® FrontPage® to unilaterally make this exact translation.
Walter also gave me a great tip on Alt keystrokes. Alt-3-digit keystrokes on most PC programs do indeed use the original PC Display Adapter character mapping as reported (in white-on-dark-gray lettering) on the back of the HTML Card. But Alt-4-digit keystrokes with a zero-prefix can be used under Windows (but not under DOS) for the windows-1252 character mapping. For example, the cent-sign ¢ is ¢ or a single decimal 162 byte. One can enter it by typing either Alt-155 or Alt-0162. This can help with all other character codes under Ā. For example © is Alt-0169. And the most common special character of all: Alt-0160 can embed non-break space. I used it throughout this sentence, which you can see will not wrap.
Unfortunately it's no help with character codes 256 and over. Alt-0931 does not make an uppercase sigma. (It makes an English Pounds Sterling sign £ because of 8-bit truncation: 931-256-256-256 = 163 and Alt-0163 is a £.)
Not-So-Special ASCII Characters
Melissa Holden thoughtfully pointed out I'm missing some characters like plus sign (+) and asterisk (*). In a rather nerdly assumption I left out all standard ASCII characters to save space, thinking folks would naturally seek those on the keyboard. Foolishly I assumed everyone was familiar with ASCII, as I've known it more than half my life. I should have at least mentioned "These are the characters other than what you'll find on a normal English-language keyboard." Here then are the 94 printable ASCII characters not included in the Special Characters section:
~ ! @ # $ % ^ & * ( ) _ +
` 1 2 3 4 5 6 7 8 9 0 - =
Q W E R T Y U I O P { } |
q w e r t y u i o p [ ] \
A S D F G H J K L : "
a s d f g h j k l ; '
Z X C V B N M < > ?
z x c v b n m , . /
And thanks again to Ms. Holden for pointing out that the following four ASCII characters from the upper left corner of the Special Characters page should always be encoded in HTML, as many tools do automatically:
" & < >
" & < >
(As you can see if you View the Source of this page, FrontPage 2000 encoded all of them. A single-quote should also be encoded but ' is not nearly universal yet)
HTML to XHTML Checklist (page 4)
Patrick Woolsey of Bare Bones pointed out that the first example is invalid in XHTML. Here is the new entry I plan to use:
Lower-case elements and attributes: <TD VALIGN="top"> to <td valign="top">
(This item applies to edition 1, the September 2000 edition, of the HTML Card)
<?xml ...?> Some validators require a space before the terminator. It appeared to be a bug for a while:
XHTML 1.0 section 3.1.1 seems to favor this minimal header on all XHTML files:
<?xml version="1.0" encoding="UTF-8"?>But the XHTML validator used to reject it, and ones like it. Thanks to Martin we know the truth: some validators require a space before the ?> terminator:<?xml version="1.0" encoding="UTF-8" ?>
Text foreground/background. The CSS Validator frets when you specify color without simultaneously specifying background-color. It gives numerous warnings to this effect on example.html but otherwise approves it.
Linked CSS does not appear to be supported in Microsoft® FrontPage® 2000. So if you edit example.html it will not appear the same as when browsing.
windows-1252 appears to be the universal default character set (also called character encoding) for all browsers, though IANA doesn't even define the name, let alone document the coding. (I haven't tried browsers other than for English-US.)
The Microsoft windows-1252 spec is the only place in the known galaxy I've found it documented, for example, that — is an em dash a favorite character of mine. That is the only code for em dash supported in Netscape 3. Other codes are — (Netscape 4) and — (Netscape 6). All are supported in IE4 - IE5.5.
Windows-1252, if it were defined, would probably be deprecated in favor of ISO-8859-1, which is more in sync with Unicode®. Characters € through $#159; are nonprintable control characters in those standards.
Thanks to cathersdr for pointing out the example on page 4 for lower casing XHTML tags and attribute names would be better to follow (and to mention) another rule for XHTML, that attributes must always have values (ref XHTML 4.5 and C.10):
<td nowrap="nowrap">
which touches on the problem that some browsers may not recognize the nowrap option unminimized like this.
But perhaps an even better example than that (since this attribute is deprecated in HTML 4.01) would be:
<A HREF="image.gif"> -> <a href="image.gif">
which reinforces that attribute values have no such new case restrictions.
mailto:email@company.com?subject=subject&body=body Of course! Thanks to JQS for pointing this out!
The dagger "obsolete" symbol indicates really old, bad stuff. (I started using this symbol when I read it's used in genealogies to indicate date of death.) The dagger I use for features that seem quite clearly unwise and ill-mannered to use.
The yellow pointing hand is meant to indicate a much milder reproach. Most uses of the word "deprecated" in HTML 4.01 are indicated by the stern yellow hand of W3C. Deprecated is a term gratuitously used in W3C specs. It is, I humbly suggest, often ahead of its time. More a strategic weather-vane for the future than a tactical cue for designers coding pages for anxious clients. For example, <font> was deprecated when designers had no alternative for 20% of the browsing public. (In August 2000 the figure is probably less than 1%.) When W3C deprecates a term I don't want to suggest designers would be unwise to use it. I openly (not too bluntly, I hope) differ in a few cases with W3C, such as suggesting <i> instead of <cite> <em> <var> <xmp>, where W3C deprecates <i> in favor of (one is left to guess, and I do) {font-style:italic}. What I want to communicate for W3C-deprecated features is (a) the alternative W3C appears to favor, and (b) the browser-support for both features, so designers can choose wisely.