I'd like to be able to claim full and bug-free support for css3-background in Firefox 3.7/Gecko 1.9.3, but there are a whole bunch of bugs to fix first. Most have something to do with border-radius.
Nearly all of these bugs would make good newbie projects or intern projects. I think everything could be fixed with less than three man-months of effort, provided that reviews are timely.
These are correctness issues that should probably be fixed before we drop the -moz- prefix on the border-radius properties:
Vertical percentages in a border-radius specification are supposed to be relative to box height, not box width. This is trivial to fix in the rendering engine, but requires a theme audit, because many themes are using a single percentage and expecting to get circular corners.
Content, especially images, is supposed to be clipped to the inner curve under some conditions. We currently don't. I think this is a simple matter of programming. 485501 has a work-in-progress patch from dbaron.
We can get visible single-pixel seams at both edges of a curved border, where the underlying box shows through, due to antialiasing at the boundary. This is especially visible with a light-colored underlying box, a dark solid-color border, and box-shadow (at the outer edge) or a dark solid-color background (at the inner edge). The top left figure shows this effect (mimicked with SVG).
Closely related problems appear when the border is semi-transparent. The top middle figure has an outer edge that's a little too dark. The top right figure has a seam at the inner edge which could not be corrected by removing the "don't draw the background under the border when the border is opaque" optimization.
I think we can resolve these problems with trapping (drawing with overlap) rather than supersampling. The bottom row of figures have 0.5 SVG pixels of trapping. At left, we have to make the box-shadow and the background extend a little under the border; in the middle, we pull the background in a little from the outer edge; at far right, again we make the background extend a little under the border. This is the one case that is still not right; the inner curve is now too dark. I can argue that this is worse, and I can argue that it's better.
This approach probably won't get us the pixel perfection that reftests expect, and I'm not sure it'll work for very eccentric ellipses.
For dotted or dashed borders, we have to fit a pattern neatly along a curve that may be elliptical and may not have a constant thickness. No drawing API gives us this as a primitive. The left diagram shows one possible approach to dashes: clip to the triangles, then fill the light blue curved area. The right diagram shows what we need to be doing for dots, but I don't think we have any alternative to drawing each circle individually.
The real challenge here, though, is finding a good algorithm to place the individual dots and dashes. See bug 19963 for just how hard it is to do dashes and dots neatly along a line...
The border-image spec was totally rewritten after we implemented it. We ought to pick up the changes. (Bug 497995).
background-position, background-size, background-repeat, and background-attachment are all partially implemented: bugs include 319729, 411244, 483446, 506373, 522607, 526602, 539941, 548372.
We don't implement the official background-clip syntax (we have "border" and "padding" instead of "border-box" and "padding-box"); I wasn't able to find an existing bug for this.
Anything else I missed?
There are a bunch of bugs describing massive CPU load from scrolling or switching tabs on pages (or chrome, perhaps) with curved corners, but I can't reproduce any of the problems.
Do we know about any other situations where it's too slow?
Conic gradients for color transitions along a curved corner (bug 483696) would be relatively easy if we had gfx support for them.
A common use of -moz-border-colors in the wild (see
also below) is to make the border a gradient. Can we add support
for gradient functions in border-color?
This completely nonstandard property appears to have been intended solely as a hack for browser themes, but is being used for web pages in the wild (and claimed to be part of css3-background!) It's inconveniently verbose, and can't be used at all unless you know exactly how thick your border is in pixels.
Since it's out there in the wild, we ought to think about how we could turn it into something we wouldn't be ashamed to propose for css4-background. We're stuck with something not entirely unlike the current syntax for backward compatibility's sake, but we could make it be, say,
border-[top|right|bottom|left]-colors:
( <color> ( <length> | <percentage> | 'auto' )? )+If the length field is left out, it defaults to 'auto'. Percentages are relative to the width of the border on the relevant side. After all fixed- and percentage-width stripes are satisfied, the 'auto' entries divide the remaining space amongst themselves. (Defaulting to 'auto' is technically a change from existing behavior, but since you can't really use it right now unless you say exactly how thick the border is I doubt it'll be a problem.)
My web designer friends asked me if we could add the ability to clip the background to the middle of the border; this looks better with dots and dashes.
Border images are pixelated when upscaled on Linux (bug 532396). I could swear I coded it specifically to avoid that. Maybe it was broken when we put in tile caching? Anyway, should be a quick fix.
Border images show seams between the tiles under some conditions (e.g. when rotated). Possibly fixed by layers? Or by drawing to an offscreen surface that's not rotated, and then blitting to a rotated one.
There are a bunch of bugs on the interaction between border-radius and tables; frankly I don't understand what's supposed to happen there.
Should an 'outline' pick up curves from the border-radius (as box-shadow does) or should it continue to have its own curve spec?
For elegant transitions between border styles along a curved corner, someone with more graphic design skillz than me should sit down and figure out what they should look like.
A path construction function which appends a quarter-ellipse (or a general elliptical arc a la SVG) to the current path; bug 501262. This would get us out of having to draw several clipped rounded rectangles for every border with a curved corner.
Conic gradients, and more generally, the ability to paint a linear gradient either parallel or perpendicular to an arbitrary path. Code might be available in the Anti-Grain Geometry library. Unfortunately, this does not correspond to a PDF or SVG primitive, and I don't know if OpenGL can accelerate it either.