Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Introducing LiveStyle: Better, Stronger And Smarter CSS Live Reload

In the past, we featured some exciting tools and libraries: PrefixFree1, Foundation2, Sisyphus.js3, GuideGuide4, Gridpak5, JS Bin6 and CSSComb7. All of them have been developed and released by active members of the Web design community as open-source projects. Today, we present LiveStyle, a plugin for live bi-directional (editor ↔ browser) CSS editing of the new generation! — Ed.

Tools for live CSS editing aren’t new these days. You may already be familiar with tools like LiveReload8, CodeKit9 and Brackets1210. So, why would someone ever need to create yet another tool and even call it a “live CSS editor of the new generation”?

The tool I’d like to introduce to you today is Emmet LiveStyle11. This plugin takes a completely different approach on updating CSS. Unlike other live editors, it doesn’t simply replace a whole CSS file in a browser or an editor, but rather maps changes from one CSS file to the other.

In order to better understand how LiveStyle works, let us first take a look at the current state of live edit tools.

A State Of Live Edit Tools Link

Most live reload/edit tools work in a pretty simple manner: They look out for CSS files in a special folder and update the Web browser once something has been changed. So users have to edit the CSS file and save it before they can preview the changes. Not exactly a “live” update, but this simplicity has its own benefits. You can use these tools together with preprocessors so your webpage gets updated automatically whenever you save your LESS or SASS file.

About a year ago, a new breed of live editing tools appeared. Editors like Brackets1210 and WebStorm13 integrate with Web browsers (more specifically, with Google Chrome) directly and allow you to see updates instantly, e.g. without saving a file. They send the updated file content to the browser every time you change something. But in order to use live edit, they require a special built-in Web server to be used to properly map your local files with browser URLs.

Getting changes from DevTools back into your CSS file is not so popular. There are a few tools like Tin.cr14 that allow you to save your DevTools changes back to the file (the Chrome Dev team introduced Chrome Workspaces15 recently for this very same purpose).

Summing up, to use these tools for truly live development (deliver updates from editor to browser and vice versa), you have to:

  • Use the same CSS files in your text editor and Web browser.
  • Keep your files in a local file system.
  • In some cases, use a special tooling Web server.

All of these tools work just fine once you’ve started your project development, but what happens when your website goes into production? What if you concatenate and minify your CSS code for better performance and UX? Most of these tools become pretty much useless:

  • You can’t use the tooling Web server because you need to use your own one for backend/CMS.
  • You can’t get the DevTools changes back into your file since (concatenated and minified) CSS within browser is not the same as your source code.
  • In some large projects, you can’t use a local file system — your files might be in your private sandbox on the dev server.

So, you don’t have much options now, right? If you ask me, there are two things that must be eliminated:

  1. Any middleware between the browser and editor. The editor should be able to talk to the browser directly, without using any files or Web servers.
  2. Full CSS content swapping. The browser or editor must receive only the updated sections, not the entire source.

To solve these issues, LiveStyle was created. Unlike other tools, it does not work directly with files, nor does it replace them in the browser or editor. It maps changes from one source to the other.

How LiveStyle Works Link

Imagine you’re editing a CSS file and I ask you, “What did you just change?”

Your answer could be: “On line 2, I replaced the characters from 12 to 16 with the word red.” But I’m pretty sure your answer will rather end up being: “In the body selector, I changed the background property value to red.” In other words, instead of describing how bytes were changed within the text file, you would describe how the structure of the CSS file was changed.

But the thing is, if you pass this very same information to another developer, i.e. “in body, change background value to red,” he can perform the very same changes in his own CSS file and get the very same result!

This is exactly how LiveStyle works. Whenever you update a CSS source, it performs structural comparisons with the previous state and creates a special patch that describes how the CSS structure was changed. This patch is then transmitted to all clients and is applied to the associated CSS source.

This approach gives you the following benefits:

  • You can associate two completely different CSS sources for live editing. For example, you can take a minified and concatenated CSS source in a browser, associate it with one of the source CSS modules in an editor, and use them for fully bi-directional live editing.
  • You don’t need to keep your files in a local file system. You can simply open it directly from the FTP, your fancy network mount, or whatever. If a file can be opened by a text editor, you can use it for live editing as well.
  • You can even create new, untitled files and use them for live editing right away!
  • You don’t need a special Web server, code snippet or file watcher, everything works in the editor and browser.

Here’s a demo video demonstrating how this approach works in real life:

In the video above, I used the Facebook main page to demonstrate the power of LiveStyle. There’s no doubt it’s one of the largest and complex websites on the planet and I don’t have access to either the Facebook server nor its CSS source. But I need just a few clicks to start the live CSS editing. Imagine how easy it is for you to do the very same for your own website!

Installation Link

Currently, LiveStyle works in Google Chrome, WebKit Nightly (for iOS apps live editing) and Sublime Text. The installation process is pretty straightforward:

  1. Install the “LiveStyle” plugin from the Package Control in Sublime Text.
  2. Install the extension for Google Chrome16.

The WebKit extension can be installed directly from Sublime Text, just pick ToolsInstall LiveStyle for WebKit extension menu item, or run the LiveStyle: Install WebKit extension command from the Command Palette.

That’s it! Now you can start using LiveStyle to tweak your websites. If you have any trouble with the LiveStyle installation or need any further assistance, please go to the official installation guide17.

Using LiveStyle Link

To start with the live CSS editing, simply follow these four easy steps:

  1. Start Sublime Text and open a CSS file or create new one.
  2. Start your Chrome browser and go to the page you wish to edit.
  3. Open DevTools, go to the LiveStyle panel and check the Enable LiveStyle for current page option.
  4. Once enabled, you’ll see a list of the external style sheets on the left and a list of editor files on the right. Simply pick the editor file that should be associated with the browser and you are done!

Note that the editor’s files list is automatically updated every time you create, open or close files within the editor.

Important: You must keep DevTools open during your live editing session and for every window (in multi-view mode). You don’t have to be on the LiveStyle panel all of the time, but DevTools must remain open otherwise the incoming updates won’t be applied.

New Workflows Link

LiveStyles’ CSS patching concept introduces a number of workflows you can use in your development process:

Simple Mode Link

This one’s a basic one-to-one live editing mode. Simply associate any external CSS file in the browser and the editor, and start editing. All your editor changes will be automatically reflected in the browser and your DevTools updates will be reflected in the editor.

If your browser file is large enough, your editor updates may take some time to apply. If you want to speed things up or you don’t have any external style sheets on your page, you can create a new style sheet by pressing the Add file button and using it for live updates.

Multi-View Mode Link

Multi-view mode is ideal for tweaking responsive Web designs. Open multiple windows of the same page and resize them for your RWD breakpoints. DevTools must be open for each window, otherwise it won’t apply any updates.

In multi-view mode:

  • All editor updates will be applied to all windows.
  • All DevTools updates will be applied to the editor and all other windows with the same page.
  • All LiveStyle panel updates (like file associations) will be automatically applied to all other windows with the same page.

Multi-Site Mode Link

This mode is useful if your Web project has different versions of desktop and mobile websites but shares the same CSS code base.

Just like in the “multi-view mode”, you need to open a few windows with your website’s versions and associate your browser CSS files in the LiveStyle panel with the same editor file. LiveStyle will use this editor file as a reference to patch your browser files with incoming updates, even from DevTools.

Designer Mode Link

This mode is for designers who work on large projects and don’t have direct access to the CSS sources. (Please note that this is an experimental mode and is subject to change!)

Imagine you spot an error on your production website. Instead of asking the developer to spend some time with you to fix these issues, you can fix them by yourself and send the developer a patch so he can apply it later to the original source.

All LiveStyle updates are recorded into the “Patch history”, available in the LiveStyle DevTools panel. A new patch history entry is created automatically every time you open or refresh a Web page. Click on the “Patch history” pop-up entry to apply recorded patches and click on the red icon on the right to download it.

So, all you have to do is to tweak the layout in DevTools and download the most recent patch history entry. You can send the downloaded patch to the developer so he can apply it to original CSS source.

Note that in this mode you don’t need Sublime Text extension at all; you just need the DevTools extension.

Behind The Scenes Link

I’m pretty sure anyone who’s tech savvy is interested in how LiveStyle works and what lessons I learned from this project.

How LiveStyle Patches CSS Link

When you edit styles in DevTools, you see that properties in selectors are modified accordingly: Existing selectors are updated and absent ones are created — even whole CSS selectors are automatically created (and I really hope this is the only thing you see).

But did you notice there’s no CSS formatting configuration step? You didn’t have to open any preferences file to specify that you don’t need space after a colon and all your properties should be written in single lines.

That’s because LiveStyle tries to match your coding style as close as possible. Whenever it needs to insert something in the document, it analyzes your personal coding style and automatically creates formatting rules for you.

This is also possible due to the original Emmets’ cssEditTree component. This module provides a DOM-like interface for CSS modifications, e.g. rule.value('background', 'red'), rule.add('padding', '10px'), but also keeps track of CSS token positions and inherits formatting rules for newly created properties. You can actually create an Emmet extension and reuse this module to automate your CSS modification tasks (for example, like in the Update Image Size action18).

Performance Link

As described earlier, LiveStyle doesn’t simply swap CSS content, it parses CSS into a tree, compares it with its previous state and generates a special patch. On the other end, it also has to parse CSS, locate proper place to patch, analyze your coding style and then create patched CSS source. And everything must be done after each keystroke which means that LiveStyle should be fast — blazingly fast.

I had to use some advanced tricks to make this possible; I had to optimize for Garbage Collector, optimize for JIT, optimize function inlining and even multi-threading programming.

JavaScript Optimization Link

LiveStyle is written entirely in JavaScript. Thanks to Google DevOps, we have a brilliant V8 JavaScript engine (powers Chrome and PyV8, used to run JS in Sublime Text) and DevTools for debugging JS performance.

V8 can run JavaScript very fast, but it’s not a magic box. We have to obey some rules to make it work that way.

The very first thing we need to be able to start optimization is a working product, covered by unit tests. “Premature optimization is the root of all evil”, you know.

Once we have our product up and running, start using Profiler to determine slow parts of your code. Chrome and Firefox have awesome built-in profiles and many tutorials on how to use them, so this shouldn’t be a problem.

Among other things, the great performance boost was achieved by replacing array iterators like Array.forEach19 with plain loops in critical parts of the performance. This technique is called “Inlining20“. Plain loops are much faster than native implementations of Array.forEach and some libraries like Lo-Dash21 use the very same technique to run faster. Despite the fact that I’ve heavily used Lo-Dash in LiveStyle, I did use plain loops in performance-critical parts since every function call has its own small performance penalty.

As soon as all parts were optimized, the slowest process was the garbage collection (GC). GC is a process of removing unneeded data from memory. In JavaScript, we don’t have direct access to the garbage collector so we can’t, for example, delay its execution and explicitly call it again later. The only thing we can do here is to avoid producing so much garbage.

Consider the following example:

function getSize(obj) {
    return {
        width:  obj.left - obj.right,
        height: obj.bottom -

var size = getSize(parent);  = size.width; = size.height;

In this example, we use the getSize() function as the utility method to calculate width and height from the given object. While this example is pretty simple, it actually produces a lot of garbage; If we called the getSize() method, say, 10,000 times, it will generate 10,000 objects that are not required for further program execution, so they must be collected by the GC.

A better implementation of the getSize() function may look like this:

var _size = {};
function getSize(obj) {
    _size.width  = obj.left - obj.right;
    _size.height = obj.bottom -;
    return _size;

In this example, even if the getSize() function is called 100,000 times, only one object will be created in the memory — which greatly reduces GC calls.

I achieved a huge performance boost with all of these manipulations, and it still wasn’t the end. Now, we can make our app run even faster with the help of the just-in-time (JIT) compiler.

Since LiveStyle parses CSS, it creates a lot token objects that should be accessed by the patcher very often. I analyzed my code and saw that these token objects are modified during runtime, e.g. new properties were added to some of these objects.

V8’s JIT optimizer has a so-called “Hidden Class” feature, a special assembly that optimizes access to properties of similar objects. And every time we add a new property to an existing object, we break this optimization.

So I made my general optimization: I rewrote part of LiveStyle’s engine so token objects could be automatically created with all of the properties required in advance and that these objects can be reused across different parts of the app, which reduces garbage collection in general.

About a half of this enormous performance boost was achieved by optimizing JS for V8 internals. In order to demonstrate how much the LiveStyle performance boost was optimized, here are some numbers from my MacBook Air:

  • Creating patch from 15 Kb CSS source: 18 ms
  • Applying patch on 584 Kb CSS source: 212 ms

Pretty good I’d say, assuming that most live reload tools need a 1-second timeout before reloading the browser after a CSS file has been changed.

Future Plans Link

During the first days of public beta testing, LiveStyle proved that its patching algorithm is pretty stable and solid. There have been no reports of broken CSS or invalid results. In fact, LiveStyle actually helped some people to find bugs in their CSS. And there’s still a lot of work left to do: Support more browsers and editors and, of course, add preprocessors support.

In the demo video above, you saw how the live bi-directional SCSS editing is done. The editor changes in SCSS are instantly reflected in the browser’s CSS, and browser changes in plain CSS are instantly pushed into the right places of SCSS. But this is just an experiment demonstrating how powerful LiveStyle can be. For real-world usage, it basically requires a new SCSS processor to be written.

So, I hope you’ll find LiveStyle useful and spread the word! If the community support is strong enough, I’ll try my best to find funding for further development. LiveStyle is currently free during public beta testing, but will be available for a small fee after its official release.

If you experience any issues with LiveStyle or have any suggestions, feel free to create a ticket at plugin repo22. Thanks!

Further Reading Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25

↑ Back to top Tweet itShare on Facebook

Sergey Chikuyonok is a Russian front-end web-developer and writer with a big passion on optimization: from images and JavaScript effects to working process and time-savings on coding.

  1. 1

    This is awesome… gonna try this…

  2. 2

    Fantastic. Can’t wait to see what’s next.

  3. 3

    I’ll be buying this the second SASS support is added.

    • 4

      Chrome has experimental SASS support, if that helps you.

    • 5

      Kyle Newsome

      August 8, 2013 8:07 am

      Agreed. Looks really good but CSS preprocessing is even more important to me than my grunt//live reload workflow right now.

    • 6

      Very cool stuff as proof of concept, but not going to be useful until it supports CSS preprocessing. Looking forward to that!

  4. 7

    Wow! What a fantastic extension!

    I have a question from the video though. When he types ‘transition’ and make sublime text automatically created all prefixed versions, and then edit all of them at once. How to accomplish that in sublime text?

    • 8

      Plugin named Emmet you can find through package control (available via I think). It’s zen coding’s successor. SASS also allows for vendor prefixes generation.

    • 9

      Prefixr it’s a sublime package you can add it through package control. I just switched from netbeans and firefox to sublime text and chrome just because of livestyle.

  5. 10

    I just wish the nice auto reload of Codekit comes to Windows/Linux. Codekit livereload is the only reason why I have a mac

  6. 13

    Wow, thats cool! I appreciate your great work. Is there any repository or something to add to the Sublime Package Control settings? I’m asking because “LifeStyle” or “Emmet LifeStyle” is not listed in my Package Install list in Sublime.

    • 14

      Steve Sanders

      August 8, 2013 9:09 am

      You should be searching for “LiveStyle” (with a “V”, not an “F”)

  7. 15

    Can you use any text editor, or just Sublime Text for now?

    • 16

      Sergey Chikuyonok

      August 8, 2013 11:08 am

      Currently, it’s Sublime Text only, but more editors will be available later.

  8. 17

    This is amazing. I wonder if while supporting sass it will support compass as well. Is there a way to donate money to this project, I don’t see any donate button on his website.

  9. 18

    Caleb Mellas

    August 8, 2013 6:01 am

    Awesome work Sergey! This is exactly the tool I have been hoping for, for the last several years. After watching the live-edit video by Brad Victor, I have been looking forward to tools like this being created.

    If we are truly going to design in the browser we must have instantaneous live updates. Plus it needs to work with tools that people actually use like SCSS, Compass, Bootstrap, CMS’s, CoffeeScript etc. Does anyone actually use just plain HTML & CSS anymore?

    Big +1 for SCSS support!

    • 19

      Sergey Chikuyonok

      August 8, 2013 11:11 am

      Thanks! CSS support in LiveStyle is just a first step to see how LiveStyles’ patching algorithm works in a wild. I’m investigating possibilities to add bi-directional preprocessors support.

  10. 20

    NICE!!! That is truly awesome.

  11. 21

    It would be nice if it had version control.

  12. 23

    LESS support please!

  13. 26

    This is really nice. I found most of these apps wouldn’t work for me in some version of my dev environment, but explicitly setting the file means there’s a lot less opportunity for it to mess up. The first thing I would want to see is an option to carry a css file mapping across a whole domain or a url pattern. Right now every time I go to a new page on the same site I have to go to the LiveStyle tab, re-enable it, and re-set the file mapping, then I only have to do it once per project

  14. 28

    This is a great idea. I would also love this to be able to manipulate the rendered HTML source the same way.

    As someone who designs updates to existing features in our product, I have found manipulating the source in DevTools to be significantly faster than pushing pixels in Photoshop. However, DevTools (and Firebug) can be touchy when it comes to editing HTML, so the ability to use something like Sublime Text would be a huge improvement.

  15. 30

    Shane Osbourne

    August 8, 2013 12:01 pm

    This has some good potential (although limited to browser support at the moment). While we wait for this to become better supported and if you want a css-injecting solution complete with full IE support & ghostmode – check out – It’s brand new and I’m looking for feedback :)

  16. 31

    This is great, but MacRabbit’s CSSEdit and Espresso have had this for years already. Cool to see this being adopted by other IDEs.

    • 32

      Exactly what I was going to say. CSSEdit and now Espresso got most of this for years. I could not live without it.

      I could never understand how one could live with the save/reload workflow. It is, however, great that i will be able to use this kind of editing with SublimeText and Emmet, that will be very neat. :)

    • 33

      Sergey Chikuyonok

      August 9, 2013 2:13 am

      You can’t live edit production web-sites with Espresso, it’s good for small local pages only.

      • 34


        I do most of my production online. Espresso allows you to overwrite any CSS File.

        I can also overwrite one of facebooks css files, like you did in the demo video, with Espresso, nothing new there. Sorry.

        • 35

          Sergey Chikuyonok

          August 10, 2013 8:19 am

          > I can also overwrite one of facebooks css files, like you did in the demo video, with Espresso, nothing new there.

          Can you briefly describe how to do this?

          • 36

            Sure thing.

            I’ve got the Preview-Window open and navigate to facebook. Once it’s loaded I click on “Style Sheets” in the menu bar and pick the CSS File I’d like to override. Then I’ve got the choice between creating a new file and extracting the css from the existing file or – if i had a css file open, i could use that to override it.

            Once the CSS is extracted and opened in the editor, I can happily change anything. I made a little Gif demonstrating it:

            It’s actually a really handy tool for Live-Site Editing. I can change as many things as I need, see all the changes happening live and only when everything fits I press save – which tells Forklift to upload the file. No need for a separate version of the site to do some changes.

          • 37

            Sergey Chikuyonok

            August 12, 2013 3:28 am

            OK, thanks, didn’t know about this feature. Anyway, compared to LiveStyle:

            1. You can’t get changes from Web Inspector back to your source code, e.g. it’s one way editing only
            2. You can’t use real CSS source in case your web-site contains minified and concatenated CSS

  17. 38

    What a unique way to do live editing! It looks better than anything I’ve seen before on speed and RWD workflow. Can’t wait to give it a shot this weekend

    +1 for preprocessor support. Without it, I can’t see using this during the week. But who knows, I haven’t tried it yet.

  18. 39

    This seems like it could really stream line some of my work a great deal, can’t wait to check it out!

  19. 40

    That’s just awesome. One can save so much time by not having to reload over and over again.

  20. 41

    I’m just playin around with it a bit and met an issue: Reloading the page removes all the changes that I made in my browser and which were not saved to the exact file the site is using.
    I have to change every declaration which is different from the original file, in order to get the effect showing again.

    If you’re tweaking a site that’s almost done, this doesn’t seem an issue but I’d like to use it for the building process which needs reloads because of changes to the HTML.

    Am I doing or understanding something wrong?

    • 42

      Sergey Chikuyonok

      August 9, 2013 2:18 am

      There’s nothing wrong here: since you didn’t saved your file, browser loads the most recent version of your CSS. But you can apply all these changes again: simply pick the most recent entry in “Patch history” drop-down (clicking on red icon will download these changes as JSON file).

      • 43

        Okay, it’s maybe not wrong. But I prefer the way Espresso is handling it.

        LiveStyle brings the benefit that you can override certain selectors, with Espresso or CSSEdit you have to overwrite a whole file, which isn’t a big deal I think.

        With Espresso or CSSEdit I have the benefit, that the changes I did in the CSS are always applied, even if I reload the page, I don’t need to push them to the server (or save them) for them to stay. This makes it really easy to also edit the HTML or make changes in the CMS, which often goes along with working on the CSS. No extra steps needed.

        Don’t get me wrong, I would prefer to work with SublimeText and Chrome instead of the outdated Webkit-Browser from MacRabbit. So …

        Would be cool if that could work one day with SublimeText, but if it’s not possible with Chrome I won’t complain.

  21. 44

    This sounds like an amazing extension which will improve workflow. Thanks for this post, I found it very informative and will be keeping an eye on this for additional support with other text editors and the like. Very curious to see how it will work over the web.

  22. 45

    When will the Firefox extension be available? I’d like to try that!

    • 46

      When will it be available for FireFox ?

      I wish someone would develop a Browser / Tablet / Smart Phone tool that I could preview on all of those devices without going though the current hassle.

  23. 47

    Pawel Skowronek

    August 9, 2013 7:11 am

    Brilliant! I have tried it yesterday with a major day project and it shorten the whole development time by 30-40%. I will use it more often now as it’s straightforward to install and use!!!

  24. 48

    I have noticed a couple bugs.

    1. Editing % values is finicky, if I highlight the percent value and change it that seems to work, but if I backspace and retype it things get wonky. Sometimes neither method will correct the display issue generated.

    2. At some point if I’ve edited a lot of styles using Firebug in one browser tab, while having other windows open of the same page for different break points, the other pages display breaks and requires a refresh to fix. Possibly an issue with Chrome rendering?

    Also a request. Would it be possible to have the code location scroll to the edited style in Sublime? And what about the reverse in Firebug? Currently when I edit a style in Firebug the Sublime CSS file scrolls to line 1.

  25. 50

    Amazing tool even if you’re a beginner, this could raise your level astonishingly quick!

  26. 51

    Sounds interesting. Though SASS and other code editores should be supported before it fully fits into my workflow.

    In the meantime, if you have never used it, I would suggest you to try the SoFresh bookmarklet ( ). It cannot be any simpler, and it also gives you live feedback about any CSS change.

    • 52

      SoFresh provides no “live feedback” like you have it with LiveStyle or Espresso (CSSEdit).

      Live feedback means (at least for me) that you see the changes as you type without the need to save the file.

  27. 53

    Guys, you can do this all much easier and for free using Chrome native experiments ‘Workspaces’ and integrating ‘Grunt’ for LiveReload and even better capabilities than mentioned in this article, it’s open source. I highly recommend everyone checkout this screencast and tools download to get started:

  28. 54

    Knowing how stable and convinient Emmet Plugin is I expect this one to be just as good. So please please please add Brackets and Firefox support in the future! =)

  29. 55

    Very nice extension, will try it soon!

  30. 56

    Just amazing.. cant wait to get my hands dirty!

  31. 57

    Just tried this myself, works like a charm. Thank you very much for the detailed article.

    I was at first getting issues in my Sublime log:

    Emmet LiveStyle: No suitable client for diff

    All I needed to do was restart Chrome to fix this.

  32. 58

    Alvin Vogelzang

    October 29, 2013 1:22 am

    Can someone explain me why tools like this are only focused on CSS and not combined with HTML?

    • 59

      agreed, can’t wait to see html + css live editing!

      please, think about it in future, Sergei!


↑ Back to top