Really short answer: SASS

Slightly longer answer: SASS is better on a whole bunch of different fronts, but if you are already happy in LESS, that's cool, at least you are doing yourself a favor by preprocessing.

Much longer answer: Read on.

The Much Longer Answer

The Learning Curve with Ruby and Command Line and Whatever

The only learning curve is the syntax. You should use an app like CodeKit to watch and compile your authored files. You need to know jack squat about Ruby or the Command Line or whatever else. Maybe you should, but you don't have to, so it's not a factor here.

Winner: Nobody

Helping with CSS3

With either language, you can write your own mixins to help with vendor prefixes. No winner there. But you know how you don't go back and update the prefixes you use on all your projects? (You don't.) You also won't update your handcrafted mixins file. (Probably.) In SASS you can use Compass, and Compass will keep itself updated, and thus the prefix situation is handled for you. Yes you'll have to keep your local preprocessor software updated and compile/push once in a while, but that's trivial and thinking-free.

So what this comes down to is: SASS has Compass and LESS does not. But it goes deeper than that. The attempts at creating a real robust project like Compass for LESS haven't succeeded because the LESS language isn't robust enough to do it properly. More on that next.

Winner: SASS

Language Ability: Logic / Loops

LESS has an ability to do "guarded mixins." These are mixins that only take affect when a certain condition is true. Perhaps you want to set a background color based on the current text color in a module. If the text color is "pretty light" you'll probably want a dark background. If it's "pretty dark" you'll want a light background. So you have a single mixin broke into two parts with these guards that ensure that only one of them takes effect.

.set-bg-color (@text-color) when (lightness(@text-color) >= 50%) {
  background: black;
}
.set-bg-color (@text-color) when (lightness(@text-color) < 50%) {
  background: #ccc;
}

So then when you use it, you'll get the correct background:

.box-1 {
  color: #BADA55;
  .set-bg-color(#BADA55);
}

That is overly simplified, but you likely get the idea. You can do some fancy stuff with it. LESS can also do self-referencing recursion where a mixin can call itself with an updated value creating a loop.

.loop (@index) when (@index > 0) {
  .myclass {
    z-index: @index;
  }
  // Call itself
  .loopingClass(@index - 1);
}
// Stop loop
.loopingClass (0) {}

// Outputs stuff
.loopingClass (10);

But thats where the logic/looping abilities of LESS end. SASS has actual logical and looping operators in the language. if/then/else statements, for loops, while loops, and each loops. No tricks, just proper programming. While guarded mixins are a pretty cool, natural concept, language robustness goes to SASS. This language robustness is what makes Compass possible.

For example, Compass has a mixin called background. It's so robust, that you can pass just about whatever you want to that thing that it will output what you need. Images, gradients, and any combination of them comma-separated, and you'll get what you need (vendor prefixes and all).

This succinct and intelligible code:

.bam {
  @include background(
    image-url("foo.png"),
    linear-gradient(top left, #333, #0c0),
    radial-gradient(#c00, #fff 100px)
  );
}

Turns into this monster (which is unfortunately what we need for it to work with as good of browser support as we can get):

.bam {
  background: url('/foo.png'), -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #333333), color-stop(100%, #00cc00)), -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #cc0000), color-stop(100%, #ffffff));
  background: url('/foo.png'), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), -ms-linear-gradient(top left, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px);
  background: url('/foo.png'), linear-gradient(top left, #333333, #00cc00), radial-gradient(#cc0000, #ffffff 100px);
}

Winner: SASS

Website Niceitude

LESS has a nicer, more usable website. The SASS documentation isn't awful. It's complete and you can find what you need. But when competing for attention from front end people, LESS has the edge. I don't doubt this plays a large role in LESS currently winning the popularity race. Things may be changing though.

Winner: LESS

The @extend Concept

Say you declare a class which has a bit of styling. Then you want another class which you want to do just about the same thing, only a few additional things. In LESS you'd likely:

.module-b {
   .module-a(); /* Copies everything from .module-a down here */
   border: 1px solid red;
}

That's an "include" essentially. A mixin, in both languages. You could use an include to do that SASS as well, but you're better off using @extend. With @extend, the styles from .module-a aren't just duplicated down in .mobule-b (what could be considered bloat), the selector for .module-a is altered to .module-a, .module-b in the compiled CSS (which is more efficient).

.module-a {
   /* A bunch of stuff */
}
.module-b {
   /* Some unique styling */
   @extend .module-a;
}

Compiles into

.module-a, .module-b {
  /* A bunch of stuff */
}
.module-b {
  /* Some unique styling */
}

See that? It rewrites selectors, which is way more efficient.

Winner: SASS

Variable Handling

LESS uses @, SASS uses $. The dollar sign has no inherit meaning in CSS, while the @ sign does. It's for things like declaring @keyframes or blocks of @media queries. You could chalk this one up to personal preference and not a big deal, but I think the edge here is for SASS which doesn't confuse standing concepts.

SASS has some weirdness with scope in variables though. If you overwrite a "global" variable "locally", the global variable takes on the local value. This just feels kind of weird.

$color: black;
.scoped {
  $color: white;
  color: $color;
}
.unscoped {
  // LESS = black (global)
  // SASS = white (overwritten by local)
  color: $color;
}

I've heard it can be useful but it's not intuitive, especially if you write JavaScript.

Winner: Tossup

Working with Media Queries

The way most of us started working with @media queries was adding blocks of them at the bottom of your main stylesheet. That works, but it leads to mental disconnect between the original styling and the responsive styles. Like:

.some-class {
   /* Default styling */
}

/* Hundreds of lines of CSS */

@media (max-width: 800px) {
  .some-class {
    /* Responsive styles */
  }
}

With SASS or LESS, we can bring those styles together through nesting.

.some-class {
  /* Default styling */
  @media (max-width: 800px) {
    /* Responsive styles */
  }
}

You can get even sexier with SASS. There is a really cool "respond-to" technique (see code by Chris Eppstein, Ben Schwarz, and Jeff Croft) for naming/using breakpoints.

=respond-to($name)

  @if $name == small-screen
    @media only screen and (min-width: 320px)
      @content

  @if $name == large-screen
    @media only screen and (min-width: 800px)
      @content

The you can use them succinctly and semantically:

.column
    width: 25%
    +respond-to(small-screen)
      width: 100%

Note: requires SASS 3.2, which is in alpha, which you can install with gem install sass --pre. I don't think there is any doubt this is a very nice way to work.

Winner: SASS

Math

For the most part, the math is similar, but there are some weirdnesses with how units are handled. For instance, LESS will assume the first unit you use is what you want out, ignoring further units.

div {
   width: 100px + 2em; // == 102px (weird)
}

In SASS, you get a clear error: Incompatible units: 'em' and 'px'. I guess it's debatable if it's better to error or be wrong, but I'd personally rather have the error. Especially if you're dealing with variables rather than straight units and it's harder to track down.

SASS will also let you perform math on "unknown" units, making it a bit more futureproof should some new unit come along before they are able to update. LESS does not. There is some more weird differences like how SASS handles multiplying values that both have units, but it's esoteric enough to not be worth mentioning.

Winner: Narrowly SASS

Active Development

At the time of this writing...

Number of open issues on LESS: 392
Number of open issues on SASS: 84

Pending pull requests on LESS: 86
Pending pull requests on SASS: 3

Number of commits in the last month in LESS: 11
Number of commits in the last month in SASS: 35

None of that stuff is any definitive proof that one project is more active than the other, but the numbers do seem to always leans toward SASS. As I understand it, both of the leads work on the languages in whatever little free time they have, as they both have other major new projects they are working on.

Winner: Probably SASS

More Reading

• Chris Eppstein: SASS/LESS Comparison
• Jeremy Hixon: An Introduction To LESS, And Comparison To Sass
• Ken Collins: Too LESS? Should You Be Using Sass?
• Johnathan Croom: Sass vs. LESS vs. Stylus: Preprocessor Shootout

SASS vs. LESS is a post from CSS-Tricks

Direct Link to Article — Permalink

Responsive Images and Web Standards at the Turning Point is a post from CSS-Tricks

Direct Link to Article — Permalink

ShopTalk Episode 18 is a post from CSS-Tricks

The spreadsheet has the data, but let's digest it through thinking about it through the lens of practical questions.

To choose which technique is right for you and your project these questions may help as a guide. Many of the questions may apply to your project, so you'll have to sort out which techniques fit what scenarios and find the overlap.

Do I have legacy content?

Which really means... do I have legacy content that is impractical to update? For instance, I have thousands of pages of content on CSS-Tricks and a writing staff of one.

The only technique I know of that works with absolutely no markup changes is Adaptive Images. It works by routing requests for images through a PHP file which intelligently serves (and creates if need be) images of the appropriate size for the screen width.

Another question to ask yourself is if you care about legacy content. Perhaps the vast majority of traffic to your site is for newer content in which you can make markup changes and thus take advantage of other techniques. If that's the case, read on to discover those other techniques.

If you have a small project, a brand new project, or a project with legacy content that you are able go back and update, you are also able to choose a technique which does require special markup, so also read on.

Do I care about special markup?

This is really a sub-question of the above. Many of the techniques require you to use special HTML. For example, HiSRC has you put higher resolution images as data-attributes:

<img src="200x100.png" data-1x="400x200.png" data-2x="800x400.png">

I'd say this is a clean, valid, semantic technique, but it also means that you need these attributes on every <img> on your site, which may not be possible on sites with loads of legacy content.

If you know that special markup (or specialized CSS) is not an option for you, really the only option is Adaptive Images. Even Sencha.IO requires prefixing the src attribute which may not be possible with legacy content.

Do I care about semantics?

Some responsive images techniques involve markup which isn't strictly semantic. Ultimately, there is only one way an image can be semantic. That is if the src of it points to a real image and it has alt text describing that image. Brad Frost sums it up nicely:

@stowball Unfortunately its not that simple. A picture of a horse needs to be a picture of a horse or else its not a picture of a horse. :)

— Brad Frost (@brad_frost) April 5, 2012

In other words, if the technique requires at any point the src of the image to be missing or link to a transparent GIF (or the like), that's not semantic.

So why do some responsive images techniques do this? Because having an image with a src that points to that image of a horse means that that image will start downloading as soon as that image gets parsed by the browser. There is no practical way to prevent this. Even if you super quickly swap out that src with a more appropriate version, now you're downloading two images instead of one which is a performance hit instead of a performance gain. You may decide that's acceptable (e.g. "desktop" environments typically have more bandwidth). Usually if this technique is employed, the image in the src is the smallest possible image.

If semantics is important to you, you should look at Adaptive Images (covered above) or HiSRC, a plugin by Christopher Schmitt which you can use with a semantic src attribute.

A few of the techniques use <noscript> tags in which to place a fallback <img> in the case of no JavaScript being available. I'll let you decide if that's semantic or not.

Do I care about validity?

Validity as in "Does it validate?" according to the W3C Markup Validation Service. Validation is a tool to help you find problems and write better markup. But just because something doesn't validate doesn't make it bad or wrong. If invalid code works wonderfully in all browsers, you nor anyone else should care.

If you do care about validity (perhaps a client irrationally requires it from you and is holding your paycheck randsom) then there are a few techniques that you can't use. The picturefill technique, for instance, uses the <picture> element to work its magic. This may ultimately be standarized, but it isn't yet, so it's technically invalid syntax. It's also required that <img> elements have a src attribute, so techniques that remove that to get around the double-image-request problem are invalid.

I'd recommend these techniques if validity is a requirement for you: Adaptive Images, HiSRC, or Responsive Enhance. All of which use simple, valid <img> syntax that include a src.

Do I care about art direction?

Some responsive images techniques serve different resolution versions of the exact same image. While that makes things easier (i.e. less work) it may not acceptable. Here's a visual example:

These images are hand-crafted by a designer, cropped to retain meaning and impact. If you took the image on the right and just scaled it down, the people in the image would be very small and the feel of the image my be lost.

If this idea of art direction is important to your project, you'll need a technique that will allow you to specify exactly which src to serve under which circumstances. This is picture perfect (GET IT?) for picturefill which allows you to be very specific about sources and what circumstances get what.

<picture alt="description">
  <source src="small.jpg">
  <source src="medium.jpg" media="(min-width: 400px)">
  <source src="large.jpg" media="(min-width: 800px)">
</picture>

JavaScript takes it from there.

Do I care about JavaScript?

Most of these responsive image techniques utilize JavaScript to work their magic. Some only a tiny bit to set a cookie, but JavaScript none the less. Some of them have you put an <img> in a <noscript> tag so that there is a fallback image in the case that the user has JavaScript turned off. If you don't like that, and you need to make absolutely sure that your images work without JavaScript, Sencha.IO is your best bet. This service works by identifying your device through it's User Agent string and serving an appropriately sized image. So you link to the largest (reasonable) version you have of it and Sencha will squeeze it down and server smaller versions if need be (it doesn't scale up, for obvious reasons).

What about JavaScript *library* dependency?

HiSRC and rwdImages are both jQuery dependent. If your project is using a different library, these probably aren't for you. But hey, you could port it and open source that! If you aren't using a library, well, you probably should be but let's not get into that.

Do I care about Server Side Components?

Some of these techniques aren't solely JavaScript dependent. Adaptive Images works it's magic primarily through .htaccess and PHP. Well, .htaccess presupposes an Apache server. And, while of course we all know and love PHP (ahem), many websites run on technologies like Ruby or Python.

Responsive Images (the original Filament Group technique) also uses .htaccess. So if you're using something like Nginx as web server, this is either out or you'll have to port over the .htaccess component to Nginx's similar-but-different syntax.

Do I care about bandwidth testing?

Testing the browser window width and making decisions on what image to serve based on that is pretty cool and fundamental to the concept of responsive images. But it's really only half of what the decision of what image should be served should be based on. The other half is available bandwidth. If the user has a very fast internet connection speed, serving large images is OK. If the user has a very slow internet connection speed, they should get smaller images (regardless of screens size). Unfortunately native bandwidth media queries don't exist.

Two of the current techniques do bandwidth testing as part of their decision making: Foresight.js and HiSRC (both are based on the technique in Foresight.js). It works by downloading a test file and measuring how long it took (configurable). The test itself is a slight performance hit, but theoretically the savings gained by serving images based on knowing the current bandwidth is a net (GET IT?) gain.

Do I care about relying on third parties?

Sencha.IO is a completely third-party way of handling responsive images. As far as I know, it works great and hasn't been inflicted with any major downtime, but of course you always run that risk.

You might be thinking: Wow, the Sencha.IO technique is really cool but I worry about the third-party dependency. I wish I could run that on my own server. If you want to go down that road, there is the public WURFL database and this Server Side Responsive Images technique which puts that to work locally.

There are also third-party services like Device Atlas Cloud which does device detection for you. It's also a third-party dependency for your app. No doubt their goal and focus is staying up and fast at all times, but you have to be very careful about who and what you rely on for your business.

Is there a specific CMS with specific CMS powers involved?

Say your project is in WordPress. WordPress has a media uploader built in. When you upload an image with it, it can create multiple versions (scaling down) of that image for you. That's pretty cool and powerful and you could/should take advantage of that. Keir Whitaker talks about using that ability in his article Automatic Responsive Images in WordPress.

This isn't just a WordPress thing though. I'm sure the concepts at work here could be done (or made to be done) in any Content Management System.

Can I wait for the future?

The release of the "new iPad" (the third one, for longevity) is what sparked a lot of these techniques and conversations. Its high pixel density is great for vectors and big photos, but actually not great for things like small icons that need to be scaled up to be the correct size and can be blurry. But serving higher resolution icons means larger file sizes and slower websites. Hence, the need to only serve them in situations/environments that need them.

The world of web standards is aware of this problem. There is a whole group dedicated to talking about it. In time, they may solve it and then we can start using whatever way they come up with (assuming its awesome and better than what we have now).

It may be flipping out the src of images through CSS content like Nicolas Gallagher suggested. It might be the <picture> element. It might be a srclist attribute in HTML or src property in CSS. It might be a prefix.

More resources

• Jason Grigsby has an epic three-part series on responsive images starting here.
• Christopher Schmitt's slides on a whole talk about responsive images.
• Mat Marquis on Responsive Images: How they Almost Worked and What We Need

Which responsive images solution should you use? is a post from CSS-Tricks

The idea is that there is a lot of places on a website where you want a clean slate to work from and not be worried about what global styles are doing. The classic example is lists, where when using them for things like navigation you likely don't want the same margin/padding/list-style as you would within an article.

Further, you might have different sets of typographic styles you may want to apply at will. So, instead of global styles like this:

p  {    }
ul {    }
ol {    }
h1 {    }
h2 {    }
/* etc */

You would scope them to a class instead (using SCSS here):

.text-article {
  p  {    }
  ul {    }
  ol {    }
  h1 {    }
  h2 {    }
  /* etc */
}

.text-module {
  p  {    }
  ul {    }
  ol {    }
  h1 {    }
  h2 {    }
  /* etc */
}

In an area of the site that's a blog post, you can snag your article typography, and in a sidebar module, you can grab the typography for that:

<section class="main-content">
  <article class="text-article">
    ...
  </article>
</section>
<aside>
  <div class="module text-module">
     Texty module
  </div>
  <div class="module">
     Module in which typography isn't needed
  </div>
</aside>

Anthony Short feels the same way.

Of course, the effectiveness of this depends on the website. What kind of site it is and what stage in it's evolution it's in. I suspect it would work better on websites that have a more "modular" architecture and that don't have a huge set of legacy content. I'd be interested in trying it on a fresh project.

Opt-in Typography is a post from CSS-Tricks

Direct Link to Article — Permalink

ShopTalk Episode 17 is a post from CSS-Tricks

Enter Ziptastic, a free (donations welcome) API for just that.

Let's use it.

Form Markup

Five fields. Two for street then city, state, and zip. All wrapped up in a form and fieldset. Nothing special.

<form action="#" method="post" class="fancy-form">

  <fieldset>
    <legend>Address</legend>

    <div>
      <div>
        <input type="text" name="address-line-1" id="address-line-1">
        <label for="address-line-1">Street #1</label>
      </div>
    </div>
    <div>
      <div>
        <input type="text" name="address-line-2" id="address-line-2">
        <label for="address-line-2">Street #2</label>
      </div>
    </div>
    <div>
      <div class="city-wrap">
        <input type="text" name="city" id="city">
        <label for="city">City</label>
      </div>
       <div class="state-wrap">
        <input type="text" name="state" id="state">
        <label for="state">State</label>
      </div>
       <div class="zip-wrap">
        <input type="text" pattern="[0-9]*" name="zip" id="zip">
        <label for="zip">Zip</label>
        <p class="zip-error">Not a real zip code.</p>
      </div>
    </div>

    <div>
      <input type="submit" value="Submit">
    </div>

  </fieldset>

</form>

Only show the zip at first

We'll hide all the divs that wrap each row of form elements. We'll use JavaScript, so that in case the user has JavaScript turned off, the form is still usable.

$(".fancy-form div > div").hide();

Then reveal just the zip code.

form .zip-wrap {
  display: block !important;
}

Front end validation

On the front end, we're already doing the best we can to help the proper entry of a zip code through HTML5 input attributes pattern, maxlength, and required.

<input type="text" pattern="[0-9]*" maxlength="5" required name="zip" id="zip">

Notice it's not of type number. Whenever considering type=number, consider "would I be cool with the browser adding commas inside of this number?" and if it's no, don't use it, because some do.

jQuery: Watch for entry of valid zip code

We're going to watch the zip input for keystrokes. Should the final value after a keystroke be a valid zipcode, we'll attempt to get the city and state through Ziptastic and reveal the other fields.

$("#zip").keyup(function() {
  var el = $(this);

  if ((el.val().length == 5) && (is_int(el.val()))) {

    // Make Ajax call, etc

  }

}

The is_int function is just some extra protection that the number is an integer (like all zip codes) in case the current browser doesn't support the necessary HTML5.

function is_int(value){
  if ((parseFloat(value) == parseInt(value)) && !isNaN(value)) {
      return true;
  } else {
      return false;
  }
}

jQuery: Ajax the data

Yeah so jQuery. We used it above to make event handling on the input easier, but it's really need here because of its ability to make ajax calls with error handling sixty two times easier than doing it with vanilla JavaScript.

After the passed validation, we can make the Ajax call. All we give it for data is the zip code we've collected and we get some JSON back which is trivially easy to access the city and state and apply them as values to the appropriate inputs.

$.ajax({
  url: "http://zip.elevenbasetwo.com",
  cache: false,
  dataType: "json",
  type: "GET",
  data: "zip=" + el.val(),
  success: function(result, success) {

    $(".fancy-form div > div").slideDown(); /* Show the fields */

    $("#city").val(result.city); /* Fill the data */
    $("#state").val(result.state);

    $(".zip-error").hide(); /* In case they failed once before */

    $("#address-line-1").focus(); /* Put cursor where they need it */

  },
  error: function(result, success) {

    $(".zip-error").show(); /* Ruh row */

  }

});

Of course we can validate all day long for the valid format of zip codes, but not every 5 digit integer is a zip code. Should we ask Ziptastic for a zip code that doesn't exist, it will return an error. In that case we just show an error message.

Demo and Download

View Demo   Download Files

Snag the ZIP. GET IT?! Also, if someone wants to apply some actually nice UX and design to this, I'd be happy to update the demo with credit. Andru Stoicescu at Better <html> submitted a bit of a fancier design so I updated to that.

Notes

• I'm not going to tell you this is bulletproof. Addresses are hard. I heard some zip codes cross state lines.
• Ziptastic is US only. Just days after publishing this, Ziptastic starts supporting postal codes internationally. Zippopotamus is similar and supports 60 counties.

Autofill City & State from Zip Code with Ziptastic is a post from CSS-Tricks

Why is this awesome?

There are many reasons. Here are two:

1. There is a such thing as a comfortable line length for reading text on screens. I don't want to kick a hornet's nest, but let's say its around 80 characters. These units allow you to get it feeling perfect and then have that experience scale to any size screen.
2. They allow you to tightly couple the size relationship of, say, a typographic header and the content it goes with. Like your classic Trent Walton style blog post.

How they work

One unit on any of the three values is 1% of the viewport axis. "Viewport" == browser window size == window object. If the viewport is 40cm wide, 1vw == 0.4cm.

For use with font-size, I guess it's one "letter" that takes on that size, but as we know, in non-mono-spaced fonts the width of a letter is rather arbitrary. I find you just need to tweak around with the values to get it how you want it. Which is basically what we do anyway, right?

1vw = 1% of viewport width
1vh = 1% of viewport height
1vmin = 1vw or 1vh, whichever is smaller

Using them

Easy cheezy:

h1 {
  font-size: 5.9vw;
}
h2 {
  font-size: 3.0vh;
}
p {
  font-size: 2vmin;
}

Demo

Here's a video of a simple layout using vw units so the typography.

Check out the demo yourself (see browser support).

Bugs!

The support is there in Chrome 20, but it fails in one rather significant way. When the browser window is resized, the font doesn't adjust itself according to the new viewport size. The spec says:

When the height or width of the viewport is changed, they are scaled accordingly.

I bugged it. Perhaps not a huge disaster as it's pretty much just us design nerds that go around adjusting browser windows, but still. The font does adjust on a fresh page load.

To fix this issue (allow resizing without page refresh) you need to cause a "repaint" on the element. I used jQuery and just fiddled with each elements (irrelevant, in this case) z-index value, which triggers the repaint.

causeRepaintsOn = $("h1, h2, h3, p");

$(window).resize(function() {
	causeRepaintsOn.css("z-index", 1);
});

Browser Support

Chrome 20+ & IE 10+

I tried Opera Next (12), Safari 5.2, and Firefox Beta (13) and no dice.

Not just font-size

For the record, these are just units. Just like em, px, whatever. You can use them on anything, not just font-size.

I think font-size is the most compelling use case, since things like margin, padding, and width can already essentially react to browser window size by using % units. There is the case where perhaps a more deeply-nested element needs to react to the browser window size instead of its direct parent size.

Using it now

Native usage

You'll at least want to provide a fallback:

h1 {
  font-size: 36px; /* Some tweener fallback that doesn't look awful */
  font-size: 5.4vw;
}

Testing for support

Modernizr doesn't have a test for it yet, but you can test for it yourself by using some throw-away element that you see to some narrow width in CSS but then re-set to 100vw in JavaScript, then measure to see if the width of it is equal to window.width. Something like:

var testEl = $("#vw-test");

var viewport = $(window);

testEl.css({
  width: "100vw"
});

if (testEl.width() == viewport.width()) {
   $("html").addClass("vw-support");
} else {
   $("html").append("vw-unsupported");
};

Mimic the functionality with FitText.js

This idea of binding the overall width of a header with the width of its parent element is exactly what FitText.js does. Only it does it through fancy JavaScript and math and spans and stuff. Theoretically, you could run the test and use Modernizr.load to load up FitText.js if no support is detected.

So yeah

What do you think? Are you into it? Got some ideas on how to use it?

Viewport Sized Typography is a post from CSS-Tricks

Direct Link to Article — Permalink

ShopTalk Episode 16 is a post from CSS-Tricks

The article was sans-demo, so I made one.

Direct Link to Article — Permalink

Conditional Content via CSS Media Queries is a post from CSS-Tricks