MSN for Mac OS X (MSN/MacOSX) is based on a new version of the Tasman rendering engine previously used in Mac IE 5. It has remarkably good support for CSS, as shown in the MacEdition Abridged Guide to CSS2 Support. It was the first browser to have near-complete support for CSS3 selectors as shown in the MacEdition Guide to Support for CSS3 Selectors.
However, it has some bugs in it, some carried over from Mac IE 5, and some specific to MSN/MacOSX.
This guide is highly preliminary. MSN for Mac OS X is very new, and is little used because of the unfriendly per-month charge and requirement for a US billing address for one’s credit card. Therefore at this stage, Web authors should expect little traffic from this browser and need not expend many resources testing for it. However, it may become more important in the future.
Clearincorrectly inherited even when child element has
clear:nonespecified (same as Mac IE 5)
text-indent, line breaks and images (more limited scope than Mac IE 5)
overflow(more limited scope than Mac IE 5)
As demonstrated in this simple test page, if
there is any space alongside a float, the following block will be placed alongside
it even if there is not space for a block of its specified width. This problem
occurs if the following (non-floated) block element has a specified width.
This bug was first reported by “Big
John”. Phillipe Wittenbergh also has a test
case at his
site where the containing block is a fixed-width
than the canvas.
Clearincorrectly inherited even when child element has
Garrett Smith discovered that
clear is inappropriately inherited
into floated elements when the parent (block) element has a
style (any value:
even when the float element is specified to have a style
CSS2 spec clearly states that
clear should not be inherited.See this test page for an example. Thanks are due to Philippe
Wittenbergh for nailing down the many variations of this bug, including cases
with form elements.
by Philippe Wittenbergh, if floated inline elements (images and
protrude down into fixed-width block elements that come after their parent
block element, the width of the float is added to the fixed width of the subsequent
block. It seems that IE/Mac and MSN/MacOSX are trying to ensure that the
text content of the subsequent block element has the required
width, instead of the content area defined in the CSS
The test page linked here demonstrates a
strange background painting bug in IE5/Mac and MSN/MacOSX. The navigation
bar above is an unordered list with
list-style:none, with list
items displayed as inline items. Inside each list item is a link
a element) that is floated left. The list items are defined
to have a red background,
while the links above them are defined to have blue backgrounds.
The problem is that, if the
a elements are floated,
the red background on the
li elements carries through onto the
text areas (but not the padding areas) of following elements, even if they
have their own background color defined. Defining the navigation ul element
position:relative additionally results in all the text in
the subsequent elements being obscured by the red background. This is clearly
a background-repainting bug, much like the negative margin bug in Windows
IE6, because it doesn’t apply to elements that are not in the viewport
when the page is initially rendered and thus that you have to scroll down
An example of this bug is shown in the same page as the previous bug. The H3 and P elements are defined to have 10px and 30px of margin all the way around. However, there is no gap between the borders of these block elements and the bottom of the containing innerdiv. Instead, the margin is between the parent of the block element, and its parent. The same problem also affects top margins of children of elements where its parent is preceded in the markup by another block element with a margin.
This bug seems to be related to the margin protrusion bug identified by Philippe Wittenbergh, even though that bug is not specific to absolutely positioned parent elements.
text-indent, line breaks and images
Phillipe Wittenberg has
identified another text layout bug in Mac IE 5 that is also present in
MSN/MacOSX. As demonstrated
in this test page, a paragraph with
text-indent style and
a line break on the first line immediately followed by an inline image (on
the second line), will incorrectly have the text-indenting also applied to
that second line of text.
The related bug in Mac IE 5 identified by
Jeffrey Zeldman involving
text-indent specified in percentage
units appears to have been fixed. However, links at the beginning of paragraphs
text-indent are subject to the same phantom
link bug that applies to centered and right-aligned text.
If text in a floated DIV is right-aligned (
or centered, any links in the DIV also generate active areas in the empty
left-hand region of the DIV, as if the text was left-aligned. This can be
clearly seen in this minimal testcase. As
the testcase shows, dummy text before the links stops this bug activating.
A similiar problem occurs with the
<Q> element. It is as
if IE and MSN/MacOSX lay down the behaviours of the inline element –
its “linkness”, the quote marks around it – before
actually working out where the text
As demonstrated by Eric Meyer, this issue also arises in tables, even though these are not floated. Thanks to Kevin Smith for the link. This may be what caused IE5/Mac’s incorrect presentation of our “E-mail this story to a friend” in the old design for MacEdition.
The issue also seems to arise when the
style is used on paragraphs.
overflow:scroll do not seem to scroll
background images, as shown in this
test page at Peter-Paul’s site. Instead, the background image appears
as if the
background-attachment:fixed style has been applied.
This bug first became apparent in the gallery
page of Eric Meyer’s css/edge
site. A narrowed down test case is
available here at MacEdition. The bug occurs when you have an absolutely positioned
padding specified. There also needs to be an image in
the div somewhere – presumably some other kinds of replaced content
will do. Then the text of the paragraphs all goes onto one line and the absolutely
positioned div gets wider and wider and wider....
As demonstrated in the screenshot at right, and in the larger version linked here (330kb PNG), MSN for Mac OS X has some strange problems with recovering from a cancelled print. The problem arises when you print preview a site with a print stylesheet, like MacEdition. The preview works fine, but when you return to the screen window, strange layout artifacts occur. This is possibly a result of incomplete screen updating after the print dialog is dismissed.
Here’s another screen redrawing problem, this time occurring when the user moves between pages. Is it the MSN user page, or is it Eric Meyer’s css/edge site? You be the judge.
This bug hit the redesign of MacEdition recently, but has since been worked around. Essentially, if there is no whitespace between the end tag of an absolutely positioned DIV and the end tag of the containing element, the containing element does not appear. A simplified test case is available at this linked page.
MSN/OSX appears to suffer from some rounding problems when calculating
box widths; for an example, see this
test page at Owen Briggs’ Box
Lessons site. For an example, see more test
pages (and this
one) at Owen Briggs’ Box