Hiding CSS from iCab

To hide CSS files from iCab, use the HTML type entity hack: <style
type="&#116;ext/css"> body {background:
black; color: white} </style>. See the CSS-Discuss
Wiki for more information. This hack was discovered by Dominik
Boecker.

To hide individual CSS declarations from iCab, use a backslash as
a character escape on any letter in the declaration that is not A–F or
0–9, like this: \html div {padding:1em;} or di\v
{padding:1em;}. See Edwardson
Tan’s test page for more information. Note that any character
escaping within a stylesheet hides the whole stylesheet from Netscape
4.
Character escaping on the selector also hides the rule from Safari,
which may not be what you want.

To hide property-value rule combinations from iCab, again, use
the character escaping hack, but this time on the property name, like
this: \padding:1em or paddi\ng:1em. This
also
hides CSS from OmniWeb. First-letter escapes also hide the CSS from
Safari, but escapes on other letters do not.

Other comments: iCab

Does not style HTML element separate from body (example: hixie.ch
test or any of the other tests in that part of hixie.ch). Also does not
support the use of html body as a selector with identical effect
to body. In this respect it emulates the parsing problems of
Netscape 4. However, because it doesn't have the excess margin on body
issue that Netscape has, this means it has problems with the workaround for Netscape's
window margins documented by Char James Tanny and Mark Howells (iCab actually
displays the negative margins). MacEdition suggests using an imported stylesheet
in addition to the html body selector, to override the negative margin Netscape
4 requires to generate a zero margin.

If font-size for BODY is set at a non-standard size (eg
font-size:90%;) to scale down unsightly large default text
sizes in browsers, with block elements then set at font-size:1em;,
then the block elements end up too large. This is particularly vile for
nested lists and div elements, as can be seen from this page using em units.
Sizing the elements with percentage units instead of ems
works fine, as shown in this
test page using percentage units.

Draws colored backgrounds for styled text areas in forms to the correct
width, but does not actually size the text area with CSS.

Strange background coloring bug:
when block elements are inside tables, the width of the blocks is defined
by the maximum widths of previous blocks in that table cell, if the block
elements have a font-family style defined in the stylesheet.

Appears
to allow quote marks around standard font-family keywords like monospace,
which is not correct, but handles most other quoting issues properly.

In font-family declarations, if the relevant font at the front
of the list is quoted (which you’re meant to do if the font name has
more than one word in it) and if there is a generic font family specified
at the end (which you are also meant to do) then iCab 2.8x for OS X doesn’t
see any of the font names other than the generic family (see test page).

Further to this issue, OS X users with Lucida Sans as well as Lucida Grande
installed may have problems seeing either font (see test page). Fortunately, the workaround
is straightforward.

Definition terms (DT elements) have around 1em
of extra line height above text. If background color set on these elements,
may obscure some text in previous line. Workarounds: set
background to transparent, or add margin-top:1em;
to DT element style.

List items treated as inline elements. Results in glitches with short elements'
backgrounds not going to end of block, and text going over boundary of background
if positive margins set.

There have been no reports of iCab 2.7, 2.8.x or 2.9 improving on the CSS
support in version 2.6. However, version 2.9 introduced a bug in its handling
of padding on BODY that fouls up the presentation of all pages on MacEdition,
as can be seen in the screenshot
comparing version 2.8 (above) and 2.9 (below).

No warranties are given on the correctness of this page, since this
depends both on the correctness of the tests and correctness of my
interpretation of the tests. All reasonable efforts have been made to
ensure accuracy. Corrections, clarifications and updates for new
versions of these browsers will be gratefully appreciated. Thanks are
due to Matt McIrvin, the rest of the MacEdition staff, and numerous
dedicated web developers with Macs, who have sent comments, diagnoses
and screenshots.