The image in the header at the top is from Mac OS X 10.3 right? You should take it down :-)

Add a "regular" size to the font menu to restore the default shipping font size...

Option #4 definitely sounds like the winner to me. If I set a margin, and especially a height, I'd like it to be followed. So, bully for you, long live option #4!

Solution #4 seems to be a nice, compromise, but why not get the Panther HI team cracking. Maybe I'm nuts, but it seems crazy to jump through so many hoops to essentially hard-code Safari to Aqua's current static bitmap based widget implementation. What happens in a few years when Aqua is yesterday's news?

The obvious solution seems to be to make a stir within Apple and get a more flexible widget API that allows for scaling of widgets.

don't worry about the controls being too close to together, we have to code round it in netscape et al anyway...go option 4 !

I still want to be able to tab to select and pulldown menu's. Actually, I want that system wide, really, but I can kind of do it system wide, if the developer app has set the nextKeyView correctly.

Oi. I can rant that Mac OS X lacks consistency for usability, but you should know that.

You can fully navigate ALL controls in the OS via the keyboard if you tell it to do so.

System PReferences->Keyboard->Full Keyboard Access tab

It offers two options: tab goes to text boxes and lists only OR Any control

It seems to work in every app I have - except for Safari.

>Maybe I'm nuts, but it seems crazy to jump through so many hoops to essentially hard-code Safari to Aqua's current static bitmap based widget implementation. What happens in a few years when Aqua is yesterday's news?

I agree. I know this is way outside of Dave's purview but with LCD panels getting denser all the time we desperately need resolution independent interface controls (i.e. inherently scalable) otherwise we'll soon be trying to click on millimeter sized buttons.

"The obvious solution seems to be to make a stir within Apple and get a more flexible widget API that allows for scaling of widgets."

Ah, so you've never worked in a large corporation. =D

Apologies if you have, but most places I've seen this would be (sadly) nigh impossible.

I was one of the people who suggested #1 - more specifically, to scale down a control so it and the margin around it needed for the focus ring still fit within the specified limits.

However, I agree that #4 is a better solution. No sense in wasting time on extra calculations if there are no specified size limits, as it would introduce potential for more bugs.

So yes, stick with option #4.

Sounds like a good summary, and good conclusion under the circumstances.

(I liked the comment about a browser being a web terminal, and agree that when Apple's widgets change, so must the rules for interpreting their application to said terminal.)

For the sake of clarity (or because it's Sunday and my brain's not working very well after last night), what happens to the highlight on focus when a widget is specified as a specific width? Would the highlight itself overrun the next element (e.g. border, or next widget) even though because (for example) the height's not specified the highlight doesn't overrun the element immediately above or below?

Look at the entire Safari window. Shrink your view to not include the toolbars and the scrollbars. This box you're not looking at is web designer's territory, whether or not they be good or bad. There's no sense in cutting the legs out from under the proffesionals just because there's a large crowd of kiddies. Inside this box is not Apple or Safari's interface, it's mywebsite.com's interface. If you don't like that, that's where tools like Sherlock come in. That's Apple's interface.

Last I checked, style was still a valid attribute of the input tag and there is nothing stating CSS cannot be declared for inputs. I'm just as much a fan of Aqua widgets as the next machead, but I'm not a fan of being told I don't know what I'm doing and being overridden. If I did I could just go back to being a brainless Microsoft Windows fan.

Look at finder, or iTunes, or any other of your favorite user-friendly applications that have an inset search textbox. You're telling web designers that those things are awesome, but you can't do them. I can do them in other browsers using CSS to take off borders and such, but Safari tells me I'm a backwards kiddie designer and leaves me out in the cold.

IE, Phoenix/Firebird, and Mozilla with either v1.2 or v1.3 uses first the default OS widgets, then if specific style declarations exist, then serves up just what I ordered. Sites arn't made to match Brand-Y OS, they're made to match coporate branding.

Again, I'm a fan of Mac widgets, but we're not talking Mac's interface here, we're talking brand-x.com's interface and I think you can trust them to to know what's best for their own interface.

"Sites arn't made to match Brand-Y OS, they're made to match co[r]porate branding."

These days, many people buy computers in order to get on the Web. This means they are just learning about what "widgets" are. How do you want to explain to them how to recognize a pop-up menu or a button?

-Walter

Re: cgriego

I really have to disagree with you there. The interface does not end to be in the domain of "Mac interface" just because it is part of a web site.

Users of Safari or whatever web browser will feel foreign if everyday control objects such as buttons and text boxes start to look and behave differently from what they expect. For many users, there isn't a tangible difference between the web and the browser; it is sometimes, in my opinion, correct to override a web designers choice when the user is to interact with objects that lie at the core of computer usage experience.

um... I agree with cgriego /and/ all the other comments. we should use Aqua UI widgets by default, and respect all CSS style for the inputs.

Is there some simple CSS we [as users] could put in a user style sheet to "re-Aquify" author-styled widgets? Like using 'auto' for width/height/color/background?

-Walter

Hmm. When Safari 1.0 ships, could it include a folder full of sample contributed user style sheets?

Also, can the style sheet cache be cleared separately from the "clear histories" kiosk-specific thingie?

thanks,
-Walter

> I'm not a fan of being told I don't know what I'm doing
> and being overridden. If I did I could just go back to
> being a brainless Microsoft Windows fan.

Web users out-number web designers 100 to 1. What you are proposing is that designers should be given priority - even when it usually means that usability is sacrificed - so that said designers can push some sort of "brand" upon us.

I'm a web developer myself - but I know who I'm ultimately making my projects for. I also understand that the web, despite allusions of the contrary, is NOT print media.

> Again, I'm a fan of Mac widgets, but we're not talking
> Mac's interface here, we're talking brand-x.com's
> interface and I think you can trust them to to know
> what's best for their own interface.

Trust "brand x"? Ha!

Given that we're bombarded by brands X, Y and Z up to 24 hours a day and 7 days a week, I honestly don't care what some marketeer thinks I should see. It's my computer, my computing experience, and my web browser. Those people don't care about me. Their interest only perks up when I fish out my credit card.

Those defending non-native widgets seem to forget that the web isn't just a means used to shovel worthless "branding" down someone's throat. It's an interactive medium, not a passive one.

It's also a tool that people use to find useful information, interact with others, work and play. I understand that there are those out there who think of me only as Joe P. Consumer #96,536,6554 - but I'm hoping Apple keeps in mind who they're REALLY making this browser for.

Look - I understand the benefit of making a nice web page. I'm not someone who likes ugly pages, and I'm not even averse to customized widgets in certain situations. But anyone that proposes hindering my ability to use the web efficiently and under my own terms is going to get an earful.

Just my 2 cents...

I just want to repost a comment I made a long time ago on another thread:

Sometimes the CSS style actually have a usability purpose, I would maybe like to make the text and border of input-fields red if they are filled incorrectly or be using different styles for different types of fields in my webapps.

I'm actually not in favor of giving the designers total control, I think it increases usability if the user and the environment can customize/override the appearance, but I just want to point out the above. It may not just be eye-candy in every case :-)

When trying to access http://www.cupid.co.il the page is downloaded instead of displayed.

Works fine in Chimera/Mozilla/IE - anyone ever seen this happen anywhere before?

Jonas: using color alone to communicate is very bad for accessability.

http://www.cupid.co.il
works fine for me using safari beta 2

I've advocated this for Camino (nee Chimera) for some time, and I'll suggest it again. As a compromise between the native-widgets zealots and the form-stylers, might I suggest that Aqua's square buttons be used for form widgets, rather than the pill buttons?

These buttons look and feel much closer to the buttons used on other browsers and platforms, while still retaining their 100% pure Aqua appearance. In addition, I know that in Cocoa it's possible to change the background of a button programatically using the setBackground: message; I assume something analogous can be done in HIView. Using this, it would be possible to have Aqua buttons which still obeyed some CSS declarations, in particular color and background-color (which are the major reasons people style forms anyway). To add to that, the square buttons handle scaling much better than the pill buttons do. I don't know if this would help solve the focus-ring issue, but it may even do that.

I just don't see any disadvantages to the square buttons, and plenty of advantages to them. And since they can be done while still maintaining an Aqua "look" for the Aqua-purists, this seems to me to be the ideal solution.

Millennium:

Indeed - the square buttons seem to have been dismissed out-of-hand. Maybe there is a good reason why they're not being considered, but some kind of comment on why they're unsuitable would be interesting.

(For those wondering what we're on about - they're the buttons in the Universal Access system preferences. If you've got Developer Tools installed, look at the 'Grab Bag' tab in /Developer/Applications/Extras/AppearanceSample)

Actually, Chris, those weren't quite the buttons I was talking about, though they're similar enough to demonstrate what I'm talking about. I'm talking about the gel-looking ones (the corners are slightly rounded).

Looking in InterfaceBuilder, it looks like the term is "rounded bevel button". I'm having some trouble finding instances of it in real-world apps -they don't seem to get used very often- but this seems like an ideal place for them. If you go to the apple.com site, they look sort of like the "Hot News Headlines" ticker, closer to the white part of it by default (as opposed to the grey).

(/me opens Interface Builder...)

Ah - I see what you mean now. You don't see those often at all, do you? I Am Not A Programmer, so I can't comment on their suitability...

Apple's Safari Web browser doesn't validate the Common Name of a SSL certificate, according to a report on Secunia, an Internet security Web site.The lack of validation makes it possible to spoof SSL sites, so that you can't trust the authenticity of an SSL site, according to Secunia. As a result, the site recommends you not use Safari to access SSL sites where you "need to trust the authenticity.""SSL serves two main purposes; one is to ensure the authenticity of the server, which you are communicating with, the other is to provide encrypted communication," Secunia reports. "The authenticity part is completely broken when the Common Name isn't verified, since the user can't know if he is communic..
This information from mac central online

Listen, I think it's extremely important that widgets remain consistant with the OS. PDA's and other tools are actually being used to access websites now. Also, Mozilla seems to be taking the native widget look now too.

It's just a matter of time before designers stop customizing widgets and learn to live within standards.

Look at any old mac application or any old Windows app. They all had different UIs because designers went crazy, but now companies are starting to match OS UIs. It's smart design and it's just a good practice.

Matt -

There is a need for things to be consistent with the OS, but there is also a need for things to be consistent with the page. That is why I believe that this compromise is a good idea: Aqua widgets which obey the applicable CSS. Consistency does not mean blind, slavish lock-step with the exact look of the rest of the OS; it means being recognizable as concerns their function. Those are two completely different things, and can exist totally independently of one another.

Or, to put it another way, it doesn't matter whether a designer turns an Aqua button yellow, or changes its size; a user is still going to recognize it as a button so long as it retains the gel-like look that Aqua is now famous for. Further, there is an Aqua widget which seems to be practically made for this sort of thing, namely, the Aqua rounded bevel button, which a programmer can resize and recolor, and yet it remains recognizable for what it is. Given how well-suited it appears to be for the task of a stylable form control, why aren't we using it?

I would prefer solution 4. Without solution 4, we have to stick with linked images instead of html buttons using css.

I know there are valid reasons why people would prefer the OS widgets to override the designers' widgets for corporate sites. But a web site is not a dialog box. While it's vital that the functionality of widgets remain unchanged, the designer should be able to change the appearance of the widget to match corporate branding. Nothing like one blue Aqua button in the middle of a red themed corporate site to make the designer resort to images instead of widgets. If you want people to use CSS, you have to let them have control.

However, color is the most important issue for corporate designers. Background images and border styles are of lesser importance. If we could have a red jellybean instead of a blue jellybean in Safari, we'd not care about not having css border styles for buttons.

For those who avocate keeping with Mac HIG over all...You realize this solution is at odds with CSS in as much as these widgets cannot be styled fully per CSS (for better or worse). Perhaps ethically this is the right thing to do. It should be stated that this forces Apple to be explicitly rejecting part of a standard (which though more well-intentioned sounds like another companies commitment to standards). I hate the crap people do to sites on the web, but I would rather see people use one set of markup/styling instead of the totally bizarre hacks people do to work around browser presentation behavior (think box model hacks for Win/IE).

Rounded bevel buttons can be seen in the Calculator.

(Historical note: Apple originally had it with the "pill" buttons but it looked awful so they changed it.)

Now if Apple can see fit to do that for Calculator...

-boo

It is important to remember that the CSS standard makes it quite clear that user agents are free to ignore color and border properties on form controls, since they are replaced elements.

You can argue that Safari should support color and border styling because other browsers do it, but you can't argue it from a standards-compliance perspective.

Native widgets may be consistant with the OSX but the webpages should be cross platform. I like my page look alike in Windows as well as Mac or Linux. Native widgets is a nightmare for web designer. I think Mozilla and IE's ability to control the style of widgets via CSS styling is a much better idea. Camino and Safari are frustrating. Be consistent with 99% of browsers, make the CSS styling widgets, please please....

the osx interface offers a square button that is scalable. if the css for an element defines specific dimensions for a button, the square button can be used instead of the default button. it would break some hig guidelines (but so does the brushed metal) may look awkward in some situations, and square buttons (along with everything but tabs and round buttons) are still in the 10.1 style, but it would solve the scalability problem - for buttons anyway. i would say that the interface gurus need to bring all of the "glass" elements up to 10.2 standards, but with 10.3 so close, hopefully things will be a little more consistent and i can stop using smoothstripes just so that the interface doesn't look funny.

Jason says "Native widgets is a nightmare for web designer."

No, they are a *constraint*. If you are any kind of designer, you must have heard of the famous designer Charles Eames. He said "Constraints are a designer's best friend."

-Walter

PS. Please excuse the rampant non-parallel construction what with the singulars and plurals.

"I speak English gooooood -- I layrn eet from ay boook." --Manuel, "Fawlty Towers"

-boo :)

Two suggestions, I don't know how succesful they may be:

1. Use the "iApp buttons" All the brushed metal apps seem to be using that x^3 reflection button (seen in Safari's very own,back/forward,refresh, etc. buttons). I think these would be pretty sleak for the website as well, and possibly maintain the continuity of the enitre application. We already know Apple is willing to use them and I guess they are almost standard, they're in iTunes, Safari, etc. It would take some coding though, since you would have to do the drawing yourself. The buttons in the sytle of the "+" and "Edit" in Address Book may work too.

2. This is a little far fetched, but why not drop the focus ring. Would it be considerable to simply have the background of the widget become slightly bluer when being edited? For example, the buttons I mentioned, could become the color of the focus ring, then the traditional blue clicked on color when selected. Text fields and ares would have the space actually containing the text turn a the same light blue. Not to dark so as to not distract, but dark enough to make the user aware of a change.

Just the first things that came to mind. Mainly because my thoughts are this: the sad truth is most web people will not be developing for Safari. So if we have custom CSS stuff as previously mentioned then just about the only sites that would bother with them are those mad by mac people (that know about it). In other words, it probably wouldn't even be included in those CSS books (it may be). Also, if you have unique behavior, it will not be predicted by the majority of people who make sites on Windows.

The whole problem you're having is with the focus rings right? Why is there a problem if the CSS2 outline set of properties is correctly implemented?

Speaking of OS-specific behavior within browsers, how about the traditional Mac way of marking a radio button or a checkbox when the user clicks anywhere on the label associated with it?

George:

That's done with the LABEL tag from HTML. To use it, you assign an ID attribute to a button, and then use {label for="id} to designate what the button's label is. Clicking the label does whatever clicking the control would do.

WIthout the LABEL tag, there is no way to tell what a button's label is. Therefore, we should be lobbying content producers to use the LABEL tag more often.

How about this... any web page that uses CSS for widgets should use CSS widgets. Everything else should default to Aqua widgets.

Any questions?

"It is important to remember that the CSS standard makes it quite clear that user agents are free to ignore color and border properties on form controls, since they are replaced elements."

I couldn't find any mention of being able to ignore color for replaced elements in the specs:

http://www.w3.org/TR/REC-CSS1
http://www.w3.org/TR/REC-CSS2

I did find this about borders in CSS2:

"Notably for HTML, user agents may render borders for certain elements (e.g., buttons, menus, etc.) differently than for "ordinary" elements."

Am I missing something?