The paint layers are badly named. We should rename NS_FRAME_PAINT_LAYER_BACKGROUND to NS_FRAME_PAINT_LAYER_BLOCK and rename NS_FRAME_PAINT_LAYER_FOREGROUND to NS_FRAME_PAINT_LAYER_INLINE. (If we don't get rid of them completely first.)

I'm going to turn this into a bug on removing paint layers, which should speed up painting a bit, and should (I hope) be allowed by the next version of CSS.

Ugh. Do we really want floats to paint on top of text?

Why not? It only matters when people use negative margins, negative text indent, or something similar.

BTW we need to change things to create a view for every float (because floats can have a containing block other than their parent element, and this needs to be reflected into the view system to fix some obscure bugs). This would also have an effect on z-ordering.

Why do floats need views? According to CSS2, they *can't* have views because that would break the z-ordering that paint layers do, but that's probably relaxed in CSS 2.1.

(BTW, I think I want to start attaching floats to their containing block rather than their closest block, which they have very little to do with. That might need to happen first. Is that what you're talking about?)

There's already a pile of logic in nsCSSFrameConstructor to attach floats to the floater containing block. Does that not work?

I think they go in the floater list of the nearest block, which is technically the containing block according to the spec, but not logically.

So the spec is wrong and will be changed? Also, like all other frames, there are various reasons why we might want to attach a view to a float, for example if it's translucent. We have to be able to do that successfully.

This seems to make things (much) easier for bug 185977

Note that even if floats paint at the z-index:0 layer, or some other layer on top of blocks, all inlines should still paint on top of all blocks backgrounds and borders, according to all the proposals I've seen sent to the WG. Personally I am still attached to the idea of having floats paint over other blocks, but having all inline elements paint above everything in normal flow.

What about inlines that contain blocks? Can't we just continue to say "document order", possibly clarify that by saying that if A contains B then A comes before B in the document, and then be done with it? That will guarantee inlines on top of the blocks that contain them.

I think the spec is pretty settled here, so let's go with wontfix. (The layers still exist as part of nsDisplayList, but with new names.)