Tutorials Bugs Masterclass Free stuff Test pages Proposals

RichInStyle.com bug guide - Internet Explorer 5/5.5

Bugs (continued)

Bugs by type

Topics to be found in the other section of this bug guide

Part 0 - Core issues - everyone must read

Section A - Bugs relating to the attachment of styles to pages (5 bugs)

Section B - Bugs relating to the application of styles to elements (10/12 bugs)

Section C - Bugs relating to key concepts (5/3 bugs)

Section D - Bugs with units (1 bug)

Part 1 - Topic related issues - must read if you use the section involved

Section E - Font bugs (13 bugs)

Section F - Text bugs (15/13 bugs)

Section G - Margin and padding bugs (7/4 bugs)

Section H - Border bugs (7/6 bugs)

Topics to be found in this part of the bug guide

Section I - Width and height bugs (4 bugs)

Section J - Float and clear bugs (7/6 bugs)

Section K - Display, cursor and printing bugs (7 bugs)

Section L - Positioning bugs (4 bugs)

Part 2 - Element related issues - must read if you use the elements involved

Section M - Form bugs (10 bugs)

Section N - HR bugs (7 bugs)

Section O - Table bugs (5/4 bugs)

Section P - List item bugs (8 bugs)

Part 3 - Error correction bugs - bugs, but inconsequential unless you produce invalid style sheets

Section Q - Error correction bugs (47/50 bugs)

Total bugs (IE 5) = 5 + 10 + 5 + 1 + 13 + 15 + 7 + 7 + 4 + 7 + 7 + 4 + 10 + 7 + 5 + 8 + 47 = 162.

Total bugs (IE 5.5) = 5 + 12 + 3 + 1 + 13 + 13 + 4 + 6 + 4 + 6 + 7 + 4 + 10 + 7 + 4 + 8 + 50 = 157.

Section I - width and height bugs

Bug 1: Elements that overflow their containing block

When an element is too big for its containg block, it should overlap outside the block, but in IE 5 it doesn't, instead causing the block to be enlarged. E.g.:

P {width: 400px;
border: solid;
padding: 0}
DIV {width: 300px;
border: solid}

This also applies to elements that overflow the root element, except with these subsequent elements' content is not extended, but their backgrounds and borders are. For example, an element with width: 200% would cause the content area of subsequent elements to be the normal size, but there would be a large amount of space to their right that would be red. This would only be noticed if a background or border (except left border) was set.

Note that this is significant insofar as padding-right: 0 will not work to suppress this - the space is in addition to padding-right.

Note as well that this bug doesn't apply to elements whose width has been extended via margin-right.

Bug 2: only works on DIV

Width only works on DIV, table elements and replaced elements.

Bug 3: small widths

You should avoid widths smaller than the width of the widest word or replaced element in the block; for example, width: 0, which should result in every word overflowing (and hence being visible) the containing block would instead chop off every word that overflowed the containing block - that is all of them. Typically words do not exceed 30 pixels in wide; the width of replaced elements depends on which you use, but you should avoid setting the block width to less than that of the widest one.

Bug 4: elements that should overflow the bottom of elements instead extend their height

Where an element has an explicitly set height, all content that is taller than it should overflow the block. IE 5 instead causes the element to be increased in size to fill all the content; for example, height: 100px with an element inside it that is taller than that should result in it overflowing the element's bottom, but in IE 5 results in the height being increased.

Section J - Float and clear

Floating inline elements
Bug 1: inline floats that are not the first thing in their line box are moved down to the line beneath

Although the CSS spec states that floats that are not the first thing in their line box should simply result in reflow around the point from which they were displaced; for example, <P>e<SPAN style="float: left; width: 1em">m</SPAN> like</P> would result in 'me like'; IE 5 does not apply this, instead preferring to move the float down to the next line unless it is the first thing in its line box. Thus:

(a) Find the turning points of the function y=x3. <span style="float: right; width: 3em; text-align: right">(20)</SPAN>

would result in the (20) being moved down to the line below instead of being right-aligned within the line box as it should be; whereas:

<span style="float: right; width: 3em; text-align: right">(20)</SPAN>(a) Find the turning points of the function y=x3.

is non-problematic because the float is the first thing in its line box (as, for example, drop caps always will be, so these aren't problematic). This presents a problem insofar as the natural place for the float in the markup is on the right, because this is the logical place for non-CSS supporting browsers, but in IE 5 it won't work unless it is placed in the illogical place on the left.

Bug 2: text wraparound is only done on one side

IE 5 only supports text wrapping on one side of a float. For example:

<P style="margin-left: 100px">
<IMG style="float: left">
This text should flow on both sides of the image - to its left and to its right, but in IE 5 will only flow on the right.


<P style="margin-right: 100px">
<IMG style="float: right">
This text should flow on both sides of the image - to its left and to its right, but in IE 5 will only flow on the left.

There is a demonstration of this in one of RichInStyle.com's bug pages.

All floats
Bug 3: content that overflows floats rendered invisible

Content that overflows floated boxes is rendered invisible. The exhaustive list of cases that this will affect are:

  1. Drop caps overflowing their box (e.g., because their line-height is much less than font-size).
  2. Small left margins on OL/UL causing the marker glyph to be rendered outside of the box.
Floating block elements
Bug 4: Not wrapped

Although the CSS specification states that where a float will overflow its containing block due to another float, the float should be moved below that float, IE fails to follow this, instead allowing the containing block to be overflowed, thus causing a scroll bar as a result of the third of the element's below overflowing the containing block:

<DIV style="float: left; width: 50%">
<DIV style="float: left; width: 50%">
<DIV style="float: left; width: 50%">

To avoid this, you should always use clear to do what the browser should do for you. E.g.:

<DIV style="float: left; width: 50%">
<DIV style="float: left; width: 50%">
<DIV style="float: left; width: 50%; clear: left">
<DIV style="float: left; width: 50%">

Bug 5: block elements that follow floats that combine to the width of the containing block or nearly that, trigger horrendous bugs unless cleared 5

Although the code below should result in the P text below the DIV (although the P's block is the top of the float, the float's width is the same as P's, and thus it will appear to be below it), IE will put some of the content next to the float (thus triggering an unsightly scroll bar), and some beneath it. Thus bad in IE 5 is:

<DIV style="float: left; width: 100%">
<P style="/* since the width of the previous element is 100% of the viewport, this element's content must go below the floated div, but it won't */">
P's content here

Good is:

<DIV style="float: left; width: 100%">
<P style="clear: left">
P's content here

Bug 6: horizontal rules overlapping with floats shortened instead of overlapped

When horizontal rules overlap with previous floats, instead of overlapping, as would be correct, they are shortened.

Bug 7: clear on floated elements allowed to affect block elements

Since floated elements are removed from the normal flow, although clear obviously affects the floats themselves, it doesn't affect subsequent block elements. In IE 5 however, if a floated element is cleared it is erroneously allowed to affect subsequent non-floated elements. For example, <DIV style="float: right; width: any"> <DIV style="float: right; clear: right; width: any"></DIV <P>, which should place the top border edge of the non-floated P at the top of the first right-floated P instead puts it at the bottom of the cleared element.

If you don't understand why this is so, see RichInStyle.com's floats document.


Width only works on DIV, ergo only use DIV for floats.

Section K - Display, cursor and print bugs

Bug 1: url

Cursor: url() doesn't work.

Bug 2: pointer

Cursor: pointer doesn't work, but cursor: hand does (a pre-CSS2 name for it), so declare SELECTOR {cursor: pointer; cursor: hand} instead. You must declare it in that order, because of IE's bug of not ignoring invalid declarations (pointer is invalid to it), but instead applying the initial value. This won't cause problems with compliant UAs, since these would ignore (i.e., treat as though it wasn't there) the cursor: hand declaration.

Bug 3: auto

Cursor: auto doesn't work. For example, say you put HTML {cursor: default} to set the cursor to the pointer rather than the I bar, but on DIV you want the browser to use its usual cursor for this element (the I bar), so you put DIV {cursor: auto} to allow the browser to determine it itself. In IE 5 this won't happen because it doesn't support cursor: auto.

Most of the effect of this bug is removed, however, by the fact that in its browser style sheet it has the cursor set for the A, INPUT, BUTTON and TEXTAREA elements.

This means that if you specify INPUT {cursor: auto} to override the HTML {cursor: default} statement, it will actually work, although not because of the reason you told it to - IE 5 would apply automatic cursor selection to INPUT anyway, so it would actually use the right cursor (the only way to change the cursor on these 4 elements is to explicitly state a different one - inheritance won't work (note that this is not a bug because it is permissible for UAs to have this in their browser style sheet; however, it is arguably bad practice).

Bug 4: n-resize, ne-resize, nw-resize, w-resize, e-resize, s-resize, se-resize, sw-resize buggy

IE 5 uses the wrong cursor for n-resize, ne-resize, nw-resize, w-resize, e-resize, s-resize, se-resize and sw-resize - it uses a single-headed cursor, whereas in Windows these cursors are double-headed cursors (in addition, se-resize should be the same as nw-resize - it is not in IE 5).

Bug 5: display: list-item doesn't work

Display: list-item doesn't work.

page-break-before, page-break-after
Bug 6: left and right treated as always

IE 5 treats the left and right values as always. This is wrong even though IE 5 prints left and right pages the same. For example, <P style="page-break-before: left> <P style="page-break-before: right>, which should result in one or two page breaks before the first element and two or one (the other number from which the previous element caused) simply results as one.

Note that this is non-serious bug because as IE 5 doesn't maintain any difference between left and right pages, it makes little difference.

Printed margins
Bug 7: still honored at the top of pages

IE 5 incorrectly uses margin at the top of pages; for example, P {margin-top: 3in} should not give the P a top margin if the P starts on a new page, but in IE 5 it does.

Section L - Positioning

Bug 1: scroll doesn't always result in a scroll bar

Overflow: scroll, which should always result in a scrollbar (e.g., so that content can be dynamically removed and added without causing reflow), only results in one when overflow occurs in IE.

Bug 2: overflow-handling behavior only triggered for content that overflows the bottom of its containing block

IE only honors overflow for content that overflows the bottom of element. For example, height: 10px; overflow: whatever would trigger the overflow-handling behavior if the content overflowed the bottom (note that content that overflows the top is always treated as overflow: visible)of the block as a result of that height declaration, but all other overflow would be treated as visible.

Information: auto's treatment

IE treats overflow: auto as overflow: scroll when the element overflows its containing block, but overflow: visible otherwise (as is its prerogative).

Bug 3: not supported

IE does not support clip.

Bug 4: hidden suppresses element and all descendants

The visibility property should not cause suppression of the element and all its descendants; for example, <P style="visibility: hidden">Some hidden text <SPAN style="visibility: visible">and some visible text</SPAN></P>, should result in the visibility: visible text being visible. However, in IE visibility: hidden erroneously causes the element and all its descendants to be suppressed and this example would cause a totally hidden element in IE.

Section M - Form bugs


Form controls do not inherit style, but have the OS-default styles applied to them (typically font-size: 10pt (or thereabouts); font-family: serif; color: black; background: white, but it depends on the OS' settings). This is not a bug, since this is validly includable in a browser style sheet (necessarily via UI fonts and colors).

Superior to all browsers is the fact that this can be overridden.

Note that padding, margin and border do work on form elements, even though they do not work on other inline elements.

Bug 1: Font properties not supported on OPTION

Font properties can only be applied to <SELECT>, not to <OPTION>.

Bug 2: Background and color

Radio buttons, check boxes and upload buttons (but not the text box) on INPUT type="file" can't have backgrounds or color.

Bug 3: background images

IE 5 does not support background images on SELECT or OPTION elements.

Bug 4: line-height not supported on OPTION

Although IE 5 applies line-height to BUTTON, SELECT, INPUT type="reset", type="submit" and type="button", it does not apply it to OPTION.

Bug 5: line-height and padding destroyed on INPUT type="text" and type="password"

IE 5 destroys line-height and padding on INPUT type="text" and type="password" by applying it but not increasing the height of the box to compensate, thereby hiding any initial (via value="") content of these controls.

Bug 6: text-decoration unsupported on SELECT, OPTION and INPUT type="image"

IE 5 does not not support text-decoration on SELECT, OPTION or INPUT type="image" (i.e., on the alt text of INPUT type="image").

Bug 7: white-space unsupported on TEXTAREA

IE 5 does not support white-space on TEXTAREA, irrevocably applying it as a preformatted element.

Bug 8: padding not supported on SELECT or OPTION

IE 5 does not support padding on SELECT or OPTION.

Bug 9: margin not supported on OPTION

IE 5 does not support margin on OPTION.

Bug 10: border not supported on INPUT type="radio" or type="checkbox"

IE 5 does not support borders on INPUT type="radio" or type="checkbox".

Section N - HR bugs

Bug 1: width set on its own

When width is set on a horizontal rule, IE centers it.

Bug 2: margin-left set on its own

When margin-left is set on its own, width is not altered to compensate, thus meaning that the rules containing block will be overflowed, probably resulting in a scroll bar and the rule being pushed off the screen.

Bug 3: both margin-left or margin-right and width set

When both margin-left/margin-right and width are set on a horizontal rule, they are applied subject to the normal margin bugs, but since IE does not adjust values to fit the viewport on HR, a scroll bar will result (since it is highly unlikely that BODY's width, which is what HR should relate to, will be exactly that of the viewport).

What does it all mean?

All this means that you should not apply box model properties to HR (padding doesn't work at all, so this might be an alternative to exclude IE). [At a pinch you could try: HR {width: desired width - BODY's margin-right + BODY's paddding-right; margin-right: 100% - (BODY's margin-left + BODY's padding-left) - desired width}
E.g., given BODY {margin-left: 10%; margin-right: 5%;} then HR {width: 50%; margin-right: 40%} would work to get the width of 40%, and wouldn't conflict with other browsers]

However, the best solution if you only need to adjust a few HRs, you should just use the width attribute in the markup.

Bug 4: Height in %

Height in % doesn't work on HR.

Bug 5: color applied as a border and background color

IE 5 draws HR as a border around a transparent box. This means that you should be able to change the border color and background color. It ignores both of these properties on HR and only applies color to HR, which causes the HR to be set to a solid color.

Bug 6: border properties

Border properties don't work on HR

Bug 7: padding

Padding doesn't work on HR

Section O - Table bugs

Bug 1: height, width, position and margins not honored on CAPTION

IE ignores height, width, position and margins on CAPTION.

Bug 2: inheritance 5

IE incorrectly fails to inherit any styles from the parent element except font-family, instead inheriting those of the BODY. As a result, given, e.g., DIV {background: red; color: green} BODY {background: green; color: red}, the TABLE would be green (BODY's) on green =invisible. Similarly, DIV {font-family: 16px sans-serif} would inherit the sans-serif but not the 16 pixels.

Bug 3: padding not applied to tables or table rows, but instead inherited therefrom

IE 5 does not apply padding to TABLEs, table row groups, or table rows, but instead inherits the padding to the cells; for example, TABLE {padding: 10px} would inherit that padding to the cells.

Bug 4: properties 'inherited' from columns 5

IE 5 incorrectly allows inheritable properties to inherit from columns. For example, COL style="color: red" would make the table cells red, which is incorrect because the only properties that should have an effect on columns are background, border, visibility and width. Similarly, COL style="visibility: hidden" is allowed to hide the column by reason of its inheritance whereas to hide the column actually requires COL style="visibility: colapse".

Bug 5: unclosed P prior to table causes the table to be considered as part of the P

If you fail to close a P element before a table the table will be treated as part of the P element, which is incorrect since P cannot contain other block elements (such as TABLE), and therefore the start of the TABLE implies the end of the P. Thus <P style="border: solid; background: red; margin-right: 50%"><TABLE> will cause the TABLE to be inside the P. As a result, you should close P elements before tables, and must close them when the P has a lot of inheritable styles.

Bug 6: negative margins in table cells causes truncation

Where content overflows the border edge table cells (as a result of a negative margin), it will be rendered invisible. For example, say you have H1 {margin-left: -5%} in a table cell. This would cause all of the H1 that overflowed the table cell to be rendered invisible.

Table-layout: fixed
Bug 7: applied even when the TABLE has width: auto

IE 5 applies table-layout: fixed even when the table hasn't been explicitly assigned a width. This is incorrect.

Bug 8: content that overflows table cells as a result of table-layout: fixed will be truncated

If as a result of table-layout: fixed, content overflows table cells, IE 5, instead of allowing it to overflow, will truncate it, thereby making it invisible.

Bug 9: completely broken

IE 5's border-collapse implementation is badly broken. To see this demonstrated, you should click here.

Section P - List item bugs

List styling
Bug 1: marker not taken into account for finding height of the line box

IE 5 does not take into account the marker box for the purposes of finding the height of the line box; for example, LI {line-height: 100px; background: red} with a SPAN.insideLI {line-height: 10px} should make the line box 100 pixels high because the line-height of the list marker is 100 pixels, but in IE 5 will give 10 pixels high. Again, this is unlikely to cause any problem.

Bug 2: text-indent moves list marker

Text-indent moves the list marker as well as the content, whereas it should just move the content.

Bug 3: text-align moves list marker

Text-align moves the list marker as well as the content, whereas it should just move the content.

Bug 4: list markers suppressed where list items overlap with floats

When list items overlap with floats (e.g., DIV {float: left; width: 50%} followed by an uncleared LI), the marker is suppressed.

Bug 5: very large font sizes cause list marker/principal box overlap

When you set font-size very large (> 100px), because IE 5 measures the distance from the left of the marker to the left of the principal box, it will overlap with the principal box.

List style positions
Bug 5: buggy

List-style-position: inline is glitchy - it should result in the marker being placed as the first item of content in the principal block, much as the 'L' at the start of this sentence is the first item of content in its principal block, but in IE 5 it will straddle the two. This is annoying but not catastrophic.

It also means that backgrounds will cause problems.

List style types
Bug 6: '.' placed after ordered list marker glyphs

Internet Explorer 5 places a '.' after markers on decimal, lower-alpha, upper-alpha, lower-roman, upper-roman (1., 2., 3., rather than 1, 2, 3), which is technically incorrect.

List style images
Bug 7: all but small images destroy when line-height is set to a value other than normal

If you use any other than small images and set line-height to a value other than normal (even <number> is problematic), Internet Explorer 5 will destroy the list item. This is because rather than placing the right edge of the list marker (say) 10 pixels from the left of the content it is marking, it places the left edges relative to the left of the content - regardless of the size the image. As a result, you should use list images that are an absolute maximum of 30 pixels wide.

Bug 8: none doesn't work

Although the list-style shorthand resets all unset values to their initial value, in IE 5 it doesn't, and list-style-image: url(listimage.gif); list-style: decimal, which should apply decimal (equally so when a list style image is inherited), not the image, applies the image. This bug is avoidable by declaring list-style-image: none (adding none to the list-style shorthand won't work).

Part 2 - (In)Validation problems

Section Q - error correction problems

Some people might think that these are irrelevant, and that it is pointless pedantry to list them.

They would be wrong.

The habit ominpresent amongst browser makers of permitting invalid style is a dangerous one that causes many problems. For example, say you have @import url("wrong.css);. This would work in IE, and as a result the author would have no idea that anything was wrong.

Unfortunately, when they (or worse, someone else) came to look at the page in a compliant browser, it would not look correct. In addition, other problems introduced by the habit of browers of not ignoring invalid CSS include the encouragement of sloppy or invalid design. As an example, I have seen many people using SPAN for styles that are only valid on block elements. Because this works in many browsers, they are not encouraged to produce valid CSS, and as a result their site will suffer.

  1. Border-style: solid thin is rendered as if it were border-style: solid none none none, but this isn't valid CSS.
  2. Style is applied when element_name is enclosed in < and >, which isn't legal CSS.
  3. Width is applied to inline elements, transforming them to floating block elements.
  4. Height is illegally and buggily applied to inline elements.
  5. The font shorthand works even when both of size and family have not been specified.
  6. IE 5 allows invalid line heights in the font shorthand; for example, no space after the line height or a space before or after the /.
  7. IE 5 permits (ignoring) carriage returns and line feeds inside strings in the string macro when it forms part of the URI token, but this isn't allowed. 5
  8. It permits the end (but not beginning) quote to be omitted from the string macro in the URI token.
  9. Style sheets are imported that do not precede all blocks, which is prohibited by the CSS spec.
  10. Inline style contained in curly brackets is rendered
  11. Margins separated by commas are rendered: e.g., margin: 12pt, 12pt, 12pt, 12pt;
  12. Vertical-align is (buggily) applied to block elements, whereas it only applies to inline elements by the spec.
  13. White space such as a line feed is incorrectly ignored at the end of font-family declarations - e.g., font-family: "Courier New
    " works but shouldn't.
  14. It tolerates invalid border declarations; for example, border: solid thick thin applies a solid thin border and solid red groove, red medium groove.
  15. Fonts containing white space without quotes are incorrectly parsed as such, whereas the CSS spec states that the white space should be removed - e.g., font-family: Times New Roman should become font-family: TimesNewRoman.
  16. It incorrectly allows non-integer values on the decimal rgb format
  17. It destroys future colors - color: red; color: 3dbackground is treated as color: [no declaration].
  18. It doesn't ignore shorthand declarations where part of the value is invalid
  19. If the unit is omitted from DIMENSION tokens, IE 5 implies px, but this is invalid and the declaration should be ignored.
  20. It incorrectly allows more than 1 decimal place on the % rgb format
  21. Colors without the # sign are applied.
  22. SELECTOR {property: } is parsed as SELECTOR {property: initial-value}, which is not correct (the declaration should be IGNOREd).
  23. Values in quotes are illegal, but IE 5 applies them (e.g., font-size: "12pt").
  24. If more than four margin values are provided, IE 5 applies the first four.
  25. It fails to treat the first instance of </ as terminating <STYLE>.
  26. It allows IDs to contain character references, but this isn't valid.
  27. It illegally allows tokens to start with very many invalid characters; for example, #1 and #-id are both invalid, but IE 5 will accept them.
  28. If the closing } is omitted on a ruleset, the style is applied provided the ';' is included.
  29. It applies {property: value} to HTML {property: value} 5.
  30. It applies rulesets that contain invalid combinators as part of one of their selectors by applying the ruleset only to the last selector, rather than ignoring it entirely as it should. E.g., DIV & P, .eight would be applied to .eight, but .eight, DIV & P would result in .eight being ignored. 5
  31. It permits comments inside the uri token, but comments aren't allowed inside tokens, only between them. 5
  32. It disregards the case of proprietary font names (e.g., aRial).
  33. It allows Times to match Times New Roman
  34. If % is used on height without the ancestor having an explicit height, the % is related to the height of the viewport, but it should be treated as auto. 5
  35. It will ignore any number of characters between a property and its colon; for example, color 4536487587: red would apply color: red! Note this only applies where there is an space between the property name and the invalid characters.
  36. It treats the media attribute as case-insensitive
  37. It doesn't ignore text-decoration declarations that contain an invalid value provided they contain at least one value; for example, text-decoration: underline cheese would apply text-decoration: underline, but should be ignored as invalid.
  38. It fails to truncate the media attribute - whereas media="screen fhdfk dfjkd hf" should be treated as screen, IE doesn't bother. Compare this with Opera, which does correctly truncate it.
  39. IE 5 applies text-align to horizontal rules, but it should have no effect on them - the correct way to center (for instance) horizontal rules is with margin-left: auto; margin-right: auto, and a width value < 100%.
  40. It allows non-integer values on z-index (rounding down).
  41. It allows background position keywords to be mixed with lengths, but this isn't valid
  42. It will have problems with future cursor values because it does not ignore them; for example, cursor: wait; cursor: busy, which should result in cursor: busy being ignored and thus reversion to cursor: wait, in IE 5 results in the inherited cursor (or browser cursor in the case of BUTTON, INPUT, A and TEXTAREA).
  43. It applies % on top when the containing block doesn't have an explicitly set height, but this should be ignored.
  44. It allows spaces between numbers and the length; for example, it allows 5 em, but this isn't valid.
  45. It allows = to be used for style assignment (i.e., instead of :).
  46. It allows comments between {ident} and '(' on the FUNCTION token, but this isn't valid because comments are only valid between tokens, not inside them ('rgb(' is a single token).
  47. IE 5 destroys pages that don't include at least one closing comment tag for all the open ones (e.g., --> for all the <--). This is incorrect because it shouldn't treat comments in the style element as such; however, it isn't serious because it's a stupid thing to do anyway.
  48. 55IE 5.5 incorrectly applies clear to :first-letter (it doesn't apply to inline elements).
  49. 55IE 5.5 incorrectly applies clear to :first-line (it doesn't apply to inline elements - note that the spec is in error on this point).
  50. 55IE 5.5 incorrectly allows the pseudo-element other than last in the selector.
  51. 55IE 5.5 incorrectly allows :first-line:first-letter, which isn't valid.
  52. 55IE 5.5 incorrectly applies &nbsp; as not the first-letter for :first-letter; the nbsp should be red (although this won't be apparent) - not the next letter