[Pro] Conditional Statements, Sprites, IE9 plus all other browsers

I’ve been using the following code in Page HTML Markup to get my search field to work properly with a sprite:

<style type="text/css">
input.safari, input.safari_focus {
    font: 12px Helvetica, MS Serif, Sans-serif;
    border: none;
    padding: 6px 20px 6px 24px;
    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) no-repeat left top;
    height: 14px;
    width: 152px;
}

input.safari_focus {
    overflow: visible;
    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) 0 -26px;
}

*:focus {outline: 0;}
</style>

You can see an example in the bottom left of this page in my site:

But I am now optimizing my size for Retina displays using 2x graphics. As such, I now am wanting to use the following Page Markup instead:

<style type="text/css">
input.safari, input.safari_focus {
    font: 12px Helvetica, MS Serif, Sans-serif;
    border: none;
    padding: 6px 20px 6px 24px;
    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) no-repeat left top;
    background-size: 197px 52px;
    height: 14px;
    width: 152px;
}
input.safari_focus {
    overflow: visible;
    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) 0 -26px;
    background-size: 197px 52px;
    height: 14px;
    width: 152px;
}
*:focus {outline: 0;}
</style>

The problem is that IE6/7/8 don’t support “background-size” and as such my graphic appears at 100% size and is clipped on those browsers. (And please don’t tell me to “just ignore those old browsers” because 42% of my web visitors still use IE8, and 14% still use IE6/7.)

I investigated using “If lte IE8” and other such conditional statements, but there’s a problem. You see, IE9 and higher support “background-size” so I want to support IE9 & higher PLUS “all other browsers.” But how do I make such a conditional statement?

Asking my question another way…

What exact code must I write in Page Markup to display my old “safari_search_2013.gif” 72ppi graphic sprite on “IE8 and lower” while displaying my new “SearchField_144.gif” to “IE9 and newer, plus all other browsers”?

I look forward to your replies.

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi James,

hmmm - how to say something but avoid the “just ignore old browsers”?

Honestly I can’t help you with the above.

I made a lot in your other topic (the shadow stuff, Inflow Construction, Atomz, IE hack) that maybe qualifies me, to throw out the following:

Taking care of older browsers is important if it comes to functionality but isn’t worth the time if it comes to aesthetics.

BTW (try if this works now):

http://kimmich-dm.de/testings/kiramek/

42%+15% of your visitors do anyway only see the half of what a modern webpage can offer - and they’re used to, they don’t care - except broken functions. By the way:
Those buddies are seeking for the “search” or “start” button so you should change your placeholder to “hit enter to start a search” or something like that.

The above journey was more than interesting - a challenge - but not kind of a “wow - a must have”. And I found maybe a couple of answers that reduces the amount of time you invested.

Doing the splits has its natural border - and IE6 and Retina hurts, for sure.

Cheers

Thomas


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thomas, thank you for your reply, but even in Chrome I’ve noted that the search field on your example page is a boring old rectangle, and you have added Search Button clutter too. At least my search field has rounded corners, and you submit the search with a mere press of the Return key.

But getting back to my root question, let me prod you in the right direction. Forgot the details of what I am trying to do and just consider the markup. Dwell only on what code is required to get the “conditional statements” to feed IE6/7/8 with CODE-A and IE9/10 and all other browser with CODE-B. That is the heart of my original post.

If anyone else would like to chime in with some code suggestions, I am all ears.

Thank you!

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

… to be clear:

I can’t help you with the search field.

The example belongs to the:

http://www.freewaytalk.net/thread/view/126417#m_127146

topic.

I maybe better post it there (if I find some time).

Cheers

Thomas


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

<style type="text/css">
<!--[if lte IE 8]>
input.safari, input.safari_focus {
    font: 12px Helvetica, MS Serif, Sans-serif;
    border: none;
    padding: 6px 20px 6px 24px;
    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) no-repeat left top;
    height: 14px;
    width: 152px;
}

input.safari_focus {
    overflow: visible;
    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) 0 -26px;
}

*:focus {outline: 0;}
<![endif]-->
input.safari, input.safari_focus {
    font: 12px Helvetica, MS Serif, Sans-serif;
    border: none;
    padding: 6px 20px 6px 24px;
    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) no-repeat left top;
    background-size: 197px 52px;
    height: 14px;
    width: 152px;
}
input.safari_focus {
    overflow: visible;
    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) 0 -26px;
    background-size: 197px 52px;
    height: 14px;
    width: 152px;
}
*:focus {outline: 0;}
</style>

D


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thank you for the code suggestion, David. But I have a question about the way the code executes.

A simplistic outline of your code is as follows:

<style>
<if IE8 and lower only>
CODE-A
<end if>
</style>

<style>
CODE-B
</style>

I can fully understand why IE6/7/8 will execute CODE-A. That’s a no-brainer. But what prevents IE6/7/8 browsers from then executing CODE-B that follows?

I see no conditional statements around CODE-B that would prevent any browser from trying to execute it, including IE6/7/8. And since CODE-B is not 100% the same as CODE-A, how then could an ELSE statement merely be “implied”?

This is the source of my confusion and is why I posted my original query.

I look forward to your reply.

Thank you,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Just reverse the order of these. Put your retina code first, then override it in the conditional comment for the lesser browsers. The last one wins, and all the normal browsers will ignore the conditional comment, so for them it will be as if it wasn’t’ there at all. IE will look through the first style code, but then encounter the second code (in the comments) and that will be the only thing it paints to the screen.

Walter

On Mar 26, 2013, at 5:11 PM, JDW wrote:

Thank you for the code suggestion, David. But I have a question about the way the code executes.

A simplistic outline of your code is as follows:

<style>
> <if IE8 and lower only>
> CODE-A
> <end if>
> </style>
> 
> <style>
> CODE-B
> </style>

I can fully understand why IE6/7/8 will execute CODE-A. That’s a no-brainer. But what prevents IE6/7/8 browsers from then executing CODE-B that follows?

I see no conditional statements around CODE-B that would prevent any browser from trying to execute it, including IE6/7/8. And since CODE-B is not 100% the same as CODE-A, how then could an ELSE statement merely be “implied”?

This is the source of my confusion and is why I posted my original query.

I look forward to your reply.

Thank you,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Walter,

Thank you for your suggestion.

But why would the lesser browsers only “look through” the first style code instead of executing it and then executing the second code segment that follows? That’s my root question about all of these conditional statements.

If CODE-A was 100% the same as CODE-B, I can understand why the browser would look through both A and B and then decide which one of the two to execute. But since CODE- in not completely the same in my example, how then does the browse know CODE-A is “similar enough” to CODE-B so it will only execute whichever one of the two has a conditional statement attached to it?

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

CSS is a state machine. You start somewhere, make changes, and end up somewhere else. The browser considers all of the rules, and for example if you define the same attribute twice, only the last one “wins”. So when I say it looks through all the rules, it does. I just compiles a state and as it’s reading through the styles, it changes that state based on the rules it encounters, in the order in which it finds them. It does this for the entire page “stack” – the external sheets, the head styles, and the inline styles. And THEN it starts painting the screen. It never applies a rule until it has completely worked out what that rule would eventually look like in the final state.

a { color: blue; }
/* bunch of other styles in between */
a { color: red; }

Result: at no point ever will a link be blue, not even for an instant.

Walter

On Mar 26, 2013, at 6:00 PM, JDW wrote:

Walter,

Thank you for your suggestion.

But why would the lesser browsers only “look through” the first style code instead of executing it and then executing the second code segment that follows? That’s my root question about all of these conditional statements.

If CODE-A was 100% the same as CODE-B, I can understand why the browser would look through both A and B and then decide which one of the two to execute. But since CODE- in not completely the same in my example, how then does the browse know CODE-A is “similar enough” to CODE-B so it will only execute whichever one of the two has a conditional statement attached to it?

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

One other thing to think about: CSS styles can be partially overridden, not just entirely overridden. So if you had:

input.search {
	background-positiion: center center;
	background-repeat: no-repeat;
	background-image: url(path/to/image.png);
}

and then

[conditional comment for i.e. 8 and lower]
input.search {
	background-image: url(path/to/another.png)
}
[/conditional comment]

All of the stuff you didn’t change would still apply in IE8 and lower, and the new image would show, and IE wouldn’t – even for an instant – load the original image. These sorts of tweaks can be in any part of a style, too, and you don’t have to have defined the background in the expanded form as I did. Let’s say you had set it like this:

input.search { background: #fff url(path/to/image.png) center center no-repeat; }

Your conditional comment could be exactly the same as above – just changing the URL to the image – and everything else would still apply. It only matters that it comes after the initial style, not before, in the source order.

Walter

On Mar 26, 2013, at 6:00 PM, JDW wrote:

But why would the lesser browsers only “look through” the first style code instead of executing it and then executing the second code segment that follows? That’s my root question about all of these conditional statements.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

One other thing to think about: CSS styles can be partially overridden, not just entirely overridden.

I was going to go back and say that there is no need to repeat any of the code that doesn’t change - but as usual in haste!

D


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Walter,

I followed your advice and placed the following Markup on my page:

<style type="text/css">
input.safari, input.safari_focus {
    font: 12px Helvetica, MS Serif, Sans-serif;
    border: none;
    padding: 6px 20px 6px 24px;
    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) no-repeat left top;
    background-size: 197px 52px;
    <!--[if lte IE 8]>
    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) no-repeat left top;
    <![endif]-->
    height: 14px;
    width: 152px;
}
input.safari_focus {
    overflow: visible;
    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) 0 -26px;
    background-size: 197px 52px;
    <!--[if lte IE 8]>
    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) 0 -26px;
    <![endif]-->
    height: 14px;
    width: 152px;
}
*:focus {outline: 0;}
</style>

Unfortunately, this does not work as expected. Specifically:

  1. When I view in IE7/8, the high-rez (SearchField_144.gif) graphic is still displayed, and it is twice as big as it should be, and it is truncated (i.e., no improvement over the broken markup I was using before).

  2. I still see the 144ppi graphic in Mobile Safari on my iPad, but the search field is shifted up by 1px and there is a faint, blue, horizontal line that appears a few px below the search field. That faint blue line appears in the same way in Firefox & Chrome on WinXP too, but no line appears in FireFox or Chrome on OS X.

Since I implemented my markup using the logic you described to me, I am confounded why it is not working properly.

I put the conditional statements inside each of the two appropriate sections. And although the “background-size” line comes before my conditional statements, it isn’t recognized in IE anyway, so I would think it should be ignored.

Here’s my test page:

http://visionsecurity.jp/en/test/contact.html

I look forward to your thoughts.

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Try making a completely separate stylesheet inside the conditional comments, so you have two separate stylesheets. Like this:

http://scripty.walterdavisstudio.com/bigger

Also, you really don’t need to do anything for Safari or Mobile Safari except set the input type to search. This is all you need to get the search box appearance in any WebKit browser:

<input type="search" name="q" autosave="saved.data" placeholder="Search..." />

That’s completely valid HTML5, and will fall back gracefully to a normal text input on less enlightened browsers. So you could set up your CSS to only target the non-search browsers, by testing to see if the browser sets the -webkit-appearance=search attribute. That I would do in JavaScript, so you could be sure you didn’t trigger your faux Safari in Safari, where it is just a waste of cycles.

Walter

On Mar 26, 2013, at 9:49 PM, JDW wrote:

Walter,

I followed your advice and placed the following Markup on my page:

<style type="text/css">
> input.safari, input.safari_focus {
>    font: 12px Helvetica, MS Serif, Sans-serif;
>    border: none;
>    padding: 6px 20px 6px 24px;
>    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) no-repeat left top;
>    background-size: 197px 52px;
>    <!--[if lte IE 8]>
>    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) no-repeat left top;
>    <![endif]-->
>    height: 14px;
>    width: 152px;
> }
> input.safari_focus {
>    overflow: visible;
>    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) 0 -26px;
>    background-size: 197px 52px;
>    <!--[if lte IE 8]>
>    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) 0 -26px;
>    <![endif]-->
>    height: 14px;
>    width: 152px;
> }
> *:focus {outline: 0;}
> </style>

Unfortunately, this does not work as expected. Specifically:

  1. When I view in IE7/8, the high-rez (SearchField_144.gif) graphic is still displayed, and it is twice as big as it should be, and it is truncated (i.e., no improvement over the broken markup I was using before).

  2. I still see the 144ppi graphic in Mobile Safari on my iPad, but the search field is shifted up by 1px and there is a faint, blue, horizontal line that appears a few px below the search field. That faint blue line appears in the same way in Firefox & Chrome on WinXP too, but no line appears in FireFox or Chrome on OS X.

Since I implemented my markup using the logic you described to me, I am confounded why it is not working properly.

I put the conditional statements inside each of the two appropriate sections. And although the “background-size” line comes before my conditional statements, it isn’t recognized in IE anyway, so I would think it should be ignored.

Here’s my test page:

http://visionsecurity.jp/en/test/contact.html

I look forward to your thoughts.

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Walter,

After reading your latest post, I wanted to test things one step at a time. I’ve still not gotten it to work right, but here’s what I did.

  1. I copied David’s code and pasted it into my page (by editing the page directly on the server via TextWranger). That didn’t work out well at all. The search box reverted to a generic rectangle on most all browsers, and it didn’t work in IE.

  2. I then followed your advice about separating the two bits of code, as follows:

<style type="text/css">
input.safari, input.safari_focus {
    font: 12px Helvetica, MS Serif, Sans-serif;
    border: none;
    padding: 6px 20px 6px 24px;
    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) no-repeat left top;
    background-size: 197px 52px;
    height: 14px;
    width: 152px;
}
input.safari_focus {
    overflow: visible;
    background: url(http://www.kiramek.com/Resources/SearchField_144.gif) 0 -26px;
    background-size: 197px 52px;
    height: 14px;
    width: 152px;
}
*:focus {outline: 0;}
</style>

<style type="text/css">
<!--[if lte IE 8]>
input.safari, input.safari_focus {
    font: 12px Helvetica, MS Serif, Sans-serif;
    border: none;
    padding: 6px 20px 6px 24px;
    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) no-repeat left top;
    height: 14px;
    width: 152px;
}
input.safari_focus {
    overflow: visible;
    background: url(http://www.kiramek.com/Resources/safari_search_2013.gif) 0 -26px;
}
*:focus {outline: 0;}
<![endif]-->
</style>

The above code works great in all browsers, except IE7/8. But it works better than before insofar as the “rollover” sprite properly comes into view when I click inside the field. The broken part is that the initial view of the search field is still the 144ppi graphic, display at it’s enormous size and truncated. It’s strange. Try it in IE8:

http://visionsecurity.jp/en/test/contact.html

(Once I get the code to work right in IE7/8, then I will try your separate advice on Webkit browsers.)

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

I just SOLVED THE PROBLEM in IE7/8 by moving the and <endif} tags OUTSIDE the and tags. I don’t see why it matters but apparently it does to ancient versions of IE!

With that big problem out of the way, I am now experimenting with the code you proposed for Webkit browsers. Just for a quick and dirty test, I put the following code into page Markup:

  <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/prototype/1.7/prototype.js"></script>
  <script type="text/javascript">
    document.observe('dom:loaded', function(){
      var _test = new Element('input', {type: 'search'});
      if( ! ('-webkit-appearance' in _test.style) || _test.style['-webkit-appearance'] && _test.style['-webkit-appearance'] != 'search'){
        $$('input[type="search"]').addClassName('safari');
      }
    })
  </script>

  <input type="search" name="sp_q" size=33 maxlength=128 accesskey="F" type="text" autosave="saved.data" placeholder="Search this site..." />

That places a separate search field in the top left corner of my page (not where I intend for it to go, but again, this is just for test purposes).

Here are my problems:

  1. Your code produces a very nice looking search bar, but I obviously want that to appear IN PLACE OF my sprite, on all Webkit browsers. How do I get it to do that? I can get it to appear atop my page now, only because it is a separate search field. It is not “replacing” anything.

  2. When I view the page in IE7/8 with the above code, the search field at the bottom left of the page reverts to a square rectangle (my sprite is not loaded at all). (But my sprite is being loaded properly in other browsers.)

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Here’s what I recommend you try, as a teaching tool for yourself.

  1. Set up an example of the sprite image trick on a new blank page. Use the original 1x version of the graphics.
  2. Set up a second page using only the 2x version of the graphics, and using the background-size property to “scale” the 2x graphic to fit inside the same box size as the first page.
  3. Now just move all of the code from the first page inside the IE8 conditional comment on the second page. (And Profit!)

Walter

PS: To answer another of your questions from earlier. To replace the search field on the bottom of your page with the one that works natively, in FW6, just change the Input type to ‘search’. In FW5, click once on the field, open up Item / Extended, and enter type: search in the name: value fields. (Also add the other attributes from my code example if you want to get the placeholder and the little caret with the previous search items.)

On Mar 26, 2013, at 12:54 AM, JDW wrote:

What exact code must I write in Page Markup to display my old “safari_search_2013.gif” 72ppi graphic sprite on “IE8 and lower” while displaying my new “SearchField_144.gif” to “IE9 and newer, plus all other browsers”?


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Walter, with regard to your “PS,” I’m afraid I’ve got GOOD and BAD to report:

THE GOOD

  1. Works as expected in Chrome on OSX.
  2. Works as expected in Safari on OSX.
  3. Works as expected in Firefox on OSX (sprite).
  4. Works as expected in Firefox on WinXP (sprite, 144ppi).
  5. Works as expected in IE7/8 on WinXP (sprite, 72ppi).
  6. Works as expected in IE10 on Win8 (sprite, 144ppi).

THE BAD (showstopper)

  1. On Mobile Safari in iOS6 (on iPad3 hardware), the search field is badly mangled, and the 144ppi sprite partly displays. Ditto for every iPhone and iPad available in the XCODE iOS Simulator.
  2. On Chrome in WinXP, the search field reverts to a generic rectangle, and the vertical height is so short you cannot even see your full text cursor.

Have a look yourself here:

http://visionsecurity.jp/en/test/contact.html

Best,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

The sprite should never apply to a browser that supports the search field natively. Just use what you get in WebKit browsers. Mobile Safari’s version of the search field doesn’t have the completely round ends, but it has a distinctive look compared to a normal input. Make a comparison page with an input type=text and an input type=search and look at it on all your target browsers. For those where it appears to be the same thing exactly, then you should use your sprite to “shim” it into your desired appearance. But for those that have a native search field, you should go with that and not try to horse it around.

Walter

On Mar 27, 2013, at 9:43 PM, JDW wrote:

Walter, with regard to your “PS,” I’m afraid I’ve got GOOD and BAD to report:

THE GOOD

  1. Works as expected in Chrome on OSX.
  2. Works as expected in Safari on OSX.
  3. Works as expected in Firefox on OSX (sprite).
  4. Works as expected in Firefox on WinXP (sprite, 144ppi).
  5. Works as expected in IE7/8 on WinXP (sprite, 72ppi).
  6. Works as expected in IE10 on Win8 (sprite, 144ppi).

THE BAD (showstopper)

  1. On Mobile Safari in iOS6 (on iPad3 hardware), the search field is badly mangled, and the 144ppi sprite partly displays. Ditto for every iPhone and iPad available in the XCODE iOS Simulator.
  2. On Chrome in WinXP, the search field reverts to a generic rectangle, and the vertical height is so short you cannot even see your full text cursor.

Have a look yourself here:

http://visionsecurity.jp/en/test/contact.html

Best,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Walter, you appear to have misunderstood what I meant by “badly mangled” in my previous post. Here’s a screen shot to show you!

Test it yourself in the iOS Simulator (XCODE):

http://visionsecurity.jp/en/test/contact.html

—James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

No, I have asked you to do something different than what you’re trying to do on that page. Please view this page on as many different devices as you like: untitled

(Note: that’s not a real 2x safari screenshot in there, I had to scale it up in Photoshop because I don’t have a Retina Mac.)

WebKit browsers will show a native search box (it’s subtly different on iOS than Mac OS) and non-WebKit browsers get a screenshot of the Safari box. The box is sized with CSS to fit the screenshot, and the background is centered. Note that the only thing we do differently on the IE8 and under is change out the image. All of the other CSS remains unchanged.

Walter

On Mar 28, 2013, at 12:07 AM, JDW wrote:

Walter, you appear to have misunderstood what I meant by “badly mangled” in my previous post. Here’s a screen shot to show you!

http://www.kiramek.com/21test95/BustedSearchField_iPad.PNG

Test it yourself in the iOS Simulator (XCODE):

http://visionsecurity.jp/en/test/contact.html

—James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options