XING multilingual search slot
Make it flexible by Nils Lauk
Here’s a little addition to the relaunch in June 2011, a kind of “maybe someone’s interested in this” article. This time it’s about the search slots in the main content area of the new XING. “But nothing has changed”, I can hear you mumble. Au contraire! We made a lot of under the hood changes!
XING is a multilingual platform and that’s exactly why the life of a frontend developer is so tough. The average everyday situation is this: UX creates something in Photoshop, hands the design over to Frontend, Frontend starts to build it and then the Frontend team pulls its hair out (When I started here at XING, I had more hair. True story!). What looks nice in Photoshop could well appear to be broken in the browser. Why? Well, of course we test our items, and that includes switching the user language. And would you believe it, all of a sudden the English word “search” will become “encontrar” in Portuguese. And “search for” is even shorter in Italian – “cerca”.
If we arrange the search slot in-between the “search for” label and the “search” button, then we can’t use fixed widths for all three elements. Sure, we could select the longest language and use this as a basis to work with. But as soon as the language is short (e.g. Chinese) we will see gaps and/or whitespaces, which isn’t pretty. Not to mention the fact that UX would be hopping mad at us.
A flexible solution should do the trick. We had an idea, but first let’s see what our colleagues from other companies had come up with:
Fig. 1: A few different search slots on other sides.
This isn’t really what we’re looking for here at XING. We want a label, a search slot, and a search button. When they have something similar – like on Amazon – they don’t have the language problem. Amazon uses a “Go” button as a submit button. This “Go” is part of a sprite image, which isn’t flexible but doesn’t pose any language problems. We don’t want to have an image for every button.
We wanted to use a list. Maybe something with display: inline;? This is quite tricky. While playing around with the code I soon realized that the input field is the weak point as it’s not really possible to make the input field stretch properly. Believe me, I tried. We could have used a table. But then again… nah… ;-)
So this is our solution:
<ul class="big-search-slot"> <li class="thelabel"> <label for="search_keywords" id="search-keywords-label">Search</label> </li> <li class="theslot"> <input id="search_keywords" name="keywords" type="text"> </li> <li class="search"> <button type="submit" name="send" value="find"> Search </button> </li> </ul>
The corresponding CSS will do the trick with the flexible design. Now we can have different languages, and the label and button will unfold beautifully with the input field stretching or shrinking accordingly.
.big-search-slot { background: #ebebeb; -moz-border-radius: 3px; -webkit-border-radius: 3px; border-radius: 3px; display: table; margin-bottom: 5px; padding: 15px 15px 20px; } .big-search-slot li { display: table-cell; } .thelabel, .big-search-slot li.search { font-weight: bold; white-space: nowrap; } .theslot { padding: 0 10px; width: 100%; } .theslot input { margin-bottom: 0; } .big-search-slot button { float: none; margin: 0; }
This will result in these search slots languages. See? It’s flexible.
Fig. 2: Flexible search slots on XING in different languages. From the top we have: German, English, Chinese and Portuguese.
Tables for designing a page?
One small flaw in this scenario would be that not every browser will interpret the display: table; properly. Yep, you guessed it, I’m talking about the IEs, namely IE6 and IE7. Maybe this is the reason why we don’t find all that many display: table; out there?
XING is a business platform and we therefore need to develop right down as far as IE6, but a) the numbers of IE6 users is decreasing and b) we were given the green light for a “don’t spend too much time on these IEs” approach.
The old IEs should not be corrupted in terms of their handling, and that’s precisely what we don’t do. Although the search slot doesn’t look as nice as in modern browsers, it is still functional for IE users.
This is why we’re providing these CSS adjustments that only will be delivered to IE6 and IE7:
.big-search-slot li { display: inline; } .big-search-slot li.search { margin-top: 10px; width: 100%; } .big-search-slot .thelabel, .big-search-slot .search { width: 150px; } .big-search-slot .search { vertical-align: bottom; } .theslot { width: 100%; } .big-search-slot .theslot input { width: 250px; }
And to answer the question of whether you should use tables for design reasons – the answer is, apparently, no. But our nice little display: table; is not a table. It’s a list disguised as a table.

Nils Lauk works as a Frontend Architect at XING. He loves semantics and accessibility. He's also a big fan of microformats.
Hi Niels, thanks for sharing. A little though on semantics: I agree that tables are the wrong structure for this case. But so is the list since the label-input-button-combo has nothing todo with a list when looked at without css. What are the advantages of using a list-elements in comparison to just using a nested div-structure?