CSS Cookbook/Browser Issues

From DPWiki
Jump to navigation Jump to search

What Is a Non-CSS Browser and Who Cares?

In designing the PG HTML standard, some people have argued strongly that the HTML of an ebook should never depend on CSS code to convey the text. Problems arise mostly in styling poetry, drama, and page numbers. Others feel that the reader who lacks a CSS-capable browser should be contented to read the plain-ASCII text file. To which the first party replies: even if it renders the pretty styles in an ugly way, the non-CSS browser still supports the hyperlinks in the TOC, index, and notes—so there is more value in the HTML version, even when the styles aren't supported.

The one often-mentioned non-CSS browser is Lynx, which is described in its Wikipedia entry this way:

Lynx is a text-only WWW browser for use on cursor-addressable, character cell terminals.

Browsing in Lynx consists of highlighting the chosen link using cursor keys, or having all links on a page numbered and entering the chosen link's number... Tables are linearized (scrunched together one cell after another without tabular structure), while frames are identified by name and can be explored as if they were separate pages... In 1995, Lynx was released under the GPL and is now maintained by a group of volunteers.

Because of its text-to-speech-friendly interface, Lynx was once popular with visually-impaired users, but better screen readers have reduced the appeal of Lynx to blind people.

The same Wikipedia entry has links to the Lynx home page and to entries describing several other text-only browsers.

How web designers see Lynx (cartoon by Illiad)

Internet Explorer 7

The long-awaited upgrade to IE7 was released in early October, 2006. It claims to have repaired most of the CSS incompatibilities present in IE5 and IE6, some of which are described below. The IE7 Developer Blog gives a technical discussion of all the fixes.

The key point in that article: in order for the fixes to be effective, the document must begin with a valid !DOCTYPE statement specifying a document type of XHTML, or a type of HTML Strict or Transitional specifying a URL for the DTD. When this is the case, IE7 should behave much more like Firefox and other standards-compliant browsers than did IE6.

Etexts you create using Guiguts automatically contain a !DOCTYPE, specifically one that reads

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

An etext that starts this way should behave properly, CSS-wise, in IE7.

(Somebody please post actual experiences?)

Col and Colgroup Unsupported

The HTML 4 standard says that one may code the <colgroup> or <col> elements in a table, and in this way specify uniform rendering of the cells of one or more columns.

(Note that the standard is not explicit about which properties of the cells can be controlled through <colgroup> or <col> elements. The HTML4 standard cited above does specifically mention "horizontal" and "vertical" alignment in cells, and also says that either element can incorporate a style attribute containing "inline style information"—and the link for that phrase leads to an example that includes the font-size property. However the CSS Standard for Column Selectors explicitly limits the properties of "column and column-group elements" to only border, background, width and visibility, thus excluding the alignment properties both horizontal (i.e. text-align) and vertical (i.e. vertical-align), either of which would be highly useful as a column property. Thus the two relevant standards are in conflict.)

In any case, if any column properties were consistently supported it would be very useful. Unfortunately the column elements are inconsistently supported across browsers. Here is a test case; the code validates as XHTML-Transitional. Try it in your browser!

<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
		Test of colgroup and col

<table border="1" style="width:100%;text-align:left;">
<caption>table using <col style=""></caption>
<col style="width:25%;text-align:justify;background-color:silver;" />
<col style="width:50%;text-align:center;vertical-align:bottom;font-style:italic;" />
<col style="text-align:right;font-weight:bold;vertical-align:top;" />
<td>This text should be justified in the column on a light-gray background.</td>
<td>centered? bottom? italic?</td>
<td>right? bold?</td>
<table border="1" style="width:100%;text-align:left;">
<caption>table using deprecated attributes in col</caption>
<col width="25%" align="justify" valign="middle" style="background-color:silver;" />
<col width="48%" align="center"  valign="bottom" style="font-style:italic;"/>
<col             align="right"   valign="top" style="font-weight:bold;" />
<td>This text should be justified (in IE6 only)
in the column on a light-gray background.</td>
<td>centered? bottom? italic?</td>
<td>right? bold?</td>

In a stunning reversal of the usual situation, Internet Explorer 6 almost fully supports this test, and all other tested browsers do not. Specifically:

Browser bg. color width text align vert align font style font weight
IE6 win-xp yes yes yes yes yes yes
IE5.2 mac yes yes no no no no
Opera 9 yes yes no(a) no(a) no no
Netscape 7.1 no yes no no no no
Omniweb 5.1 no no no no no no
Firefox 1.5 yes yes no no no no
Safari 2 yes(b) yes(b) no no no no

Note (a): Opera executes the deprecated align= and valign= coding but ignores the equivalent style declarations.

Note (b): Safari completely ignores the col or colgroup elements when they are preceded by a <caption> element. If there is no <caption> or if <caption> follows the col or colgroup elements, it executes color and width specifications. Safari allows <caption> to follow col or colgroup but the HTML validator calls this placement incorrect.

Because of inconsistent and unpredictable support, it does not seem wise to use colgroup/col elements in an etext.

Absolute Position Bugs in IE6

These cookbook styles use absolute positioning in several cases: to right-align page numbers in a TOC; to put visible page numbers in the right margin; to put poetry line numbers along the left or right margin of the poem, etc. Unfortunately, one of the most widely-used browsers, Microsoft Internet Explorer version 6 ("IE6"), has a bug that makes it mis-position positioned elements under certain circumstances. The problem has to do with the definition of a "container." To quote Eric Meyers in Cascading Style Sheets: The Definitive Guide (p. 309),

When an element is positioned absolutely, it is completely removed from the document flow. It is then positioned with respect to its containing block... The containing block for an absolutely positioned element is the nearest ancestor element that has a position value other than static. It is common for an author to pick an element that will serve as the containing block for the absolutely positioned element and give it a position of relative with no offsets...

This explains why the classes TOC and poem are coded with position:relative: so that absolutely-positioned page numbers, line numbers, or stage directions inside them will be located with respect to their margins and will stay in the same places relative to the margins as the window changes shape.

Every other tested browser (Netscape 7, Firefox, Opera 8 and 9, Safari, Camino, OmniWeb, even Internet Explorer 5.2 for Mac) defines a "container" this way. Only IE6 does not make an element a container when it has position:relative. Unless we take special pains, it positions elements with respect to the window. Page numbers in a TOC or line numbers in a poem will be found against the extreme right edge of the window frame, destroying the readability.

IE6 treats an element as a container when the element has a Microsoft-proprietary attribute called hasLayout. You can code CSS in several ways to trigger hasLayout, making IE6 treat an element as a container, but the only way that is standard CSS and works the same in all browsers is the width attribute. If an element is defined with a width value, either an absolute value or a percentage, IE6 treats it as a container.

For this reason, we specify both position:relative and width in any class that is meant to contain absolutely-positioned elements. For example, in class poem, we want to indent on left and right. We get the left indent with margin-left:5% but we get the effect of margin-right:5% by coding width:90% instead. This works in all browsers, and in IE6 it triggers hasLayout as well.

CSS Cookbook Topics
Intro  • Styles   • Browser Issues   • About   • Reference
Styling  • Basic Text   • Heads   • Lists   • Tables
 • Block Quotes   • TOC and Index   • Images   • Poetry
 • Sidenotes   • Drama   • Footnotes   • Page Numbers