Hm. Very interesting question. I don't know if I have a good answer yet -- but I'll think about it. Some of the obvious answers may bring up complications -- like, what happens if the author or the user overrides the margins via CSS and sets them to zero?

If Ben Goodger, for example, ran around setting:

input, textarea { margin: 0px; }

... in order to fix the appearance of his site in Safari.

Hmm. Then again, if someone WANTS to have a jazzy design, maybe this is the price they need to pay for it? Presumably the author should decide if it's okay for a zero width margin -- and if they don't specify, then it's left up to the browser and the user. This is the way the Web's supposed to work, after all? Maybe.

Still thinking.

--Kynn

This is an interesting problem and I have seen it when creating my own applications.

I think you're right about the web being designed for Windows browsers. As you probably know, the native widgets in XP have a glowing focus effect similar to Aqua, but they have put the glow inside buttons probably to avoid this problem. I sorta like how you can't change Aqua widgets that much, I think it leads to a better experience. I've seen so many form controls on the web that have been modified so much that you can't tell they are controls anymore... Although as you say it would solve alot of problems if they were scalable.

I'm sure someone has a solution out there, or you could just leave it :). Good luck... I'm definitely going to ponder this further...

Unless I'm missing something, the answer is pretty simple: Knock on some doors at Apple HQ and get the core UI guys to implement scaleable 'native' widgets.

Whatever you do, though, please don't implement non-native widgets. No matter how many times I've heard "oh, they'll be just like the real thing" from coders I've never seen anyone do it well enough (*cough-Mozilla-cough*).

Remember, this is an Apple browser we're talking about. It needs to feel like an Apple product through-and-through.

If you can get the core OS guys to make a change for you, Mac OS X versions 10.X and up can have the expected layouts, and the rest can have it as it is now.

...

If that's not an option, I'd err on the side of native looking and acting widgets. I've been using Safari for a few months now and I don't think I've ever seen this bad behavior you speak of, but if I do I'll chalk it up to a designer making rash assumption and go elsewhere.

I was designing a new site yesterday or 2 days ago and encountered just that very problem you mention as problems nr 2 & 3...
I especially wanted to use a non-shaded text input box, with a tiny red border. I had done that before in websites, but never noticed Safari doesn't render those nicely. Only while making the new site I indeed saw that none of the websites I knew using that technique did fine in Safari, or in any other Mac browser I tried (Camino and IE).
Indeed: Camino and IE also will keep using 3D widgets, whereas for example IE6 on Windows will make a 2D input box if you define style="border: 1px;" in the tag or in a separate CSS class.
I would like to be able to use the border thing, but I can understand if that is a lot of trouble. As for the scaling, that is quite important, even if it were only to be able to visit sites designed with people who do not check multiple browser behaviours.

IIRC there is definitely some rectangular buttons that could be used easily enoguh unless I'm totally mistaken. I'd imagine those would scale easily enough. Whatever the case something needs to be done as you've noticed. And once that's fixed printout with buttons on them will look halfway decent too...

Also while you're at the whole widget thing, is there any way you could make drop downs easier to navigate. For some reason I dislike the way the mac handles them and miss the smaller box that windows drops down with provided scrollbar. Some happy medium could be found.

You're preaching to the choir. I absolutely hate Mac dropdown lists. I think they are less usable than Windows-style dropdown lists in virtually every way... especially since Web sites load up the lists with many items. I would actually be interested to see a treatise from a Mac expert on why the dropdown list was designed that way, and why it's considered more usable than the Windows dropdown list, because I'll be very impressed if that person could come up with any arguments that I would buy. :)

When Camino got for a period "non-native" widget...i really really like that! i know that this can sound like a blasphemy to many mac users here, but...too many time aqua widget look really bad in a site. They don't match at all with anything around them, they seem "aliens" in a country house :) I don't want a consistence of widget with my system, because or all the web page is consistence with my system or it's a nonsense that only the widget are "consistence"....i prefer a consistence in the web page...

my 2 cents

Hi

I opposed the W3C/XUL insanity of web-styled widgets from the very beginning for this exact reason. In my humble but correct opinion, controls in web pages should be platform-native widgets, end of story. Web pages should not be able to override the fonts in them any more than they can override the fonts in the menubar. I'm not even convinced it's a good idea to allow them to control the colors.

But hey, what do I know.

The problem is that the capabilities of widgets on different platforms differ. Sure, it's easy to use native widgets on Win32, since you know people are designing for those widgets, but on alternative platforms life is a lot more difficult even without the "W3C/XUL insanity".

For example, the issues I raised with the sizing of form controls are created only because the Windows widgets work a certain way, and people design expecting that behavior. It's perfectly acceptable for native widgets to ignore CSS properties from a standards-compliance perspective.

The problem is that WinIE honors certain properties, thus forcing everyone else to honor them too or risk having bad page layout., and if your native widgets don't have the same capabilities, you have to either design new native ones or make your own non-native ones.

Either task is huge. Neither should be necessary though. You're right about that. I just blame the difference in widget abilities (and the support added to WinIE that uses those abilities) for the problem and not CSS itself.

Would it also be possible to Aqua-fy the 'button' controls? I have an intranet site that uses a combination of 'input type=submit' buttons (nice and Aqua, and 'button' buttons - which are nasty grey Windows-like square buttons. (I use these because it's often useful to put an icon in the button to get people to press the right one...)

Web site UI design is about creating an environment visually independent of the computing platform. The fact that some platforms take over the environment in special cases (widgets) removes the control the designer has over the appearance and usability of the site. The whole point about standards is that they provide a standard - so that we can build something that looks and behaves exactly the same irrespective of the machine the user happens to be sat in front of. Control over every aspect of the interface must therefore be left with the designers, even if, as is the case, there are only a few who actually know what they are doing. The fact that 95% of the web sites we see are rubbish does not mean we should pander solely to those with no appreciation for good UIs (which is I guess why most of us prefer MacOS over Windows in any case).

Standards should and must come first. If that means a particular OS' UI widgets look wrong, then that, I'm afraid, is a problem for the OS UI designers, not the standards. A designer might then choose to cater to all the various foibles of the various OS' widgets, if they want the user to be presented with default system UI; otherwise, they should be allowed to expect widgets on a web page to respect the web standards, and be allowed to expect the correct behaviour in browsers, and to expect to be able to make intelligent decisions on their own without being pandered to - again this is the reason why some people loathe the Windows UI.

Dave, please let the designers make the decisions when they design sites, and carry on building the perfect, compliant browser that we have come to look forward to / expect. If Apple wants to make the OS UI more compatible with standards, great. Perhaps, more practically, they could add a "widget when applied to a web page" UI guideline in the next OS upgrade. If not, designers are bright enough to be able to make the decisions themselves, based on observing the effect of their UI decisions on your perfect browser's rendition of their perfect web site.

(hyatt)
> I would actually be interested to see a treatise from a Mac
> expert on why the dropdown list was designed that way,
> and why it's considered more usable than the Windows
> dropdown list

You should probably follow the Apple UI guidelines on this one:

http://developer.apple.com/techpubs/macosx/Essentials
AquaHIGuidelines/AHIGControls/index.html

It says not to use pop-up menus "for more than 12 items; use a scrolling list". I guess just count the number of items, and handle as necessary.

I'm not a big fan of scrolling lists, even for lengthy lists, and I think most of the time they're used for lists under 12 itemss anyhow. But if going against my preference means complying with Apple UI guidelines in an Apple application, I'll learn to get over it. :>

(felix)
> Standards should and must come first.

Exactly, though I read this 100% differently.

The UI standards of the computer you use day in and day out should trump the 'standard' Joe Designer chooses for his web site. Particularly since this so-called standard results in a million different variations for the _same exact widget_.

Most sites will never be visited again. Worst case scenario, if people take advantage of this 'feature' I'll have to re-learn what widget does what with each site I visit, when most of the time I'm just browsing through and will never return. Why? So some designer can make it look a little nicer?

> removes the control the designer has over the
> appearance and usability of the site

Appearance, maybe, but how exactly do native widgets detract from _usability_?

The web is for users, not designers. Given that most of the "designer-ish" sites I've ever used are usability nightmares - full of flashy-but-useless graphical gizmos and unintuitive design elements - I think I'll take a halfway consistent UI instead.

Again, the web is for users, not designers. There are a lot of us out here who need to use it to get work done, and playing a game of "Where's The Widget" isn't conducive to that goal.

Just my contrib...
This is gonna sound like moving the mountain instead of mohammed but maybe, to future-proof the OS, the Aqua widgets should be amended to allow WebCore to use them in a more web-friendly way, even if this is just a flag or some such thing that allows you to remove focus rings or scale fonts as needed. Surely this would benefit Sherlock, the Help System and any other current or future use of WebCore in OS X.
Go ask Steve J if he can shoehorn it into Panther before WWDC...

I'm with Jeff C. all the way on this. Like rock/paper/scissors, Macness beats Webness. Always. Everywhere. Forever.

I would like to see some sort of "second-tier" native scalable widgets, designed solely for use in "platform-ignorant" applications.

As for dropdown lists, Dave -- I'm confused. When you say "Mac dropdown lists," are you referring to pop-up menus? Cuz those ain't dropdowns. If you've ever used FileMaker to create a layout, you may have noticed that they provide both pop-up menus and dropdown lists (the db developer chooses the field behavior). And FoxPro has an application preference for Mac vs. Windows behavior.
Of course Cocoa has a "combo box" widget which is like an editable dropdown list, but there's no non-editable dropdown list.
Hey, how about option-clicking on a pop-up menu to get a dropdown list?
Just a wild idea at 3:00am.

-boo

Seb: "icon in the button to get people to press the right one"

But if you use a 'button' button, you are then requiring JavaScript, which a 'submit' button does not.
And what is the "wrong" button? If you mean 'reset' I hope you realize that is optional. There is probably only one in a million forms where a reset button is needed; it's often pointless.

-Walter

Dave,

Asking why the Mac "dropdown list" (which does not exist; we have pop-up menus) is considered more usable than the Windows dropdown list, is an invalid question because when Apple designed pop-up menus, MS Windows did not even exist in Bill Gates' head.
A valid question would be, "Why did Microsoft invent the dropdown list instead of using pop-up menus?"
The answer, of course, is that PCs came with DOS, not mice, so Windows needed a fully keyboard-drivable set of widgets.

I think that's really all there is to it.

-Walter
::emailing John Geleynse::

>You're preaching to the choir. I absolutely hate Mac dropdown lists. I think they are less usable than Windows-style dropdown lists in virtually every way

Hmm as always a little history would help here. This time in the form of Apple's Human Interface Guidelines:

1. The system didn't have drop down lists, only popup menus and normal lists.
2. Use of a popup menu was recommended for small numbers of items, on average less than 6.
3. If you want to display a list of containing more than 6 items then a full list box is a better way to do it.

So you can't blame Apple for millions of brain dead web designers who don't care for HCI usability, or those that go for the ostrich approach: ignorance is no excuse. They were never designed to accomodate a list of over 100 countries. Font menus are bad enough too.

Windows drop down lists suck ass, out of the web browser you can't tell what they are (they may be combo-boxes with their own peculiar behaviour), they still look partially like text boxes even though you can't enter text directly in them. In the browser you are forced to scroll through a list of more than 8 or so items, the list isn't centred on the selected item.

Also not all web form elements respond to CSS rules, the drop-down list in Win IE is notoriously inflexible.

Anyway how to handle <select> tags in a sane manor.

* If the standard popup-menu can accomodate the font-size use one of those.
* If the font-size is really small use the small popup-menu widget.
* Create a scaleable version of the popup-menu control for larger text sizes (smaller ones don't matter if the text is much smaller than the size small popup-menu is designed to contain it will be practically unreadable anyway).

Toying with the idea of having both custom (non-mac-like) widgets and mac widgets. Use Mac wigdets when no appearance changing CSS is used on form elements. Switch to custom ones if things like border colour are changed. Don't like the inconsistency aspect of that but alot of web pages use their own button graphics anyway so who knows.

This is what I would expect from the controls (buttons and popup) in Safari:

I don't think making scalable widgets with the aqua look would be great, but what about setting a threshold for using the small variant and the bigger one?

For the size of the element, I would simply consider the margin to be part of the control, so if your control is 30px width, you take up 4-6 px reserved to the aqua focus ring and the real size of the control is now 26-24 px.

And for custom styling of theses controls, I'm not a big fan of them, but I would try to implement them using a transparent popup (just like the ones in Project Builder with the list of opened files) that can use whatever colors, border and font specified. But only allow them when the CSS specify both custom background AND border. And don't forget to set the popup arrows the same size and color as the text.

I hope it gives you some ideas.

I have an idea.

If the page uses controls without the fancy properties (borders, colors, etc), draw true Aqua controls.

If the page does use the fancy properties, draw faked ones. (Hey, the BUTTON tag is already faked, right?) :)

> Hey, the BUTTON tag is already faked, right?

Correction: I mean, the control that is drawn using the BUTTON tag, of course. :)

"Windows drop down lists suck ass, out of the web browser you can't tell what they are (they may be combo-boxes with their own peculiar behaviour), they still look partially like text boxes even though you can't enter text directly in them."

Oh lord, ain't that the truth. At SLAC, we actually got a bug report from a [Windows] user who complained that she couldn't type into the box. (I did my best to explain to my boss that it was not a bug in my Web application but was due to Microsoft's design of Windows and thus completely beyond our control.)

-boo

Off topic I know, but I don't have your email address Dave.

It's about better integration with Mail.

The problem it solves is the multiple trips back and forth you need to do if you want to email someone a web page. You often want to copy the URL and some of the text right? That makes two copy and paste trips.
 
The addition of a 'Send to Mail Button' makes it all happen in one click.
 
You select some text on the page if you want to specify what text is emailed. If you don't specify any text, either all the text, the beginning (first 200 characters followed by an ellipsis) or none, depending on your preference setting (default is first 200 characters) are used.
 
You then click the 'Send to Mail Button' and your selected text is automatically put in the body of a new message, followed by the URL, the title of the page is in the subject, after "Site:" so all you need to do it enter the name of the recipient and send, or add some comments, as you prefer. And that's all there is to it.

NOTE: This is also found on http://www.liquidinformation.org/safari-mail.html with an animated screenshot.

This become really important for web based applications. We are building a web app for architects, engineers and construction companies. They use it every day. Drop down lists are very important, and so is their quick navigation.

We use size and color for efficient layout. Also drop down list navigation in Windows is better because you can type a letter and the list and go straight to the section of the list beginning with that letter. Great for state lists in addresses

I don't use Macs so I don't know what these focus rings are, but couldn't you simply clip them, were there to be any overlap with other controls?

Jeff:
> The UI standards of the computer you use day
> in and day out should trump the 'standard' Joe
> Designer chooses for his web site. Particularly
> since this so-called standard results in a
> million different variations for the _same
> exact widget_.

Must disagree; the 'standard' should be set by W3C. The user should get the same behaviour every time (hence this thread). The designer shouldn't choose - the designer should follow the standards, not follow the wide variety of OS UIs, some great, some terrible. If the designer wants to vary something (for better or worse - and when I say designer I mean expert in visual communication, not artist, illustrator or coder), then they have to rationalise that decision to their consciences, client and audiences, the latter of which will decide if s/he keeps the job.

There are too many variations in what they have to work with because work-in-progress browsers like Safari (brilliant though it is) don't actually work properly when The Standard (W3C) conflicts with the standard (MacOS UI Guidelines). The web is supposed to be accessible to all, irrespective of system. If Dave's implementation overlaps, something's got to give between W3C and Apple, and to be fair, we're looking at W3C space (in my case) through an Apple mirror; the latter is the one doing the distorting.

Now, if someone could give Apple the financing to buy and break up Microsoft, perhaps Dave's UI designer colleagues would have a little more say in designing a more user-friendly button standard that he could reflect in Safari without the angst :)

Why not give us a preference setting to either use aqua native widgets, or the standard CSS modifiable widgets?

The glowing focus rings, couldn't they be made opaque and glow over whatever is right next to the selected widget? While the glowing would overlap slightly with the neighboring widget, the opaqueness would make the text of the next widget still readable. Just a thought.

However, currently the pull-down menus don't seem to be selectable when tabbing between text fields. This is something I really liked in IE for Mac. There one can tab between all text fields and also the pull-down menus. When selecting a pull-down menu, one can type in the selection (i.e. type NM to select the state New Mexico)...

hyatt said: "third problem with native widgets is the difficulty in supporting other CSS properties like colors and borders"

Ignore colors on form widgets and claim that the UI guys at apple wouldn't let you ;-)

Hyatt: There are coloredButtonCell controls flying around on the internet. It's doable.

one thing i really miss is keyboard navigation like IE/mac.

being about to tab through links on the page and form elements (even checkboxes, radio buttons, pop-up menus, and submit buttons), or opt+tab through just text inputs.

and that when you have the focus on a pop-up menu, you can just type the answer without even clicking the menu.

like if a wanted texas

tab to state pop-up, type "texas" or "tx" depending on the format. or you can press just "t" and arrow down till you get to texas.

all these fatures are sorely missed in safari, and slow me down so much when navigating pages.

one more thing, i like the fact that you can type the name of a link, and it will have the focus then you can just press return. no need for the mouse, no need to scan the page for the link. great for finding that damn search link on pages.

I don't want colors in my controls. I don't want different fonts. I don't want non-standard controls, either. I want my Mac. I want my Aqua buttons, menus, and controls. I want web designers that want *that level* of control to be *disappointed* that someone else knows better than to give it to them.

I want Safari to flip them off and laugh after throwing the Jaguar HIG at them. If you need a border to draw a focus ring, you go on and do it. Apple's ignored the HIG for two years [ducks] so do what you need to, by default, follow it. They can override the CSS if they really, really want to.

For the fellow wanting keyboard control in Safari, enable Full Keyboard Access.

[tries his advice]

GAH! Doesn't work! Feature request: obey the operating system directives.

I think the answers are to have scalable and stylable widgets implemented at the widget level, even if it means engineering work outside of the Safari cabal, and to not include an automatic border around these widgets, but to improve the visual experience when a halo around one item overlaps another item.

The bigger concern for me by far is that Safari doesn't respect the Universal access settings, to allow people to navigate to and within popup lists.

I'm happy to hear you're trying to add focus rings to the form input widgets. Using a laptop, it is far easier to fill out web forms using only the keyboard and IE is great in this respect.

Of course, Safari's widgets look much nicer than IE's, but keyboard access is more important to me and has kept me from making Safari my default browser.

As far as the whole 'form fields won't fit in the layout correctly' issue ... I'm a web designer, and what I was taught was to never layout a page where form fields were put inside tables with set pixel cells and so forth because form fields were, by their nature, not consistent from browser to browser and platform to platform. If a designer has done this, then it's too bad for them if it breaks their design. They're obviously not considering other browsers and won't care if somebody e-mails them and says 'your page looks wrong in Safari or browser Y for the Mac.'

Form and function if possible, but, if not, function first.

I've got a relatively simple-sounding idea. How about scaling the margin inward instead?

Make the input boxes, buttons, and maybe even the fonts inside the input boxes slightly smaller to compensate for the margin. That way, the input box will be exactly the same size as originally intended, and still be able to show off its Apple UI compliance.

Hi,

my job is webproducer. For me it is important, that the behavior of safari is like windows IE; that's what I expect. No company will - ok some will :) - spend extra money on a webdesign that's adapted for one browser with less then five procent marketshare... so it have look as on windows.
For me it would also be very helpful, if I could design the form-elements as i can do on win ie. With border, background-color and so on. But the biggest problem is the w3c-behavior by tags. They produce a break after closing-tag. So we have to positioning them non-w3c like. If this could be fixed....

form-examples: http://www.designplace.org/tutorials.php?page=1&c_id=9

PS - non-topic: a bluetooth apple-mouse with additional right-button would be great... :P

btw, support of attribute accesskey would be great..

http://www.w3.org/WAI/UA/TS/html401/cp1102/1102-INPUT-CONFIGURATION.html

>What's a Web browser to do? :)

Make the user's web experience match what the web designer expects. I would rather have my web site viewing predictable (and show me all the text the site developer thinks I'm seeing!) than to look a lot like my OS. If you can get both things, great, but if not, always err towards having the user see what the site expects them to.

1. don't mess with the Aqua UI outside the browser
2. use Aqua widgets when nothing else is requested
3. use custom widgets when the web site specifies so
4. give me a preference option to switch off custom widgets! (If a site uses those it's probably messed up anyhow ...)

There's nothing wrong with popup menus. The web just lacks list boxes.

bye. Andreas.

The people who are saying that the OS must in all cases bend itself to exactly what the designer specifies are full of it. The question is more complicated than that.

I mean this with all due respect to W3C and web page designers everywhere... but you all know that some of the poorer designers out there do some horribly nasty, evil stuff. Any good page designers reading this, you're not the problem. The problem occurs when bad designers attempt to be too clever for their own good and go beyond simple elegant code. As a page gets more and more complex, the likelihood of bugs increases. Not validation-type bugs, but accidental-reliance-on-implementation-detail bugs. At times this reliance on implementation detail winds up getting turned into the standard, and realistically that can be considered a bug in the standard. (Perhaps a bug you're stuck with, but a bug nonetheless.)

The funny thing is that this isn't anything new. Application reliance on implementation details is a problem that occurs all the time in traditional non-web software design. I don't know if there's any literature on what has happened with these types of issues in the past, but it might be worth looking into.

To make it worse, on the web you have several entities all going in different directions: The page designers, the standards bodies (W3C), the dominant implementation (MSIE for Win), and the little-guy implementations. But though they aren't trying to do so, they follow a herd mentality:

- The page designers test against MSIE for sure, and W3C if you're lucky.
- MSIE tests against the page designer's work, and W3C if they feel like it.
- W3C does whatever it feels like, and may consider existing implementations if you're lucky, but usually restricts itself to the needs of "the majority" of existing implementations.
- The majority of existing implementations are emulating MSIE because they must... because see above, the page designers are only testing with MSIE.
- The end result is that W3C indirectly codes its standards for MSIE without really meaning to.

And voila, everything winds up looking like MSIE whether you like it or not. Welcome to the herd. What can the little guy who thinks different do?

There are a lot of answers to that question, but it doesn't leave a lot of room for innovation or making things better.

The closest parallel I can think of is multi-fork files. If you know the story there, Apple used them originally, then gave up and is moving away from them ... just as the rest of the world is starting to move that way. I'm going to guess that Dave and Safari are going to try to do the right thing, encounter so many problems that they eventually (several releases down the road) give up, and implement pure Windows behavior ... then finally the rest of the world is going to come around because Microsoft and Mozilla decide that they want to implement more Aqua-like controls that aren't quite as ugly or as subject to arbitrary scaling as the standards currently require them to be.

Sorry Dave, I wish I had advice but all I can give you is a prediction of the future. Try to make it happen better than I've painted it. :-)

Adreas, you beat me at the finish line :-) , I agree totally. I'll just post these quotes wich i agree on:

"If the page uses controls without the fancy properties (borders, colors, etc), draw true Aqua controls.

If the page does use the fancy properties, draw faked ones. (Hey, the BUTTON tag is already faked, right?) :) "

"Why not give us a preference setting to either use aqua native widgets, or the standard CSS modifiable widgets? "

"never layout a page where form fields were put inside tables with set pixel cells and so forth because form fields were, by their nature, not consistent from browser to browser"

The web is intended solely for a graphical user interface, I often use Lynx (textbased browser) when on a server. The colors you specify in css should never have a critical meaning (or get you upset if they break) - because you can't be sure your user can see them. I'm a designer, but my advise is not to listen to the designers :-), listen to the users.

jonas

(hyatt)
"The second problem with Aqua widgets is that they weren't designed to be scalable"

The Java-Swing Aqua widgets are pretty scalable (when I look at LimeWire), maybe you should talk to the "Swingers" :-)

I may be way off on this

"The web is intended solely for a graphical user interface"

Ooops, i mean: "The web is NOT solely intended for a graphical user interface"

As for the Mail.app integration requested above...
Drop this in a new applescript and put that in the AppleScript sample folder that gets shown in the menu bar... Doesn't copy selected text only though, does all text. But then again, I only had 2 minutes :)

tell application "Safari"
set the_text to text of document of window 1
set the_subject to URL of document of window 1
end tell

tell application "Mail"
set newMessage to make new outgoing message with properties {subject:the_subject, content:the_text & return & return}
tell newMessage
set visible to true
end tell
activate
end tell

It seems pretty obvious to me, Dave:

When regular widgets are called, use regular widgets.

When a regular widget gets scaled out of proportion, use a bevel button (which is designed to scale) and map the appropriate functionality to it (see /Developer/Examples/Carbon/AppearanceSample/ for an example of what bevel buttons can do. They're designed to be scaled.)

As for custom colors, just do it the way iChat and iCal do - by tinting/colorizing the existing widgets. Should look reasonably nice.

-reg

Dave, you're getting two sets of answers here:

(1) answers from users -- "obey the native OS at all or (at least most) costs"
(2) answers from web designers -- "ignore the native OS, obey us instead"

A second observation: the problem with menus not being scalable is bogus. You can do this in Carbon. Your problem is that NSMenu/NSMenuItem is crippled, because the Cocoa team doesn't think styles or sizes matter very much. There's no reason they can't bridge the underlying (Carbon) implementation of menu item attributes to Cocoa apps in an Objective-C happy way.

I appreciate the information on the Mac popup widget. Sorry for calling it a "dropdown list". I'm revealing my Windows origins (and lack of Mac knowledge) by using that term. :)

So it sounds like the problem is that the widget we use for select size=1 is basically not appropriate, i.e., it is not a widget that was ever intended to contain a large number of items. Clearly a new widget is needed for that particular control that *can* handle large #s of items more easily.

There's sufficient precedent for Apple to alter its traditional policies or trample upon its own UI guidelines for the sake of compatibility, witness file name extensions or Aqua/metal look. Given that, what would be the downside of Safari having an easily accessible compatibility button on the toolbar capable of spoofing various user agents and looks? (Other than the extra work, of course.:-)

Safari can spoof user agents from the hidden Debug menu. If you turn that on in your preferences, then you can use spoofing.

Well, as a recent switcher to the Mac, I'd just like to say that I vastly prefer Macintosh pop-up lists, because they are easier to scroll through. On windows, when I click on a pop-up list, I then have to navigate all the way down to the usually tiny scroll button or bar and then do complicated mouse aerobics to get where I want to. On the Mac, I just move the cursor down and let it stay there, and the list scrools itself. Much easier on my wrist. I also like how what is currently selected is then placed at the point you clicked on, with items above and below it as needed. On Windows, if I've selected Pennsylvania, and I click on a drop-down list, the whole thing opens below where I've clicked, making life more annoying if I just wanted to select an item one place above it.

Also, I don't have access to my Mac at this moment (using the God-forsaken Compaq at the parents house), but isn't it true that for especially long lists, you can just type "P" for, Pennsylvania, for instance, and it will be highlited? I mean, there are a few Mac things I can gripe about, but pop-up lists certainly aren't one of them for me.

But hey, I'm not a web designer, so this is moot ; )

Being a web designer who likes to control the way everything looks and works in his pages I have to agree with the people who say that the operating system widgets should trump the designers' choices. Why? Because there are a lot of designers out there who shouldn't be (9 out of 10). They have no idea how to make something usable and understandable, and what one designer thinks is attractive and awesome is almost certainly not going to appear that way to a lot of their users. For those designers who absolutely cannot stand to have the OS native widgets appear on their pages: use Flash or something else like that instead. For the W3C: stop tailoring your standards to what MSIE does and start tayloring them to what makes sense.

I proposed a similiar solution to the Camino crowd a while back, because of their insistance on Aqua controls. I don't dislike Aqua controls, I just think that the content of a Web site should adhere to W3 standards for cross platform conformity rather than Apple's HIG. The content of a Web page IS NOT a part of the platform's GUI.

Sad, but true is the fact that 90+% of the Web audience is on Windblows. This is the reality that Web designers have to deal with every day. It'd be better if Apple, Lunux and MS followed standards for the Web, rather than each doing their own thing with widgets.

And yes, I know there is not yet a true W3 spec for the CSS Styling of wodgets, but Apple can be very proactive here, and lead.

So I proposed the following:

1. Use Aqua Widgets by default when no CSS is applied.

2. If CSS is employed by the site/page to style widgets, use either a platform neutral widget set like Mozilla's or have a fully scalable/styleable Aqua variant (including a option to flatten the controls, because Aqua really does look out of place in many designs).

3. Provide a user preference to "Always Use Aqua Widgets" to override 1 & 2.

As always, the user should have ultimate control, BUT the user is not always right, so #3 should be off by defualt.

I believe this scheme would satify the interests of most if not all parties to this discussion.

-Michael

I can't see a way of making Aqua controls scale as they exist now; bugging the OS X team to make scalable controls is probably the best solution. I think it is important that the app uses native OS widgets while still honouring most, if not all, CSS properties. If the OS team can't do anything, I agree with Regulus that bevel buttons should be used instead of standard push buttons when specific widths/heights are specified. The tinting is a pretty good idea too.

As for the focus ring, I think it would not be unwise to emulate what the Aqua L&F does with in Swing, which is to calculate the area occupied by the focus ring as part of the control. Therefore, if a website specifies a table with cellspacing 0px and cellpadding 0px and places 100x100 buttons in each cell, and the focus ring occupies, say, 2px, the buttons would actually be 96x96 and 4px apart. It might lead to some controls that are smaller than the designer planned for, but I think it'll have pretty much the same effect as the current CSS hack without occupying the extra space that causes the controls to split out of their containing blocks or overlap neighbouring controls.

Oops... I guess I should have read ALL the posts first, as I seem to be just chiming along with what others have already said.

Nevertheless, this scheme, which I and others are proposing, seems like a viable compromise!

-mpm

Thomas, you're a genius!

Frodo wrote, and it bears repeating:
>
> Dave, you're getting two sets of answers here:
> (1) answers from users -- "obey the native OS at all or (at least most) costs"
> (2) answers from web designers -- "ignore the native OS, obey us instead"

This argument is interminable, and we've had it since 1994, back when there were actually three platforms (rather than today when there's one platform, plus 1/10th of a platform, and oh, over here there's 1/50th of a platform too.) When someone decides to buy a Brand_X computer, part of their decision in buying it is how it works: people don't buy Windows boxes because they want Macs, nor do people buy Macs because they want Windows.

So is a web browser a program that runs on (and plays by the rules of) an operating system?

Or is a web browser a W3C terminal that plays only by the rules of the W3C and pretends it's not actually running on a computer that has its own guidelines and neighboring non-web-browser applications?

Back when Netscape was playing the game of "let's try to commodify the OS by making the web browser be the only application platform that matters, so nobody cares what the underlying OS is any more, since they rarely use it", we pushed hard for the second interpretation. That notion -- web matters, OS doesn't -- was the crux of the Netscape battle against Microsoft.

Guess what, we lost. That's not what people want (or, at least, not what they voted for with their feet and wallets.)

Yes, I favor (1), so the goal should be to improve the Aqua widgets or produce new Aqua widgets that blend in well with the rest of the OS and yet support the features that are required in order to avoid a disruption of page layout.

David - as far as the popup menus and combo-boxes in OS X - one thing that I am uncertain about.

In EVERY Cocoa app I use - the popup menus and dropdown lists are COMPLETELY keyboard navigatable if I have that option on in my System Preferences->Keyboard->Full Keyboard Access tab.

Only Safari does not obey this. So for example, in iCal or Keynote - popup menus and lists, and combo-boxes are all completely keyboard navigatable. With that option on - I see no way that the Windows dropdown list is any better (UI wise) than the Mac one.

Here, I was Hoping Pather would support customizable Aque buttons where we can choose ANY color... I take it that won't happen... plus I don't think developers would support that.

Frode: just adjusted the basic samples that come with AppleScript :)
The geniusses are at Apple: those who put the right AS commands in the apps!

Chuck Sievert, iChat support custom color for Aqua bubble so Safari could too..

also, Frode, look in your Services menu (under the Safari menu) and see if either of Mail's services will fit your needs - they work on currently selected text

We all love our native widgies but we spend most of our time on the web.

I love my XBL widgies. I hope Safari will love them too one day.

"but we spend most of our time on the web."

That's scary!

Regarding popup menus vs. dropdown lists, there is a new "combo box" style control available in Jaguar. In Cocoa it is the NSComboBox control (which is available, for example, in Interface Builder below to the popup button control).

I'd also second the request for the Mac OS to support arbitrarily-sized widgets. Many apps, not just Safari, could benefit from that.

hyatt writes: "A third problem with native widgets is the difficulty in supporting other CSS properties like colors and borders, although this is minor compared to the need to support size-affecting properties."

Just some 2c here, saying that these things are used on the web, and are useful:

I'd have to say that this is a problem that is very apparent in Safari. There's two places where I use CSS in form elements:

1) I use a colored right-border inside of a select/option set, as part of a color picker. Although MSIE ignores this CSS style also. (only mozilla/firebird seem to support this, of those I checked: Camino also ignores this property).

2) I use padding inside of elements, to reflect indentation in a dynamic way for a form where people input "bullet-point" type text. All browsers I've tried other than Safari honor this. (MSIE,Moz,Camino, etc.). This looks pretty bad, but we worked around this by providing alternate means of seeing this information.

I looked for "aqua" in this blog, and maybe this is the best place to ask for my question, even if I wonder whether this is a good place...
Here it is :

Is there any place on the internet where you explain why you choose the metal look instead of the Aqua look ?

I don't want to flame you, on the contrary ! I just feel like it's better to have web site in metal, rather than in aqua. I can escape the feeling thing by thinking that it's good to help the user remember that he's /somewhere else/. Help Viewer.app doesn't do that, and it's hard to forgive this app for it slowness... Microsoft doesn't either, and they have been sued...

BTW, is there a link you could provide, where you explain why metal was chosen ??