When Flex 3 was first released in beta you may have noticed a bug having to do with the Panel component when you set borderStyle to anything other than “default” (which funny enough, isn’t even a code-hinted option in Flex Builder). The issue was that the Flex 3 SDK laid out the Panel contents on top of the title bar, so the content ended up overlaid on the title and it would generally look like total crap. Basically if you had a Flex application that used the solid (or inset or outset) borderStyle on Panel to style your application, suddenly when you upgraded to Flex 3 your app looked really bad. Since Alert and TitleWindow extend Panel this affects those components too. You may have seen things in your app that looked like this:

Yeah, that sucks.

So I figured this was one of those bugs that would get reported quickly (it did) and fixed quickly (it did not and will not). There are 4 duplicate reports of this issue in Adobe’s bug tracking system, the first one was reported June 13, 2007. Here are the 4 issue reports:

• Issue 11279
• Issue 12215
• Issue 12872
• Issue 13012

They’re all the same thing, and they each have example screenshots or SWF files that show how bad the resulting bug looks.

The bugs have all been marked as Not a Bug. And this is the explanation for this resolution:

After some back and forth discussion, Glenn and I have decided that Panel will no longer support any borderStyle besides “default”. The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.

Panel will support other borderStyles when using the backwards compatibility flag. In addition, it will be possible to use a combination of explicit heights/widths and absolute positioning to replicate most of the old behavior for alternate borderStyles.

PanelSkin’s implementation of alternate borderStyles will be mostly working, but won’t layout the header and control bar in the correct locations, nor will it size the Panel to be large enough. We need to document these issues.

In the release notes there will be a line that reads:

Release Note: Panel only officially supports the “default” borderStyle. If you use an unsupported borderStyle, use padding values or absolute positioning to place your content in the correct place.

I call bullshit. This is not an acceptable resolution.

Why bullshit? Let me count the ways.

1. You should never be able to make a Panel that has the content overlaid on top of the title bar. That is fundamentally against the definition of what a Panel is. A Panel has a title bar ABOVE the content area. ALWAYS. If the content area overlaps on top of the title bar then something is wrong. If the answer is that Panel will not layout the contents correctly unless the borderStyle is default, then you should not be able to set it to anything other than default (which is not a good resolution either, but at least it wouldn’t produce such crappy looking Panels).
2. This worked very well before, was there ever a single person who complained that the Panel didn’t lay out its contents correctly? It did exactly what it was supposed to do, which is to lay out the content below the title bar.
3. The default Panel skin gets old quickly, and we want to change up the look of the Panel. Used to be that you could just set borderStyle to solid and make some nice looking Panels that didn’t have that same opaque content area with semi-transparent border look. Now those decent looking Panels you styled in your old app are harder to make.
4. I don’t buy the argument that “The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.” I guess the issue is with graphical skins as opposed to programmatic skins. PanelSkin returns border metrics that are used to layout the Panel’s contents (ie place them below the title bar by checking the headerHeight of the Panel). That code seems kinda hacky to me already, it means that the layout of the children in Panel is determined by a programmatic skin. But if PanelSkin is returning the border metrics used in Panel to layout the children then it could easily do so for the other border styles too. This would at least solve the problem when using the default PanelSkin (which must be the bulk of what people do). Maybe I don’t understand the issue with graphical skins, but let’s say you’re using some graphical skin to skin Panel, when would you ever want your Panel to have the content area overlap the title bar? Never. I just don’t get it.
5. The “solution” for people that want to use the “unsupported” border styles is to set the paddingTop style to be the same or greater than your headerHeight, which will force the content to be placed below the header. But wtf kind of solution is that? We have headerHeight for a reason, and that reason is so the content gets placed below headerHeight pixels from the top. This just sounds like an answer of “well, you can hack your way around it, so that’s good enough.”

So basically I’m just bitching, because this bug will likely just stay “resolved” and be released in Flex 3 when it ships with a little release note to warn people to not do what they will invariably try to do. I don’t know if there is a formal thing I should do to try to get someone at Adobe to reconsider, the bug was filed 4 times and all are marked resolved. I assume if I submit a new one it will be marked as a duplicate and resolved. Sigh.

Oh, and Flex for Dummies will have a sentence similar to this:

WARNING: If you set a Panel’s borderStyle style to anything other than default then you must also set the paddingTop style to at least be as many pixels high as your title bar. The default implementation of Panel with borderStyle set to anything other than default sucks.