The documentation notes,
Not yet supported are (CSS1) "font-variant";
"list-style-image"; "vertical-align"; "float"; "first-line"; and "first-letter". There are also some restrictions with in line elements
This much is true, and iCab's developers are to be commended for coming clean and having limitations that are centred on certain properties instead of quirks that can't be predicted without extensive testing. This way, developers can know what they can rely on working. Nonetheless, there are some glitches not addressed in the release notes, and the exact nature of the limitations on inline elements isn't described. This page tries to fill in those gaps in the documentation.
One point worth mentioning at the outset: iCab 2.5 preview has partial
support for CSS1. So it
doesn't do any CSS2
a:hover or any absolute positioning. Of course, it's
ironic that the one CSS property that even the most CSS-phobic web author
will use is that
hover pseudo-class. CSS1 isn't CSS2, folks, and it's about
time that professional web designers understood the difference. The other
active) do work.
The limitations on inline element styles are box model properties; colors
and background colors work fine. iCab doesn't yet support borders on inline
margins and padding have disastrous
effects, frequently obscuring earlier text on the page. Examples of
these problems can be seen at points 16 and 33 of the color
sampler test page here at MacEdition and some W3C test pages. Without
margin support on inline elements, it resizes but
doesn't center images,
iCab's current CSS support makes some mistakes for the box model. As demonstrated in this test page or on Tantek Celik's hack page, block elements with borders end up a slightly different width to elements without them. Widths of elements also seem to be calculated differently depending on whether or not there is a margin (tip for young players: CSS width includes text area but not padding, borders or margins). Elements with margins sometimes end up with the text running into the border or off the edge of the colored background. There are also glitches with negative margins. There are also problems with borders: iCab makes room for borders that have no border-style set, which is not correct. It also tried to render an invalid border style.
Between the box model problems and the lack of support for float, the so-called box acid test looks diabolical!
Worse, structural elements such as
additional top padding and margins that you cannot get rid of, and seem to
be added on to margins and padding that you define. This means that you
can never get rid of the margin between paragraphs or headings if that's
what you want. And margins on list items are utterly broken, with bottom margins breaking in a very different way
to top margins (this W3C
page suggests the same behaviour). This will need to be fixed
before the final release.
Box model styles (margin, padding, border) on the BODY element are also broken. On this test page, the content elements (DIVs, Ps and H4s) don't go to the edge of the window as specified, while this W3C page doesn't show a margin on BODY, to let the different background color defined for the HTML element show through.
There also seem to be some oddities in its font-sizing. To its credit, iCab
maps the CSS font-size keyword
medium to the default text
size. It also resizes fixed-pixel sizes, thus keeping its reputation as a
browser that takes accessibility seriously. There are, however, some other
problems that need looking at. Some of them are stylistic: personally I
font-size:small is too small relative to
xx-small are not different enough
small to be distinguishable, unless you set your default
text size to something enormous like 36px.
sampler also indicates some problems. We knew iCab doesn't support
font-variant for small caps, but there are also some glitches
in the compact
font: declaration. Sometimes the italics don't
come out, as shown in points ,  and  of the font sample page –
although it works in a similar W3C test
page. The style
text-transform is supported, unlike
font-variant, but this W3C test
page indicates some glitches with the
iCab's developers admit that some styles aren't implemented for inline elements, but there's no mention that it fails in different ways depending on whether the inline element is inside a table or not. This suggests that there is something in the CSS implementation in iCab that is flawed, because such differences simply shouldn't happen. You can see what I mean in this simple test page at MacEdition.
There are other glitches resulting in things displaying differently in
tables than outside them, judging by the W3C test pages. iCab doesn't pick up
table-specific selector, or has a problem with background
style and compact
style on Ps within tables. The area covered by background colors on
elements within tables also seem problematic: sometimes,
out over background colors when inside tables. Backgrounds on Ps don't go to
the right edge inside
tables, but are fine outside them. Another problem is that images don't
rescale to a percentage of parent inside tables
but do outside them.
Tables themselves are also limited in their CSS support in iCab: borders on table cells don't work at all, it seems. Neither does padding, as you can see in my table test page or a similar W3C page.
Aside from things I've already mentioned, I detected a few problems with iCab's current CSS implementation based on the W3C test suite – a must-see site for all browser developers and CSS-using web authors.
BODYdidn't inherit into tables
A's style (maybe because an
IDwas used twice?)
blink, but doesn't underline graphics (almost everyone makes this mistake) and underlines in the current color, not the color of the parent where the underline is actually defined.
display:inlineare not yet implemented but
list-itemseem to work.
Despite these glitches, there are some nice things about iCab's CSS
implementation, even in these early stages. Take Section 1.1
(inheritance) from the W3C's test suite: it has a nice touch: the
bullets are red even though the text is different, because
was defined as having red text, and this was overridden for the list items
with another style on
LI. Even though
list-style-image isn't yet supported,
are. However, the alternative compact notation (
list-style) isn't quite
inside style is not a normal hanging indent
is it properly flush with the list marker as expected.