The current Aqua widget styling used by Camino's Cocoa widget implementation has a number of problems, including: 1) <input type="button"> uses Aqua push-buttons, but honors some CSS styles, which in certain cases merely cause visual problems and others more serious usability problems (e.g. bug 315024) 2) <button> uses regular, CSS-styleable gfx buttons, so it looks out-of-place on pages with other Aqua elements (e.g. Gmail) 3) assorted problems with background-color, font-color, and other styles in <select size="n"> (listboxes) 4) probably some additional problems with other form elements See bug 205136 (especially its many dupes), bug 309556, bug 310266, bug 315203, and bug 193232 for some of the real-world cases and previous discussion. What Safari is going to do for <input type="button"> and <button> is creating a hueristic determining which type of button you'll get based on the styles specified and which CSS properties will be disabled/ignored on Aqua-style buttons, and creating some sort of vendor CSS property (AFAIK) that allows authors to completely disable Aqua styles if they want a blank slate on which build their own button with CSS. This seems to be a reasoned and practical approach for dealing with the problems of Aqua buttons and CSS styles, and we should consider doing something similar (ideally, the same thing as Safari to ease authors' jobs), and this bug is for discussion of the possibility of doing such a thing for Cocoa widgets. (Please switch components and cc additional folks as appropriate if I've missed anyone.)

So how exactly does this all differ from our existing IsWidgetStyled checks?

Camino only uses IsWidgetStyled for a couple of widgets. This would basically consist of widening/improving Cocoa widget's IsWidgetStyled use. Although, to do <button> right really requires examining the style/contents of the subtree, and I'm not sure if there's currently a mechanism for that.

> This would basically consist of widening/improving Cocoa widget's > IsWidgetStyled use. OK. Sounds like a good idea. > Although, to do <button> right What does "right" mean? Is the issue that a <button> may have arbitrary content as children? Or something else?

> What does "right" mean? Is the issue that a <button> may have arbitrary > content as children? Yes. There are lots of cases where things that would cause falling off into gfx if they were on the <button> could instead be applied to the contents of the <button>.

So what do other platforms do for <button>?

For the sake of completeness, see also http://webkit.opendarwin.org/blog/?p=17 for checkboxes and http://webkit.opendarwin.org/blog/?p=51 for poking-your-eyes-out with form fields, but <input type="button"> and <button> are really the two key issues/widgets.

Should this be closed?

Looks like it.