Cocoa Widget Work

I’m working on Cocoa widgets some now, trying to fix them up and get them working in Firefox. Basically, we’ll have Camino-style widgets in Firefox. Using Cocoa widgets doesn’t necessarily mean that widgets (form buttons, etc…) will look like native widgets, that just happens to be the case with many widgets. It really only means that the widget code is (mostly) written using the Cocoa API as opposed to the Carbon API. So, with Cocoa widgets in Firefox we get some better looking forms and easier-to-maintain code. Furthermore, if we can get all products onto one widget set then we will have further reduced maintenance overhead. I’m learning the code right now, and starting to know enough to get some real work done. I may have it limping along by next week, but it won’t be a part of Firefox until some time after Firefox 1.1 is released. There is a considerable amount of work to be done.

13 thoughts on “Cocoa Widget Work

  1. Is this sharing the code from Camino at all?

    Also do you think this is undermining Camino at all?

  2. I’m not a developer. What’s this mean in terms of navigating around assorted fields in the interface? Will we pick up the Cocoa/Emacs keybindings instead of having to edit the platformHTMLBindings.xml file?

  3. This is excellent news. Will there be an option to maintain the current look -and, more importantly, styleability- of the current widgets?

  4. I am just curious. But what do Cocoa widgets do that its Carbon counterparts can’t? Going native widgets doesn’t mean have to be going Cocoa, does it?

  5. Stephen Chu: I explained that in the post. Carbon widgets could look native too, but the way we have them implemented they don’t. We’re not going to cocoa widgets just for the sake of looking native. The cocoa API is just way better for what we need to do.

  6. How will all this affect how CSS affects form elements, especially in terms of size?

    I know “real” CSS for form widgets is not here yet, but Mozilla/Firefox always provided Web developers with widgets that looked the same cross platform, and were easily controlled with css. I’d hate to loose this.

    One thing that microsoft did reasonably well is the fact that when form elements are CSS affected, they comply, and drop their native appearance as needed. I’d hope Firefox’s implementation does something similiar.

    Designing form elements for tight spaces is nearly impossible without CSS, and it’d be nice of Firefox doesn’t “throw the baby out with the bathwater” for the sake of “native” widgets.

    A compromise would be to use native widgets when no CSS is present, and then the Firefox “standard” widgets when CSS is applied.

    This could be a sliding scale as well — i.e. draw native widgets as best as possible to css provided (especially things like width and height, which are critical to layout control) — then only resort to non-native when appearance-specific CSS is applied, like borders, colors, etc.

  7. Actually Michael, Firefox on Win XP has native-style form widgets, not “widgets that looked the same cross platform”.

    I believe while they’re not actually native widgets, XP’s theme service/skin engine is used to style the form widgets, unless the page author has applied any CSS styles to them. In fact the funny thing is it actually works a lot better in Firefox than IE, try making a very wide, unstyled form button (put enough text as its label to be as wide as your screen, and yes I have seen real in-the-wild buttons that wide) and viewing it in IE on Windows XP (Luna), then do the same in Firefox, you’ll notice that in IE the corners of the form buttons start looking very nasty and pixellated (like a stretched bitmap) whereas it stays looking just as smooth in Firefox.

    If you have an XP box you can see it using the native styled widgets quite easily by switching between the XP Style (Luna) and Classic (Windows 2000 style) themes in XP, then running Firefox and seeing what happens to unstyled form buttons (and other widgets, though form buttons and radios are some of the most obviously changed widgets).

  8. I guess I wasn’t clear… I meant that when you apply CSS attributes to form elements, particulary buttons, they no longer appear as native XP widgets, but rather follow the CSS specified. Firefox does this better than IE, but they both do it.

    This page for instance:

    CSS allows you to differentiate the two buttons on the page with color. You can also do a lot with borders and background images to acheive different effects. Most critically, text adn button size attributes allow you to fit form elements into layouts better.

    In Safari, for instance, all this formatting is lost, and you just have two out-of-place-looking gray aqua buttons.

    I just hope this is not the case for the new native widgets implementation in the Mac version of Firefox. Otherwise, it’s losing funtionality, IMO.


  9. Allow me to echo Michael’s sentiments: the widgets need to be able to respond to styling. We should not sacrifice important Web functionality for the sake of a few UI zealots who don’t understand that the Mac and the Web are two different things, and that to force the conventions of one onto the other is a Very Bad Thing.

    I have long been against the idea of native-looking form widgets, precisely for this reason: they cannot be made to respond to styling. If there is a way to switch to the Moz-style widgets (as opposed to Mac-style widgets) when styling is applied, however, then this would make a good compromise: the zealots can have their native widgets while the Web can have its stylability.

Comments are closed.