Blog

Edit: This was originally written to be posted in www-style, the mailing list for CSS development. I thought it might be a good idea to post it here as other people might be interested too. It wasn’t. Most people commenting didn’t really get the point of the article and thought I’m suggesting we should simply drop prefixes. Others think that it’s an acceptable solution for the CSS WG if CSS depends on external libraries like my own -prefix-free or LESS and SASS. I guess it was an failure of my behalf (“Know your audience”) and thus I’m disabling comments.

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.

What kind of transitions can you create with only one property? This is what my new experiment, animatable aims to explore.

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 :P ). 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 :)

This month has been very busy conference-wise. I had 4 conferences in a row, so I was flying from country to country and giving talks for 2 weeks. As I usually do after conferences, this post sums up my experiences and feedback I got from these conferences, in chronological order.

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:

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:

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:

https://twitter.com/V\_v\_V/status/121511282758258688

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:

https://twitter.com/addy\_osmani/status/121885202581684224

https://twitter.com/Georg\_Tavonius/status/121888702678044672

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:

https://twitter.com/gustaff\_weldon/status/123741227563753472

https://twitter.com/gav\_taylor/status/123742248646094848

https://twitter.com/ken\_guru/status/123744573666246656

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. :)

My newest article on Smashing Magazine’s coding section is for the geekiest among you. It’s about how you can pack long lists of boolean values into a string in the most space-efficient way. Hope you enjoy it :)

I always loved Github’s ability to publish pages for a project and get the strain out of your server. However, every time I tried it, I struggled to keep the gh-pages branch up to date. Until I discovered the awesome git rebase.

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… :)

I wrote this script while at the airport travelling to Oslo and during the Frontend 2011 conference. I think it’s amazing, and it makes authoring CSS3 a pleasure.

Read my announcement about it on Smashing Magazine.

Hope you like it!

I’m writing this blog post while eating some of the amazing Lindt chocolates I got for free 10 days ago at Frontend conference in Zurich. But it wasn’t a good experience only because of them!

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:

https://twitter.com/smash\_it\_on/status/112107410155515904

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

A week ago, I released Chainvas. It was a spin-off script I wrote while developing my cubic-bezier tool, to make using the Canvas API a bit less painful. However, unlike similar attempts to make the Canvas API chainable, most of my code was written in a very generic manner, and was actually able to make every API chainable. However, when I released it, even though I mentioned that it can be used for other APIs and provided some examples, practically everyone that shared the link on twitter or other means (thank you .net magazine for the newsletter mention btw!) focused on what Chainvas did for Canvas.

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.

This approach has the disadvantage that there is no default filename, and the “Save page as…” link is deactivated in Chrome (why Chrome??). However, I like the idea so much, I don’t mind these shortcomings.

That’s about it. Enjoy and let me know about any bugs.

A few days ago, I had a talk at a conference in Zurich (I’m going to write more about it in another post). The talk was about “10 things you might not know about CSS3”. The first of those things was how you can do bouncing transitions with cubic-bezier() instead of an easing keyword. As usual, my slides included a few live demos of the functionality, in which I edited the cubic-bezier() parameters and the audience could see the transition produced.

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

I also used my tiny chaining framework, Chainvas throughout this project.

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

It’s definitely not the first time someone writes a script to make the canvas API chainable, as a quick Google search will confirm.

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!

You can find it here: chainvas

Enjoy!

Thought I’d let you know that my Smashing Magazine article with that title was published today. It discusses why, how, when and where to report browser bugs, as well as how to make a good bug report.

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

steps() is a relatively new addition to the CSS3 animations module. Instead of interpolating the values smoothly, it allows us to define the number of “frames” precisely. So I used it to create headers that have the well-known animated “typing effect”:

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

Whenever I wanted to convert a CSS named color to RGB, I used to open the CSS3 colors spec in a new tab, search in the page and copied the values. Every time it felt even more tedious. I didn’t want to search in long tables, I wanted to type the color somewhere and get the values back, in an easy to copy format. So, after yet another color lookup earlier today, I decided to scratch my own itch and do it myself.

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.

Enjoy: CSS.coloratum

Happy color sharing! Let me know of any problems or suggestions you may have.

PS: In case you’re wondering about the domain, I’ve had it for ages for another project and I thought it was quite fitting.

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

Yesterday, I was watching some season 6 episodes of Futurama (btw, this is their best season ever!) and I noticed the URLs in the website I was in (let’s call it foo.com). They were like:

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)

Regarding hierarchy and RESTful design, the first example isn’t exactly correct. If it was hierarchical, it should be foo.com/futurama/seasons/6/episodes/9. As it currently stands, it’s key-value pairs, masquerading as hierarchical. However, it still reads better.

So I’m leaning towards the first three explanations, although I think all of them have a grain of truth. Which makes me wonder: Did we choose the wrong characters for our protocol? Could we have saved ourselves the hassle and performance overhead of URL rewriting if we were a bit more careful in choosing the separators back then?

Also, some food for thought: Where do you think the following URLs stand in the legibility scale?

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

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

http : //foo.com/futurama-season-6-episode-9  (suggested by Ben Alman)

Do you think there are there any explanations that I missed?

And I’m not referring to learning.

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? :)