h3 {
  display: run-in;
}

The point is to allow a header to run into text below it, without sacrificing semantics or running into the problems you might run into trying to force it with other layout techniques.

Let’s take a closer look.

But why not __________?

But why not float it to the left? Well headers are often of larger font-size than body type. So if you float the header to the left, you might catch more than one line.

But why not make it an inline element? Because the following text might be (actually, is likely to be) inside of a paragraph tag. Paragraph tags are block-level, and thus the will break to a new line if they follow an inline element and the effect will not be achieved. You could insert the <h3> tag within the <p> tag, but that has semantic concerns, and more importantly, long term maintenance concerns. What if this effect goes out of vogue?

But why not use inline-block? Same problem as above. The effect will not be achieved unless you tuck the header into the following paragraph which is problematic.

How does it work then?

If a run-in element precedes a block level element, the run in element will behave structurally as if it has become the block level elements first inline child element.

Browser Support

Haven’t heard much about this? Well it might be because browser support is a bit weird.

Rumor has it that Mozilla isn’t happy with the spec. Firefox doesn’t support it at all, including the version 4 betas.

The WebKit family (Safari and Chrome) are supporting it, as well as Opera and IE 8. There are some differences in how these browsers handle things though. Reports have it that older versions of WebKit and Konqueror allowed run-in elements to run into succeeding inline elements which is incorrect.

Issues in the spec?

In my own reading of the spec, I find it a bit unclear.

If a sibling block box (that does not float and is not absolutely positioned) follows the run-in box, the run-in box becomes the first inline box of the block box.

That makes sense and appears to be how it works, but does “becomes the first inline box” mean that the run-in box should become a descendant of the block box? In WebKit, the run-in element retains its solidarity.

A run-in cannot run in to a block that already starts with a run-in or that itself is a run-in.

Does that mean that there can’t be two headers, both run-ins, that run into a paragraph below? That’s how I would read it, but I think the WebKit implementation where they both fall inside makes more sense. Opera and IE 8 follow the spec in that the first run-in becomes block and the second goes inline.

Then it says:

Otherwise, the run-in box becomes a block box.

Otherwise is a big word, but implementations have been pretty good here. Three run-in’s in a row inside a parent with no other siblings? They all go block. A run-in sandwiched between two inline elements? It goes block. Run-in > absolute-position > block, the run-in goes block. Mind-bending, I know, but current modern browsers are doing good here.

If the run-in element contains anything block-level, it becomes block-level. All browsers seem to agree on that one.

Demos

Here is my own simple demo page. There is also a super hardcore demo (which is over 10 years old).

Thanks to Gene for having me! I really recommend to everyone to check out Unmatched Style. A web design gallery is also part of what they do. I always tell people it’s my favorite web design gallery because they don’t just post a screenshot and call it a wrap, they write about why they like the design, and even parts they don’t like. Not to mention these are folks who build websites for a living, so there is nobody more qualified to critique and promote others work.

Uhm, yeah, why wouldn’t I?

It’s totally insecure. Hackers could destroy your computer.

Hackers? What is this 1995? And, no they can’t.

They can definitely steal information about you without you knowing.

Like what?

Like you’re address book information or your browsing history, depending on your browser and settings.

So if I were to visit some dark corner of the internet where people ran malicious scripts like this, people might be able to capture that my name is Bob and I live at 123 Maple Drive Mayberry, NC? And that sometimes I look at boobs at The Daily Niner?

Yes.

But I don’t use autofill on my forms at the browser level, they can’t. What about you? Isn’t like every single website you visit seemingly broken?

Well good websites are coded to work fine without JavaScript, and I can selectively enable sites I trust to allow it.

That sounds like a lot of work to maintain a whitelist manually. And it’s not like you do a security audit of each site before whitelisting it right? You just decide to trust it, basically because you want to look at and use that website right now and JavaScript is the only way.

Yes but I’m much more likely to enable it on a big businesses website than some random blog. Look, I’m not alone here, millions of people have downloaded the NoScript plugin for Firefox alone.

I see that. Here’s some empirical evidence for you though. I’ve never once blocked JavaScript on any of the browsers I’ve used. I browse around all day with little regard to my trust level of the current website. In general my trust level is actually fairly low. I know a lot of sites I visit are hosted on shared hosting by folks like me who aren’t security gurus. I’ve had my websites hacked before on the server-level (nothing to do with JavaScript), which then inserted malicious JavaScript into my pages. I’m sure this has happened to many of those other sites I visit. Sometimes that JavaScript stores weird cookie data or redirects the website. Totally sucky and undesirable, but nothing that serious has ever happened to the point where I even consider just turning off JavaScript. I’ve never lost sensitive data or gotten spyware or anything like that.

Are you sure? Have you ever had weird charges on a credit card you’ve had to refute?

Well yeah.

Do you know exactly how that information was stolen from you?

No I don’t, but I doubt it was JavaScript.

Doubt… Trust… two sides of the same coin.

Here’s another reason I browse with JavaScript on. I like JavaScript. I write JavaScript. It does cool stuff and I like to see how other people use it. So I’m biased in that regard. As a web designer and developer, I don’t like hearing how many people browse with JavaScript off. I want that to go away. I don’t want to create gracefully degrading websites because it’s often twice the work and only for accommodating people with outdated concerns about this technology. And don’t tell me all about accessibility, I hear that most screen readers handle JavaScript just fine.

A site that works well without JavaScript also means it also likely has good architecture. It works great alone, and JavaScript adds to the user experience as needed. Relying on JavaScript entirely is just lazy.

You see it as lazy I see it as the future. So what about Flash, do you block that too?

No, I love Flash.

I knew I didn’t like you. You’re probably a PC guy too huh?

Dude, we’re not going there.

TextMate is a mac-only code editor. Sorry to all the PC users this time around. If you’ve been watching these screencasts for a long time, you know I used to mostly use Coda. Since I’ve been working a lot more locally, I’ve been using much more TextMate, which I’ve always considered to be superior as a code editor but just wasn’t as convenient as Coda being all-in-one. I’ll cover some things I find cool and useful in TextMate, like vertical text selection, mass indenting, commenting, code folding, find in project, using the minimal bundles, zen coding, and more. I’m sure there are some TextMate gurus out there, so please feel free to share your own tips.

View Screencast

The basic idea

The border-image shorthand property has 3 parts:

border-image: url(border-image.png) 25% repeat;

Essentially, these allow you to specify:

1. An image to use as the border
2. Where to slice that image, dividing the image into 9 sections
3. How the browser should apply those sections to the edges of your element

The pertinent details

Let’s look at each part of the process in a little more detail. The first part is easy, and is familiar from the background-image property. For demonstration purposes I’ll use this image, which is 100px x 100px:

Slicing your image

The second part can have from one to four values, much like the border-width property, and they are specified in the same order: top, right, bottom, left. You can use percentages or pixels. Strangely, the percentages require the “%”, while pixels should be listed without the “px”:

border-image: url(my-image.gif) 25% 30% 10% 20% repeat;
border-image: url(my-image.gif) 25 30 10 20 repeat;

In this case, since my image is 100px x 100px, the two rules above are equivalent – they slice the image in the same places. I’ve added some dimensions on my image to demonstrate:

Repeat, Round, Stretch

border-image will always place the corner sections of your image into the corresponding corners of your element box, but the third part of the shorthand rule tells the browser how to treat the middle sections of your image — the ones that will go along the edges of your element. Repeat (repeat, or tile, the image) and stretch (stretch, or scale, the image) are pretty self-explanatory. Round means tile the image but only so that a whole number of tiles fit, and otherwise scale the image. Right now, Safari and Chrome interpret round as repeat. There can be up to two values: one for the top and bottom edges of the element, and one for the left and right. Here’s an example with the top/bottom value set to repeat, and the left/right value set to stretch:

#example-one {
	border-width:25px 30px 10px 20px;
	-moz-border-image:url("border-image.png") 25 30 10 20 repeat stretch;
	-webkit-border-image:url("border-image.png") 25 30 10 20 repeat stretch;
	border-image:url("border-image.png") 25 30 10 20 repeat stretch;
}

Screenshot for Example One

Border-width

border-image won’t do anything if you don’t specify a width for your border. For browsers that understand border-image, your image slices will be scaled to the specified width. If you use the border shorthand property, it provides a nice fallback for browsers that don’t:

#example-two {
	border:50px double orange;
	-moz-border-image:url("border-image.png") 25 30 10 20 repeat;
	-webkit-border-image:url("border-image.png") 25 30 10 20 repeat;
	border-image:url("border-image.png") 25 30 10 20 repeat;
}

Screenshot of Example Two

Or you can specify each width individually (in this example I’ve specified widths such that the image slices aren’t scaled at all):

#example-three {
	border-color:orange;
	border-style:double;
	border-width:25px 30px 10px 20px;
	-moz-border-image:url("border-image.png") 25 30 10 20 repeat;
	-webkit-border-image:url("border-image.png") 25 30 10 20 repeat;
	border-image:url("border-image.png") 25 30 10 20 repeat;
}

Screenshot of Example Three

Using a plain border at the same widths as your border-image won’t always be ideal, however, so you may want to use conditional stylesheets to give IE some different border styles altogether.

Browser quirks

Predictably, IE doesn’t understand anything of border-image. Browsers that do support border-image only support the shorthand property, not all the individual properties that are described in the spec. Some potentially useful properties aren’t supported at all, especially border-image-outset, which would solve this problem.

Also, the default behavior is supposed to be to discard the center section of the image, and use the ‘fill’ keyword on the border-image-slice property to preserve it:

The ‘fill’ keyword, if present, causes the middle part of the border-image to be preserved. (By default it is discarded, i.e., treated as empty.) (Read the spec)

But the current browser behavior is to preserve the middle, and there is no way to turn it off. Thus, if you don’t want your element’s content area to have a background, the center section of your image must be empty. However, you can use this filling behavior to your advantage, to create a box with a fancy border and background, with only one image.

Interactive demo

I built a border-image demo page to help me get my head around this complicated new set of CSS3 properties. You can pick an image, specify repeat, round, or stretch, and adjust the border-width and slicing. Enjoy!

Examples in the wild

• Chris Spooner uses it to nice effect to give his images a custom border.
• On the travel blog Go Pink Boots I built recently, I used it to add a torn-paper background to images.
• I use it on my site The Web Designers’ Review of Books to highlight blockquotes.

If you have other examples on live sites, I’d love to see them. Leave a link in the comments!

About the Author

Nora Brown is a freelance web and graphic designer based in Boston. Her pet project at the moment is the Web Designers’ Review of Books, where she reviews books on everything from Blue Note album covers to HTML5. Have a look!

Well, it’s that snagging of the file path that is the problem. I did some research and testing in different browsers and I thought I’d document the results.

Genesis

The idea comes from the fact that you can see see the file path in the file input after you select it.

Your eyeballs can see it, but JavaScript cannot.

Security issue

In all my naivety, I just though “Hey we’ll just get the value of the input and use that as the src of an image element next to the input!” As I quickly learned, there are some security concerns with allowing the browser to see a local file path like that. A malicious script could learn a good deal about your local file system if a file input was willing to cough up data like that.

What browsers actually do

Internet Explorer & Opera

Both these browsers will return a value like this when trying to access the value of the file input:

C:\fakepath\image.png

This article has a bit more information on the subject. Apparently if you add the site in question to the “Trusted sites” list in Internet Explorer it will return the file path. But of course you can’t expect users to do that.

WebKit (Safari / Chrome)

Return no value whatsoever for the file input value.

Firefox

Firefox is unique in that it returns only the filename for the file inputs value. While clearly that won’t work to get a local image preview working, this thread on StackOverflow lead to an interesting solution.

While it won’t give you the file path, Firefox will let you use a function called ‘getAsDataURL()’ on the files attribute of the DOM on that input.

// Browser supports `files` as part of DOM
if (this.files) {

   //  This works in Firefox, #image-preview is an <img src="" />
   $("#image-preview").attr("src", this.files[0].getAsDataURL());

}

View Demo (only Firefox does anything)

1. Image as textarea background, disappears when text is entered.

You can add a background-image to a textarea like you can any other element. In this case, the image is a friendly reminder to be nice =). If you add a background image, for whatever reason, it can break the browser default styling of the textarea. The default 1px solid bolder is replaced with a thicker beveled border. To restore the browser default, you can just force the border back to normal.

textarea {
  background: url(images/benice.png) center center no-repeat; /* This ruins default border */
  border: 1px solid #888;
}

That background image might interfere with the readability of the text once the text reaches that far. Here is some jQuery that will remove the background when the textarea is in focus, and put it back if the textarea is left without any text inside.

$('textarea')
  .focus(function() { $(this).css("background", "none") })
  .blur(function() { if ($(this)[0].value == '') { $(this).css("background", "url(images/benice.png) center center no-repeat") } });

2. HTML5 placeholder text

There is a new attribute as part of HTML5 forms called placeholder. It shows faded gray text in the textarea (also works for text-style inputs) which disappears when the textarea is in focus or has any value.

<textarea placeholder="Remember, be nice!" cols="30" rows="5"></textarea>

HTML5 placeholder text works in Safari 5, Mobile Safari, Chrome 6, and the Firefox 4 alpha.

3. Placeholder text, HTML5 with jQuery fallback

We can easily test if a particular element supports a particular attribute by testing with JavaScript:

function elementSupportsAttribute(element, attribute) {
  var test = document.createElement(element);
  if (attribute in test) {
    return true;
  } else {
    return false;
  }
};

Then we can write code so that if the browser does support the placeholder attribute, we’ll use that, if not, we’ll mimic the behavior with jQuery:

if (!elementSupportsAttribute('textarea', 'placeholder')) {
  // Fallback for browsers that don't support HTML5 placeholder attribute
  $("#example-three")
    .data("originalText", $("#example-three").text())
    .css("color", "#999")
    .focus(function() {
        var $el = $(this);
        if (this.value == $el.data("originalText")) {
          this.value = "";
        }
    })
    .blur(function() {
      if (this.value == "") {
          this.value = $(this).data("originalText");
      }
    });
} else {
  // Browser does support HTML5 placeholder attribute, so use it.
  $("#example-three")
    .attr("placeholder", $("#example-three").text())
    .text("");
}

4. Remove the blue glow

All WebKit browsers, Firefox 3.6, and Opera 10 all put a glowing blue border around textareas when they are in focus. You can remove it from the WebKit browsers like this:

textarea {
  outline: none;
}

You could apply it to the :focus style as well, but it works either way. I have not yet found a way to remove it from either Firefox or Opera, but -moz-outline-style was about as far as I tested.

REMINDER: The blue glow is becoming a strong standard and breaking that standard is typically a bad thing for your users. If you do it, you should have a darn compelling reason to as well as a similarly strong :focus style.

5. Remove resize handle

WebKit browsers attached a little UI element to the bottom right of text areas that users can use to click-and-drag to resize a textarea. If for whatever reason you want to remove that, CSS is all it takes:

textarea {
  resize: none;
}

6. Add resize handle

jQuery UI has a resizeable interaction that can be used on textareas. It works in all browsers and overrides the WebKit native version, because this version has all kinds of fancy stuff (like callbacks and animation).

To use it, load jQuery and jQuery UI on your page and at its most basic level you call it like this:

$("textarea").resizable();

7. Auto-resize to fit content

James Padolsey has a super nice jQuery script for auto resizing textareas. It works just how you likely hope it does. The textarea starts out a normal reasonable size. As you type more and more content, the textarea expands to include all of that text, rather than triggering a scrollbar as is the default.

The plugin has a variety of options, but at its simplest you just load jQuery, the plugin file, and call it like this:

$('textarea').autoResize();

8. Nowrap

To prevent text from wrapping normally in CSS, you use #whatever { white-space: nowrap; }. But for whatever reason, that doesn’t work with textareas. If you want to be able to type into textareas and would rather lines do not break until you press return/enter (a horizontal scrollbar is triggered instead), you’ll have to use the wrap="off" attribute.

<textarea wrap="off" cols="30" rows="5"></textarea>

9. Remove default scrollbars in Internet Explorer

IE puts a vertical scrollbar by default on all textareas. You can hid it with overflow: hidden, but then you don’t get any scrollbars at all when you expand. Thankfully auto overflow works to remove the scrollbar but still put them back when needed.

textarea {
  overflow: auto;
}

All the above examples can be seen here.

Translate your content

This is perhaps the most obvious but also the most important tip. English is arguably the most commonly used language internationally, but it still serves as a native tongue for only about 20% of the world’s population. Clearly, an English-only website will be inaccessible to a huge percentage of your potential online audience of 1.8 billion people.

There are various ways to translate your content and the method you choose may reflect budget and time constraints. The easiest way is to add a translation widget such as Google Translate or Babelfish to your site, allowing visitors to translate text to the language of their choice. Remember that any text embedded in Flash files won’t be translated – which is (yet another) a good argument against using too much Flash.

If you’re confident in using inline functions, you can build inline translation code into the site using Ajax, in connection with geolocation, to facilitate a smooth immersive translation process that directs the visitor to the correct language version, as determined by where their ISP is hosted.

If you do use machine translation, try to make your original content as simple and direct as possible and avoid specific cultural references, as these will invariably not translate well.

If budget allows, having your copy professionally translated is the optimum choice. Using a native speaker from the target market will ensure that meaning and nuances will carry over to your translated site and any linguistic or cultural mistakes can be avoided.

Use horizontal navigation bars

Not all languages read from left to right like English. Scripts such as Arabic and Hebrew read from right to left. While CSS makes it easy to flip a vertical navigation bar (which would normally be located on the left-hand side for a left-to-right language) and script direction from one side to the other, using a horizontal bar located across the top of the page will add a sense of continuity and cohesive design to localized versions of your site.

Use Unicode UTF-8

Unicode UTF-8 is the ideal character encoding tool. Compatible with over 90 different written languages or scripts, it’s also supported by all the major browsers. Even if you see no need for a localized site in Arabic or Simplified Chinese right now, using UTF-8 will give you the flexibility to create one in the future and it also incorporates all the additional characters from extended Latin alphabets (such as the German Ä, Ö, Ü and ß).

Bear in mind that some scripts and languages will take up more space than others to convey the same information and this may affect your page design.

Use appropriate colours

The use of colours can enhance a site’s visual appeal and help convey a theme or emotion, but some colours have different connotations in different cultures. White, for example, can signify marriage in the west but is associated with death and mourning in much of the east.

Tailor your design to the market

Some cultures (such as Japan and China) can be defined as ‘high context’ cultures. These cultures have a tendency to draw information from context and situation. ‘Low context’ cultures (including Germany, Scandinavia and North America) tend to look for explicitly worded and expressed information. In terms of website design, this means that sites with a more visual and immersive feel may be better received in high context cultures and sites with concise, clear layouts and text will appeal more to low context cultures. As an example, take a look at Nokia’s clearly structured and information-heavy German site, with prices and products listed on the front page, and compare it to the more visually oriented Chinese version.

Nokia’s Chinese site

Nokia’s German site

Localize your SEO

There’s little point having a beautifully designed series of websites which are accessible to a range of different cultures if nobody can find them. SEO keywords can vary tremendously from location to location so don’t just translate your keywords directly. A little research may reveal that colloquialisms, alternative terms or even misspellings are more commonly used in your new target market. Research keywords not only on the local versions of search giants like Google but also on any major local competitors such as Baidu (the leading search engine in China).

Note from the editor

Christian has written for a number of other blogs on this same subject, so if are very interested in this, check out his other articles:

• Design for the World: Cross Cultural Web Design
• Tips and Thoughts on Cross-Cultural Global Web Design
• Building A Cross-Cultural Web Design For A Wider Audience

I’m sure it’s partly me getting better at JavaScript, but I found the API quite well done and easy to work with. For one thing, it’s fully evented. That means you can attach event listeners to different thing, like the map itself or things inside the map. A simple example would be if a marker is clicked, you can change the zoom level of the map, change information shown elsewhere on the page, or really anything else you might want to do with JavaScript.

Not only is it evented for dealing with things inside the map, but the objects you used to create the map and stuff inside it are full of methods for controlling them. This makes it easy to control the map with events that happen elsewhere on your page.

I decided to play with it a little and try to build something.

View Demo Download Files

I used jQuery to help out, but that’s definitely not required.

I created a list of locations in an unordered list. Each list item had HTML5 data attributes containing the latitude and longitude of it. It also contained a title and long and short descriptions.

<li data-geo-lat="41.9786" data-geo-long="-87.9047">
  <h3>O'Hare Airport</h3>
  <p>Flights n' stuff</p>
  <p class="longdesc"><strong>About:</strong> O'Hare International Airport has been voted the "Best Airport in North America" for 10 years by two separate sources: Readers of the U.S. Edition of Business Traveler Magazine (1998-2003) and Global Traveler Magazine (2004-2007). Travel and Leisure magazine's 2009 "America's Favorite Cities" ranked Chicago's Airport System (O'Hare and Midway) the second-worst for delays, New York City's airport system (JFK, Newark Liberty, and LaGuardia) being the first.</p>
</li>

When one of these list items is hovered over, I apply a “hover” class to deal with styling, “pan” the map to the new coordinates, and fill out the right area with more information.

It’s all fairly straight forward and further commented to clarify. Adding/editing points is as simple as changing coordinates and text right in the HTML part.

Idea

The idea came from this website which I found in a tweet by ilovetypography.