Safari’s search field
I know that this is old news, but I’ve just noticed that Safari 1.3 and 2.0 support a new HTML form element: A search field that looks and behaves exactly as the one used in all Mac OS applications.
Syntax
The syntax for the search field is as follows: <input type="search" />. Further details can be found on Dave Hyatt’s Website. So how does the new search field look like?
Appearance
Well if you are using Safari you might have noticed that the new search field is already in use in the upper right corner of this site. The small “x” in the right corner provides you with a way to clear the content of the search field — clicking the icon on the left displays a list of your last search queries. Neat.
What about Standards?
Even though that’s all very interesting, those attributes aren’t compliant and valid in any HTML or XHTML spec. So you might argue that it’s not recommendable to use them in any project. Well normally I would agree. But since its presence seems to cause no harm — it just degrades to a normal text input — I presume it is justifiable to make use of it. Or is it a bad idea since my site will no longer validate as XHTML 1.1… What do you think?
46 comments so far
Skip to comment form
niklas June 04, 2005 at 02:16 AM
niiice
me·ta June 04, 2005 at 02:26 AM
I don’t really care, I don’t use Safari. But I’ve never looked for valid XHTML on your site, consequently you could leave this search field where it is now.
johannes June 04, 2005 at 02:31 AM
Since the search seems to work in “non-safari” browsers, too, i would use it :) I believe standards are important to keep your code clean, but in your case, where code and visual output are as clean as water there is no need to be that “kleinkariert” (<- don’t ask me this word in english, please^^) if you are not sure you could use a script which only outputs type=”search” if the user agent is a safari 1.3/2… then you wouldn’t get validation errors in browsers which don’t profit from it anyway ;)
Jérôme June 04, 2005 at 03:00 AM
As a native English for Runaways speaker, I would say: „kleinkariert“ -> „smallchequered“ =).
Pascal June 04, 2005 at 03:24 AM
You’d better provide a search field, that works well (and looks nice) in all modern Browsers via JavaScript. Using AJAX, you could even provide “search as you type”! History is often provided by the clients, a “clear” Button is very easy to implement…
Markus June 04, 2005 at 03:33 AM
Hi Wolfgang. Your website is really awful. I was stunned by the excellent designs when I came here yesterday (via mezzoblue.com — even Dave Shea seems to like your work ;)). At the moment I am making a website that uses a search field as well. I used an onfocus- and onblur-Scripting (similar to what you are using on this page), which I did not really like, as it did not fit into the clean HTML-Code. When I read this article an hour ago, I decided to recode the search field and to include the Safari search field as well. So this is it: Link It uses proper XHTML and only changes the type-value of the input field to “search” if it detects Safari (as suggested by Johannes). Furthermore, it includes the onfocus-/onblue-Scripting, there is no need for event handlers in the HTML-Code any more. I hope you like it. :)
Mirko June 04, 2005 at 04:14 AM
Markus: The search field in your link looks like a standard mac search field in that it has rounded corners, but the little X and the recent search feature are both missing. Don’t know what could be causing that, it works fine for me on this site.
Wolfgang June 04, 2005 at 04:47 AM
Wow, thank you for your feedback. With the help of Markus’ demo page I’ve just changed the code so that the type property is replaced via Javascript. And yes I have plans to implement some kind of “find as you type” search as soon as I got a bit more familiar with AJAX and stuff like that — I think taking a look at “DHTML Utopia” by Stuart Langridge will help me a lot Link
ZicklePop June 04, 2005 at 05:13 AM
Use it, W3C compliance may look kool, but just see if it still works on all the different browsers out there (Konqueror, Opera, Internet Explorer, Mozilla, Safari, and if you wanna get geeky: Lynx and Links). If all those show it nicely, do you really need W3C compliance?
Philipp Daun June 04, 2005 at 06:21 AM
An sich nett. Zumindest für alle Mac-Besitzer. Nicht dass ich so dämlich und/oder blind wär, die Leiste rechts oben nicht als Suchleiste zu identifizieren, aber für manche wirkt ein unbeschriftetes und leeres Eingabefeld wohl etwas verwirrend. Ein Label würde hier schon helfen. Doch da die meisten deiner Leser wohl eh einen Mac zuhause zu stehen haben, kann ichs dir nur empfehlen…
Markus June 04, 2005 at 07:06 AM
Philipp: Das Eingabefeld ist ja eigentlich nicht leer, es wird ja vom Script mit dem Wert “Search this Site…” gefüllt; vielleicht solltest du nochmal aktualisieren, damit das Script auch geladen wird. Mein Firefox hat vor dem Reload einen Fehler gemeldet, weil er die Funktion init() noch nicht kannte. Mirko: Is JavaScript enabled in your Safari? I don’t really understand why it works for Wolfgang but not for you. Wolfgang: Danke, viel besser so ;)
Markus June 04, 2005 at 07:13 AM
Oops, I forgot: Is there a special reason for repeating “window.onload = init;” in the HTML-Code? I do not see an advantage in that; there is rather the disadvantage of getting an error as long as script.js has not been reloaded.
Wolfgang June 04, 2005 at 07:24 AM
For some reason it doesn’t work if don’t call the function directly from the HTML page. Any clues?
Markus June 04, 2005 at 07:54 AM
Yep, found the reason. Your styleswitcher Link overwrites window.onload. I’ve changed the code so that it calls the old onload-function first instead of overwriting it. When you use this version, you have to make sure that style.js is included after styleswitcher.js, otherwise the styleswitcher will do the overwriting.
Keri Henare June 04, 2005 at 08:27 AM
The Safari search tool is cool but I’m not really a fan of propietry code and browser sniffing is usually a bit of a no no. I agree with using an AJAX solution.
Scott June 04, 2005 at 04:07 PM
So, essentially you are adding approximately 20 lines of javascript code to replace one word of xhtml code — just to fool the validator (remember, the original degrades cleanly). Sometimes I wonder why we (myself included) will often go so far out of the way — and add extra lines of code — to “adhere” to standards (defined more by the validator results than the ideals themselves), when the point of the standards in the first place is to simplify our code… Very nice site btw.
Wolfgang June 04, 2005 at 05:15 PM
Thanks Markus — now it works as intended… and well, it’s really kinda weird to add several lines of code just to fool the validator. But I’m quite on the horns of a dilemma: on the one hand I really love such neat widgets, on the other making a site validate somewhat soothes my conscience. Sounds weird — I know. So the javascript solution works best for me :)
Keri Henare June 04, 2005 at 05:21 PM
RE: Comment 16 I actually find more often that it’s very easy to write standards compliant markup. However I have to go far out of the way adding extra markup and javascript to make something that works fine in Gecko and Opera work properly in Internet Explorer.
Boris June 04, 2005 at 05:39 PM
As long as you’re sending your documents as text/html (instead of application/xhtml+xml), it is not “correct” XHTML 1.1, even when the W3C Validator says so … Might interest you: Link Regards, Boris
Tobias June 06, 2005 at 01:39 AM
Boris: I use application/xhtml+xml but I saw that e.g. links2 seems not to be compatible with that.
Wolfgang June 06, 2005 at 06:35 PM
Normally when serving pages with application/xhtml Internet Explorer prompts you with a download dialog. Did you experience any problems?
Mirko June 06, 2005 at 07:12 PM
Markus: Ja, Javascript is an. Jetzt sehe ich sogar ein völlig normales Texteingabefeld, die runden Ecken sind auch verschwunden. Wenn ich den Sourcecode der beiden Seiten vergleiche, sehe ich dass Wolfgang value=”search” benutzt hat, bei dir aber class=”search” steht. Will dir ja nicht reinpfuschen, aber von meiner Seite ist alles in Ordnung :).
Guillaume Rischard June 07, 2005 at 02:53 AM
It’s a shame the javascript doesn’t detect other browsers that use webcore, such as NetNewsWire.
lagroue June 07, 2005 at 04:33 AM
I put the safari search field on any intranet I work on. And users find it terrific. I don’t even try to fool the validator. It degrades so smoothly I can’t resist.
electrikmonk June 07, 2005 at 05:38 AM
you can create your own DTD too allow validation if you’re really concerned: Link i’ve never tried to do this, but the source is reliable. i don’t see a point though. validate it without the input and then add it back. other posts would suggest it degrades well. it looks just like my safari search.
Markus June 07, 2005 at 06:21 AM
Mirko: Wolfgang hat nicht value=”search” benutzt…? Dass ich class=”search” benutze, liegt daran, dass ich im JavaScript alle input.search’s erkennen lasse, um schön flexibel zu sein. Wolfgang hingegen hat das Script so umgeschrieben, dass es nur ein input#suchbegriff manipuliert. Daher der Unterschied im HTML-Code. Warum aber mag Safari die Klassen-Überprüfung nicht? Und warum klappte es bei Wolfgang auf meiner Demo-Seite, aber nicht bei dir? Ich hab keine Ahnung… vielleicht sollte ich mir doch irgendwann einen Mac anschaffen, dann könnte ich es sogar selbst testen ;) — Guillaume: I’ve changed the detection method; does it detect the other browsers that use WebCore now? I’m sorry I can’t test it. — lagroue: I wouldn’t describe it as “fooling” the validator — this is just an application of the Third Layer — the DOM — for the purpose it is designed for: improving the user interface when possible. — Wolfgang: There are no visible problems when serving XHTML as text/html, but a variety of (rather theoretical) reasons for not doing so. When you want to write real XHTML, you must serve it as application/xhtml+xml, otherwise the code is processed as HTML (so it can’t be called XHTML anymore). This means the browser gets tag soup, but as it is very tolerant, it tries to figure out what you meant. Example: processed as HTML should in fact be displayed exactly like >, but the browser knows you did not mean it and therefore renders it as you intended. By the way, Doctypes do not count (they only tell the browser if he should use quirks or standardsmode). More on this: Link — When you really want to serve your XHTML as application/xhtml+xml, you need to use a script that sends this mimetype only to those browsers that support it: Link — So there are really reasons for switching back to HTML; many people have allready done this, like Anne: Link
Markus June 07, 2005 at 06:24 AM
hmpf, ok, apparently any html is stripped from the comment, so I’m posting the broken sentence again: Example:
processed as HTML should in fact be displayed exactly like
>, but the browser knows you did not mean it and therefore renders it as you intended.
Aj_saD June 07, 2005 at 06:47 PM
Hello :) Could you tell me whats happen with Apple / Intel cooperation. When I come here i hope that you had put some information about that
Sophie June 07, 2005 at 09:43 PM
Schaut mal unter Link Apple bietet dort den Look des Safari search field unter allen gängigen Browsern an.
t June 08, 2005 at 12:06 AM
it would seem your site doesn’t validate anyway because you’ve used id’s that start with numbers. can’t do that buddy!
Wolfgang June 08, 2005 at 01:38 AM
It seems as if Apple styled the input element using background-images. Not bad. Btw, the IDs in the journal section have already been fixed and the site should now validate again.
Sean June 08, 2005 at 11:42 AM
Hi, I got a question about Markus’ JavaScript method. I have my website LiveSearch-enabled, and it seems the method doesn’t work due to onload=“liveSearchInit()” within body tag. I removed the onload property and then LiveSearch doesn’t work correctly while the method works fine. Does anyone know how to resolve this issue?
pickupjojo June 08, 2005 at 12:27 PM
It works nice with the last Safari CVS release too ! :-)
Wolfgang June 13, 2005 at 08:42 PM
By the way the script also works in NetNewsWire — you just have to enable Javascript.
Patrick Haney June 14, 2005 at 12:06 AM
While it’s true that this new “search” input type is quite attractive, I’m one of many who will probably never see it in use. I’m a Firefox user, whether in OS X or Windows, and rarely touch Safari. At the moment I see about 3-5% of my website’s user base is using Safari. Normally I’d say you could disregard the fact that your site no longer validates as XHTML considering the nice features this search box creates. However, it doesn’t degrade as nicely in other browsers as it could, and that seems to be the real issue. My suggestion would be to create your search box as usual and then do a Javascript-based replacement for any Safari browser that supports this “search” input type. That way your page validates, non-Javascript users will see the usual search box, and only Safari users will see the nifty new search field.
Drew McLellan June 16, 2005 at 07:13 AM
There’s no arguing that it’s neat. However, my reservations are twofold: 1) Because it seems to degrade to a text input in everything you’ve tried, doesn’t mean that you’ve tried everything. As there’s no way one person can be expected to try their site in every browser, mobile, assistive or other device we have web standards to ensure compatibility. That’s the crux of standards at the end of the day — to make sure you page works with my browser. 2) Even if you had some super testing lab with every possible browser and device available on the market today, there’s no way you could test for everything that might be on the market tomorrow. This is why we have web standards … (you know the rest!). As someone has already mentioned, it’s a really nice option for a very controlled environment like an intranet. But in an environment like the public internet where you never know what’s coming, it really does pay to stick to W3C recommendations.
Patrick H. Lauke June 16, 2005 at 10:02 AM
surely it’s nonsensical to have this in a document with an official W3C XHTML doctype…it defeats the entire purpose of defining a doctype in the first place. if this were to only work in a safari/apple specific doctype, fine…or even if they wrote an extension to the existing XHTML doctypes. anythin else is pure nonsense. if IE were to do this, everybody would be up in arms about how they’re breaking the web again…but as apple is the “underdog”, it’s ok i guess? hey apple, why not bring out a revived version of the marquee element as well?
Chris Evans June 16, 2005 at 07:43 PM
Patrick — wholeheartedly agree with you. One rule for everyone — and that is, stick to agreed standards. New HTML elements get defined in the next version of HTML, not the next version of some enormous multinational’s fancy pants browser.
BlogD June 17, 2005 at 12:11 AM
I tried this input type on my site, and I can get the rounded text box and the (x) to clear–but the “recent search” magnifying-glass bit doesn’t show up. Any idea on why that might be?
Wolfgang June 17, 2005 at 12:49 AM
You have to define the “autosave” attribute in order to get the “recent search” functionality. For example: autosearch=”at.bartelme.search”
BlogD June 17, 2005 at 01:06 AM
Thanks! But how do I determine the autosearch designation, which you gave as “at.bartelme.search”? Do I just make it up and that’s that, is there a syntax that must be followed, or do I have to further define/support the designation elsewhere? Your help is very much appreciated!
Wolfgang June 17, 2005 at 01:25 AM
As far as I know it’s that simple — at least I haven’t experienced any problems yet.
BlogD June 17, 2005 at 01:31 AM
Found out the problem: in additon to the “autosave” one has to add a “results” attribute. It’s working now. Thanks again!
Joe Clark June 17, 2005 at 05:12 AM
When Markus said this Web site was “awful,” I’m sure he meant “awesome.” “Awful” means “terrible.”
Markus Stange June 18, 2005 at 02:10 AM
Omfg. Thanks… next time I’ll use a dictionary — of course I meant awesome.
kosmar June 21, 2005 at 03:43 AM
i would’t do anything that won’t validate … but thats far too cool. couldn’t the type attribute just be replaced by a js dom-hack only for safari >1.3, that would mask the invalidness good enough for the concerned ones and give safety for any other misbehaving browser of the future still are you aware of the fact that your new searchbox breaks your layout in safari 1.2.3 , at least in mine?——-