Every time you call a proprietary feature “CSS3″, a kitten dies

Some comments about it on twitter:

What you think is CSS3, really may *not* be. How #CSS3 was infiltrated under a -webkit- cloak! http://t.co/BKgh0Ehf

February 14, 2012 16:13 via SGPlusReplyRetweetFavorite

@kkmett

Keith Kmett, CUA

Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies - http://t.co/8dfmh93u

February 14, 2012 16:19 via TweetDeckReplyRetweetFavorite

@codepo8

Christian Heilmann

Sing it, @leavrou "…proprietary features of today are no better than ActiveX & IE filters…only difference is better PR" http://t.co/TWVTAtSQ

February 14, 2012 16:20 via webReplyRetweetFavorite

@lydiamann

lydiamann

✩ Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies by @leaverou. http://t.co/V2iKffE8 #webkit #mustread #css3

February 14, 2012 16:22 via Tweet ButtonReplyRetweetFavorite

@zeldman

Jeffrey Zeldman

Lea Verou: Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies. http://t.co/8ILOQtQz #css3 #webstandards

February 14, 2012 16:23 via Twitterrific for MacReplyRetweetFavorite

@alistapart

A List Apart

Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies: Lea Verou in a special issue of @alistapart. http://t.co/6pcX26Ob

February 14, 2012 16:24 via Twitterrific for MacReplyRetweetFavorite

@happycog

Happy Cog™

Eye opening for me at least, had no idea some features in CSS3 where make believe http://t.co/vkHk5bEZ

February 14, 2012 16:33 via webReplyRetweetFavorite

@AlanBWhitney

Alan Whitney

I <3 new @alistapart articles: Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies http://t.co/IRaoGpJx #webstandards

February 14, 2012 16:38 via webReplyRetweetFavorite

@LeftyDesigner

Shannon Mølhave

I'm in love with the Valintine's Day issue of @alistapart. @LeaVerou is awesome. http://t.co/EZcU79Bd

February 14, 2012 16:48 via Twitter for MacReplyRetweetFavorite

@dap6000

Derek Pennycuff

Save teh kitteh (and teh web): Every time you call a proprietary feature “CSS3” a kitten dies, by @LeaVerou: http://t.co/uW7Lz6Q1

February 14, 2012 16:55 via Twitter for MacReplyRetweetFavorite

@martuishere

Marta Armada

Important Read! — Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies: http://t.co/T3HX6tYy

February 14, 2012 17:25 via Tweet ButtonReplyRetweetFavorite

@rachelober

Rachel Ober

Also on #ALA, @LeaVerou on the difference between CSS and WebKit and what it means for kittens http://t.co/OhOnSiWZ

February 14, 2012 17:30 via webReplyRetweetFavorite

@sgalineau

Sylvain Galineau

A List Apart on -webkit- css - http://t.co/wTGRIG5a - remember, the last time vendors ignored standards groups... we got a decade of IE6

February 14, 2012 17:50 via chrome-shareReplyRetweetFavorite

@sdague

Sean Dague

A cautionary tale of modern browsers: Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies: http://t.co/ynWIpbZN

February 14, 2012 18:01 via Tweet ButtonReplyRetweetFavorite

@whitman

Bobby Whitman

Go and read what @LeaVerou says about proprietary features, #CSS3 and kittens. http://t.co/4ogWcjwt

February 14, 2012 18:20 via webReplyRetweetFavorite

@peterwinnberg

Peter Winnberg

Before you disagree with me, just read this: http://t.co/pztTosp1 I'm so pissed off at @LeaVerou for being so damn talented. Great article.

February 14, 2012 19:09 via TweetDeckReplyRetweetFavorite

@cssquirrel

Kyle Weems

@LeaVerou nails it. http://t.co/H07y5AQJ Seems like we keep fighting the same battles. #css #standards

February 14, 2012 19:38 via webReplyRetweetFavorite

@jameswillweb

james williamson

Excellent couple articles on vendor prefixes at ALA: http://t.co/uz6zA7FW, http://t.co/MSKZVm4a. Brace yourself before reading comments tho.

February 14, 2012 20:06 via webReplyRetweetFavorite

@rogerjohansson

Roger Johansson

@LeaVerou great #ala article http://t.co/gCtSokC7 and the best possible followup for recent misunderstandings. Keep up the good work.

February 14, 2012 20:37 via webReplyRetweetFavorite

@beardChamp

Tim McElwee

And that brings us to the other thing that made me sad these days. 2 days ago, the CSS WG published its Minutes (sorta like a meeting) and I was surprised to hear that I’ve been mentioned. My surprise quickly turned into this painful feeling in your stomach when you’re being unfairly accused:

tantek: Opposite is happening right now. Web standards activists are teaching
 people to use -webkit-
tantek: People like Lea Verou.
tantek: Their demos are filled with -webkit-. You will see presentations
 from all the web standards advocates advocating people to use
 -webkit- prefixes.

Try to picture being blamed of the very thing you hate, and you might understand how that felt. I’ve always been an advocate of inclusive CSS coding that doesn’t shut down other browsers. It’s good for future-proofing, it’s good for competition and it’s the right thing to do. Heck, I even made a popular script to help people adding all prefixes! I’m even one of the few people in the industry who has never expressed a definite browser preference. I love and hate every browser equally, as I can see assets and defects in all of them (ok, except Safari. Safari must die ).

When Tantek realized he had falsely accused me of this, he corrected himself in the #css IRC room on w3.org:

[17:27] <tantek> (ASIDE: regarding using -webkit- prefix, clarification re: Lea Verou - she's advocated using *both* vendor prefixed properties (multiple vendors) and the unprefixed version after them. See her talk http://www.slideshare.net/LeaVerou/css3-a-practical-introduction-ft2010-talk from Front-Trends 2010 for example. An actual example of -webkit- *only* prefix examples (thus implied advocacy) is Google's http://slides.html5rocks.com/ , e.g.
[17:27] <tantek> http://slides.html5rocks.com/#css-columns has three -webkit- property declarations starting with -webkit-column-count )

That’s nice of him, and it does help. At least I had a link to give to people who kept asking me on twitter if I was really the prefix monster he made me out to be. The problem is that not many read the IRC logs, but many more read the www-style archives. Especially since, with all this buzz, many people were directed into reading this discussion by the above articles. I don’t know how many people will be misled by Tantek’s uninformed comment without reading his correction, but I know for sure that the number is non-zero. And the worst of all is that many of them are people in the CSSWG or in the W3C in general,  people who I have great respect and admiration for. And quite frankly, that sucks.

I don’t think Tantek had bad intentions. I’ve met him multiple times and I know he’s a nice guy. Maybe he was being lazy by making comments he didn’t check, but that’s about it. It could happen to many people. My main frustration is that it feels there is nothing I can do about it, besides answering people when they take the time to talk to me about it. I can do nothing with the ones that won’t, and that’s the majority. At least, if a forum was used over a mailing list, this could’ve been edited or something.

So, even though this solution was better, I wasn’t fully satisfied with it due to the need for the extra element. So, it kept being stuck in the back of my head.

Recently, I suggested to www-style that transform-origin should be a list and accept multiple origins and presented this example as a use case. And then Aryeh Gregor came up with this genius idea to prove that it’s already possible if you chain translate() transforms between the opposite rotates.

I simplified the code a bit, and here it is:

With the tools we currently have, I don’t think it gets any simpler than that.

Today I decided to simplify it a bit and make it more flexible, at the cost of browser support. The new version fully works in Firefox 1+ and IE10, since Opera and WebKit don’t support the ch unit and even though IE9 supports it, it doesn’t support CSS animations.

To put it simply, one ch unit is equivalent to the width of the zero (0) character of the font. So, in monospace fonts, it’s equivalent to the width of every character, since every character has the same width.

In the new version, we don’t need an obscuring span, so no extra HTML and it will work with non-solid backgrounds too. Also, even though the number of characters still needs to be hard-coded, it doesn’t need to be hardcoded in the animation any more, so it could be easily done through script without messing with creating/modifying stylesheets. Note how each animation only has one keyframe, and takes advantage of the fact that when the from (0%) and to (100%) keyframes are missing, the browser generates them from the fallback styles. I use this a lot when coding animations, as I hate duplication.

In browsers that support CSS animations, but not the ch unit (such as WebKit based browsers), the animation will still occur, since we included a fallback in ems, but it won’t be 100% perfect. I think that’s a pretty good fallback, but if it bothers you, just declare a fallback of auto (or don’t declare one at all, and it will naturally fall back to auto). In browsers that don’t support CSS animations at all (such as Opera), the caret will be a solid black line that doesn’t blink. I thought that’s better than not showing it at all, but if you disagree, it’s very easy to hide it in those browsers completely: Just swap the border-color between the keyframe and the h1 rule (hint: when a border-color is not declared, it’s currentColor).

Edit: It appears that Firefox’s support for the ch unit is a bit buggy so, the following example won’t work with the Monaco font for example. This is not the correct behavior.

Enjoy:

How it works

css3test (very superficially) tests pretty much everything in the specs mentioned on the sidebar (not just the popular widely implemented stuff). You can click on every feature to expand it and see the exact the testcases run and whether they passed. It only checks what syntax the browser recognizes, which doesn’t necessarily mean it will work correctly when used. WebKit is especially notorious for cheating in tests like this, recognizing stuff it doesn’t understand, like the values “round” and “space” for background-repeat, but the cheating isn’t big enough to seriously compromise the test.

Whether a feature is supported with a prefix or not doesn’t matter for the result. If it’s supported without a prefix, it will test that one. If it’s supported only with a prefix, it will test the prefixed one. For properties especially, if an unprefixed one is supported, it will be used in all the tests.

Only stuff that’s in a W3C specification is tested. So, please don’t ask or send pull requests for proprietary things like -webkit-gradient() or -webkit-background-clip: text; or -webkit-box-reflect and so on.

Every feature contributes the same to the end score, as well as to the score of the individual spec, regardless of the number of tests it has.

Crazy shit

Chrome may display slightly different scores (1% difference) across pageloads. It seems that for some reason, it fails the tests for border-image completely on some pageloads, which doesn’t make any sense. Whoever wants to investigate, I’d be grateful.
Edit: Fixed (someone found and submitted an even crazier workaround.).

Browserscope

This is the first project of mine in which I’ve used browserscope. This means that your results will be sent over to its servers and aggreggated. When I have enough data, I’m gonna built a nice table for everyone to see In the meantime, check the results page.

It doesn’t work on my browser, U SUCK!

The test won’t work on dinosaur browsers like IE8, but who cares measuring their CSS3 support anyway? “For a laugh” isn’t a good enough answer to warrant the time needed.

If you find a bug, please remember you didn’t pay a dime for this before nagging. Politely report it on Github, or even better, fix it and send a pull request.

Why did you build it?

To motivate browsers to support the less hyped stuff, because I’m tired of seeing the same things being evangelized over and over. There’s much more to CSS3.

Current results

At the time of this writing, these are the results for the major modern browsers:

• Chrome Canary, WebKit nightlies, Firefox Nightly: 64%
• Chrome, IE10PP4: 63%
• Firefox 10: 61%
• Safari 5.1, iOS5 Safari: 60%
• Opera 11.60: 56%
• Firefox 9: 58%
• Firefox 6-8: 57%
• Firefox 5, Opera 11.1 – 11.5: 55%
• Safari 5.0: 54%
• Firefox 4: 49%
• Safari 4: 47%
• Opera 10: 45%
• Firefox 3.6: 44%
• IE9: 39%

Enjoy! css3test.com Fork css3test on Github Browserscope results

Tabs take up less space

Yes, this might be an insignificant difference after gzipping and a nonexistent one after minification. But it means you need these processes to keep your code size reasonable. You depend on them, for no reason. Comments for example are useful, and it’s worth having them even if you knew you couldn’t minify or gzip your code. Tabs could do the same thing as spaces, so you’re just bloating your code for no reason.

Tabs can be personalized

The width of a tab character can be adjusted per editor. This is not a disadvantage of tabs as commonly evangelized, but a major advantage. People can view your code in the way they feel comfortable with, not in the way *you* prefer. Tabs decouple the code’s presentation from its logic, just like CSS decouples presentation from HTML. They give more power to the reader rather than letting the author control everything. Basically, using spaces is like saying “I don’t give a rat’s ass about how you feel more comfortable reading code. I will force you to use my preferences because it’s my code”.

Tabs are better for collaboration

Personalization is incredibly valuable when a team is collaborating, as different coders can have different opinions. Some coders prefer their indents to be 2 spaces wide, some coders prefer them to be 4 spaces wide. Rather than manually or automatically converting the code post-pull, and then back pre-commit, it would be adjusted automatically, depending on the editor’s tab-width setting, so every coder could start editing right away, with their favorite type of indent.

You don’t depend on certain tools

When using spaces, you depend on your editor to hide the fact that an indent is actually N characters instead of one. You depend on your editor to insert N spaces every time you press the Tab key and to delete N characters every time you press backspace or delete near an indent. When you have to use something that’s not your editor (for example when writing a snippet of code on a webapp that embeds something like codemirror) you will have to face the ugliness of your decision. Especially with codemirror, everyone else will have to face the ugliness of spaces too, as it converts tabs to spaces

Tabs are easy to select

Assume for some reason you want to select all indents and double them or convert them to spaces. This is very easy with tabs, because that’s their sole meaning. Tabs were invented for this sort of thing. Spaces on the other hand, have many meanings, so you can’t just find & replace space characters. And how do we usually call the practice of using things for a different purpose than they were made for? Yup, that’s right, using spaces for indentation is a hack.

Code indented with tabs is easier to copy & paste

As pointed out by Norbert Süle in the comments, when you copy and paste code that’s indented with spaces, you have to manually adjust the indentation afterwards, unless the other person also happens to prefer the same width indents as you. With tabs, there is no such issue, as it’s always tabs so it will fit in with your (tabbed) code seamlessly. The world would be a better place if everyone used tabs.

But what about the web? Tabs are super wide there!

This used to be a big problem, and even the enlightened coders that prefer tabs usually convert them to spaces before posting code online. However, CSS3 solves this problem, with the tab-size property. It’s supported by Opera, Firefox and very soon by WebKit too. It also degrades gracefully: The code is less pretty, but still perfectly readable.

Are spaces always evil?

Spaces are the best choice for aligning, rather than indenting. For example, in the following code snippet:

var x = 10,
    y = 0;

you need 4 spaces to make the variables line up. If you used tabs, they would only line up when the tab width is 4 and the formatting would look messed up in every other case. However, if this code snippet was also indented, the indents could (and should) still be tabs.

Another example is aligning CSS3 properties with different vendor prefixes. The indent should be done with tabs, but the aligning with spaces, like so:

div {
	-webkit-transition: 1s;
	   -moz-transition: 1s;
	    -ms-transition: 1s;
	     -o-transition: 1s;
	        transition: 1s;
}

It’s just a pointless detail, are you seriously that obsessed?

Um, ok I am exaggerating a bit when I say how spaces suck. I do think they suck, although I admit the world has much bigger problems than coders who use spaces for indentation.

For example, coders that don’t name their variables properly. Or the ones that prefer Emacs over Vim

Further reading

• Indentation With Spaces Considered Harmful
• Tabs vs spaces for code indentation
• Why I love having tabs in source code
• Tabs vs spaces
• Relevant: Elastic tabstops

Blogs are excellent places for new year’s resolutions. Posts stay there for years, to remind you what you’ve been thinking long ago. A list on a piece of paper or a file in your computer will be forgotten and lost, but a resolution on your blog will come back to haunt you. Sometimes you want that extra push. I’m not too fond of new year’s resolutions and this may as well be my first, but this year there are certain goals I want to achieve, unlike previous years were things were more fluid.

So, in 2012 I want to…

• Land my dreamjob in a US company I respect
• Get the hell out of Greece and move to the Bay Area
• Strive to improve my english even more, until I sound and write like a native speaker
• Find a publisher I respect that’s willing to print in full color and write my first book.
• Stop getting into stupid fights on twitter. They are destructive to both my well-being and my creativity.
• Get my degree in Computer Science. This has been my longest side project, 4 years and counting.

We can’t do templating across pages

Before rushing to tell me “no, we can”, keep reading. I mean have different files and re-use them accross different pages. For example, a header and a footer. If our project is entirely client-side, we have to repeat them manually on every page. Of course, we can always use (i)frames, but that solution is worse than the problem it solves. There should be a simple way to inject HTML from another file, like server-side includes, but client-side. without using JavaScript at all, this is a task that belongs to HTML (with JS we can always use XHR to do it but…). The browser would then be able to cache these static parts, with significant speed improvements on subsequent page loads.

We can’t do localization

At least not in a sane, standard way. Client-side localization is a big PITA. There should be an API for this. That would have the added advantage that browsers could pick it up and offer a UI for it. I can’t count the number of times I’ve thought a website didn’t have an English version just because their UI was so bad I couldn’t find the switcher. Google Chrome often detects a website language and offers to translate it, if such an API existed we could offer properly translated versions of the website in a manner detectable by the browser.

Update: We have the ECMAScript Globalization API, although it looks far from ideal at the moment.

We can’t do screen capture

And not just of the screen, but we can’t even capture an element on the page and draw it on a canvas unless we use huge libraries that basically try to emulate a browser or SVG foreignObject which has its own share of issues. We should have a Screen Capture API, or at the very least, a way to draw DOM nodes on canvas. Yes, there are privacy concerns that need to be taken care of, but this is so tremendously useful that it’s worth the time needed to go intro researching those.

We can’t get POST parameters and HTTP headers

There’s absolutely NO way to get the POST parameters or the HTTP response headers that the current page was sent with. You can get the GET parameters through the location object, but no way to get POST parameters. This makes it very hard to make client-side applications that accept input from 3rd party websites when that input is too long to be on the URL (as is the case of dabblet for example).

We can’t make peer to peer connections

There is absolutely no way to connect to another client running our web app (to play a game for example), without an intermediate server.

Anything else we still can’t do and we still don’t have an API to do so in the future? Say it in the comments!

Or, if I’m mistaken about one of the above and there is actually an active spec to address it, please point me to it!

Why would you want to do these things client-side?!

Everything that helps take load away from the server is good. The client is always one machine, everything on the server may end up running thousands of times per second if the web app succeeds, making the app slow and/or costly to run. I strongly believe in lean servers. Servers should only do things that architecturally need a server (e.g. centralized data storage), everything else is the client’s job. Almost everything that we use native apps for, should (and eventually will) be doable by JavaScript.

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.

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 working in a web app and you press a keyboard shortcut, chances are you’re looking to interact with that app, not with the browser Chrome.

For example, I’m currently writing in WordPress’ editor. When I press Cmd+S, I expect my draft to be saved, not the browser to attempt to save the current HTML page. Would it make sense if they wanted to be polite and chose a different shortcut, like Alt+S? I would have to learn the Save shortcut all over again and I’d forever confuse the two.

Of course, it depends on how you define a web app. If we’re talking about a magazine website for example, you’re using the browser as a kind of reader. The app you’re using is still the browser, and overriding its keyboard shortcuts is bad. It’s a sometimes fine distinction, and many disagreements about this issue are basically disagreements about what constitutes a web app and how much of an application web apps are.

So, what are your thoughts? Play it safe and be polite to the host or take advantage of muscle memory?

Edit: Johnathan Snook posted these thoughts in the comments, and I thought his suggested approach is pure genius and every web UX person should read it:

On Yahoo! Mail, we have this same problem. It’s an application with many of the same affordances of a desktop application. As a result, we want to have the same usability of a desktop application—including with keyboard shortcuts. In some cases, like Cmd-P for printing, we’ll override the browser default because the browser will not have the correct output.

For something like tab selection/editing, we don’t override the defaults and instead, create alternate shortcuts for doing so.

One thing I suggest you could try is to behave somewhat like overflow areas in a web page. When you scroll with a scroll mouse or trackpad in the area, the browser will scroll that area until it reaches it’s scroll limit and then will switch to scrolling the entire page. It would be interesting to experiment with this same approach with other in-page mechanisms. For example, with tabs, I often use Cmd-Shift-[ and Cmd-Shift-] to change tabs (versus Cmd-1/2/3, etc). You could have it do so within the page until it hits its limit (first tab/last tab) and then after that, let the event fall back to the browser. For Cmd-1, have it select the first tab. If the user is already on the first tab, have it fall back to the browser.

• 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”).

Features

So what does dabblet have that similar apps don’t? Here’s a list:

• Realtime updates, no need to press a button or anything
• Saves everything to Github gists, so even if dabblet goes away (not that I plan to!) you won’t lose your data
• No page reloads even on saving, everything is XHR-ed
• Many familiar keyboard shortcuts
• Small inline previewers for many kinds of CSS values, in particular for: colors, absolute lengths, durations, angles, easing functions and gradients. Check them all in this dabblet.
• Automatically adds prefixes with -prefix-free, to speed up testing
• Use the Alt key and the up/down arrows to increment/decrement <length>, <time> and <angle> values.
• Dabblet is open source under a NPOSL 3.0 license
• You can save anonymously even when you are logged in
• Multiple view modes: Result behind code, Split views (horizontal or vertical), separate tabs. View modes can be saved as a personal preference or in the gists (as different demos may look better with different view modes)
• Editable even from an embedded iframe (to embed just use the same dabblet URL, it will be automatically adjusted through media queries)

Examples

Here are some dabblets that should get you started:

• http://dabblet.com/gist/1441328
• http://dabblet.com/gist/1454230
• http://dabblet.com/gist/1454409
• http://dabblet.com/gist/1457668
• http://dabblet.com/gist/1457677
• http://dabblet.com/gist/1421054
• http://dabblet.com/gist/1454889

Credits

Roman Komarov helped tremendously by doing QA work on dabblet. Without his efforts, it would have been super buggy and much less polished.

I’d also like to thank David Storey for coming up with the name “dabblet” and for his support throughout these 3 weeks.

Last but not least, I’d also like to thank Oli Studholme and Rich Clark for promoting dabblet in their .net magazine articles even before its release.

Update: Dabblet has its own twitter account now: Follow @dabblet

Discussion about prefixes was recently stirred up again by an article by Henri Sivonen, so the CSS WG started debating for the 100th time about when features should become unprefixed.

I think we need to think out of the box and come up with new strategies to solve the issues that vendor prefixes were going to fix. Vendor prefixes have failed and we can’t solve their issues by just unprefixing properties more early.

Issues

The above might seem a bold statement, so let me try to support it by recapping the serious issues we run into with vendor prefixes:

1. Unnecessary bloat

Authors need to use prefixes even when the implementations are already interoperable. As a result, they end up pointlessly duplicating the declarations, making maintenance hard and/or introducing overhead from CSS pre- and post-processors to take care of this duplication. We need to find a way to reduce this bloat to only the cases where different declarations are actually needed.

2. Spec changes still break existing content

The biggest advantage of the current situation was supposed to be that spec changes would not break existing content, but prefixes have failed to even do this. The thing is, most authors will use something if it’s available, no questions asked.  I doubt anyone that has done any real web development would disagree with that. And in most cases, they will prefer a slightly different application of a feature than none at all, so they use prefixed properties along with unprefixed. Then, when the WG makes a backwards-incompatible change, existing content breaks.

I don’t think this can really be addressed in any way except disabling the feature by default in public builds. Any kind of prefix or notation is pointless to stop this, we’ll always run into the same issue. If we disable the feature by default, almost nobody will use it since they can’t tell visitors to change their browser settings. Do we really want that? Yes, the WG will be able to make all the changes they want, but then then who will give feedback for these changes? Certainly not authors, as they will effectively have zero experience working with the feature as most of them don’t have the time to play around with features they can’t use right now.

I think we should accept that changes will break *some* existing content, and try to standardize faster, instead of having tons of features in WD limbo. However, I still think that there should be some kind of notation to denote that a feature is experimental so that at least authors know what they’re getting themselves into by using it and for browsers to be able to experiment a bit more openly. I don’t think that vendor prefixes are the right notation for this though.

3. Web development has become a popularity contest

I’ll explain this with an example: CSS animations were first supported by WebKit. People only used the -webkit- prefix with them and they were fine with it. Then Firefox also implemented them, and most authors started adding -moz- to their use cases. Usually only to the new ones, their old ones are still WebKit only. After a while, Microsoft announced CSS animations in IE10. Some authors started adding -ms- prefixes to their new websites, some others didn’t because IE10 isn’t out yet. When IE10 is out, they still won’t add it because their current use cases will be for the most part not maintained any more. Some authors don’t even add -ms- because they dislike IE. Opera will soon implement CSS animations. Who will really go back and add -o- versions? Most people will not care, because they think Opera has too little market share to warrant the extra bloat.

So browsers appear to support less features, only because authors have to take an extra step to explicitly support them. Browsers do not display pages with their full capabilities because authors were lazy, ignorant, or forgetful. This is unfair to both browser vendors and web users. We need to find a way to (optionally?) decouple implementation and browser vendor in the experimental feature notation.

Ideas

There is a real problem that vendor prefixes attempted to solve, but vendor prefixes didn’t prove out to be a good solution. I think we should start thinking outside the box and propose new ideas instead of sticking to vendor prefixes and debating their duration. I’ll list here a few of my ideas and I’m hoping others will follow suit.

1. Generic prefix (-x- or something else) and/or new @rule

A generic prefix has been proposed before, and usually the argument against it is that different vendors may have incompatible implementations. This could be addressed at a more general level, instead of having the prefix on every feature: An @-rule for addressing specific vendors. for example:

@vendor (moz,webkit,o) {
    .foo { -x-property: value; }
}

@vendor (ms) {
    .foo { -x-property: other-value; }
}

A potential downside is selector duplication, but remember: The @vendor rule would ONLY be used when implementations are actually incompatible.

Of course, there’s the potential for misuse, as authors could end up writing separate CSS for separate browsers using this new rule. However, I think we’re in a stage where most authors have realized that this is a bad idea, and if they want to do it, they can do it now anyway (for example, by using @-moz-document to target Moz and so on)

2. Supporting both prefixed and unprefixed for WD features

This delegates the decision to the author, instead of the WG and implementors. The author could choose to play it safe and use vendor prefixes or risk it in order to reduce bloat on a per-feature basis.

I guess a problem with this approach is that extra properties mean extra memory, but it’s something that many browsers already do when they start supporting a property unprefixed and don’t drop the prefixed version like they should.

Note: While this post was still in draft, I was informed that Alex Mogilevsky has suggested something very similar. Read his proposal.

3. Prefixes for versioning, not vendors

When a browser implements a property for the first time, they will use the prefix -a-. Then, when another browser implements that feature, they look at the former browser’s implementation, and if theirs is compatible, they use the same prefix. If it’s incompatible, they increment it by one, using -b- and so on.

A potential problem with this is collisions: Vendors using the same prefix not because their implementations are compatible but because they developed them almost simultaneously and didn’t know about each other’s implementation. Also, it causes trouble for the smaller vendors that might want to implement a feature first.

We need more ideas

Even if the above are not good ideas, I’m hoping that they’ll inspire others to come up with something better. I think we need more ideas about this, rather than more debates about fine-tuning the details of one bad solution.

It’s essentially a gallery of basic transitions. It aims to show how different animatable properties look when they transition and to broaden our horizons about which properties can be animated. Hover over the demos to see the animation in action, or click “Animate All” to see all of them (warning: might induce nausea, headache and seizures ). You can also click on it to see more details and get a permalink. Instead of clicking, you can also navigate with the arrow keys and press Esc to return to the main listing.

Fork it on Github and add your own ideas. Be sure to add your twitter username to them as a data-author attribute!

I’ve only tested in Firefox and Chrome for OSX so far. Not sure which other browsers are supported. However, since it uses CSS animations, we know for sure that it won’t work in browsers that don’t support CSS animations.

Hope you enjoy it

FromTheFront

This was a rather low-budget Italian conference that took place in Cesena, a city near Bologna. Despite the extremely low ticket price, they managed to pull off a very decent one day conference, which is very admirable. Italian food is so good that I’d recommend visiting this country even if it’s just for the food! They were very nice hosts, and I thoroughly enjoyed my time there.

My talk was right after Jeremy Keith‘s, who is a very well-known and experienced speaker that knows how to make audiences delirious (in a good way), so I was naturally a bit nervous about the unavoidable comparison. Despite my fears, my talk was very well received. Here’s a sample of the twitter feedback I got:

@LeaVerou is presenting js methods I did not even know existed during her css3 talk!!

September 29, 2011 21:50 via Plume  ReplyRetweetFavorite

@cedmax

cedmax

#ftf11 this is a real css/js hardcore talk. Fascinating @LeaVerou

September 29, 2011 21:54 via Twitter for AndroidReplyRetweetFavorite

@caludio

Claudio Cicali

#ftf11 when you watch a @LeaVerou presentation there is always something you didn't know

September 29, 2011 22:03 via Gravity!ReplyRetweetFavorite

@andypanix

Andrea Panisson

#ftf11 I hugged @leaverou at the end of her presentation at @fromthefront :-) Loved her

September 29, 2011 22:40 via Twitter for iPhoneReplyRetweetFavorite

@verlok

Andrea Verlicchi

Great presentation by @LeaVerou #ftf11

September 29, 2011 22:41 via Twitter for iPhoneReplyRetweetFavorite

@fburatti

Filippo Buratti

A whole hour of CSS3 to the tenth by @leaverou at #ftf11

September 29, 2011 22:48 via Twitter for iPhoneReplyRetweetFavorite

@Facens

Andrea Giannangelo

@leaverou "what can we do in this case?" Nice presentation of css problem solving #ftf11

September 29, 2011 22:19 via Twitter for iPadReplyRetweetFavorite

@matteocollina

Matteo Collina

JSConf EU

Next stop was Berlin and JSConf’s European sister conference. This was one of the most well organized conferences I’ve been to: The food, the coffee, the afterparties, the wifi, the projectors, everything was top notch. Also, it had a get-together the day after the conference (called “hangover.js”) which I think is great and more conferences should start adopting this tradition. It eases the pain of the conference being over and you get to say goodbye to a few folks you weren’t able to catch at the afterparty. It also featured many cool ideas, like a gal drawing live visualizations of the talks (Here’s mine) and a singer to open the conference in the first day singing a song to …Brendan Eich (!). I made new friends, had lots of fun and everything was awesome.

I was a bit more nervous about my talk for two reasons: Firstly, it was my first JavaScript talk, and secondly, it had no live demos like my CSS talks, which is a big part of why people like them. It went much better than I expected, and I got very good feedback and even though I went hugely overtime (I had 30 minutes and did 55!) nobody complained. Thankfully, it was right before lunch so I didn’t eat up another speaker’s time (which is part of the reason I love the pre-lunch spot so much).  I didn’t get the super-enthusiastic feedback I get from my CSS talks, but it was good enough to not be disappointed. Here’s a sample:

Now the lovely @leaverou is rocking the polyfills on stage at #jsconfeu - good talk, I worked through the slides with her earlier :)

October 2, 2011 12:49 via TweetDeckReplyRetweetFavorite

@codepo8

Christian Heilmann

wise JS code+hints on CSS and DOM features detections by @LeaVerou #jsconfeu

October 2, 2011 13:19 via Twitter for AndroidReplyRetweetFavorite

@WebReflection

Andrea Giammarchi

Awww @LeaVerou is sooo cute when saying "in other browsers, CSS polyfills are a pain in the ass!". Nice talk btw! #jsconfeu

October 2, 2011 13:19 via TweetDeckReplyRetweetFavorite

@nddrylliog

Amos Wenger

@LeaVerou dropping knowledge bomb after knowledge bomb about how to build polyfills. Awesome Talk! #jsconf

October 2, 2011 13:24 via Twitter for MacReplyRetweetFavorite

@cramforce

Malte Ubl

Don't do CSS polyfills! Says @LeaVerou. She is soooo right! #jsconfeu Excellent talk, really more technical then thought it would be!

October 2, 2011 13:38 via Twitter for iPhoneReplyRetweetFavorite

@wpbasti

Sebastian Werner

Overwhelming talk by @leaverou on #polyfills great detail hope to see it published! srsly this girl rocks http://t.co/APkxpGPl

October 2, 2011 13:49 via Twitter for iPhoneReplyRetweetFavorite

@claudiopro

Claudio Procida

some great work by @LeaVerou at #jsconfeu. "Impossible to detect"? Sounds like a fun game! :)

October 2, 2011 13:55 via webReplyRetweetFavorite

@VeganBen

Ben Green

@LeaVerou Really long and really informative. Dope styling + rich content. Congrats :)

October 2, 2011 14:05 via TweetDeckReplyRetweetFavorite

@nddrylliog

Amos Wenger

You can find my slides on Speakerdeck , Slideshare or the HTML version on my website.

Fronteers

I was looking forward to Fronteers the most, since it’s my favorite conference. It might not be the one with the most money or the biggest, but it has a special place in my heart for a number of different reasons (not all of which I can write in a public blog post). It was the first international conference I ever attended (in 2010) and I’ve met there so many people I used to only know (and admire) as a name & avatar before. It’s the conference I’ve had the most fun at, in both years I’ve been there. Everyone, the volunteers, the attendees, the speakers, everyone is awesome. There is something magic about this conference, as most of its speakers and attendees think about it in the same way (Christian Heilmann for example calls it “his special conference” and he goes to A LOT of conferences). It doesn’t just feel like a professional conference, it feels like a big, loving, open, web development family that gets together once a year to celebrate the advances in our field.

But this time, I wasn’t just an attendee. I wasn’t a regular speaker either. I was also hosting a workshop, my first full day workshop. I was super stressed about that, and in retrospect, it was the most exhausting thing I have ever done. Some other speakers told me it felt so exhausting because it was my first, I really hope they’re right. Luckily, attendees loved it, and they didn’t seem to notice my progressively getting tired after the 4th hour. Here’s some of the feedback I got:

Cool way of testing your CSS3 skills. Interesting workshop so far @LeaVerou #fronteers11 http://t.co/ht9XwgHY

October 5, 2011 10:52 via webReplyRetweetFavorite

@flyingpinguin

Jurgen Vansteelant

Need coffee to keep up with @LeaVerou! Very nice and interactive workshop so far, though. #fronteers11

October 5, 2011 11:05 via YoruFukurouReplyRetweetFavorite

@V_v_V

Vivienne

Lea Verou really does it right. Her css3 workshop is pretty awesome! @leaverou #fronteers11

October 5, 2011 11:36 via TweetDeckReplyRetweetFavorite

@Jessman5

Jessica Lazarus

Agree :) RT @Jessman5: Lea Verou really does it right. Her css3 workshop is pretty awesome! @leaverou #fronteers11

October 5, 2011 11:57 via TweetDeckReplyRetweetFavorite

@tforza

Tamara Forza

The CSS3 workshop by @LeaVerou is pretty well executed. Learning loads of new stuff!

October 5, 2011 12:24 via Twitter for MacReplyRetweetFavorite

@ronderksen

Ron Derksen

My talk was the next day, and even though I was afraid it would be bad due to being tired from the workshop and the pre-party, I think it was my best talk ever. I was much more relaxed, and I got the most enthusiastic feedback I ever have. My hand literally got tired favoriting tweets, and I’m pretty sure I missed some. Here’s a small sample:

If you thought you can just miss the CSS talk by @leaverou at #fronteers11, you're doing a big mistake. The talk will be amazing.

October 6, 2011 11:36 via TweetDeckReplyRetweetFavorite

@smashingmag

Smashing Magazine

Up next is @LeaVerou, awesome! #fronteers11 http://t.co/ZsL1mPST

October 6, 2011 11:38 via Twitter for iPadReplyRetweetFavorite

@ldebrouwer

Luc De Brouwer

Whee, @LeaVerou on stage. Css3 madness ensues. #fronteers11 http://t.co/OefgPsYQ

October 6, 2011 11:39 via Twitter for iPhoneReplyRetweetFavorite

@wnas

wilfred nas

Live coding CSS queen @LeaVerou is now talking about 10 things we didn't know yet. #fronteers11

October 6, 2011 11:44 via EchofonReplyRetweetFavorite

@FronteersConf

Fronteers Conference

.@LeaVerou is like a CSS3 knowledge cannon on stage! #fronteers11 http://t.co/3IOXbUQl

October 6, 2011 11:47 via Twitter for iPadReplyRetweetFavorite

@ldebrouwer

Luc De Brouwer

I've seen @LeaVerou's 10 things talk three times now, yet still somehow manage to learn something new each time. Nice work.

October 6, 2011 11:51 via Twitter for MacReplyRetweetFavorite

@addy_osmani

Addy Osmani

Great live CSS coding session by @LeaVerou revealing some very handy ans usable#CSS tricks #fronteers11

October 6, 2011 12:01 via TweetDeckReplyRetweetFavorite

@LuukWilms

Luuk Wilms

There are some really awesome CSS3 tricks shown by @LeaVerou here at #fronteers11

October 6, 2011 12:05 via webReplyRetweetFavorite

@Georg_Tavonius

Georg_Tavonius

@LeaVerou just made geeks to love CSS. Nice usage of CSS pseudo-selectors! #fronteers11

October 6, 2011 12:06 via Twitter for iPhoneReplyRetweetFavorite

@okonetchnikov

Andrey Okonetchnikov

@LeaVerou is on fire. #fronteers11

October 6, 2011 12:07 via Twitter for iPhoneReplyRetweetFavorite

@decthomas

Thomas Deceuninck

CSS Mindfucks by @LeaVerou #fronteers11

October 6, 2011 12:08 via Tweetbot for iPhoneReplyRetweetFavorite

@eising

Arjan Eising

@leaverou showing off insanely amazing capabilities of CSS3 with the :nth-child selectors with adding and removing elements #fronteers11

October 6, 2011 12:08 via Twitter for MacReplyRetweetFavorite

@artjulian

Arthur Stobbelaar

Impressive css selector-fu by @LeaVerou gets an applause from the #fronteers11 audience. And rightly so. Respect!

October 6, 2011 12:09 via Mobile WebReplyRetweetFavorite

@ronderksen

Ron Derksen

I was sceptical because of the title of this talk. But @LeaVerou rocks "10 things you might not know about CSS3" #fronteers11

October 6, 2011 12:10 via Twitter for iPadReplyRetweetFavorite

@dantz

Andreas Dantz

Indeed 10 CSS3 Secrets that are actually secrets. Mind=blown. #fronteers11 by @LeaVerou

October 6, 2011 12:11 via Twitter for MacReplyRetweetFavorite

@nerdismus

Nils Riedemann

Can't wait for @LeaVerou 's presentation/slides to come online. And she's not even done. #fronteers11 #cssQueen

October 6, 2011 12:12 via Twitter for iPhoneReplyRetweetFavorite

@okke29

Auke

.@LeaVerou has magic css powers. Seriously! #fronteers11

October 6, 2011 12:16 via Tweetbot for iPhoneReplyRetweetFavorite

@mylittletony

Anthony

@LeaVerou kudos for your live coding slides! Awesome! And thank you very much for some very useful tips!

October 6, 2011 12:24 via TweetDeckReplyRetweetFavorite

@LuukWilms

Luuk Wilms

@LeaVerou talks things about CSS3, I didn't know before. I am shocked! o_O #fronteers11 http://t.co/i4A6MdOk

October 6, 2011 12:25 via webReplyRetweetFavorite

@soswow

Aleksandr Motsjonov

@leaverou on CSS3 completely blew me away. Very creative use of properties and selectors. #fronteers11

October 6, 2011 12:25 via EchofonReplyRetweetFavorite

@mennovanslooten

Menno van Slooten

Kudos to @LeaVerou for cramming all these unknown CSS gems in one hour! Thanks! #fronteers11

October 6, 2011 12:28 via EchofonReplyRetweetFavorite

@FronteersConf

Fronteers Conference

@leaverou makes CSS look easy! #fronteers11

October 6, 2011 12:29 via EchofonReplyRetweetFavorite

@edgarleijs

Edgar Leijs

@LeaVerou kicked a whole lotta ass! #fronteers11

October 6, 2011 12:29 via Socialite.appReplyRetweetFavorite

@usethetics

Usethetics

Totally amazed by the vast knowledge and CSS skills of @leaverou. Wow. Learned some nice css3 tricks along the way! #fronteers11

October 6, 2011 12:33 via TweetDeckReplyRetweetFavorite

@peterpeerdeman

Peter Peerdeman

Just seen @LeaVerou pull some amzing rabbits out of the hat. Pure magic at #fronteers11

October 6, 2011 12:35 via SeesmicReplyRetweetFavorite

@bjornjohansen

Bjørn Johansen

10 blackbelt CSS3 techniques in under one hour. @LeaVerou is a CSS guru! #fronteers11

October 6, 2011 12:37 via Twitter for AndroidReplyRetweetFavorite

@cruster

Ján Sokoly

@LeaVerou just rocked my CSS3 world. #impressed

October 6, 2011 13:36 via Twitter for iPhoneReplyRetweetFavorite

@decthomas

Thomas Deceuninck

This is probably the most enjoyable/informative talk on CSS I've attended (& I've attended many) @leaverou = awesome presenter. #fronteers11

October 6, 2011 14:12 via Tweetbot for iPhoneReplyRetweetFavorite

@aral

Aral Balkan

So glad I got to thank the lovely @LeaVerou in person for all her hard work! #fronteers11

October 6, 2011 18:57 via Twitter for iPhoneReplyRetweetFavorite

@ldebrouwer

Luc De Brouwer

Recapping the first day of #fronteers11 - the talks by @aral and @leaverou were the definitive highlights. I'm glad I came.

October 6, 2011 18:57 via webReplyRetweetFavorite

@wiekatz

Patrick Hund

First day at #fronteers11, with great presentations by @LeaVerou (awesome skills), @brucel (really funny) and @aral (inspiring enthusiasm)

October 6, 2011 19:02 via webReplyRetweetFavorite

@GovertVerschuur

Govert Verschuur

@LeaVerou BTW, saw you in Stockholm and sat behind you today during the afternoon. Big fan! #fronteers11 #sweden

October 6, 2011 19:23 via Twitter for iPhoneReplyRetweetFavorite

@johannesaxner

Johannes Axner

The "10 secrets of css3" talk at #fronteers11 by @leaverou all summed up here http://t.co/IJeW3UdP

October 6, 2011 22:16 via Twitter for MacReplyRetweetFavorite

@flurin

Flurin Egger

My slides are now online at Speakerdeck, Slideshare and the interactive version on my website.

Frontend 2011

Oslo is a city I’ve been to many times in the past, so there was nothing new to see there. I didn’t make it to the speakers dinner & pre-party due to my late flight, which kinda sucked but it’s my fault since it took me a long while to decide on my flight dates. The conference itself was a bit more design-focused that I’d like, but very well organized. It took place in the same hotel the speakers were staying at, which is always a good thing. It also had the best coffee I’ve ever drank at a conference, and one of the best I’ve tasted in general. I also loved the idea of having multiple projectors, so that everyone in the audience can see clearly. They had the very original idea of not only drawing caricatures for every speaker (here’s mine, I also got it in a nice frame) but also having the artist in the venue to draw caricatures for attendees as well!

My talk went smoothly, and received very good feedback:

Awesome CSS3 use cases from @LeaVerou on #frontend2011 livestream http://t.co/a1YLCZLE

October 11, 2011 14:30 via Twitter for MacReplyRetweetFavorite

@iceMagic

Eystein

fantastic presentation from @LeaVerou at #frontend2011 is online http://t.co/GP5VU5Whuses her own build CSSS slides framework

October 11, 2011 14:46 via webReplyRetweetFavorite

@gustaff_weldon

Gustaff Weldon

Great CSS3 Talk at #frontend2011 by @LeaVerou!

October 11, 2011 14:47 via Twitter for MacReplyRetweetFavorite

@kaelig

Kaelig Deloumeau

Great presentation @leaverou ! Grwat presentation framework! http://t.co/zKw8XRHH #frontend2011

October 11, 2011 14:50 via HootSuiteReplyRetweetFavorite

@orioltf

Oriol Torrent

Wow, @LeaVerou fantastic presentation.Link to slides: http://t.co/6ssRhhxL. #frontend2011

October 11, 2011 14:50 via Twitter for MacReplyRetweetFavorite

@chemikpil

Michał Maćkowiak

really enjoyed @LeaVerou's talk, some great tips n tricks #css3 #frontend2011

October 11, 2011 14:50 via webReplyRetweetFavorite

@gav_taylor

Gavin Taylor

Just attended an amazing session with @LeaVerou. Thank you! #frontend2011

October 11, 2011 14:51 via Mobile WebReplyRetweetFavorite

@mikaeljorhult

Mikael Jorhult

Inspiring peek into the less widespread secrets of #CSS3 with @LeaVerou . @ded up next on modular #JavaScript with Ender #frontend2011

October 11, 2011 14:59 via Twitter for MacReplyRetweetFavorite

@ken_guru

Ken Paulsen

Great preso on CSS3 by @LeaVerou http://t.co/6wOOpoCB Thanks a lot Lea, really enjoyed it.

October 11, 2011 18:52 via Twitter for MacReplyRetweetFavorite

@cornae

Cornelis Kolbach

That’s it. I now get to rest for a while. Next stop is SWDC in November, which will host the première of my new talk “CSS in the 4th dimension: Not your daddy’s CSS animations” which will be about CSS transitions & animations, from the basics all way to badass secrets.

Thanks to all the conference organizers for inviting me and for the attendees for attending and giving feedback on my talks. You are all awesome, and it was the best 2 weeks ever.

Usually my github workflow is like this:

git add .
git status // to see what changes are going to be commited
git commit -m 'Some descriptive commit message'
git push origin master

Now, when I use gh-pages, there are only a few more commands that I have to use after the above:

git checkout gh-pages // go to the gh-pages branch
git rebase master // bring gh-pages up to date with master
git push origin gh-pages // commit the changes
git checkout master // return to the master branch

I know this is old news to some of you (I’m a github n00b, struggling with basic stuff, so my advice is probably for other n00bs), but if I had read this a few months ago, it would’ve saved me big hassles, so I’m writing it for the others out there that are like me a few months ago.

Now if only I find an easy way to automate this…

Read my announcement about it on Smashing Magazine.

Hope you like it!

First of all, it gave me the opportunity to visit Zurich for free, and meet an old friend for the first time. A girl we used to be penpals with at primary school & junior high when she was still living in Athens and I in Lesvos. She is now living in Zurich and doing her PhD in ETH. I arrived in Zurich a day earlier and stayed in her place that first night. We caught up and I had a great time.

Secondly, the rest of the speakers are great people and fun too, it was a pleasure to meet them. Especially Smashing Magazine‘s Vitaly Friedman. He’s a very kind guy, nothing like what you’d expect from somebody so successful. I also got the chance to meet Robert again, who was lots of fun as always. Those Swedes have a great sense of humor!

The conference itself was very nice, although small (only 200 people). Many inspiring talks, although I couldn’t attend them all because they were split into multiple tracks in one day. I would very much prefer it if it had 1 track and was 2 days. The 2nd day was an unconference, where attendees could speak, about whatever they wanted. I decided to get some sleep the second day, so I arrived a bit later, and didn’t attend many talks. It was kinda sad that it finished so early, around 4pm almost everyone was gone and most speakers were flying back the same day.

My talk went great, although I had the most technical glitches I’ve ever faced in a talk. That was my fault, not the conference’s. I guess I should learn to stop tweaking my slides at the last moment, cause things might break (and this time they did). Despite those glitches however, the audience loved it. Here’s a small sample of the twitter feedback I got:

.@LeaVerou is up the stage now! Live stream: http://t.co/qG3eM7Q

September 9, 2011 11:07 via CoTweetReplyRetweetFavorite

@frontendconfch

Frontend Conference

I really like the slides by @LeaVerou. Please make them available later on, Lea. #FEC11

September 9, 2011 11:08 via Twidroyd for AndroidReplyRetweetFavorite

@FabianBeiner

Fabian Beiner

Outstanding live CSS examples in the slides by @leaverou. #fec11

September 9, 2011 11:09 via EchofonReplyRetweetFavorite

@michalbe

Michal Budzynski

Using multiple outlines with CSS3 box shadows, one of @LeaVerou's awesome live slides at #fec11: http://img.ly/8dgR

September 9, 2011 11:14 via Tweetbot for iPhoneReplyRetweetFavorite

@jfahrenkrug

Ⓙohannes Ⓕahrenkrug

@LeaVerou has some seriously good CSS3 tricks up her sleeve. #fec11

September 9, 2011 11:14 via Twitter for MacReplyRetweetFavorite

@kcornelius

Kathryn Cornelius

Wicked! Spread-radius for box-shadow could be really useful /cc @LeaVerou

September 9, 2011 11:14 via Twitter for MacReplyRetweetFavorite

@backflip

Thomas Jaggi

Multiple box-shadows! Brilliant! Thank you @LeaVerou #fec11

September 9, 2011 11:16 via EchofonReplyRetweetFavorite

@cainvommars

Peter Willert

I sure hope the slides will be available online, there are some really cool CSS tricks in the talk by @LeaVerou #fec11 /cc @lejoe @nicam

September 9, 2011 11:21 via Tweetbot for iPhoneReplyRetweetFavorite

@euklid

Fabian

Learning a lot of CSS3 hacks with @LeaVerou at #fec11.

September 9, 2011 11:31 via webReplyRetweetFavorite

@shvi

Pierre Spring

@LeaVerou sure knows what she is talking about. #impressing #fec11

September 9, 2011 11:33 via webReplyRetweetFavorite

@lorentzforce

Simon Josi ⚡

.@LeaVerou sure knows how to catch the audience ;) #SwissFlag #fec11 #kudos /cc @frontendconfch http://t.co/ysl61uG

September 9, 2011 11:54 via TweetDeckReplyRetweetFavorite

@mettlerd

Daniel Mettler

Thanks @LeaVerou, this was an awesome talk. :)

September 9, 2011 11:54 via Twidroyd for AndroidReplyRetweetFavorite

@FabianBeiner

Fabian Beiner

Check out @LeaVerou's awesome html5 slides framework CSSS at http://t.co/vgPTwWL #fec11

September 9, 2011 11:55 via Tweetbot for iPhoneReplyRetweetFavorite

@jfahrenkrug

Ⓙohannes Ⓕahrenkrug

Thank you for your absolutely awesome talk @LeaVerou!

September 9, 2011 12:00 via Tweetbot for iPhoneReplyRetweetFavorite

@jfahrenkrug

Ⓙohannes Ⓕahrenkrug

And here is the recorded Session of @LeaVerou at the @frontendconfch http://t.co/A3dxNaU #fec11

September 9, 2011 12:01 via TweetDeckReplyRetweetFavorite

@Schnitzel

Michael Schmid

@leaverou great presentation about #css3 secrets. i really need to check #csss now http://t.co/CW2Ipy1 #fec11

September 9, 2011 12:03 via Mobile WebReplyRetweetFavorite

@marcoegli

Marco Egli

@LeaVerou Don't be disappointed by "no questions". This just means your talk was so good that there are no open ones. :)

September 9, 2011 12:04 via Twidroyd for AndroidReplyRetweetFavorite

@FabianBeiner

Fabian Beiner

great speach by @leaverou she really showed 10 new things bout css3 I didn't know

September 9, 2011 12:06 via Tweetbot for iPhoneReplyRetweetFavorite

@mauricenaef

Marcel Maurice Naef

@sprain @frontendconfch Der Talk von @LeaVerou war sehr lehrreich!

September 9, 2011 12:11 via Twitter for iPhoneReplyRetweetFavorite

@lulezi

Luzi Humm

@LeaVerou Wonderful presentation Lea! :-) Great work! Impressive CSS3 examples you had... Enjoyed it very much! :-) εύγε!

September 9, 2011 12:17 via webReplyRetweetFavorite

@smash_it_on

Iris

@LeaVerou Nice presentation with some very useful examples!

September 9, 2011 12:19 via webReplyRetweetFavorite

@walktheweb

Robin

WEB: CSS3 Secrets: 10 things you might not know about CSS3 from @LeaVerou at @frontendconfch http://t.co/9mVeOfz Smart girl ;-)

September 9, 2011 12:43 via TweetDeckReplyRetweetFavorite

@andypanix

Andrea Panisson

If you fancy css3, the talk by @LeaVerou @frontendconf is a must watch. http://t.co/bQaiwrs #fec11

September 9, 2011 13:13 via webReplyRetweetFavorite

@lorentzforce

Simon Josi ⚡

Delightful, eye-opening talks by @michalbe (next gen web games) and @LeaVerou (CSS3 wizardry) were a great kickstart to #fec11

September 9, 2011 13:31 via webReplyRetweetFavorite

@loleg

Oleg

@LeaVerou totally rocked at her #CSS3 presentation. The #fec11 fee is now worth every penny. http://t.co/C1QlPqm

September 9, 2011 13:59 via TweetDeckReplyRetweetFavorite

@whitefleaCH

Thomas Lohbeck

@LeaVerou - Awesome CSS3 Secrets presentation. Loved your comment "Thats what they deserve for using IE8" =) http://t.co/U5bULgo

September 9, 2011 18:09 via EchofonReplyRetweetFavorite

@Juztin

Justin

Totally blown away by @leaverou's "10 things about CSS3" talk http://yjo.go.ly - she channels the pragmatism of @simplebits to a T. #mustsee

September 9, 2011 21:52 via TweetDeckReplyRetweetFavorite

@codepo8

Christian Heilmann

OMG @leaverou is such a CSS think-tank superhero! Watch her talk on CSS3 http://t.co/QFkA5KX now. And then worship her. I do.

September 9, 2011 23:26 via TweetDeckReplyRetweetFavorite

@derSchepp

Christian Schaefer

Just listened to @LeaVerou speaking at @frontendconfch, what a fantastic talk. So would love to hear her speak in person some time.

September 10, 2011 00:11 via webReplyRetweetFavorite

@susanjrobertson

Susan Robertson

If you read the above carefully, you might have noticed that my talk was recorded, so you can see it too. Enjoy!

Actually, while using Chainvas myself, I found it immensely more useful for chaining DOM methods and setting multiple element properties at once. Chainvas had a lot of potential, that most people were missing. And then it dawned on me: I should modularize the library! A generic chaining library at its core and additional modules for making the different APIs chainable. And I did it.

On the way to that, I added IE8 compatibility, and tested in many other browsers, thanks to Browserstack. I actually found that Chainvas’ core even works in IE6! I also wrote unit tests, a much more extensive documentation, added a script generated table of contents and designed a logo and a Chainvas pride banner.

Also, since it was now modular, it needed a build script. I badly wanted to make this client side, so I followed this architecture:

• Every module is included in chainvas.js and chainvas.min.js, along with a header comment that follows a specific syntax.
• The user selects a compression level and then, the relevant script is downloaded through XHR and split into parts according to the module headers. Then a module list is generated with checkboxes for the user to select the ones they want to include.
• When the user checks and unchecks those checkboxes, the URL of the download link changes to a data URI that contains the script.

However, in the case of cubic-bezier() that’s not enough. No matter how much you see someone changing the parameters, if you don’t picture it in a 2D plane, it’s very hard to understand how it works. So, the night before, I searched for a tool I could use to show them how bezier curves are formed. I found plenty, but all of them restricted the the coordinates to the 0-1 range. I’m not sure if the cause is ignorance about the spec changes or that Webkit hasn’t caught up with those changes yet (but it will, soon). The only one that supported values out of range was this one from the Opera Dragonfly developers, but I found it kinda impossible to adapt.

For my talk, I tried to adapt one of them but it was late so I gave up after a while and ended up just showing them a screenshot. And the day after the talk, I started adapting this to my needs (ever tried coding at a conference? It’s awesome, you get to ask questions from very knowledgeable people and ger replies straight away). And then I started cleaning up the code, changing how it worked, adding features. At this point, I think the only thing that’s left from that tool is …the HTML5 doctype. After 3-4 days, I finished it, and got it its own domain, cubic-bezier.com (I was surprised it was still free).

So, in a nutshell, what makes this better?

Lots of things:

• It supports y values out of range, as per the latest version of the spec (and shows a warning for Webkit)
• It’s fully accessible from the keyboard
• You can move the handles not only by dragging but also by clicking on the plane or using the keyboard arrow keys
• You can mouse over the plane and see the progression and time percentages that correspond to every point
• You can save curves you like in your “Library” (uses localStorage to persist them)
• You can import and export curves to/from your library to share them with others
• You can share a permalink to every curve. For example, here’s a bouncing transition (FF & Opera only)
• You can compare the current curve with any in your library, setting the duration yourself
• Custom favicon that reflects the current curve

Cool stuff used

Given that this tool is not only for developers, but for badass developers that care about stuff like cubic-bezier(), I think I can safely assume they’re using a top notch browser. So, I went crazy with using cool modern stuff:

• HTML5: Canvas, localStorage, History API, range inputs, oninput event, output, classList, data- attributes
• ES5: Accessors, Array#map, Array#forEach
• Selectors API
• JSON
• CSS3: Transitions, gradients, media queries, border-radius, shadows, :in-range pseudoclass, box-sizing, transforms, text-overflow

Browser support

So far, I’ve tested it in modern versions of Chrome, Firefox, Opera and Safari and it seems to work. I haven’t tested it in IE10 (too lazy to open vm), although I want it to work there too, so if it doesn’t let me know.

Enjoy! cubic-bezier.com

However, I think my attempt has merit, because it’s not really focused in chaining canvas methods, but just about every API you use it on and because it’s super small, only 1KB!

Get comfortable and make a big cup of coffee before you dive in, as it’s quite long (4000 words).

As you can see, the number of characters is hardcoded in the steps() function, but that’s the only place. Everything else is totally flexible. Apart from the font: It has to be monospace, so that every character has the same width.

Also, this particular way requires a solid background and an extra <span>. You can avoid these limitations by directly animating the width of the heading itself, but this requires a fixed target width hardcoded in the animation, so 2 things that need to be changed for every heading:

If you’re having trouble understanding how it works, take a look at this simpler example, with just the cursor.

Gecko (Firefox) and Webkit only at the moment, since other engines haven’t implemented CSS animations yet. However, both examples degrade very gracefully in other browsers (IMO at least).

Of course, I didn’t plan to include a whole database of CSS colors in the website. My idea was much simpler: Use the named color to draw a rectangle in a <canvas> and then read the R,G,B values through ctx.getImageData().

I got the core functionality done in under 10 minutes, so I started adding stuff. I added a hex and HSL representation, I used canvas.toDataURL() to get a data URI of the rectangle and use it as a dynamic favicon*, I made the colors sharable and bookmarkable by using an old-fashioned hash. Also, I realized it actually supports any CSS supported color represenation by design, not just named colors.

Regarding the color conversions themselves, I took extra care to avoid redundancy. So values < 1 don’t have leading zeroes (.5 instead of 0.5) and when the hex color is in the format #xxyyzz it gets converted to #xyz. When it’s an RGBA color, it still converts it to hex, since those values will be supported in CSS4.

Since it’s for developers, I didn’t bother at all with fallbacks.

Cool stuff used:

• HTML5: canvas, autofocus, output, oninput event, hashchange event
• CSS3: gradients, media queries, box-sizing, background-clip, border-radius, shadows, RGBA
• ES5: Array#map()
• Selectors API

The reason the input’s border appears weird on Webkit is this long standing Webkit bug. Also, for some reason my nice dynamic favicons don’t display on Firefox, although they display fine in Webkit and Opera.

*Thanks to @milo for giving me the idea of using a dynamic favicon

http://foo.com/futurama/season/6/episode/9

I thought to myself “hey, this looks very clean and readable”. And then I noticed that it only has 1 less character than its non-rewritten counterpart:

http://foo.com/?futurama&season=6&episode=9

However, I’m pretty sure you agree that the second one is much harder to read. I asked for opinions on twitter, and got many interesting replies. Apart from the ones that completely missed the point, these were the core explanations:

• = and especially & are more complex and look more like letters, so our brain has trouble tuning them out (@feather @robert_tilt @rexxars @mrtazz @manchurian)
• Slashes have more whitespace around them, so they are less obtrusive (@feather @stevelove @kenny1987 @janl)
• They’re all visual noise, but we always have slashes in a URL, so using the slash to separate keys and values as well only introduces 1 separator instead of 3 (@bugster @craigpatik @nyaray)
• Slashes imply hierarchy, which our brains process easier than key-value pairs. Key-value pairs could be in any order, paths have a specified order. (@sggottlieb @edwelker @stevenhay @jwasjsberg @stazybohorn)
• Ampersands and equal signs are harder to type than slashes. They’re both in the top row and ampersands even need the Shift key as well. (@feather)
• Ampersands and equal signs have semantic meaning in our minds, whereas slashes not as much (@snadon)

For example, yesterday I was trying to write code for something and it ended up beng harder than I expected. It’s one of those rare cases where you can fully imagine how the solution should work, enough to tell it to another person, but you can’t put your thoughts to code and you feel you’re not smart enough.

I find that in those cases, it helps a lot to open a new editor window and try to write code that just works. Without being elegant, fast or maintainable. Just something that works properly. And after you manage to put your thoughts into (bad) code, it’s easy to refine it from there and end up with good code.

Just don’t stop at the bad code, like many beginners do. It’s like when designers sketch a rough draft for a logo, before drawing the digital version. Could you imagine how horrible it would be if they wanted to stop there and give the rough sketches to the client instead?

But can we use no JavaScript for a rating widget and make it just with CSS?

Actually, we can. By adapting Ryan Seddon’s technique for custom radio buttons with CSS, we can turn a series of radio buttons into stars that change colors (for the purposes of this demo they’re just unicode characters that change colors, but in your case they may as well be images) and use the sibling combinator to color the previous stars. A series of radio buttons is what many people use as a star rating widget fallback anyway, so the markup required is not necessarily more than usual. The only thing that needs to be done differently is their reverse ordering: The highest ratings need to go first, due to the way CSS3 selectors work (this limitation might be removed in CSS4, but that’s a long way ahead).

Of course, you’d still need JS to attach an event handler if you want the votes to be registered through AJAX, but that’s not part of the rating widget per se (it could still work as part of a regular form).

What’s best is that it’s fully keyboard accessible (focus and then use keyboard arrows) and screen reader accessible (although VoiceOver will also pronounce the generated stars, but that won’t happen if you use images instead of unicode stars). I’m guessing it could become even more accessible with proper ARIA, but I’ll leave that as an exercise to the commenter

In browsers that don’t support :checked (essentially only IE < 9), it degrades to a series of radio buttons (haven’t verified that it does, but it should do).

So, here it is:

• In which other industry is it common for people to spend several hours, days or in some cases even months, working on something to give it away for free, just to help people?
• In which other industry do people help you and promote you just because they think you’re good, without getting anything out of it?
• In which other industry do people listen to you, not because of your titles, degrees and “decades of experience”, but because of what you actually know?
• In which other industry can you go to a big professional conference with jeans and a t-shirt and be in the majority? (And the best part is, even if you don’t like that kind of outfit and you prefer to wear a suit, you still fit in, cause appearances just don’t matter)
• Judging whether someone’s work is good is a very rational and objective process (unlike arts). Sure, the various criteria have different weights for every person, but the criteria are the same for everyone, more or less (correctness, speed, maintainability, readability etc).
• Even though it’s a male dominated field, I’ve never* experienced any discrimination or lack of respect due to my gender. Quite the contrary actually.
• I’ve yet to meet a developer that lacks a sense of humor.
• Work for us is our passion, not a chore. Yes, there are passionate people in every field, but in our industry it’s the norm, not the exception.
• You don’t need to hide your geekiness. Instead, you’re encouraged to embrace it.

Yes, I know that not all of them are true for every single person that happened to be a web developer. I’m talking about the part of the industry that’s active and that I meet in conferences, meetups, twitter etc.

So, what are your reasons for liking our industry, if any? Lets keep this post happy and not whine about what we DON’T like please.

*Well, except one bad joke once, but he recently said he’s sorry and his intentions were good throughout, so I don’t count it.

So, I thought I’d take a chance at trying to recreate this effect without any extra markup. And it turned out to be quite easy, although using CSS gradients limits browser support a bit (IE10, Firefox 3.6+, Chrome, Safari 5.1).

They have the same disadvantage as the originals: They depend on the background color. However, unlike the originals, they come at less code, they’re scalable without changing a million values (as shown in the “bigger” section) and of course, no extra markup.

You can see the results in the fiddle below:

Disclaimer: webdesign tuts+ occasionally has some nice tutorials. I didn’t write this post to attack them in any way.

The latter isn’t an entirely horrible option. However, I see 3 big downsides:

1. I’m not very comfortable with the idea of some external service hosting my content which could close down any time due to failure to monetize their website. In that case, I’d be left with some dead links that are of no value and my content would be lost forever. Yes, they usually warn you in advance in such cases, but such news could be missed for a number of reasons.
2. People (including yours truly) don’t plan those things in advance. They just seek services like that at the exact moment when they want to post a long tweet. Being greeted with a prompt to use Twitter Connect is NOT nice. For starters, it slows me down. Also, I don’t want to give permission to every website on the effing interwebs to post on my twitter timeline. I owe it to my followers to be responsible and not risk filling their timelines with crap.
3. Most of these websites look like someone puked and what came out happened to be HTML and CSS. The only exception I’ve found is twtmore, but it still suffers from #1 and #2.

So, like every developer with a healthy amount of NIH syndrome, I decided to write my own

1. It had to be entirely client-side (except initially getting downloaded from the server of course). This way, whoever is concerned can download the full website and decode their tweets with it if it ever goes down. Also, being entirely client side allows it to scale very easily, as serving files is not a very resource intensive job (compared to databases and the like).
2. No Twitter Connect, the tweets would get posted through Twitter Web Intents.
3. It had to look good. I’m not primarily a designer, so I can’t make something that looks jaw-droppingly amazing, but I can at least make it look very decent.
4. If I was gonna go through all the hassle of making this, I may as well try to keep it under 10K, so that I could take part in the 10K apart contest. (I haven’t submitted it yet, I’ll submit a few days before the deadline, as it seems you can’t make changes to your submission and I want to polish the code a bit, especially the JS — I’m not too proud about it)

I managed to succeed in all my goals and I really liked the result. I ended up using it for stuff I never imagined, like checking if a twitter username corresponds to the account I think (as it shows the avatars). So I went ahead and came up with a name, bought a domain for it, and tweeplus.com was born

twee+? Seriously?

Yes, I like it. The plus means “more”, which is fitting and + kinda looks like a t, so it could be read as “tweet” as well. Yes, I know that the word “twee” has some negative connotations, but oh well, I still like the name. Whoever doesn’t can just not use it, I won’t get depressed, I promise.

Geeky stuff

How it works

• A relatively new feature, Twitter automatically wraps URLs in t.co links, making them only 20 characters long.
• All the text of the tweet is stored in the URL hash (query string will also work, although the output uses a hash). Some research revealed that actually browsers can handle surprisingly long URLs. Essentially, the only limit (2083 characters) is enforced by Internet Explorer. I decided to limit tweets to 2000 characters (encoded length), not only because of the IE limit, but also because I wouldn’t like people to post whole books in t.co links. We don’t want Twitter to start taking measures against this, do we?
• A hard part was deciding which encoding to use (twitter is quite limited in the characters it parses as part of a URL).
  • My first thought was base64, but I quickly realized this was not a very good idea:
    • The encoding & decoding functions (btoa() and atob() respectively) are relatively new and therefore not supported by older browsers. I’m fine with the app hardly working in old browsers, but existing links must as a minimum be readable.
    • It uses approximately 1.34 characters per ASCII character. Unicode characters need to be URL-encoded first, otherwise an Exception is thrown. URL-encoding them uses 6 characters, which would result in 8 characters when they’re base64 encoded.
  • Then I thought of using URL-encoding for the whole thing. The good thing with it is that for latin alphanumeric characters (which are the most) it doesn’t increase the string length at all. For non-alphanumeric characters it takes up 3 characters and 6 characters for Unicode ones. Also, it’s much more readable.
  • Still, implementing it was tricky. It doesn’t encode some characters (like the dot), even though twitter doesn’t accept them as part of a URL. Also, escape() and encodeURI() behave differently and the Unicode encoding returned by the former isn’t accepted by Twitter. So I had to combine the two and do some substitutions manually.
• When the textarea changes, the hash does too. The whole thing is a form with action=”http://twitter.com/intent/tweet”, so submitting it does the right thing naturally. I keep a hidden input with the tweet and the textarea has no name, so it doesn’t get submitted.
• Usernames, hashtags and URLs get extracted and linkified. Usernames also get an avatar (it’s dead easy: Just use twitter.com/api/users/profile_image?screen_name={username} where {username} is the user’s username)
• Internal “pages” (like “About” or “Browser support”) are essentially long “tweets” too.
• A little easter egg is that if the browser supports radial gradients, the gradient follows the mouse, creating a spotlight effect. This looks nice on Chrome and Firefox, and really shitty on IE10, probably due to bugs in the gradient implementation (which I have to reduce & report sometime).

Buzzword compliance

This little app demonstrates quite a lot new open web technologies (HTML5, CSS3 etc), such as:

• textarea maxlength
• placeholder
• autofocus (edit: I had to remove it cause it triggered a Webkit bug in Safari)
• required inputs
• New input types (url)
• History API
• oninput event (with keyup fallback)
• hashchange event
• SVG
• Common CSS3 (border-radius, shadows, transitions, rgba, media queries)
• CSS3 gradients
• CSS3 animations
• CSS3 resize
• :empty