Daily Link Aggregating from the Best Design & Showcase Sites
14,753 Links to Search From

Miguel Camacho

Posted by 365 Awesome Designers - 3 hours ago

Moonstone Interactive

Posted by CSS Mania - 4 hours ago

Chanty – Team Chat

Posted by CSS Mania - 4 hours ago

B&O PLAY Spring/Summer 2017

Posted by CSS Design Awards - 1 day ago
A new beginning Introducing Spring Summer 2017 collection

Sharjah Art Foundation

Posted by Site Inspire - 2 days ago

View | Direct link

Big Mamma

Posted by Site Inspire - 2 days ago

View | Direct link

Pictoplasma / 17

Posted by Featured / by - 3 days ago
Pictoplasma 17 conference & festival of contemporary character design. Upcoming: May 10-14 ndlr: Animation by Eran Hillelli

Expedia: VisitBritain

Posted by Awwwards - 3 days ago
UNIT9 partnered with 180LA on their series of tongueincheek infomercials to create a unique web and mobile experience


Posted by Site Inspire - 4 days ago

View | Direct link

Bureau for Visual Affairs

Posted by Site Inspire - 4 days ago

View | Direct link

Rifayet Uday

Posted by 365 Awesome Designers - 4 hours ago


Posted by CSS Mania - 4 hours ago

Popular design news of the week: March 20, 2017 – March 26, 2017

Posted by Web Designer Depot - 11 hours ago
Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.  The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, […]

Erminando Aliaj

Posted by Awwwards - 1 day ago
Someones got the look he has got the eye. A talented artist and an emerging photographer.

Ricciardo for PM

Posted by One Page Love - 2 days ago
Interactive One Pager encouraging Australian voters to get involved at MiVote via a fun marketing campaign angled at voting for F1's Daniel Ricciardo as PM. Awesome to read the build notes on the stealth timeline and respect on the pro-bono work for a great cause.


Posted by Site Inspire - 2 days ago

View | Direct link

eBay Redesigns Its Homepage (Again)

Posted by Web Designer Depot - 3 days ago
They say that three time’s the charm. Maybe for eBay, two is all that it will take when it comes to its homepage design. In late 2013, the auction site last attempted a homepage redesign that wasn’t all that user-friendly. While the then-redesign was supposed to surface relevant goods based on the interests and browsing […]

Entice Energy

Posted by css Drive - Gallery - 3 days ago


Posted by One Page Love - 4 days ago
Slick One Pager announcing Perspective, a new machine learning API project by the Google Jigsaw team. The Single Page site features a gorgeous interactive slider demonstrating exactly how the API filters and moderates content. Further down is another interactive blank document that rates your inputted text in real time. Interactive content, as shown here, really […]

Raw & Rendered

Posted by Featured / by - 4 days ago
Adorn some office or home walls with Raw & Rendered aka amazing renders. Joey Camacho is a freelance 3D motion and graphic designer. _______ Intricacies of details as modern art meshed together. Beautiful.

Drew Endly

Posted by 365 Awesome Designers - 4 hours ago

Big Omaha 2017

Posted by CSS Mania - 4 hours ago

Weber Genesis II

Posted by Awwwards - 11 hours ago
On this state-of-the-art product site, you can get up-close with the glorious Genesis II gas grill in real-time 3D, courtesy of Weber and WebGL. Introduced by POV films, the site lets you take your own perspective and 'reflect' on Weber's shiny new range in all its glory.

Adidas — Climazone

Posted by Site Inspire - 2 days ago

View | Direct link

Héloïse Thibodeau Architecte

Posted by CSS Design Awards - 2 days ago
The goal of HTA is to put forward the outmost standards in excellence in design, while maintaining superior norms in construction.

Taking Device Orientation for a Spin

Posted by 24 Ways - 3 days ago

Drew McLellan wraps up our 2016 season with a look at the HTML5 Device Orientation API and how an annoying physical interaction can become an annoying virtual one. Like the silver sixpence in your figgy pudding, there’s treasure to be found in our browsers, so dig in.

When The Police sang “Don’t Stand So Close To Me” they weren’t talking about using a smartphone to view a panoramic image on Facebook, but they could have been. For years, technology has driven relentlessly towards devices we can carry around in our pockets, and now that we’re there, we’re expected to take the thing out of our pocket and wave it around in front of our faces like a psychotic donkey in search of its own dangly carrot.

But if you can’t beat them, join them.

A brave new world

A couple of years back all sorts of specs for new HTML5 APIs sprang up much to our collective glee. Emboldened, we ran a few tests and found they basically didn’t work in anything and went off disheartened into the corner for a bit of a sob.

Turns out, while we were all busy boohooing, those browser boffins have actually being doing some work, and lo and behold, some of these APIs are even half usable. Mostly literally half usable—we’re still talking about browsers, after all.

Now, of course they’re all a bit JavaScripty and are going to involve complex methods and maths and science and probably about a thousand dependancies from Github that will fall out of fashion while we’re still trying to locate the documentation, right? Well, no!

So what if we actually wanted to use one of these APIs, say to impress our friends with our ability to make them wave their phones in front of their faces (because no one enjoys looking hapless more than the easily-technologically-impressed), how could we do something like that? Let’s find out.

The Device Orientation API

The phone-wavy API is more formally known as the DeviceOrientation Event Specification. It does a bunch of stuff that basically doesn’t work, but also gives us three values that represent orientation of a device (a phone, a tablet, probably not a desktop computer) around its x, y and z axes. You might think of it as pitch, roll and yaw if you like to spend your weekends wearing goggles and a leather hat.

The main way we access these values is through an event listener, which can inform our code every time the value changes. Which is constantly, because you try and hold a phone still and then try and hold the Earth still too.

The API calls those pitch, roll and yaw values alpha, beta and gamma. Chocks away:

window.addEventListener('deviceorientation', function(e) {

If you look at this test page on your phone, you should be able to see the numbers change as you twirl the thing around your body like the dance partner you never had. Wrist strap recommended.

One important note

Like may of these newfangled APIs, Device Orientation is only available over HTTPS. We’re not allowed to have too much fun without protection, so make sure that you’re working on a secure line. I’ve found a quick and easy way to share my local dev environment over TLS with my devices is to use an ngrok tunnel.

ngrok http -host-header=rewrite mylocaldevsite.dev:80

ngrok will then set up a tunnel to your dev site with both HTTP and HTTPS URL options. You, of course, want the HTTPS option.

Right, where were we?

Make something to look at

It’s all well and good having a bunch of numbers, but they’re no use unless we do something with them. Something creative. Something to inspire the generations. Or we could just build that Facebook panoramic image viewer thing (because most of us are familiar with it and we’re not trying to be too clever here). Yeah, let’s just build one of those.

Our basic framework is going to be similar to that used for an image carousel. We have a container, constrained in size, and CSS overflow property set to hidden. Into this we place our wide content and use positioning to move the content back and forth behind the ‘window’ so that the part we want to show is visible.

Here it is mocked up with a slider to set the position. When you release the slider, the position updates. (This actually tests best on desktop with your window slightly narrowed.)

The details of the slider aren’t important (we’re about to replace it with phone-wavy goodness) but the crucial part is that moving the slider results in a function call to position the image. This takes a percentage value (0-100) with 0 being far left and 100 being far right (or ‘alt-nazi’ or whatever).

var position_image = function(percent) {
    var pos = (img_W / 100)*percent;
    img.style.transform = 'translate(-'+pos+'px)'; 

All this does is figure out what that percentage means in terms of the image width, and set the transform: translate(…); CSS property to move the image. (We use translate because it might be a bit faster to animate than left/right positioning.)

Ok. We can now read the orientation values from our device, and we can programatically position the image. What we need to do is figure out how to convert those raw orientation values into a nice tidy percentage to pass to our function and we’re done. (We’re so not done.)

The maths bit

If we go back to our raw values test page and make-believe that we have a fascinating panoramic image of some far-off beach or historic monument to look at, you’ll note that the main value that is changing as we swing back and forth is the ‘alpha’ value. That’s the one we want to track.

As our goal here is hey, these APIs are interesting and fun and not let’s build the world’s best panoramic image viewer, we’ll start by making a few assumptions and simplifications:

  • When the image loads, we’ll centre the image and take the current nose-forward orientation reading as the middle.
  • Moving left, we’ll track to the left of the image (lower percentage).
  • Moving right, we’ll track to the right (higher percentage).
  • If the user spins round, does cartwheels or loads the page then hops on a plane and switches earthly hemispheres, they’re on their own.


When the page loads, the initial value of alpha gives us our nose-forward position. In Safari on iOS, this is normalised to always be 0, whereas most everywhere else it tends to be bound to pointy-uppy north. That doesn’t really matter to us, as we don’t know which direction the user might be facing in anyway — we just need to record that initial state and then use it to compare any new readings.

var initial_position = null;

window.addEventListener('deviceorientation', function(e) {
    if (initial_position === null) {
        initial_position = Math.floor(e.alpha);

    var current_position = initial_position - Math.floor(e.alpha);

(I’m rounding down the values with Math.floor() to make debugging easier - we’ll take out the rounding later.)

We get our initial position if it’s not yet been set, and then calculate the current position as a difference between the new value and the stored one.

These values are weird

One thing you need to know about these values, is that they range from 0 to 360 but then you also get weird left-of-zero values like -2 and whatever. And they wrap past 360 back to zero as you’d expect if you do a forward roll.

What I’m interested in is working out my rotation. If 0 is my nose-forward position, I want a positive value as I turn right, and a negative value as I turn left. That puts the awkward 360-tipping point right behind the user where they can’t see it.

var rotation  = current_position;
if (current_position > 180) rotation = current_position-360;

Which way up?

Since we’re talking about orientation, we need to remember that the values are going to be different if the device is held in portrait on landscape mode. See for yourself - wiggle it like a steering wheel and you get different values. That’s easy to account for when you know which way up the device is, but in true browser style, the API for that bit isn’t well supported. The best I can come up with is:

var screen_portrait = false;
if (window.innerWidth < window.innerHeight) {
    screen_portrait = true;

It works. Then we can use screen_portrait to branch our code:

if (screen_portrait) {
        if (current_position > 180) rotation = current_position-360;
} else {
        if (current_position < -180) rotation = 360+current_position;

Here’s the code in action so you can see the values for yourself. If you change screen orientation you’ll need to refresh the page (it’s a demo!).

Limiting rotation

Now, while the youth of today are rarely seen without a phone in their hands, it would still be unreasonable to ask them to spin through 360° to view a photo. Instead, we need to limit the range of movement to something like 60°-from-nose in either direction and normalise our values to pan the entire image across that 120° range. -60 would be full-left (0%) and 60 would be full-right (100%).

If we set max_rotation = 60, that code ends up looking like this:

if (rotation > max_rotation) rotation = max_rotation;
if (rotation < (0-max_rotation)) rotation = 0-max_rotation;

var percent = Math.floor(((rotation + max_rotation)/(max_rotation*2))*100);

We should now be able to get a rotation from -60° to +60° expressed as a percentage. Try it for yourself.

The big reveal

All that’s left to do is pass that percentage to our image positioning function and would you believe it, it might actually work.


You can see the final result and take it for a spin. Literally.

So what have we made here? Have we built some highly technical panoramic image viewer to aid surgeons during life-saving operations using only JavaScript and some slightly questionable mathematics? No, my friends, we have not. Far from it.

What we have made is progress. We’ve taken a relatively newly available hardware API and a bit of simple JavaScript and paired it with existing CSS knowledge and made something that we didn’t have this morning. Something we probably didn’t even want this morning. Something that if you take a couple of steps back and squint a bit might be a prototype for something vaguely interesting. But more importantly, we’ve learned that our browsers are just a little bit more capable than we thought.

The web platform is maturing rapidly. There are new, relatively unexplored APIs for doing all sorts of crazy thing that are often dismissed as the preserve of native apps. Like some sort of app marmalade. Poppycock.

The web is an amazing, exciting place to create things. All it takes is some base knowledge of the fundamentals, a creative mind and a willingness to learn. We have those! So let’s create things.

About the author

Drew McLellan is lead developer on your favourite content management systems, Perch and Perch Runway. He is Director and Senior Developer at edgeofmyseat.com in Bristol, England, and is formerly Group Lead at the Web Standards Project. When not publishing 24 ways, Drew keeps a personal site covering web development issues and themes, takes photos, tweets a lot and tries to stay upright on his bicycle.

More articles by Drew

Meet the trio behind ComicKult

Posted by One Page Love - 3 days ago
I got hold of the ComicKult team to find out more about the design, the build and the brand. We rapped about first impressions, obstacles, development tools, MVPs and of course comics!

CSS Writing Modes

Posted by 24 Ways - 4 days ago

Jen Simmons points us in the direction of a useful but less well known CSS feature that becomes increasingly important when designing page layouts for a global audience. Like the wise men following the Star of Bethlehem, sometimes the best direction is given to us, not chosen.

Since you may not have a lot of time, I’m going to start at the end, with the dessert.

You can use a little-known, yet important and powerful CSS property to make text run vertically. Like this.

Or instead of running text vertically, you can layout a set of icons or interface buttons in this way. Or, of course, with anything on your page.

The CSS I’ve applied makes the browser rethink the orientation of the world, and flow the layout of this element at a 90° angle to “normal”. Check out the live demo, highlight the headline, and see how the cursor is now sideways.

See the Pen Writing Mode Demo — Headline by Jen Simmons (@jensimmons) on CodePen.

The code for accomplishing this is pretty simple.

h1 { 
  writing-mode: vertical-rl;

That’s all it takes to switch the writing mode from the web’s default horizontal top-to-bottom mode to a vertical right-to-left mode. If you apply such code to the html element, the entire page is switched, affecting the scroll direction, too.

In my example above, I’m telling the browser that only the h1 will be in this vertical-rl mode, while the rest of my page stays in the default of horizontal-tb.

So now the dessert course is over. Let me serve up this whole meal, and explain the the CSS Writing Mode Specification.

Why learn about writing modes?

There are three reasons I’m teaching writing modes to everyone—including western audiences—and explaining the whole system, instead of quickly showing you a simple trick.

  1. We live in a big, diverse world, and learning about other languages is fascinating. Many of you lay out pages in languages like Chinese, Japanese and Korean. Or you might be inspired to in the future.

  2. Using writing-mode to turn bits sideways is cool. This CSS can be used in all kinds of creative ways, even if you are working only in English.

  3. Most importantly, I’ve found understanding Writing Modes incredibly helpful when understanding Flexbox and CSS Grid. Before I learned Writing Mode, I felt like there was still a big hole in my knowledge, something I just didn’t get about why Grid and Flexbox work the way they do. Once I wrapped my head around Writing Modes, Grid and Flexbox got a lot easier. Suddenly the Alignment properties, align-* and justify-*, made sense.

Whether you know about it or not, the writing mode is the first building block of every layout we create. You can do what we’ve been doing for 25 years – and leave your page set to the default left-to-right direction, horizontal top-to-bottom writing mode. Or you can enter a world of new possibilities where content flows in other directions.

CSS properties

I’m going to focus on the CSS writing-mode property in this article. It has five possible options:

  writing-mode: horizontal-tb;
  writing-mode: vertical-rl;
  writing-mode: vertical-lr;
  writing-mode: sideways-rl;
  writing-mode: sideways-lr;

The CSS Writing Modes Specification is designed to support a wide range of written languages in all our human and linguistic complexity. Which—spoiler alert—is pretty insanely complex. The global evolution of written languages has been anything but simple.

So I’ve got to start with explaining some basic concepts of web page layout and writing systems. Then I can show you what these CSS properties do.

Inline Direction, Block Direction, and Character Direction

In the world of the web, there’s a concept of ‘block’ and ‘inline’ layout. If you’ve ever written display: block or display: inline, you’ve leaned on these concepts.

In the default writing mode, blocks stack vertically starting at the top of the page and working their way down. Think of how a bunch of block-levels elements stack—like a bunch of a paragraphs—that’s the block direction.

Inline is how each line of text flows. The default on the web is from left to right, in horizontal lines. Imagine this text that you are reading right now, being typed out one character at a time on a typewriter. That’s the inline direction.

The character direction is which way the characters point. If you type a capital “A” for instance, on which side is the top of the letter? Different languages can point in different directions. Most languages have their characters pointing towards the top of the page, but not all.

Put all three together, and you start to see how they work as a system.

The default settings for the web work like this.

Now that we know what block, inline, and character directions mean, let’s see how they are used in different writing systems from around the world.

The four writing systems of CSS Writing Modes

The CSS Writing Modes Specification handles all the use cases for four major writing systems; Latin, Arabic, Han and Mongolian.

Latin-based systems

One writing system dominates the world more than any other, reportedly covering about 70% of the world’s population.

The text is horizontal, running from left to right, or LTR. The block direction runs from top to bottom.

It’s called the Latin-based system because it includes all languages that use the Latin alphabet, including English, Spanish, German, French, and many others. But there are many non-Latin-alphabet languages that also use this system, including Greek, Cyrillic (Russian, Ukrainian, Bulgarian, Serbian, etc.), and Brahmic scripts (Devanagari, Thai, Tibetan), and many more.

You don’t need to do anything in your CSS to trigger this mode. This is the default.

Best practices, however, dictate that you declare in your opening <html> element which language and which direction (LTR or RTL) you are using. This website, for instance, uses <html lang='en-gb' dir='ltr'> to let the browser know this content is published in Great Britian’s version of English, in a left to right direction.

Arabic-based systems

Arabic, Hebrew and a few other languages run the inline direction from right to left. This is commonly known as RTL.

Note that the inline direction still runs horizontally. The block direction runs from top to bottom. And the characters are upright.

It’s not just the flow of text that runs from right to left, but everything about the layout of the website. The upper right-hand corner is the starting position. Important things are on the right. The eyes travel from right to left. So, typically RTL websites use layouts that are just like LTR websites, only flipped.

On websites that support both LTR and RTL, like the United Nations’ site at un.org, the two layouts are mirror images of each other.

For many web developers, our experiences with internationalization have focused solely on supporting Arabic and Hebrew script.

CSS layout hacks for internationalization & RTL

To prepare an LTR project to support RTL, developers have had to create all sorts of hacks. For example, the Drupal community started a convention of marking every margin-left and -right, every padding-left and -right, every float: left and float: right with the comment /* LTR */. Then later developers could search for each instance of that exact comment, and create stylesheets to override each left with right, and vice versa. It’s a tedious and error prone way to work. CSS itself needed a better way to let web developers write their layout code once, and easily switch language directions with a single command.

Our new CSS layout system does exactly that. Flexbox, Grid and Alignment use start and end instead of left and right. This lets us define everything in relationship to the writing system, and switch directions easily. By writing justify-content: flex-start, justify-items: end, and eventually margin-inline-start: 1rem we have code that doesn’t need to be changed.

This is a much better way to work. I know it can be confusing to think through start and end as replacements for left and right. But it’s better for any multiligual project, and it’s better for the web as a whole.

Sadly, I’ve seen CSS preprocessor tools that claim to “fix” the new CSS layout system by getting rid of start and end and bringing back left and right. They want you to use their tool, write justify-content: left, and feel self-righteous. It seems some folks think the new way of working is broken and should be discarded. It was created, however, to fulfill real needs. And to reflect a global internet. As Bruce Lawson says, WWW stands for the World Wide Web, not the Wealthy Western Web. Please don’t try to convince the industry that there’s something wrong with no longer being biased towards western culture. Instead, spread the word about why this new system is here.

Spend a bit of time drilling the concept of inline and block into your head, and getting used to start and end. It will be second nature soon enough.

I’ve also seen CSS preprocessors that let us use this new way of thinking today, even as all the parts aren’t fully supported by browsers yet. Some tools let you write text-align: start instead of text-align: left, and let the preprocessor handle things for you. That is terrific, in my opinion. A great use of the power of a preprocessor to help us switch over now.

But let’s get back to RTL.

How to declare your direction

You don’t want to use CSS to tell the browser to switch from an LTR language to RTL. You want to do this in your HTML. That way the browser has the information it needs to display the document even if the CSS doesn’t load.

This is accomplished mainly on the html element. You should also declare your main language. As I mentioned above, the 24 ways website is using <html lang='en-gb' dir='ltr'> to declare the LTR direction and the use of British English. The UN Arabic website uses <html lang='ar' dir='rtl'>to declare the site as an Arabic site, using a RTL layout.

Things get more complicated when you’ve got a page with a mix of languages. But I’m not going to get into all of that, since this article is focused on CSS and layouts, not explaining everything about internationalization.

Let me just leave direction here by noting that much of the heavy work of laying out the characters which make up each word is handled by Unicode. If you are interested in learning more about LTR, RTL and bidirectional text, watch this video: Introduction to Bidirectional Text, a presentation by Elika Etemad.

Meanwhile, let’s get back to CSS.

The writing mode CSS for Latin-based and Arabic-based systems

For both of these systems—Latin-based and Arabic-based, whether LTR or RTL—the same CSS property applies for specifying the writing mode: writing-mode: horizontal-tb. That’s because in both systems, the inline text flow is horizontal, while the block direction is top-to-bottom. This is expressed as horizontal-tb.

horizontal-tb is the default writing mode for the web, so you don’t need to specify it unless you are overriding something else higher up in the cascade. You can just imagine that every site you’ve ever built came with:

html {
  writing-mode: horizontal-tb;

Now let’s turn our attention to the vertical writing systems.

Han-based systems

This is where things start to get interesting.

Han-based writing systems include CJK languages, Chinese, Japanese, Korean and others. There are two options for laying out a page, and sometimes both are used at the same time.

Much of CJK text is laid out like Latin-based languages, with a horizontal top-to-bottom block direction, and a left-to-right inline direction. This is the more modern way to doing things, started in the 20th century in many places, and further pushed into domination by the computer and later the web.

The CSS to do this bit of the layouts is the same as above:

section {
  writing-mode: horizontal-tb;

Or, you know, do nothing, and get that result as a default.

Alternatively Han-based languages can be laid out in a vertical writing mode, where the inline direction runs vertically, and the block direction goes from right to left.

See both options in this diagram:

Note that the horizontal text flows from left to right, while the vertical text flows from right to left. Wild, eh?

This Japanese issue of Vogue magazine is using a mix of writing modes. The cover opens on the left spine, opposite of what an English magazine does.

This page mixes English and Japanese, and typesets the Japanese text in both horizontal and vertical modes. Under the title “Richard Stark” in red, you can see a passage that’s horizontal-tb and LTR, while the longer passage of text at the bottom of the page is typeset vertical-rl. The red enlarged cap marks the beginning of that passage. The long headline above the vertical text is typeset LTR, horizontal-tb.

The details of how to set the default of the whole page will depend on your use case. But each element, each headline, each section, each article can be marked to flow the opposite of the default however you’d like.

For example, perhaps you leave the default as horizontal-tb, and specify your vertical elements like this:

div.articletext {
  writing-mode: vertical-rl;

Or alternatively you could change the default for the page to a vertical orientation, and then set specific elements to horizontal-tb, like this:

html { 
  writing-mode: vertical-rl;
h2, .photocaptions, section {
  writing-mode: horizontal-tb;

If your page has a sideways scroll, then the writing mode will determine whether the page loads with upper left corner as the starting point, and scroll to the right (horizontal-tb as we are used to), or if the page loads with the upper right corner as the starting point, scrolling to the left to display overflow. Here’s an example of that change in scrolling direction, in a CSS Writing Mode demo by Chen Hui Jing. Check out her demo — you can switch from horizontal to vertical writing modes with a checkbox and see the difference.

Mongolian-based systems

Now, hopefully so far all of this kind of makes sense. It might be a bit more complicated than expected, but it’s not so hard. Well, enter the Mongolian-based systems.

Mongolian is also a vertical script language. Text runs vertically down the page. Just like Han-based systems. There are two major differences. First, the block direction runs the other way. In Mongolian, block-level elements stack from left to right.

Here’s a drawing of how Wikipedia would look in Mongolian if it were laid out correctly.

Perhaps the Mongolian version of Wikipedia will be redone with this layout.

Now you might think, that doesn’t look so weird. Tilt your head to the left, and it’s very familiar. The block direction starts on the left side of the screen and goes to the right. The inline direction starts on the top of the page and moves to the bottom (similar to RTL text, just turned 90° counter-clockwise). But here comes the other huge difference. The character direction is “upside down”. The top of the Mongolian characters are not pointing to the left, towards the start edge of the block direction. They point to the right. Like this:

Now you might be tempted to ignore all this. Perhaps you don’t expect to be typesetting Mongolian content anytime soon. But here’s why this is important for everyone — the way Mongolian works defines the results writing-mode: vertical-lr. And it means we cannot use vertical-lr for typesetting content in other languages in the way we might otherwise expect.

If we took what we know about vertical-rl and guessed how vertical-lr works, we might imagine this:

But that’s wrong. Here’s how they actually compare:

See the unexpected situation? In both writing-mode: vertical-rl and writing-mode: vertical-lr latin text is rotated clockwise. Neither writing mode let’s us rotate text counter-clockwise.

If you are typesetting Mongolian content, apply this CSS in the same way you would apply writing-mode to Han-based writing systems. To the whole page on the html element, or to specific pages of the page like this:

section {
  writing-mode: vertical-lr;

Now, if you are using writing-mode for a graphic design effect on a language that is otherwise typesets horizontally, I don’t think writing-mode: vertical-lr is useful. If the text wraps onto two lines, it stacks in a very unexpected way. So I’ve sort of obliterated it from my toolkit. I find myself using writing-mode: vertical-rl a lot. And never using -lr. Hm.

Writing modes for graphic design

So how do we use writing-mode to turn English headlines sideways? We could rely on transform: rotate()

Here are two examples, one for each direction. (By the way, each of these demos use CSS Grid for their overall layout, so be sure to test them in a browser that supports CSS Grid, like Firefox Nightly.)

In this demo 4A, the text is rotated clockwise using this code:

h1 {
  writing-mode: vertical-rl;

In this demo 4B, the text is rotated counter-clockwise using this code:

h1 {
  writing-mode: vertical-rl;
  transform: rotate(180deg);
  text-align: right;

I use vertical-rl to rotate the text so that it takes up the proper amount of space in the overall flow of the layout. Then I rotate it 180° to spin it around to the other direction. And then I use text-align: right to get it to rise up to the top of it’s container. This feels like a hack, but it’s a hack that works.

Now what I would like to do instead is use another CSS value that was designed for this use case — one of the two other options for writing mode.

If I could, I would lay out example 4A with:

h1 {
  writing-mode: sideways-rl;

And layout example 4B with:

h1 {
  writing-mode: sideways-lr;

The problem is that these two values are only supported in Firefox. None of the other browsers recognize sideways-*. Which means we can’t really use it yet.

In general, the writing-mode property is very well supported across browsers. So I’ll use writing-mode: vertical-rl for now, with the transform: rotate(180deg); hack to fake the other direction.

There’s much more to what we can do with the CSS designed to support multiple languages, but I’m going to stop with this intermediate introduction.

If you do want a bit more of a taste, look at this example that adds text-orientation: upright; to the mix — turning the individual letters of the latin font to be upright instead of sideways.

It’s this demo 4C, with this CSS applied:

h1 {
  writing-mode: vertical-rl;
  text-orientation: upright;
  text-transform: uppercase;
  letter-spacing: -25px;

You can check out all my Writing Modes demos at labs.jensimmons.com/#writing-modes.

I’ll leave you with this last demo. One that applies a vertical writing mode to the sub headlines of a long article. I like how small details like this can really bring a fresh feeling to the content.

See the Pen Writing Mode Demo — Article Subheadlines by Jen Simmons (@jensimmons) on CodePen.

About the author

Dubbed “the Terry Gross of the tech industry,” Jen Simmons is the host and executive producer of The Web Ahead. Her in-depth interviews explain emerging technology and predict the future of the web — and won the 2015 Net Award for Podcast of the Year.

Jen is a Designer and Developer Advocate at Mozilla, where she advocates for web standards and researches the coming revolution in graphic design on the web. She’s spoken at events including SXSW, An Event Apart, Fluent, Generate, Future of Web Design, and Respond. Her talk, Modern Layouts: Getting Out of Our Ruts, was awarded Best Conference Presentation at CSS Dev Conf 2014.

Jen launched her first client website in 1998 and spent years making sites for small businesses, arts organizations, and creative individuals. Her more well-known clients include CERN, the W3C, Google, Drupal, Temple University, and the Annenberg Foundation. Jen earned a MFA in Film and Media Arts from Temple University. She lives in New York City.

More articles by Jen


Posted by Site Inspire - 4 days ago

View | Direct link


Posted by Site Inspire - 4 days ago

View | Direct link

Matcha Kari

Posted by CSS Mania - 4 hours ago

Mason & Associates

Posted by CSS Mania - 4 hours ago

Big Omaha 2017

Posted by CSS Design Awards - 12 hours ago
Big Omaha is an innovation and entrepreneurship conference held in Omaha, NE. Each year, there is a new visual theme.

Nordiva Tours

Posted by css Drive - Gallery - 2 days ago

This is Bears Ears

Posted by Awwwards - 2 days ago
Bears Ears is an interactive film from Patagonia Explore experience and take action to defend our newest National Monument

A Beginner’s Guide to Designing Conversational Interfaces

Posted by Web Designer Depot - 3 days ago
Whether you love them or hate them, conversational interfaces have started making a significant impact in the business/brand communication landscape. Though many businesses have realized that conversational interfaces are likely to cause a major shift in brand communication there are many who are skeptical about CIs.  CIs have limitations, but they are here to stay and […]


Posted by CSS Design Awards - 3 days ago
Designer and manufacturer of woven, yarn dyed, finished and embroidered fabrics for upholstery and furnishing applications.


Posted by Site Inspire - 4 days ago

View | Direct link

The Fast Way from Freelance Designer to Design Firm

Posted by Web Designer Depot - 4 days ago
Picture it: New York City, 2010; you’re working full-time as a digital designer for one of the world’s largest advertising agencies. The paycheck is steady, the hours are (somewhat) flexible, and you really never have to take work home with you. To sweeten the pot, there are plenty of perks–free swag from clients and swanky […]

Preparing to Be Badass Next Year

Posted by 24 Ways - 4 days ago

Meri Williams sets her sights on self improvement in 2017 with a guide to personal development. Like a good Christmas dinner, you can set a beautiful table, but unless you get the turkey prepared and into the oven, it’s never going to be ready to serve.

Once we’ve eaten our way through the holiday season, people will start to think about new year’s resolutions. We tend to focus on things that we want to change… and often things that we don’t like about ourselves to “fix”. We set rules for ourselves, or try to start new habits or stop bad ones. We focus in on things we will or won’t do.

For many of us the list of things we “ought” to be spending time on is just plain overwhelming – family, charity/community, career, money, health, relationships, personal development.

It’s kinda scary even just listing it out, isn’t it? I want to encourage you to think differently about next year.

The ever-brilliant Kathy Sierra articulates a better approach really well when talking about the attitude we should have to building great products. She tells us to think not about what the user will do with our product, but about what they are trying to achieve in the real world and how our product helps them to be badass1.

When we help the user be badass, then we are really making a difference.

I suppose this is one way of saying: focus not on what you will do, focus on what it will help you achieve. How will it help you be awesome?

In what ways do you want to be more badass next year?

A professional lens

Though of course you might want to focus in on health or family or charity or community or another area next year, many people will want to become more badass in their chosen career.

So let’s talk about a scaffold to help you figure out your professional / career development next year.

First up, an assumption: everyone wants to be awesome. Nobody gets up in the morning aiming to be crap at their job. Nobody thinks to themselves “Today I am aiming for just south of mediocre, and if I can mess up everybody else’s ability to do good work then that will be just perfect2”.

Ergo, you want to be awesome. So what does awesome look like?


The big trap that people fall into when think about their professional development is to immediately focus on the things that they aren’t good at. When you ask people “what do you want to work on getting better at next year?” they frequently gravitate to the things that they believe they are bad at.

Why is this a trap? Because if you focus all your time and energy on improving the areas that you suck at, you are going to end up middling at everything. Going from bad ? mediocre at a given skill / behaviour takes a bunch of time and energy. So if you spend all your time going from bad ? mediocre at things, what do you think you end up? That’s right, mediocre.

Mediocrity is not a great career goal, kids.

What do you already rock at?

The much better investment of time and energy is to go from good ? awesome. It often takes the same amount of relative time and energy, but wow the end result is better! So first, ask yourself and those who know you well what you are already pretty damn good at. Combat imposter syndrome by asking others.

Then figure out how to double down on those things. What does brilliant look like for a given skill? What’s the knowledge or practice that you need to level yourself up even further in that thing?

But what if I really really suck?

Admittedly, sometimes something you suck at really is holding you back. But it’s important to separate out weaknesses (just something you suck at) from controlling weaknesses (something you suck at that actually matters for your chosen career).

If skill x is just not an important thing for you to be good at, you may never need to care that you aren’t good at it. If your current role or the one you aspire to next really really requires you to be great at x, then it’s worth investing your time and energy (and possibly money too) getting better at it.

So when you look at the things that you aren’t good at, which of those are actually essential for success?

The right ratio

A good rule of thumb is to pick three things you are already good at to work on becoming awesome at and limit yourself to one weakness that you are trying to improve on. That way you are making sure that you get to awesome in areas where you already have an advantage, and limit the amount of time you are spending on going from bad ? mediocre.

Levelling up learning

So once you’ve figured out your areas you want to focus on next year, what do you actually decide to do?

Most of all, you should try to design your day-to-day work in a way that it is also an effective learning experience. This means making sure you have a good feedback loop – you get to try something, see if it works, learn from it, rinse and repeat.

It’s also about balance: you want to be challenged enough for work to be interesting, without it being so hard it’s frustrating. You want to do similar / the same things often enough that you get to learn and improve, without it being so repetitive that it’s boring.

Continuously getting better at things you are already good at is actually both easier and harder than it sounds. The advantage is that it’s pretty easy to add the feedback loop to make sure that you are improving; the disadvantage is that you’re already good at these skills so you could easily just “do” without ever stopping to reflect and improve. Build in time for personal retrospectives (“What went well? What didn’t? What one thing will I choose to change next time?”) and find a way of getting feedback from outside sources as well.

As for the new skills, it’s worth knowing that skill development follows a particular pattern:

We all start out unconsciously incompetent (we don’t know what to do and if we tried we’d unwittingly get it wrong), progress on to conscious incompetence (we now know we’re doing it wrong) then conscious competence (we’re doing it right but wow it takes effort and attention) and eventually get to unconscious competence (automatically getting it right).

Your past experiences and knowledge might let you move faster through these stages, but no one gets to skip them. Invest the time and remember you need the feedback loop to really improve.

What about keeping up?

Everything changes very fast in our industry. We need to invest in not falling behind, in keeping on top of what great looks like. There are a bunch of ways to do this, from reading blog posts, following links on Twitter, reading books to attending conferences or workshops, or just finding time to build things in new ways or with new technologies.

Which will work best for you depends on how you best learn. Do you prefer to swallow a book? Do you learn most by building or experimenting?

Whatever your learning style though, remember that there are three real needs:

  1. Scan the landscape (what’s changing, does it matter)
  2. Gain the knowledge or skills (get the detail)
  3. Apply the knowledge or skills (use it in reality)

When you remember that you need all three of these things it can help you get more of what you do.

For me personally, I use a combination of conferences and blogs / Twitter to scan the landscape. Half of what I want out of a conference is just a list of things to have on my radar that might become important. I then pick a couple of things to go read up on more (I personally learn most effectively by swallowing a book or spec or similar). And then I pick one thing at a time to actually apply in real life, to embed the skill / knowledge.

In summary

  1. Aim to be awesome (mediocrity is not a career goal).
  2. Figure out what you already rock at.
  3. Only care about stuff you suck at that matters for your career.
  4. Pick three things to go from good ? awesome and one thing to go from bad ? mediocre (or mediocre ? good) this year.
  5. Design learning into your daily work.
  6. Scan the landscape, learn new stuff, apply it for real.
  7. Be badass!

  1. She wrote a whole book about it. You should read it: Badass: Making Users Awesome ↩︎

  2. Before you argue too vehemently: I suppose some antisocial sociopathic bastards do exist. Identify them, and then RUN AWAY FAST AS YOU CAN #realtalk ↩︎

About the author

Meri is a geek, a manager, and a manager of geeks. She’s a CTO (these days at @MOO) and also runs micro-consultancy ChromeRose, helping digital & technical teams be brilliant. An alumna of Procter & Gamble and the Government Digital Service, she has had a career spanning development, project, programme & product management and more recently engineering & operations leadership. She’s led teams ranging in size from 30 to 300, mostly with folks spread across the world.

More articles by Meri


Posted by CSS Mania - 4 hours ago

Guardian Kingdom

Posted by CSS Mania - 4 hours ago

Comics of the week #384

Posted by Web Designer Depot - 1 day ago
Every week we feature a set of comics created exclusively for WDD. The content revolves around web design, blogging and funny situations that we encounter in our daily lives as designers. These great cartoons are created by Jerry King, an award-winning cartoonist who’s one of the most published, prolific and versatile cartoonists in the world […]

Patchwork Architecture.

Posted by cssdsgn - 2 days ago

Volleyball Canada

Posted by Site Inspire - 2 days ago

View | Direct link

&#$ by Playtype

Posted by Featured / by - 3 days ago
A few eloquent and minimal statements for my (and JF) desks using these mugs from Playtype. & my to do (wish) list is pretty long. _______ # he creates the most amazing music. _______ $ we need some of that for our projects. _______

Mécènes du sud

Posted by cssdsgn - 3 days ago


Posted by Site Inspire - 4 days ago

View | Direct link

Sacha Maric

Posted by Site Inspire - 4 days ago

View | Direct link


Posted by cssdsgn - 4 days ago