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.
Clear incorrectly
inherited even when child element has clear:none specified
(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 div rather
than the canvas.
Clear incorrectly inherited
even when child element has clear:none specified Garrett Smith discovered that clear is inappropriately inherited
into floated elements when the parent (block) element has a {clear:value}
style (any value: both, left or right),
even when the float element is specified to have a style clear:none.The
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.
As demonstrated
by Philippe Wittenbergh, if floated inline elements (images and spans)
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
spec’s
box model.
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
as 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
to see.
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
imagesPhillipe 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
with positive 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 (text-align:right;),
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
should go.
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 text-indent
style is used on paragraphs.
overflowDIVs with 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 thebackground-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
div with 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....
Post-print
float problemsAs 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.
Screen redrawing
artifactsHere’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
Lessons site.
