A couple of months ago introduced you Safari’s new search field — a special HTML form component, that looks and behaves just as the search field of Mac OS. However there is one drawback: the custom attribute “search” prevents your site from validating.
In order to make Safari display this custom input field you just have to assign another type to the input element — type="search". If you don’t mind whether your site validates or not, this approach is absolutely okay since search fields degrade gracefully in other browsers. However if you do care, you can make use of one of the following techniques.
The first and more obvious technique is to replace the type attribute using JavaScript. Since the W3C Validator does not interpret JavaScript, it only validates the following HTML…
<input type="text"/>instead of…
<input type="search"/>This techniques is perfect when viewing the site with a javascript enabled browser. However if javascript is disabled, Safari users or rather Apple Webkit users will just get a plain text field. And since your site will probably also be viewed with RSS readers such as NetNewsWire or NewsFire, in which javascript is disabled by default, this approach is somewhat half-hearted. So let’s better take a look at the second technique.
So how can we assign this proprietary value to our search field without intimidating browsers and the W3C validator? Well the answer is quite simple — by defining a custom DTD that extends XHTML a bit to include our custom attribute. This custom DTD defines our special attribute value, and the validator obeys by checking the document structure against our special flavor of XHTML. If the DTD says the value is valid, they’re valid.
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”
[
<!ATTLIST input type
(text|submit|checkbox|radio|button|password|search)
#REQUIRED>
]>
However if you look at the example you will recognize that all browsers except for Opera render the closing parenthesis ]>, which is quite annoying. But if we apply some negative text-indent to the body element, we can get rid of it. For further reading check out the following articles: Validating a Custom DTD and More About Custom DTDs at “A List Apart”.
8 comments so far
Skip to comment form
Johannes October 30, 2005 at 03:04 AM
Danke für den Hinweis!
Sophie October 30, 2005 at 04:58 AM
Do you know if there’s an official Safari DTD from Apple?
Pascal October 30, 2005 at 05:16 AM
It would be better to use a custom external DTD. This won’t produce any rendering errors (caused by the quirks-parser, AFAIK) and it is easier to manage for multiple files: Accesify tutorial, from Google Cache
Pascal October 30, 2005 at 05:16 AM
oops. No HTML, I forgot…
Link
Tom K. October 30, 2005 at 05:21 AM
There’s is another technique which I use, with PHP. Depending on the “HTTPUSERAGENT” the type of the search-input field is set. So either there is a nice “Mac OS X”-searchfield or a “normal” input-field plus a usual submit-button. Up to now I only asked for “Safari” in the user-agent string, so the apple-like searchfield didn’t appear in applications like NetNewsWire or DEVONthink. I’ve just changed my PHP-query into “AppleWebKit”, so this applications use the nicer searchfield as well. Thank you for the hint!
melted October 31, 2005 at 12:06 AM
Interesting…
tomsw October 31, 2005 at 04:22 PM
I prefer the method with PHP and the useragent.
Jason November 02, 2005 at 06:39 AM
I like the PHP method a lot, but I’m curious. Fundamentally, is this any different than doing browser detection in JavaScript, something we all know to be the least optimal way of doing things? In other words, what’s to prevent a PHP script that uses this method from breaking the moment a new browser comes on the scene, or an existing browser changes, etc.? You know, all of the normal pitfalls that come with using a browser detection method.
——-