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
remaining.
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
such as 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
pseudo-classes (link
, visited
and
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
elements like A
, SPAN
or CODE
, while
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 P
and H2
have
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
thing font-size:small
is too small relative to medium
, and
then x-small
and xx-small
are not different enough
from small
to be distinguishable, unless you set your default
text size to something enormous like 36px.
This font
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 [1], [16] and [18] 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 capitalize
style.
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
images, the background-repeat
style and compact background:
style on Ps within tables. The area covered by background colors on
elements within tables also seem problematic: sometimes,
content juts
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.
Color:green
on BODY
didn't inherit into tablesA
's style (maybe because an ID
was
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:block
and
display:inline
are not yet implemented but none
and list-item
seem to work.text-align
styles left
,
right
and center
but not
justify
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 UL
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, list-style-type
and list-style-position
are. However, the alternative compact notation (list-style
) isn't quite
right; the inside
style is not a normal hanging indent
but neither
is it properly flush with the list marker as expected.