Codebitch : Click to return to MacEdition homepage

iCab 2.5 CSS support

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.

Don't pad that span

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,

Box model messes

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.

Font follies

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.

Table Traumas

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.

W3C test suite glitches

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.

On the positive side

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.

28 April 2001