Styling text fields in Safari

Seems like step by step, one of the most usability-enhancing features of Safari is being removed. The feature I’m thinking of is that Safari does not (yet) allow web authors to freely style form controls with CSS.

As a user I find it very frustrating when a web designer has decided that they don’t like the way buttons, text fields and other form controls look in various browsers. This often leads to attempts at changing the appearance of form controls. The first step is usually trying to change the appearance with CSS. When that fails some even resort to using JavaScript, in most cases sacrificing both usability and accessibility for the sake of styling.

Safari has traditionally not allowed authors to change the appearance of form controls a lot with CSS. As a user, I love that. Unfortunately, it seems like Safari is becoming muich less strict in that regard. With the announcement of a new implementation of single line text input fields (<input type="text">) as described in Text Fields at Surfin’ Safari, it seems like text fields can now be styled just about any way you want.

It’s not all bad, of course. When used responsibly this can enhance usability. Unfortunately far too many web designers seem to find it more important for form controls to fit their particular aesthetic taste than to be usable and accessible, so I am a little worried about this.

For the sake of usability and accessibility, I hope future versions of Safari will give users the option to completely disable author styling of all form controls. Perhaps with a couple of exceptions. Actually, I’d prefer if that was the default setting.

Posted on April 11, 2006 in Browsers, CSS, Quicklinks, Usability

Comments

  1. Which prompts the question (that you may have already answered in a previous post that I missed) how do you feel about the HTML button tag?

  2. “I hope future versions of Safari will give users the option to completely disable author styling of all form controls.” - That sounds perfectly reasonable. But I admit I am surprised that you find Safari’s current inability to style form controls to be a good thing.

    Yes, when you can style things, they become open for abuse - but that’s already the case with everything else HTML. You can style it to be a completely unusable mess. That doesn’t mean you should take away the ability to style HTML. So for form controls.

    When a designer has taken time to make a visually rich website, it’s always frustrating as hell to have a big ugly completely out of character form control landed in there. It breaks flow and it looks horrendous - from a designers stand point it’s like being forced to stick a large beige Intel Inside logo on the lid of your sexy new ivory Mac.

    Give some credit to designers, and let them design. If the form controls suck, that’s a reflection on a poor designer. Molly-coddoling the end user by restricting stying options is not a viable answer. Thinking on the same logic - why not just completely disable CSS in Safari, to ensure people don’t make unusable and ugly designs?

  3. April 11, 2006 by Roger Johansson (Author comment)

    John: Not sure what I feel about input type=”button” since I have never ever, at least not as far as I can remember, used it ;-).

    Matt: I get your point, but speaking as a user here, I’d much rather have form controls that are “ugly” (though Safari’s controls certainly look much better than any “designed” controls I have seen) but easily and quickly recognisable. I think forms are best left alone or only very carefully and lightly styled.

  4. Looks like we share the same feelings. I hope I’ll be able to turn this “feature” off in future versions of Safari since I really prefer the Aqua widgets to those styled as the ones now in WebKit nightlies.

  5. My feeling is that if other browsers are going to allow styling of form fields (and they are), then Safari needs to, as well. The cat-and-mouse game browser makers play is unfortunate, but if Safari wants to be looked upon in the same light as Firefox, then it needs to support the same thing. Otherwise, some people will always consider it a second-class citizen because “Safari doesn’t do xxxx.”

    Does the CSS spec specifically say wether form fields can be styled or not? I’m not sure (though I definitely need to find out for a project I’m working on), but if it does, then that should be the be-all, end-all.

    This is tangentially related to another diatribe of mine that i’ve been trying to get people to pick up on, but no one seems to care as much as I do: browser default styling. There is no spec or recemmendation for what browser makers ought to use as default styles, and thus, us CSS developers are forced to explicitly specify everything if we want to be sure of it. For example, do you assume that paragraphs get “margin: 1em 0;” by default? So do I, but our assumption isn’t based on any spec out there. Nothing says the browser makers have to do that, and if the next version of Firefox decides that paragraphs should get no margins at all by default, so be it.

    The same thing relates to form fields. We make a lot of assumptions about what forms will look like if we leave them unstyled or lightly styled, but that’s putting a lot of faith in the browser makers, isn’t it? What if the next browser maker on the block decides that all text fields should get “font-size: 2em; border: 5px outset #cc0000;” by default?

  6. April 11, 2006 by Roger Johansson (Author comment)

    Jeff: Are you looking for something like Appendix D from the CSS 2.1 Spec: Default style sheet for HTML 4? It’s a working draft and only informative, but at least it’s a start.

  7. I see the point of protecting the form elements, but that means it makes it a proprietry descision.
    In the end, there are no other elements that are shielded in this way, and although immediately you might say that it will prevent mishandling, it seems like that is an attempt to clutch at straws. To “save the last thing that can’t be damaged” when all the other elements can be styled any way the author chooses seems a little backward.
    In my opinion, the author should have full control of the design; browser companies shouldn’t be making design descisions on our behalf - that’s how IE got to be demonised (I’m not saying that could ever happen to Safari, but I prefer the ‘trust the authors’ approach).
    Surely it is more important to provide a flexible platform to design and provide rather than a dictatorial product which constrains the design?

  8. Roger-

    i’ve seen that, and it’s sort of what I’m looking for, except the explanation of that is “the typical formatting of all HTML 4 elements based on extensive research into current UA practice.”

    In other words, “we looked at what browser makers do, and this is it.”

    That’s not a recommendation at all, it’s just research. I want something like this, but in the form of, “this is what the W3C recommends desktop browser makers use as the default style sheet.”

  9. Here Here. I dont use the mac but when i see a form on one I am envious of how they already look in the first place. On the PC I am used to using forms that have such wonderful things like pink backgrounds, etc.

    Its horrible.

    A form isnt a piece of design its a functional item that, in all honesty, looks pretty good on its own.

    Saying all this, I suppose I have to agree with Matt and say that perhaps its bad to say we shouldnt give control to style things as idiots will style things badly. There are alot of bad web pages out there, but look at what good some people can do…

  10. “Not sure what I feel about input type=”button” since I have never ever, at least not as far as I can remember, used it ;-)”

    Ahem! Now call me an AntLover but I said HTML tag, not attribute…

    I’ll get me coat.

  11. April 11, 2006 by Roger Johansson (Author comment)

    Andy: As long as the end user is given an option to disable styling of form controls, sure, open it all up.

    Jeff: While research is how they came up with it, they also state that “Developers are encouraged to use it as a default style sheet in their implementations.” So in a sense it is what the W3C recommends using.

    In the same document there is also this (emphasis mine):

    The full presentation of some HTML elements cannot be expressed in CSS 2.1, including replaced elements (“img”, “object”), scripting elements (“script”, “applet”), form control elements, and frame elements.

    I’m not quite sure how to interpret that.

  12. April 11, 2006 by Roger Johansson (Author comment)

    John: You did? Oh, yes you did! Oh well, my answer is the same. Never used ‘em. :-)

  13. Roger-

    Thanks, I missed that line. Now, if we could just get browser makers to use it. :)

  14. I agree with Matt in the second comment. Even though man can use fire to burn himself, it doesn’t mean that he shouldn’t be able to have access to it anyway. Stupid people will continue to find ways to abuse whatever technology exists, so the only thing to do is to press forward and reward those who use it responsibly (and encourage others to do the same.)

  15. April 11, 2006 by Andy

    If you want to disable form styling, you can specify a custom stylesheet in Safari’s preferences - the settings in this, I believe, are treated as !important

  16. I’ve always been frustrated the other way around, with Safari not cooperating with how I wanted things to look. When you put it from the standpoint of usability though, I think I appreciate the other side of the argument. You said that freedom in design can enhance usability, which I’m all for.

    I’m wondering, Roger, what are some of your favorite sites from a form-styling standpoint (of course, looking at them in something other than Safari). I’m geniuinely curious, wanting to take things like this into account, when/if I redesign my own site.

  17. April 11, 2006 by Scott

    Even if Safari never made this change, people would still style their form controls.

  18. Roger:

    I’d much rather have form controls that are “ugly” (though Safari’s controls certainly look much better than any “designed” controls I have seen) but easily and quickly recognisable. I think forms are best left alone or only very carefully and lightly styled.

    And that’s why your idea to be able to turn off form styling in the browser is such a good one. It leaves the choice with the user.

    But, just because you as a user prefer the default look doesn’t mean other people will, or that the option of customised styling should not be given to the designer (and thus passed to the user).

    I can think of at least one good example where Safari’s un-changable default form controls are BAD for usability - and thats in a zoom layout. Where (last time I tried it) you can make high contrast large text websites - but the form controls stay the same mono-chromatic small buttons. Useless. (I can’t actually test that the font sizing issue still exists, as I’m not at the office where the Mac is, so my point may be moot).

  19. In the latest versions of WebKit there is no simple way to force text fields and buttons to use the native system look. It is possible to force text fields to use the native system look by adding “!important” rules in a user style sheet to override all the properties that can coax WebKit into using a non-native appearance. This can obviously have other side effects.

    I would recommend that anyone interested in the ability to force sites to use the native system look for text fields and buttons should file a feature request on WebKit requesting the ability to easily control this behaviour via a user stylesheet.

  20. John,

    I must say your mentionning the button element piqued my curiosity. What did you have in mind?

  21. The full presentation of some HTML elements cannot be expressed in CSS 2.1, including replaced elements (“img”, “object”), scripting elements (“script”, “applet”), form control elements, and frame elements.

    I’m not quite sure how to interpret that.

    I’d interpret that as saying that CSS 2.1 does not provide any means to define completely the presentation of a checkbox, a radio button, a select element, and the border of a fieldset.

    By the way, what is the benefit of the search input field at the top of this page having a yellow background when I click on it? It provides a clear clue that the field is focused, something Safari accomplish beautifully with Mac OS X’s focus rings. Are the new styled inputs in Safari going to keep their focus rings?

  22. About the ability to style form widgets, CSS 2.1, under Conformance, has this to say:

    CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.

    Means, applying author styling is not a requirement for form controls. And some of the members of the CSS working group (authors of the specs) woul sure have prefered that styling of those form controls were left to the UA/OS combo.

    As others, I’d much prefer to have a preference to block author styling of form controls, in Safari, but also in Camino (more important for me, I never use Safari anyway) and Firefox. Opera has this already. Default should be no styling :-).

    Being able to do it through a user stylesheet might be an option, although much to difficult for the average user (does your grandmother knows what a stylesheet is ?).

    As a sidenote, Safari’s font-sizing in widgets is poor, mouse type sized, and doesn’t listen to min-fontsize set though the apps prefs.

  23. I’m with you on this, Roger. When I switched to Camino, one of the things I missed most was the Safari form controls. They’re just so much better than anything else out there.

    I don’t feel that Safari should adapt itself to other browsers in this regard. It’s the default browser on OS X, it doesn’t have to actively compete with Firefox as it isn’t targetting itself to a browser-switcher audience. It’s targetting itself to an OS-switcher audience, which may well be people switching over from IE. Safari would do well to be better than IE in as many ways as possible, and reducing form control styling to IE’s level just won’t do that.

  24. Roger I am with John, you should explore using button instead input. Button are almost identical to Input, except graphical richer (you can have images and flash objects inside the button element) and do not have styles imposed on you by Safari, Camino or Konqueror.

    I gave a presentation http://nickcowie.com/presentation/s5-button.html to my Perth Web Standards Group about the button element, also shows the bad habits of Safari, Camino and Konqueror with input type=submit or rest or button. (and Safari is the worse offender).

    There will be a podcast and transcript available at sometime from http://webstandardsgroup.org/audio/

  25. Just a thought, Roger: you should be able to permanently disable any form styling by specifying a custom style-sheet in your preferences, shouldn’t you?

  26. April 12, 2006 by Roger Johansson (Author comment)

    Nick: Provided I want to style buttons, that is. I don’t ;-).

    Paul D: Yes, but it should be much easier to do that. A checkbox in the advanced settings, perhaps. Also see comment #19.

  27. But sometimes formfields, buttons can be more usable if they have a non-default design, take for example the use of changing the background of a formfield when it is in focus. Also to make a formfield stand out (background & border) when there is a error. I think that this can be used for better usability. I also think it is OK to make buttons larger than normal.

  28. April 12, 2006 by Roger Johansson (Author comment)

    Jens: Agreed, that kind of light styling can increase usability, and I don’t see a problem with it. It’s the “I want to make all form widgets look exactly the same in all browsers on all platforms” approach that tends to be problematic.

  29. April 12, 2006 by zcorpan

    Does the CSS spec specifically say wether form fields can be styled or not?

    CSS specifically says that it is undefined how CSS relates to form controls.

    CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.

  30. Roger, I disagree, when done correctly, you can have some very visually appealing form controls that are easier to use than if left un-styled. For example: The Wordpress admin interface is nothing pretty to look at, but has some of the best looking buttons ever put on a web page.

    A designer should never feel restricted or be forced to do something. Wasn’t part of the original plan behind CSS to give developer’s and designer’s COMPLETE control over their work?

    What would be more appropiate is to have the ability for the browser to remove styling from form controls at the user’s request. Possibly on a site by site basis and also have the option for form styling to be disabled completely. Something like this would keep the majority happy (I would think).

  31. April 12, 2006 by Zephyr

    Roger, I applaud you for being willing to abdicate complete design control for the sake of user control!

  32. I agree that from an accessibility standpoint form controls should only allow minimal styling. This ensures that no one is confused about what they are supposed to do when presented with a form.

    However, in my personal experience, I have never come across a form that was so badly styled that I was unsure of what to do (I’m sure they’re out there though), and some browsers’ default form styling is so awful I can understand why designers want to change them (I can’t stand Opera’s yellow scrollbars and buttons).

    So, I would have to say that form styling should be left in the hands of the designers. That way, sites that require high levels of accessibility (government sites, etc.) can leave the default styling, and sites that want to be a piece of artwork can be happy too :0)

  33. Roger, the problem I have with Safari with input type=”submit” (or input type=”button”) is that the font size is restricted to a maximum size (of roughly 13 pixels) so it does not overflow the background image. No matter what the designer or user does, you can not increase the font size above 13 pixels. I consider that a major accessibility issue.

    I can see advantages in providing a consistent interface for forms including fields and buttons, for example always being able to identify the submit (input) “button”. Unfortunately input submit and reset are identical, and should the input submit be to the left or the right of the reset. Personally I do not see there is ever a need for a reset.

  34. April 14, 2006 by Josh

    Personally, I think i’d like it if browsers would come packaged with multiple groups of standard form widgets. Each group having a specific style (think of Macromedia’s ‘Halo’ form widgets). They could still be easily recognizable but have a consistency you can’t quite get with much of the css styling of form widgets.

    I’m thinking something like this:
    <form type=’halo’ name=’frmContact’ …
    <input type=’text’ name=’txtName’ …

    I’m thinking, all form elements would be governed by the form tags ‘type’ attibute. If i don’t like the default form elements I could just set this attribute to one of the other available form widget groups.

    I think by giving options in the form of ‘form widget groups’, it would aleviate the need to use css to style them. There by keeping forms more usable while giving some basic flexibility.

  35. Daniel: The WP admin is exactly the place where I prefer Safari to WebKit in the field of form styling. It’s way more usable and easier-to-navigate. And the styled buttons are for platforms with not-so-good system widgets.

  36. April 16, 2006 by alexander

    recently ran into this problem, I am working on a webbapplication were we have a very (atleast I think so) intuitive way of reporting errors with formfields, the borders are simply put red or green.

    Now with safari this reporting doesn’t work..

  37. April 16, 2006 by Roger Johansson (Author comment)

    To those of you who have mentioned Safari’s inability to size form widgets as the user increases text size, I agree. It is definitely a usability and accessibility issue that needs to be fixed.

    alexander: That sort of indicates that you should not rely on colour alone to convey important information, doesn’t it? ;-)

  38. The full presentation of some HTML elements cannot be expressed in CSS 2.1, including replaced elements (“img”, “object”), scripting elements (“script”, “applet”), form control elements, and frame elements.

    It simply means that you can’t use CSS 2.1 to completely reproduce the default presentation of the elements mentioned.

  39. May 31, 2006 by some guy

    when Apple tries to control how websites look, it’s a bit like the government telling architects how to design houses. OS-makers are the governments of the computer world, and personally, i have never liked Apple’s heavy hand when it comes to CSS styling of form controls.

    to carry the architectural metaphor a bit further, consider the fact that an architect may want to design an entranceway that uses stairs. if you’re going to build a public building these days, you have to put in a wheelchair ramp too — the government will not approve your building for use until it’s accessible by people with wheelchairs. in the real world, of course, you can put in both. on the web, there’s no sense in putting in two buttons; the cohesive look of your site is compromised by the “ramp” (i.e. a button that refuses to be styled).

    a possible reaction to such thinking could be, “hey! my dad/grandmother/third-cousin-removed is wheelchair bound, how dare you exclude them from a building that they have a right to enter!” however, there’s a fallacy in that response. what if i’m not designing a public building (i.e. a governmental website that everyone needs to access from time to time)? what if i’m designing an order form for a high-end product that is only of benefit or interest to sighted people who realize that there’s no difference between an Aqua button and my whatever-the-trend-of-the-week-is button?

    often, i notice that standards bloggers forget that the bulk of websites are used to sell something. we’re not all out here designing pages for the IRS, FCC, or EPA. we have other concerns to think of — like creating slick, impressive, and visually cohesive user interfaces that are used to sell something (a product, a lifestyle, an idea).

    that’s why i consider Apple’s pseudo-governmental role in this issue to be extremely ironic, since they are one of the most successful lifestyle marketing companies in the history of capitalism. Apple’s site is full of buttons that have been hacked in such a way that the default Aqua styles are disregarded; to say nothing of the many, many buttons that are comprised of images (no resizable text, no standard form UI, and often missing ALT text).

    so on one hand, Apple says that Safari users should see an identical button style across the entire web, and on the other hand, they’re breaking that rule to expand their own influence through sales and marketing. they have designed a slick, cohesive, visually impressive user interface that is used to sell products/lifestyles/ideas, while forcing designers to use their tricks - like images instead of scalable, text-reader-accessible buttons - to get around the limitations of their browser.

    in short, Apple’s forced “usability” is no way to empower the designers that often prefer the Mac platform. their behavior is hypocritical and controlling, and in my opinion, being able to override the Aqua-styled form controls under Safari is a great thing. just as no architect wants the government to interfere with their work, no web designer wants an OS-maker to limit his/her ability to communicate visually.

  40. alexander: That sort of indicates that you should not rely on colour alone to convey important information, doesn’t it? ;-)

    Now, I was always taught that color was an element of design and, as such, could be utilized to convey information. There’s absolutely nothing wrong with Alexander using color to show that information.

    One thing I sometimes do is darken or add color to the left border of a text field to indicate that it is a required field. I also include the tired old * REQUIRED bit in the code as well, but I use CSS to hide this. Visually-oriented individuals can benefit from the use of color, while those without the aid of sight can still get the information they need to know. Isn’t that what designing with Web standards is all about?

    Forms are one of my major pet peeves with Safari partially because of their inability to be styled, and now also thanks to Apple’s newest “feature” in Safari 3. Users are now able to resize multi-line text fields to their hearts’ content. I wouldn’t mind it so much if they only resized in the vertical direction—given the Web’s vertical nature—but allowing them to resize horizontally creates a whole mess of issues with page layout (try resizing one to be larger than its fixed-width parent).

  41. June 14, 2007 by Roger Johansson (Author comment)

    Lauren:

    Now, I was always taught that color was an element of design and, as such, could be utilized to convey information. There’s absolutely nothing wrong with Alexander using color to show that information.

    Yes, of course you can (and should) use colour. But not colour alone, especially not with certain colour combinations that are hard to differentiate for people with defincient colour-vision. As an extra bonus, using something more than colour will make it easier for everybody to notice the information.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.