# Dabblet

Published articles for Dabblet.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## URL rewriting with Github Pages

DevFeed: [URL rewriting with Github Pages](<https://devfeed.tech/articles/url-rewriting-with-github-pages-52097.md>)

Original publisher: [Read original article](<https://lea.verou.me/2016/11/url-rewriting-with-github-pages/>)

Author: Lea Verou

Published: 2016-11-26T00:00:00Z

Content type: article

Language: en

Sources: [Lea Verou's blog](<https://devfeed.tech/sources/lea-verou-s-blog.md>)

Topics: [GitHub Pages](<https://devfeed.tech/topics/github-pages.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Website](<https://devfeed.tech/topics/website.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [JSON](<https://devfeed.tech/topics/json.md>), [Single-page application (SPA)](<https://devfeed.tech/topics/spa.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [css-secrets](<https://devfeed.tech/tags/css-secrets.md>), [dabblet](<https://devfeed.tech/tags/dabblet.md>), [demo](<https://devfeed.tech/tags/demo.md>), [github](<https://devfeed.tech/tags/github.md>), [github-pages](<https://devfeed.tech/tags/github-pages.md>), [html](<https://devfeed.tech/tags/html.md>), [js](<https://devfeed.tech/tags/js.md>), [json](<https://devfeed.tech/tags/json.md>), [original](<https://devfeed.tech/tags/original.md>), [redirect](<https://devfeed.tech/tags/redirect.md>), [server](<https://devfeed.tech/tags/server.md>), [tips](<https://devfeed.tech/tags/tips.md>), [url](<https://devfeed.tech/tags/url.md>)

### AI overview

The article shows how to create readable URLs on GitHub Pages without server-side code. A missing path is served through `404.html`, where Vanilla JavaScript reads the path slug and fetches a JSON map of demo IDs to Dabblet URLs. A match redirects to the mapped URL (or to a `dabblet.com/gist/` URL built from an ID); an unknown slug displays a not-found error, and a failed JSON request displays a separate error. The author suggests the same technique could redirect to other pages on the site or support URLs for a single-page site, while describing it as a hack.

### Source excerpt

I adore Github Pages. I use them for everything I can, and try to avoid server-side code like the plague, exactly so that I can use them. The convenience of pushing to a repo and having the changes immediately reflected on the website with no commit hooks or any additional setup, is awesome. The free price tag is even more awesome. So, when the time came to publish my book, naturally, I wanted the companion website to be on Github Pages. There was only one small problem: I wanted nice URLs, like http://play.csssecrets.io/pie-animated, which would redirect to demos on dabblet.com. Any sane person would have likely bitten the bullet and used some kind of server-side language. However, I'm not a particularly sane person :D Turns out Github uses some URL rewriting of its own on Github Pages: If you provide a 404.html, any URL that doesn't exist will be handled by that. Wait a second, is that basically how we do nice URLs on the server anyway? We can do the same in Github Pages, by just running JS inside 404.html! So, I created a JSON file with all demo ids and their dabblet URLs, a 404.html that shows either a redirection or an error (JS decides which one) and a tiny bit of Vanilla JS that reads the current URL, fetches the JSON file, and redirects to the right dabblet. Here it is, without the helpers: (function(){ document.body.className = 'redirecting'; var slug = location.pathname.slice(1); xhr({ src: 'secrets.json', onsuccess: function () { var slugs = JSON.parse(this.responseText); var hash = slugs[slug]; if (hash) { // Redirect var url = hash.indexOf('http') == 0? hash : 'https://dabblet.com/gist/' + hash; $('section.redirecting > p').innerHTML = 'Redirecting to <a href="' + url + '">' + url + '</a>...'; location.href = url; } else { document.body.className = 'error not-found'; } }, onerror: function () { document.body.className = 'error json'; } }); })(); That's all! You can imagine using the same trick to redirect to other HTML pages in the same Github Pages site,

## Leaving W3C

DevFeed: [Leaving W3C](<https://devfeed.tech/articles/leaving-w3c-52070.md>)

Original publisher: [Read original article](<https://lea.verou.me/2013/07/leaving-w3c/>)

Author: Lea Verou

Published: 2013-07-11T00:00:00Z

Content type: opinion

Language: en

Sources: [Lea Verou's blog](<https://devfeed.tech/sources/lea-verou-s-blog.md>)

Topics: [W3C](<https://devfeed.tech/topics/w3c.md>), [developer-relations](<https://devfeed.tech/topics/developer-relations.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Developer Events](<https://devfeed.tech/topics/developer-events.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>)

Tags: [2014](<https://devfeed.tech/tags/2014.md>), [blog](<https://devfeed.tech/tags/blog.md>), [book](<https://devfeed.tech/tags/book.md>), [client](<https://devfeed.tech/tags/client.md>), [css](<https://devfeed.tech/tags/css.md>), [css-secrets](<https://devfeed.tech/tags/css-secrets.md>), [dabblet](<https://devfeed.tech/tags/dabblet.md>), [design](<https://devfeed.tech/tags/design.md>), [developer](<https://devfeed.tech/tags/developer.md>), [developer-community](<https://devfeed.tech/tags/developer-community.md>), [developer-relations](<https://devfeed.tech/tags/developer-relations.md>), [education](<https://devfeed.tech/tags/education.md>), [github](<https://devfeed.tech/tags/github.md>), [job](<https://devfeed.tech/tags/job.md>), [leave](<https://devfeed.tech/tags/leave.md>), [leaving](<https://devfeed.tech/tags/leaving.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [open-source-projects](<https://devfeed.tech/tags/open-source-projects.md>), [personal](<https://devfeed.tech/tags/personal.md>), [plugin](<https://devfeed.tech/tags/plugin.md>), [w3c](<https://devfeed.tech/tags/w3c.md>)

### AI overview

The author decided to leave W3C after a year, with July 31 as the planned last day, while emphasizing that the choice was personal and that they valued the experience. They wanted more time for open source projects, research, writing the advanced CSS book CSS Secrets, workshops and client work, and standards participation beyond the weekly CSS Working Group call. They also wanted work that better supported professional growth. A planned shift toward WebPlatform.org--more front-end development, design and documentation--would have reduced time for public speaking and event planning, activities the author preferred. They credited W3C with valuable colleagues, public speaking and conference-organizing experience, and said they might work there again in another role.

### Source excerpt

About a year ago, I announced I was joining W3C as a full-time staff member, to work on Developer Relations and education. Working at W3C was a dream come true and I can't say I was disappointed. Over the past year I've worked with some amazingly brilliant people, hopefully increased awareness for web standards in the developer community and helped materialize the vision behind WebPlatform.org. It's been a fun ride and working for a non-profit was very fulfilling. If somebody told me a year ago that I would decide to leave W3C on my own free will, I would've asked them what they were smoking. However, our future selves often surprise us and although it was the most difficult decision of my life, I recently decided to leave. July 31st will be my last day at W3C. I will attempt to describe the reasons below for anyone interested, but in no way does me leaving mean that I don't deeply appreciate W3C or that I regretted joining. If I could go a year back, I would make the same choice. Reason #1: I want to focus on other projects I didn't have much time to work on my pet projects, as my job was consuming pretty much the entire me. This is absolutely not W3C's fault, it's mine and a pretty common side effect of working from home. Pull requests kept piling up on Github, I didn't have many ideas for new side projects or time for research & to come up with new techniques. I was able to work a bit on Dabblet and a WPD Prism plugin, as they were useful for WebPlatform.org, but for the most part, I wanted to work more on open source projects, do more research, blog more etc. I also recently signed a book deal with O'Reilly for a book on advanced CSS techniques ("CSS Secrets", ETA Spring 2014) and I wanted to take some time off and write a great inaugural book, not just a decent one (and design it too!). I also kinda missed doing workshops or even client work, who knew! Having more time will also mean I will be able to focus more on standards work, which is a huge passion of min

## Lots of improvements coming to dabblet

DevFeed: [Lots of improvements coming to dabblet](<https://devfeed.tech/articles/lots-of-improvements-coming-to-dabblet-52059.md>)

Original publisher: [Read original article](<https://lea.verou.me/2012/11/lots-of-improvements-coming-to-dabblet/>)

Author: Lea Verou

Published: 2012-11-07T00:00:00Z

Content type: release

Language: en

Sources: [Lea Verou's blog](<https://devfeed.tech/sources/lea-verou-s-blog.md>)

Topics: [Web Development](<https://devfeed.tech/topics/web-development.md>), [Syntax Highlighting](<https://devfeed.tech/topics/syntax-highlighting.md>), [User Experience](<https://devfeed.tech/topics/user-experience.md>), [User interface design](<https://devfeed.tech/topics/ui-design.md>), [developer-relations](<https://devfeed.tech/topics/developer-relations.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [browser-support](<https://devfeed.tech/tags/browser-support.md>), [bugfixes](<https://devfeed.tech/tags/bugfixes.md>), [css](<https://devfeed.tech/tags/css.md>), [dabblet](<https://devfeed.tech/tags/dabblet.md>), [github](<https://devfeed.tech/tags/github.md>), [html](<https://devfeed.tech/tags/html.md>), [improvements](<https://devfeed.tech/tags/improvements.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [news](<https://devfeed.tech/tags/news.md>), [security](<https://devfeed.tech/tags/security.md>), [support](<https://devfeed.tech/tags/support.md>), [syntax](<https://devfeed.tech/tags/syntax.md>), [the-web](<https://devfeed.tech/tags/the-web.md>), [ux](<https://devfeed.tech/tags/ux.md>), [version](<https://devfeed.tech/tags/version.md>), [w3c](<https://devfeed.tech/tags/w3c.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

To prepare dabblet for use as WebPlatform.org's hosted live-code example platform, the author was working on a set of improvements expected to roll out to dabblet.com first and be tested by the community. Planned work included JavaScript support, with execution on startup and possibly after a pause in typing rather than on every keystroke; POST-based dabblets whose data is not stored in GitHub; better cross-browser support and security; Prism integration to bring in its bug fixes; and general bug fixing. The text describes these as work in progress and says integration with WebPlatform.org would follow community testing.

### Source excerpt

I posted about this in both the WebPlatform.org blog and Dabblet's blog, but I thought it might be interesting to many readers of this blog as well: As many of you probably know, I've started working for W3C Developer Relations since this August. Half of my time is devoted to WebPlatform.org, a very promising project to document the web with the help of all major players, in a vendor-neutral way. Even before I joined W3C, we discussed using a hosted, customized version of dabblet in WebPlatform.org, as a platform for live code examples. I recently started working towards making this happen. A lot of changes and improvements need to be made to achieve this, but the good news is, most of these will be pushed to dabblet.com as well! In a nutshell, this is what I'm currently working on: Adding JavaScript support -- This will be a challenge UX-wise, as it shouldn't run on every keystroke, like the HTML and CSS, but it should run on startup and it should be straight-forward how to get it to run. Perhaps it will also run after a significant pause in typing. Dabblets that are not stored in Github, but get their data through POST requests. Improving cross-browser support Strengthening security Integrating Prism. Dabblet's syntax highlighter might have been Prism's precursor, but currently Prism has solved many of its bugs, and these fixes need to be pushed to dabblet at some point. General bug fixing These will probably be gradually rolled out in dabblet.com and tested by the community, before we integrate dabblet into WebPlatform.org. If a new feature is significant enough, there will be a new blog post about it here, but don't expect blog posts about bugfixes. I'm really excited to see dabblet flourish, and I believe you will be too, once these updates are out!

## Introducing Prism: An awesome new syntax highlighter

DevFeed: [Introducing Prism: An awesome new syntax highlighter](<https://devfeed.tech/articles/introducing-prism-an-awesome-new-syntax-highlighter-52055.md>)

Original publisher: [Read original article](<https://lea.verou.me/2012/07/introducing-prism-an-awesome-new-syntax-highlighter/>)

Author: Lea Verou

Published: 2012-07-31T00:00:00Z

Content type: release

Language: en

Sources: [Lea Verou's blog](<https://devfeed.tech/sources/lea-verou-s-blog.md>)

Topics: [Syntax Highlighting](<https://devfeed.tech/topics/syntax-highlighting.md>), [extend](<https://devfeed.tech/topics/extend.md>), [HTML](<https://devfeed.tech/topics/html.md>), [hooks](<https://devfeed.tech/topics/hooks.md>), [markup](<https://devfeed.tech/topics/markup.md>)

Tags: [addition](<https://devfeed.tech/tags/addition.md>), [also](<https://devfeed.tech/tags/also.md>), [awesome](<https://devfeed.tech/tags/awesome.md>), [best](<https://devfeed.tech/tags/best.md>), [better](<https://devfeed.tech/tags/better.md>), [blocks](<https://devfeed.tech/tags/blocks.md>), [blog](<https://devfeed.tech/tags/blog.md>), [body](<https://devfeed.tech/tags/body.md>), [but](<https://devfeed.tech/tags/but.md>), [can](<https://devfeed.tech/tags/can.md>), [class](<https://devfeed.tech/tags/class.md>), [code](<https://devfeed.tech/tags/code.md>), [core](<https://devfeed.tech/tags/core.md>), [css](<https://devfeed.tech/tags/css.md>), [dabblet](<https://devfeed.tech/tags/dabblet.md>), [days](<https://devfeed.tech/tags/days.md>), [define](<https://devfeed.tech/tags/define.md>), [doesn-t](<https://devfeed.tech/tags/doesn-t.md>), [draft](<https://devfeed.tech/tags/draft.md>), [highlighter](<https://devfeed.tech/tags/highlighter.md>), [original](<https://devfeed.tech/tags/original.md>), [releases](<https://devfeed.tech/tags/releases.md>), [syntax](<https://devfeed.tech/tags/syntax.md>)

### AI overview

Prism is presented as a small, extensible syntax highlighter released from Dabblet: its core is 1.5 KB minified and gzipped, rising to about 2 KB with the available CSS, Markup, and JS definitions. Authors mark code with semantic `<code>` elements and `language-xxxx` classes; language declarations inherit from ancestors, so a shared language can be set once. Hooks support plugins and extending languages, and Web Workers can improve performance in some cases. The excerpt says Prism strips pre-existing HTML inside code blocks and does not work in IE8, though it does not break there.

### Source excerpt

For the past three weeks, on and off, I've been working on releasing Dabblet's syntax highlighter as standalone, since many people had requested it. Zachary Forrest suggested the name "Prism" and I liked it so much I decided to go with it, even though there is an abandoned Mozilla project with the same name. I ended up refactoring and extending it so much that I will need to backport it to Dabblet one of these days! This doesn't mean I bloated it, the core is still a tiny 1.5KB minified & gzipped. It just means it's more awesome. :) Seriously? The world needs another syntax highlighter? In certain ways, Prism is better than any other syntax highlighter I've seen: It's tiny. The core is only 1.5KB minified & gzipped, which can go up to 2KB with the currently available language definitions (CSS, Markup and JS). But many other highlighters are also small, so read on. It's incredibly extensible. Not only it's easy to add new languages (that's a given with every syntax highlighter these days), but also to extend existing ones. Most importantly, it supports plugins, through hooks strategically placed in its source. There are a few plugins already available, and it's really easy to write your own. I haven't seen any other highlighter that supports plugins. It encourages good author practices. Other highlighters encourage or even force you to use elements that are semantically wrong, like <pre> (on its own) or <script>. Prism forces you to use the only semantically correct element for marking up code: <code>. On its own for inline code, or inside a <pre> for blocks of code. In addition, the code language is declared through the way recommended in the HTML5 draft: through a language-xxxx class. One of its best features: The language definition is inherited. This means that if multiple code snippets have the same language, you can just define it once, in one of their common ancestors. Obviously, if you define a language on the <body> element, you've essentially declared a def

## Dabblet blog

DevFeed: [Dabblet blog](<https://devfeed.tech/articles/dabblet-blog-52034.md>)

Original publisher: [Read original article](<https://lea.verou.me/2012/01/dabblet-blog/>)

Author: Lea Verou

Published: 2012-01-05T00:00:00Z

Content type: release

Language: en

Sources: [Lea Verou's blog](<https://devfeed.tech/sources/lea-verou-s-blog.md>)

Topics: [Tumblr](<https://devfeed.tech/topics/tumblr.md>), [HTML](<https://devfeed.tech/topics/html.md>), [User interface design](<https://devfeed.tech/topics/ui-design.md>), [markup](<https://devfeed.tech/topics/markup.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [dabblet](<https://devfeed.tech/tags/dabblet.md>), [html5](<https://devfeed.tech/tags/html5.md>), [news](<https://devfeed.tech/tags/news.md>), [personal](<https://devfeed.tech/tags/personal.md>), [wordpress](<https://devfeed.tech/tags/wordpress.md>)

### AI overview

Dabblet now has a blog for updates, with the author directing interested readers there or to @dabblet on Twitter to avoid sending updates to regular subscribers who may not care. The author chose Tumblr, praising its free custom domains, full theme control, and interface, and says customizing a theme toward HTML5 and Dabblet's style was easy. They note that most themes use older markup and mention a few shortcomings, including no titles for picture posts.

### Source excerpt

Not sure if you noticed, but Dabblet now has a blog: blog.dabblet.com I'll post there about Dabblet updates and not flood my regular subscribers here who may not care. So, if you are interested on Dabblet's progress, follow that blog or @dabblet on twitter. That was also an excuse to finally try tumblr. So far, so good. I love how it gives you custom domains and full theme control for free (hosted Wordpress charges for those). Gorgeous, GORGEOUS interface too. Most of the themes have markup from the 2005-2007 era, but that was no surprise. I customized the theme I picked to make it more HTML5-ey and more on par with dabblet's style and it was super easy (though my attempt is by no means finished). There are a few shortcomings (like no titles for picture posts), but nothing too bad.

## On web apps and their keyboard shortcuts

DevFeed: [On web apps and their keyboard shortcuts](<https://devfeed.tech/articles/on-web-apps-and-their-keyboard-shortcuts-52033.md>)

Original publisher: [Read original article](<https://lea.verou.me/2011/12/on-web-apps-and-their-keyboard-shortcuts/>)

Author: Lea Verou

Published: 2011-12-17T00:00:00Z

Content type: opinion

Language: en

Sources: [Lea Verou's blog](<https://devfeed.tech/sources/lea-verou-s-blog.md>)

Topics: [Web app](<https://devfeed.tech/topics/webapp.md>), [Interaction Design](<https://devfeed.tech/topics/interaction-design.md>), [interactive web design](<https://devfeed.tech/topics/interactive-web-design.md>), [keyboard](<https://devfeed.tech/topics/keyboard.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [browser](<https://devfeed.tech/tags/browser.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [dabblet](<https://devfeed.tech/tags/dabblet.md>), [editor](<https://devfeed.tech/tags/editor.md>), [keyboard-shortcuts](<https://devfeed.tech/tags/keyboard-shortcuts.md>), [memory](<https://devfeed.tech/tags/memory.md>), [native](<https://devfeed.tech/tags/native.md>), [navigation](<https://devfeed.tech/tags/navigation.md>), [thoughts](<https://devfeed.tech/tags/thoughts.md>), [usability](<https://devfeed.tech/tags/usability.md>), [ux](<https://devfeed.tech/tags/ux.md>), [web-apps](<https://devfeed.tech/tags/web-apps.md>)

### AI overview

The author argues that web apps should often honor familiar application shortcuts because users can rely on existing muscle memory, while app-specific alternatives take time to learn and may conflict with shortcuts used elsewhere. In a web app, users may expect a command such as Cmd+S to act on the app rather than the browser. The author distinguishes this from magazine-style sites, where the browser remains the app and overriding its shortcuts is inappropriate. The excerpt also presents a compromise from Yahoo! Mail: override a browser shortcut when its action does not fit the app (such as Cmd-P for printing), but retain browser behavior for others. For tab navigation, the proposed experiment is to handle Cmd-number within the page and let the shortcut reach the browser when the selected tab is already at the relevant boundary.

### Source excerpt

Yesterday, I released dabblet. One of its aspects that I took extra care of, is it's keyboard navigation. I used many of the commonly established application shortcuts to navigate and perform actions in it. Some of these naturally collided with the native browser shortcuts and I got a few bug reports about that. Actually, overriding the browser shortcuts was by design, and I'll explain my point of view below. Native apps use these shortcuts all the time. For example, I press Cmd+1,2,3 etc in Espresso to navigate through files in my project. People press F1 for help. And so on. These shortcuts are so ingrained in our (power users) minds and so useful that we thoroughly miss them when they're not there. Every time I press Cmd+1 in an OSX app and I don't go to the first tab, I'm distraught. However, in web apps, these shortcuts are taken by the browser. We either have to use different shortcuts or accept overriding the browser's defaults. Using different shortcuts seems to be considered best practice, but how useful are these shortcuts anyway? They have to be individually learned for every web app, and that's hardly about memorizing the "keyboard shortcuts" list. Our muscles learn much more slowly than our minds. To be able to use these shortcuts as mindlessly as we use the regular application shortcuts, we need to spend a long time using the web app and those shortcuts. If we ever do get used to them that much, we'll have trouble with the other shortcuts that most apps use, as our muscles will try to use the new ones. Using the de facto standard keyboard shortcuts carries no such issues. They take advantage of muscle memory from day one. If we advocate that web is the new native, it means our web apps should be entitled to everything native apps are. If native editors can use Cmd+1 to go to the first tab and F1 for help, so should a web editor. When you're running a web app, the browser environment is merely a host, like your OS. The focus is the web app. When you're

## Introducing dabblet: An interactive CSS playground

DevFeed: [Introducing dabblet: An interactive CSS playground](<https://devfeed.tech/articles/introducing-dabblet-an-interactive-css-playground-52032.md>)

Original publisher: [Read original article](<https://lea.verou.me/2011/12/introducing-dabblet-an-interactive-css-playground/>)

Author: Lea Verou

Published: 2011-12-15T00:00:00Z

Content type: release

Language: en

Sources: [Lea Verou's blog](<https://devfeed.tech/sources/lea-verou-s-blog.md>)

Topics: [CSS](<https://devfeed.tech/topics/css.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [interactive web design](<https://devfeed.tech/topics/interactive-web-design.md>), [Front end](<https://devfeed.tech/topics/frontend.md>), [real-time](<https://devfeed.tech/topics/real-time.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Cross-origin resource sharing (CORS)](<https://devfeed.tech/topics/cors.md>), [Media Queries](<https://devfeed.tech/topics/media-queries.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [css](<https://devfeed.tech/tags/css.md>), [dabblet](<https://devfeed.tech/tags/dabblet.md>), [interactive](<https://devfeed.tech/tags/interactive.md>), [original](<https://devfeed.tech/tags/original.md>), [playground](<https://devfeed.tech/tags/playground.md>), [releases](<https://devfeed.tech/tags/releases.md>)

### AI overview

Dabblet is an interactive playground for CSS and HTML experiments, built to provide immediate feedback and more flexible demos than the author found in JSFiddle. It updates CSS and HTML in real time without a save or reload, stores work in GitHub gists, and can add CSS prefixes automatically with -prefix-free. It also offers inline previews for values such as colors and gradients, keyboard shortcuts for adjusting lengths, times, and angles, and multiple code/result layouts that can be saved as preferences or with a gist. Embedded demos remain editable. The author describes the release as an alpha: it only works in modern CORS-enabled browsers, has limited mobile support, cannot yet add scripts such as LESS or remove -prefix-free, and does not provide links to older versions within dabblet (though GitHub can show them).

### Source excerpt

I loved JSFiddle ever since I first used it. Being able to test something almost instantly and without littering my hard drive opened new possibilities for me. I use it daily for experiments, browser bug testcases, code snippet storage, code sharing and many other things. However, there were always a few things that bugged me: JSFiddle is very JS oriented, as you can tell even from the name itself JSFiddle is heavily server-side so there's always at least the lag of an HTTP request every time you make an action. It makes sense not to run JS on every keystroke (JSBin does it and it's super annoying, even caused me to fall in an infinite loop once) but CSS and HTML could be updated without any such problems. I'm a huge tabs fan, I hate spaces for indenting with a passion. Every time I want to test a considerable amount of CSS3, I need to include -prefix-free as a resource and I can't save that preference or any other (like "No library"). Don't get me wrong, I LOVE JSFiddle. It was a pioneer and it paved the way for all similar apps. It's great for JavaScript experiments. But for pure CSS/HTML experiments, we can do better. The thought of making some interactive playground for CSS experiments was lingering in my mind for quite a while, but never attempted to start it as I knew it would be a lot of fascinating work and I wouldn't be able to focus on anything else throughout. While I was writing my 24ways article, I wanted to include lots of CSS demos and I wanted the code to be editable and in some cases on top of the result to save space. JSFiddle's embedding didn't do that, so I decided to make something simple, just for that article. It quickly evolved to something much bigger, and yes I was right, it was lots of fascinating work and I wasn't able to focus on anything else throughout. I even delayed my 24ways article for the whole time I was developing it, and I'm grateful that Drew was so patient. After 3 weeks of working on it, I present dabblet. Features So what d