BrowserFIT

Coding with a Content-First approach means asking yourself (and whoever is in charge of the project) what is truly essencial in your project. Is striving to actually mean what you need to mean instead of pour some content into an already thought layout.

To accomplish that, there're some methods you can try:

1. Let go of lorem ipsum as soon as you can. (After all, it's "content-first", right?!)
2. Don't worry so much about the styles for now, add the mark-up to your content. (make sure your tags are meaningful and that you're not bloating your page with elements just to get some crazy shallow styling on)
3. Get feedback as much as you can. There's no one that knows better what the project should be communicating than the person who hired (or is supervising) you. So, as you set content priorities, double-check with them if you are getting the idea.

Content-first sure needs some adaptation, but it pays off really soon. (Just think about all the do-overs you'll be avoiding).

Remember Content is king.

Depending on perspective, Mobile-First can pass on as an analog expression for Content-First. That happens because they ought to be used in conjunction.

In a literal way, Mobile-First should be called "Small-First". It means that you start coding for the smallest view possible and expand progressively until you get the styles ready for every viewport sizes. As Stephen Hay once said:

1. Code for the smallest view;
2. Expand until it looks crappy;
3. Insert breakpoint;
4. Repeat.

An excellent tool to help you getting there is ish.

Full-comp layouts don't work well with RWD, mainly because they are static, and real RWD is fluid. There's a handfull of approaches to think about and implement to your workflow, the best idea would be to know them all and decide based specificaly on the project.

Here's a brief list to check them out:

• Style Tiles: see them as an abstraction above the Full Comp and below the MoodBoard. It still is static file (PSD, e.g.), but it let's you free to work on the browser.

• Element Collages: thinking the elements one at a time, and later you go joining the pieces.

• Style Prototype: very similar to the Style Tiles, but in the browser.

• Pattern Lab: Style your elements one at a time, join them progressively until it's completely ready.

As said before, using one does not exclude the use of others, in fact, some of them go really well together.

You should also check out the brilliant "Front-end style guides" book by Anna Debenham

Stylesheet writing can become really messy as your project grows and you try to mantain everything current and functioning. If you don't want to get lost around a ton of different styles and confusing selectors it's imperative that you choose a methodology for your style-writing.

It's up to you and your team to decide which approach suits best. You can even decide you're creating one methodology of your own, either way, it's highly adviseble that you take some time and read throught the main ones:

• SMACSS: Scalable and Modular Architecture for CSS
• BEM: Block Element Modifier
• OOCSS: Object-Oriented CSS

Fixed units simply don't convaluate to the flexibility RWD usually demands from content. Not just your viewport has flexible dimensions (by browser resizing, zooming, rotating, or whatever else), but the proportions between content and container, container and viewport and, consequently, content and viewport vary significantly. Since a pixel is a pixel in whatever context it's put, developers and designers can make use of relative units.

Relative to browser's font-size default or viewport dimensions. This means that as the environment changes, the unit adapts.

Font Related Units

• em: correspond to the element's font-size
  • rem: root em corresponds to the body's font-size
• %: 1/100 of the elements max value
• ex: corresponds to the x-height of the element's font-family
• ch: the width of the character 0 (zero) of the element's font-family

Viewport Related Units

• vw: 1% of the viewport's width
• vh: 1% of the viewport's height
• vmax: 1% of viewport's biggest dimension
• vmin: 1% of the viewport's smallets dimension

Be careful with Viewport Related Units' support

Make extensive use of this units, some devs have adopted pixel-free development processes. Although for media queries it's good to consider the use of pixels.

In all CSS toolbox, these are the most powerful ones for RWD. They let you listen for device variations and adapt your styles. Media Queries are declared as @media and followed -optionally- by a media declaration (which the default is all), and by a media feature (e.g. '(min-width: 30em)').

There're tons of combinations of media queries, refer to the documentation if you want to see all possibilities. The main ones are:

• min-width or max-width
• min-height or max-height
• resolution and device-pixel-ratio (must be used together for compatibility in all browser vendors)

As a W3C Working Draft, not yet supported, we have some new promising features:

• luminosity : dim || normal || washed
• pointer : none || coarse || fine
• hover : none || on-demand || hover
• script : none || enabled