Subscribe to
Posts
Comments
NSLog(); Header Image

Simple Safari Search Form Validation

In its raw form, this site wouldn't validate. Why? Because I like the Safari-only "search" text box functionality:

<input type="search" value="" name="s" id="s" size="15" placeholder="Search Here" autosave="com.nslog.search" results="9" /&g;

That one tag causes four errors in validation all by iteself:

  1. There is no "search" type.
  2. There is no attribute "placeholder."
  3. There is no attribute "autosave."
  4. There is no attribute "results.

Tough beans. Search stays. I like to get that little "Valid" button as much as the next guy, but the search degrades nicely enough that I'll continue to use it and the site will validate. How? I'll could simply hide the form by user agent, only displaying it for Safari and OmniWeb:

<?
$browser_user_agent = (isset($_SERVER['HTTP_USER_AGENT'])) ? strtolower($_SERVER['HTTP_USER_AGENT']) : '';
if(strpos($browser_user_agent, 'webkit'))
{ ?>
    <!-- WebKit-friendly search box here -->
<? } else { ?>
    <!-- "Standard" search box here -->
<? } ?>

Note the use of the faster strpos over something like strstr.

13 Responses to "Simple Safari Search Form Validation"

  1. Why not use "stripos", a case sensitive "strpos"?
    Why not filter for WebKit, displayed by every well-behaved WebKit app, instead of Safari or OmniWeb?

  2. [quote comment="21330"]Why not use "stripos", a case sensitive "strpos"?[/quote]
    Because strpos is the case-sensitive (and thus faster) one:

    stripos -- Find position of first occurrence of a case-insensitive string.

    [quote comment="21330"]Why not filter for WebKit, displayed by every well-behaved WebKit app, instead of Safari or OmniWeb?[/quote]
    I've made that change. I didn't originally because I'm lazy and didn't want to check OmniWeb's user-agent string.

  3. Already told you, but just so I don't look like a complete ass to other people: I suggested "stripos" *because* it was case insensitive, and I just messed up when trying to say that. As you said though, it's probably cheaper to downcase and do a case sensitive comparison, and thus "strpos" works.

  4. [quote comment="21338"]Already told you, but just so I don't look like a complete ass to other people: I suggested "stripos" *because* it was case insensitive, and I just messed up when trying to say that. As you said though, it's probably cheaper to downcase and do a case sensitive comparison, and thus "strpos" works.[/quote]
    Plus, I just noticed, stripos requires PHP 5.

  5. Sorry monsieur, but that's really inelegant and kludgy. You might want to look at custom DTDs -- google it or read the article at A List Apart.

  6. [quote comment="21818"]Sorry monsieur, but that's really inelegant and kludgy. You might want to look at custom DTDs -- google it or read the article at A List Apart.[/quote]
    Thanks for the pointer. I modified the page to incorporate the following addition to the DOCTYPE:

    <[
    <!ATTLIST input type CDATA #IMPLIED>
    <!ATTLIST input placeholder CDATA #IMPLIED>
    <!ATTLIST input autosave CDATA #IMPLIED>
    <!ATTLIST input results CDATA #IMPLIED>
    ]>

    That worked but, as the article noted, the "]>" characters displayed themselves. I attempted to create my own DTD and didn't succeed. So, inelegant and kludgy as it is, my method remains. It's not for validation, per se, but more to reveal features to Safari/OmniWeb users.

  7. [...] Erik J. Barzeski over at NSLog goes into it in more depth (I didn't know about placeholder="" for example) and he also goes into a way to only present it to Safari & Omniweb. Link Just because I use safari and its so cool! "They figure it has no type, so they use type="text" instead " If you do, just set the unique identifier to the same each time. [...]

  8. Just a quick heads up for people that don't know the difference between <? and <?php. Not all servers come with <? enabled, and indeed some hosts leave it disabled. (I personally always leave it disabled on my test machine to make sure I write code that is useable on every php install.)

    The problem comes when someone releases php code using <? and your server has it disabled. Then you have to go through and change all the short tags to the longer <?php type to get the code to run.

    The easy way round it is to just release all php code using the longer <?php, and indeed this is the recommendation from the default php.ini file:

    NOTE: Using short tags should be avoided when developing applications or
    libraries that are meant for redistribution, or deployment on PHP
    servers which are not under your control, because short tags may not
    be supported on the target server. For portable, redistributable code,
    be sure not to use short tags.

    Just a quick FYI for people that might not be able to get this running if (like me) php has short tags disabled!

  9. Interestingly, I note that you don't use the type="search" feature on your own search box!

  10. [quote comment="39659"]Interestingly, I note that you don't use the type="search" feature on your own search box![/quote]

    Yes I do. Obviously you'll need Safari (or OmniWeb) to see it.

  11. Wouldn't it also make sense to hide the submit button for webkit browsers, given that the search box is shown without one in the vast majority of cases?

  12. [quote comment="41695"]Wouldn't it also make sense to hide the submit button for webkit browsers, given that the search box is shown without one in the vast majority of cases?[/quote]

    It's not a live search box, though - you have to press enter. Without the button, I think some people might type and wonder why nothing's happening.

  13. why not use javascript to insert the type="search" and such...?
    This way you don't even have that ugly apple-proprietary-markup.
    Just my two cents...