Repositioned content via JavaScript coupled with floats is triggering a variety of bugs in various browsers.

Test page Workaround is not included
Reported by: Chris Hester.

Changing the status of a checkbox less then a second after it's been changed doesn't change the status again. Try clicking the checkbox twice in rapid succession.

Test page Workaround is not included
Reported by: Velko Georgiev.

Placing a right-floated element in a left-positioned absolutely-positioned element causes the following behavior:

• Opera and iCab display correctly (I think); the absolutely-positioned element is sized to fit the float or other nodes of the element, whichever is wider
• Gecko stretches the absolutely-positioned element to the maximum width allowed by the containing block
• KHTML stretches the absolutely-positioned element to the sum of the width of the float and the other child nodes
• (ppknote: IE behaves as Firefox)

My understanding of the box model spec is that Opera and iCab's behavior is correct; if anyone can corroborate this it would be greatly appreciated.

Test page Workaround is not included
Reported by: Josh Fremer.

A break tag in your code when text is aligned right causes a space at the end of the line. This has the effect that the last line in a group appears too far right.

Test page Workaround is included
Reported by: Chris Hester.

IE can drop a floated column with a percentual width when the browser window is narrowed.

ppknote: Explorer Mac crashes when you resize the test page.

Test page Workaround is included
Reported by: Chris Hester.

Negatively margined (or indented) elements get cropped if their parent elements have layout (hasLayout == true).

(ppknote: IE 7 crops the right margin of the first example, but not the left. IE Mac ignores the margin-right: -10px in the first example.)

Test page Workaround is not included
Reported by: Margaux.

In a single select element the select control is rendered incorrectly during selection, if an option element is present containing character entities/references. This does not apply to ampersands.

Test page Workaround is not included
Reported by: Toby Woodwark.

If an image is given various heights, but not a width, browsers enlarge it to fit the ratio of the physical dimensions of the image. But over a certain size, bugs can occur.

Test page Workaround is not included
Reported by: Chris Hester.

Safari doesn't allow you to set a background image on a textarea.

Test page Workaround is not included
Reported by: Jean-Charles Meyrignac.

If you try to add style declarations in the head of a document, IE borks at the name 'style' - "unexpected call to method or property access".

I guess its getting confused between the head element <style> and the object property .style?

Test page Workaround is not included
Reported by: Ross Howard.

When you use font-variant: small-caps, Explorer ignores text-transform: uppercase || lowercase.

Test page. Workaround is not included.
Reported by ppk.

An event handler for onmouseover an anchor should not show the URL in the status bar when you return false, and it should when you return true, but actually it does exactly the opposite.

Test page Workaround is not included
Reported by: Lal.

This bug is caused by IE not calculating position of floats correctly. As far as I can tell the left edge of the content is calculated and then the width is applied, the correct behaviour is to apply the width and then see where the content should be layed out due to any floats.

Test page Workaround is not included
Reported by: Marc Pacheco.

When you remove an element by innerHTML='' it's possible to re-append the element to the document. In Explorer Windows, though, the text goes missing.

Explorer Mac loses track of the element when it's been removed. So in this browser elements don't stay in hyperspace after they've been emptied from the innerHTML.

Test page. Workaround is not included.
Reported by ppk.

Explorer Windows and Mac, Mozilla and Opera see <fieldset>s as form fields, even though the spec doesn't mention them in the list of control types.

Mozilla and Opera allow change events on <fieldset>s, even though they don't make sense.

Test page. Workaround is not included.
Reported by ppk.

The following will throw an exception:

var button=document.createElement("button"); button.type="button";

The only workaround for dynamically creating <button type="button"> seems to be to convert the button HTML to a string and append it to innerHTML.

Test page Workaround is included
Reported by: Garret Wilson.

When creating a table dynamically and inserting table rows with table data cells and text nodes and add it to the document tree, it is not displayed at all when you don't include a <tbody> tag. W3C DOM2 methods are used.

(ppknote: Test case does not work in Safari)

Test page Workaround is included
Reported by: Gunnar Vestergaard.

In Explorer, if you need to set the accesskey attribute using setAttribute(), the attribute name passed in must be "accessKey" and NOT "accesskey".

Test page Workaround is not included
Reported by: Toh Zhiqiang.

When creating an object using the inline object syntax, it is possible to use numbers as property names:

var foo = {7:'bar'};

In Internet Explorer for Mac, this will throw a syntax error and cause the entire script to be ignored.

Test page Workaround is included
Reported by: TarquinWJ.

When trying to break a list of floats into rows with clear: left on the first cells in the future "rows", the cells after the cleared ones just fill up the remaining space from the previous "rows" as long as the parent's width allows.

Test page Workaround is included
Reported by: Valentin Agachi.

When a floated list with overflow: auto; contains a dropdown, the dropdown disappears when changing its value (Mozilla) or never appears at all (Explorer Mac).

Test page Workaround is not included
Reported by: Benjamin.

A background on a TR doesn't work. Instead the TDs inherit the TR's background image.

Test page Workaround is not included
Reported by: Valentin Agachi.

A percentual width of an abolutely positioned element should be calculated relative to the containing block (the body, if there is no other absolutely positioned element. Unfortunately Explorer (Win and Mac) and Opera calculate the width relative to a static block that contains the HTML for the absolute element.

Test page Workaround is not included
Reported by: G�rard Talbot.

Explorer Mac and Safari also trigger the onload event when you use an internal anchor to jump to. The jump is executed time and again.

(ppknote: This bug is closely related to Setting location.hash to the same value twice causes reload, but it's not quite the same.)

Test page Workaround is not included
Reported by: Benjamin Eric Morin.

IE is wrongly case sensitive about the usemap attribute of an image map. To change the map for an image in run time, you have to set the attribute "useMap", which is against the XHTML Strict standard. In a proper situation, you should set the "usemap" attribute.

Test page Workaround is included
Reported by: Pauli Ojanper�.

Opera misplaces absolutely-positioned elements when their containing block is subject to text-align of center or right. It places them where they would have been if they were subject to text-align:left.

Explorer Mac positions the text correctly, but makes the divs far too wide.

Note that you need to be setting display:inline on a DIV, or similar, to be affected by this.

Test page Workaround is not included
Reported by: Phil Endecott.

In some browsers getAttribute("HREF") on an A element returns a complete URL, even if the HREF attribute in the source specified a relative path. In others it returns the exact text of the attribute in the source, which may be relative.

All browsers put the complete, resolved, URL for an A element in its .href property. In Explorer (Win and Mac) and Opera 8 the same value is returned by getAttribute("HREF"), while Mozilla (FF1.0), Safari and Konqueror (3.2.2) return the source value. I consider the latter behaviour to be correct.

The test case contains two links, the first absolute and the second relative, and reports the values of .href and getAttribute("HREF") for each. It is the last reported value that differs.

Test page Workaround is not included
Reported by: Phil Endecott.

Explorer Mac can't handle class names that start with a space: it applies very weird styles to the element.

Test page. Workaround is not included
Reported by ppk.

Safari and Explorer Mac have trouble with reading JavaScript properties of an entire radio button array.

Test page. Workaround is not included.
Reported by ppk.

An absolute layer positioned on top of an iframe will always disappear behind the iframe, even if you set its z-index.

Test page. Workaround is not included.
Reported by ppk.

When you click on a label, the click event of the related form field should fire. Unfortunately Opera and Explorer Mac don't always do this.

Explorer Mac doesn't fire the click event on text fields and textareas, while Opera only fires the click events on radios and checkboxes.

Test page. Workaround is not included.
Reported by ppk.

When creating custom DTDs like the one below, all browsers except Opera see the end of the ATTLIST as the end of the DOCTYPE. The result is that they print "]>" on the screen.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
[
<!ATTLIST p behavior CDATA #IMPLIED>
]>

Test page. Workaround is not included
Reported by ppk.

The CSS 'bottom' property can be used to place an absolutely positioned element relative to the bottom of the containing block. When 'top' is also specified, the element should stretch from 'top' to 'bottom'. However, when both are specified, IE ignores 'bottom' and instead bases the height of the element on its contents (shrink-to-fit).

IE similarly ignores the CSS 'right' property when 'left' is specified.

Only IE 6.0 and Firefox 1.0 tested. No pure CSS (non-javascript) workaround found yet.

Test page Workaround is not included
Reported by: Justin Schiller.

In Explorer Windows an element both floated and cleared is ignored by a subsequent float: the latter is positioned higher than the former, and overlaps it.

Explorer Mac and Opera don't get it quite right, either, but they're not as bad as Explorer Windows.

Test page Workaround is not included
Reported by: Bruno Fassino.

The box model of a td turns out to be unchangeable in Explorer (Win and Mac), Mozilla and Opera. Explorer Mac forces it into the traditional model, while the other browsers force it into the W3C box model.

Therefore you can't switch the box model of a td, something that is possible for any other element.

Explorer Windows, though, switches the TDs to the correct box model when you use table-layout: fixed. Unfortunately this does not work in the other browsers.

Test page. Workaround is included only for Explorer Windows.
Reported by ppk.

If you use appendChild to move a table row to the end of its table (tbody), Explorer 5 Mac will hang up.

Test page Workaround is included
Reported by: TarquinWJ.

In a frameset a body {overflow: hidden} declaration is carried on to the next page.

Test page. Workaround is included.
Reported by ppk.

When using overflow: auto for an element inside a page, the page nonetheless may become long enough to contain the entire content of the element, even though part of it is hidden. This creates unwanted scrollbars.

Test page. Workaround is not included.
Reported by ppk.

Explorer positions a background-image underneath the border of the element. Therefore it's impossible to get the position of a background image in an element with a border correct in all browsers.

Test page. Workaround is not included.
Reported by ppk.

When using multiple class names for an element, Explorer will ignore all but the last of class names:
element.class1.class2 { }
Explorer completely ignores the class1 selector and happily applies the rule to an element that has only class2 set.

Test page Workaround is not included
Reported by: Tino Zijdel.

Mozilla and Opera split up one huge text node into several smaller text nodes. Explorer Mac acts weirdly.

Maximum text node sizes:

• Mozilla: 4K
• Opera: 32K
• Explorer Mac: 64K (?)

Test page. Workaround is not included.
Reported by ppk.

Mozilla doesn't honour a position: relative on a table, which can therefore never serve as a container for absolutely positioned elements. This is a deliberate choice, and not a bug, oddly.

Test page. Workaround is not included.

On the other hand, Explorer Mac behaves as if every table has a position: relative. It always positions absolute layers in the table relative to the table, even if they should be positioned relative to the browser window.

Test page. Workaround is not included.
Reported by ppk.

Absolutely positioned elements have a secret right and bottom margin of 15px. When you place such an element flush right or bottom, an unwanted scrollbar may appear.
Possibly the margin is the space reserved for the element's scroll bar.

Test page. Workaround is included.
Reported by ppk.

When you change the font size of button elements, odd things start to happen in IE Win & Mac, and Mozilla. Of course, each browser has its own take on 'odd things'. The Mozilla problem is solvable.

Test page. Workaround is included.
Reported by ppk.