Lea is a front end web developer from Greece. You have likely heard of her, as ever since she started blogging in English (read more about that below), she's had quite a boom in popularity. Or perhaps you've seen some of her work. She's created a number of one-page sites that either show off amazing things CSS can do or help you with a difficult/tedious task.

I asked Lea some questions about critical reaction to her work, the community in Greece, the future of CSS, and more.

*Chris: I think you proved with your pattern gallery that CSS3 gradients can do a lot more than make 3D looking buttons. What are some real-world design scenarios you've come across where you've reached for gradients to help get it done?

Lea: Here's the first ones that come to mind:

  • On my blog, as you can see one side is peachy stripes, the other side is white. Actually, gradients aren't only used there for the peachy stripes, but also to cover the other side with white. I used the same trick in the -prefix-free homepage.
  • On cubic-bezier.com, the guides are made with CSS gradients.
  • On CSS.coloratum, I use black & white stripes made with gradients, behind the color, which helps when it's semi-transparent (it doesn't show at all when it's a solid color).
  • On Michaelia Hotel's website, for the hole in the circle and also the lower left diagonal corner on the booking page.

Of course I've also reached for CSS gradients in many more cases where I needed, well, gradients. But I guess you weren't asking about that :)

*Chris: You recently authored -prefix-free, a JavaScript CSS processor that automatically adds the required vendor prefixes to CSS properties to make them work in whatever browser a user happens to be in. You've gotten extreme mixed reactions on this. An opposer might talk about "flash of un-CSS3'd content" or generically that JavaScript isn't correct for this kind of thing. Can you recap the most common complaints and have your say?

Lea: "Extreme mixed reactions" indeed! People either absolutely love it or absolutely hate it. Luckily, the ones in the former category far outnumber the ones in the latter one. The most common complaints by the people in the 2nd category are:

"It will cause FOUC (Flash of Un-CSS3-ed content)"

My answer: If you put -prefix-free right after the stylesheets, the FOUC is so minimal that nobody will notice, unless they're looking for it. Regular users don't go hunting for FOUCs like we do. We might think "it was super quick but I managed to notice a FOUC, ha!", but users don't even think of taking part in silly "spot the FOUC" games. They will notice it if it lasts too long or if the difference is too big. For example, regular FOUC (Flash of Unstyled Content) is much easier to notice, because the page is completely unstyled. -prefix-free's FOUC is just some CSS3 missing for a fraction of a second.

"It makes the style depend on JavaScript"

My answer: If JavaScript is not available (< 2% of visitors), the only styles that will be missing are some CSS3 features (less and less as the time passes and vendors drop prefixes). If you designed the page with graceful degradation in mind, it should work and look fine even without any CSS3. If you didn't, you'll have bigger problems than that. "This is something better done on the server. Do it once instead of on every pageload"

My answer: What -prefix-free exactly does, is impossible to do in the server. -prefix-free detects which features need a prefix and only adds it if needed. Also, it automatically detects which properties are available that need a prefix. It doesn't have to keep lists of which prefixes to add for which features, everything gets feature detected, and thus is very future proof. With preprocessors, lists need to be maintained about this sort of stuff. Such lists are doomed to be incomplete and quickly get out of date. Every server-side prefixer I ever tried fails in a number of cases.

For example, think about CSS animations. In the beginning, it was only Webkit. Then Firefox implemented them, and we had to go back and add -moz- versions too. Now IE has just implemented them too, so everything has to change and include a -ms- prefix as well. Soon, Opera will implement CSS animations. Are we really going to go back for a third time and add @-o-keyframes? Probably not. Most people will just start making up excuses about how Opera's market share is low and how they don't need to bother. -prefix-free is great for cases like that, because you never need to go back and change anything. When Opera implements CSS animations, they will work fine in Opera too, without even -prefix-free requiring an update.

"But what if you actually need vendor prefixes because an implementation is buggy?"

My answer: -prefix-free doesn't change stuff that's already prefixed, so if you need to specify something different for a specific engine, you can use prefixed along with unprefixed. -prefix-free also adds a class with the current prefix to the root element, to give you even greater flexibility.

*Chris: You live in Greece now. Maybe it's just my perspective but Greece doesn't seem like a hotbed for progressive web technology. Or am I wrong? Clearly that didn't prevent it from creating a world class developer like you. Does location matter much anymore for what you can achieve?

Lea: You are not wrong at all Chris, Greece is very far from being a hotbed for progressive web technology. You might be surprised to hear that I hardly get any recognition in Greece. I even have a Greek hater! (although he lives in Brussels, not Greece)

When I first started blogging, I started posting my research in Greek. Nobody paid much attention. After a few months I decided to try my luck with an English blog and well, we both know how that turned out :)

I think it's because most Greek developers just want a quick solution that works in every browser, to apply to their current project and move on. They don't have time to think about research and cool new stuff, they're still struggling with getting things to work. So, even though they will recognize projects and people that helped ease their day-to-day development pain, they won't care much about experimental stuff. Greeks are also very ageist, they won't even hear what you have to say unless you have lots of "years of experience" in your back. Young people are generally put down a lot here, and if you're not strong enough, you might actually believe you can't do anything until you reach your forties. Luckily, location doesn't matter a lot in our field, at least as far as countries go. If you want to have an international audience, you just start using English in everything you do online, it's that simple.

However, I am planning to move out of Greece in a few months, hopefully to the US. Even though I'm Greek, Greece never really felt like home to me. I'm much happier when I'm not here. There was a quote from the recent "Rise of the Planet of the Apes" movie, that I found very moving, for this exact reason. After Caesar spent some time with other apes and met his human foster-father again, he refused to come home and instead told him "Caesar is home". Sometimes, the place you belong in ("home") is not the place where you grew up or where your loved ones are. It's where you can easily find others that are similar to you and truly "get" you.

*Chris: For years now, designers have been stretching the abilities of CSS by creating complex imagery through "Pure CSS". On one hand, usually clever and impressive. On the other, usually impractical and unsemantic. A year and a half ago you called this out and cited SVG as a better alternative. Why do you think designers aren't experimenting with SVG more? A year and a half later, is it still a better choice?

Lea: Yes, I still think SVG is a better choice. It was created for this purpose, and it allows for many more things than even CSS3 does. However, it still doesn't have the adoption it deserves, which I mainly attribute to the following reasons:

  1. Difficult syntax. SVG allows us to do crazy things, but with most of the times just as crazy and complicated syntax. It makes sense once you understand how each feature works, but the learning curve is very steep. Especially since there's no debugging tool that helps you understand what you did wrong and very little information about browser support, so you might get stuck wondering if you misunderstood something or it's just not supported.
  2. Not enough resources. This is kind of a chicken and egg thing. If not enough people fiddle around with SVG, not enough people write tutorials, so not enough people are inspired to learn SVG. The few resources that exist are either very simple examples for beginners or academic stuff without much relevance to applied work (and both are usually ugly as f***, turning designers away).
  3. Hard to understand specifications. While CSS and HTML specs are reasonably easy to understand for the most part, a big part of the SVG specs requires university-level Computer Graphics and Linear Algebra knowledge. Even if you have that kind of knowledge, it's still hard. Given the lack of good SVG resources mentioned above, this hurts SVG adoption much more than meets the eye.
  4. Laziness. People like what's familiar, what they already know. If they can avoid learning something new, most will.
  5. Browser support issues. SVG brings its own set of browser bugs to the table, most of which are far less documented than CSS & HTML bugs. This is also a chicken and egg thing: The more developers use a certain technology, the highest priority its bugs get. Currently there are SVG bugs that are left unresolved for years, because not enough people use it.

I think however that there's lots of untapped potential in SVG, especially now that we can embed it in HTML5 documents. It's hidden there, waiting to be discovered. We just need more creative minds to start playing with it.

*Chris: What is your CSS wish? Something that you regularly wish you could accomplish with CSS but can't. Perhaps an existing feature with very limited browser support. Or something completely outside the current spec and discussions around the spec.

Lea: My favorite CSS3 feature that doesn't have enough implementations yet is the CSS3 generalization of attr(). In CSS2.1, we can use attr() in the content property, to use attribute values in generated content. In CSS3, we're supposed to be able to use attr() in every property, which will greatly reduce presentational JavaScript code. Unfortunately, only IE9 supports it, and not fully. If only developers realized how many use cases it simplifies and started pushing browser vendors for it!

But I also have lots of not yet existing features in my CSS wishlist:

  • A generalization of currentColor: A current() function that would accept any property (currentColor would then just become an alias to current(color)).
  • The inherit keyword becoming a function, that would accept a parameter to specify how many nesting levels to go up. inherit would then be aliased to inherit(1).
  • Being able to use the color keyword invert everywhere, not just in outlines.
  • Being able to use attr() and counter() in selectors.
  • Conical gradients, which are hopefully coming in CSS4.
  • Diagonal corners, with adjustable angle and size (example)

and many, many more. When it comes to CSS, I'm a big dreamer :)

*Chris: Thanks, Lea!