A LIST Apart: For People Who Make Websites

No. 308

Discuss: Stop Forking with CSS3

Pages

« First  <  2 3 4 5 6 >  Last »

31 I can't download the libraries, but they sound fan

I was wondering if there was a way to make CSS3 work on all browsers. If flash can do it why couldn’t CSS?

Implementing this through Javascript is even better, the users don’t even have to install any plugin.

However the working example isn’t really… working. I’ll be checking the download link until I manage to get the libraries, I’ll test them in all major browsers including IE6 on Windows XP or Firefox on Ubuntu.

I’ll post the results here, that’s if I ever manage to download the scripts :)

posted at 11:51 am on June 24, 2010 by Radu.Tanasescu

32

As posted in the eCSStender FAQ and in response to several comments:

As much as we’d love to say everyone should be using eCSStender, it’s just not practical in many instances. The following are a few reasons eCSStender may not be a good choice for you:

  • You use CSS3 selectors and properties sparingly (e.g. you only use border-radius in a handful of places and that’s it)
  • You don’t care about backward-compatibility (e.g. IE6 is a not-so-fond, but rather distant memory)
  • You aren’t looking to use the extensions to CSS that are available.

Reasons you may want to use eCSStender include:

  • You use CSS3 all over the place and need backwards compatibility with older browsers (e.g. you want your CSS transitions to work in IE6 so you don’t have to learn JavaScript).
  • You want to take advantage of cutting edge enhancements or proposed additions to the CSS language (e.g. OOCSS, CSS variables, etc.).

When it comes down to it, there’s a trade-off of file size and flexibility. eCSStender currently weighs in under 20K (before GZipping), but you also need to factor in the size of the extensions as well. It’s a small performance hit (especially if you munge the minified files together and serve them over a CDN), but it’s probably not going to balance out minimal use of advanced properties.

If you’re considering using eCSStender to get away from vendor-specific prefixes, we’d recommend taking your non-prefixed stylesheet and giving eCSStender a whirl on a dev server. You can, using a developer toolbar of some sort, copy out the content of the stylesheets it embeds in the document and add those rules to your CSS file, comment out eCSStender, and see if there’s a noticeable speed improvement.

posted at 02:41 pm on June 24, 2010 by Aaron Gustafson

33

If you’re having problems downloading, please try one of the methods mentioned on this page. If you still can’t get a copy, please drop a message on the mailing list to let me know what it is.

posted at 02:43 pm on June 24, 2010 by Aaron Gustafson

34 A good way to go?

I liked the article, and thought it was a certainly a possible solution if combined with Modernizr. However, when I started to try it, the support for properties like border-radius and box-shadow is not consistent at all. And the point of the project is pretty much lost that way, at least in my opinion.

posted at 10:39 pm on June 24, 2010 by combus

35

There’s been a ton of debate over the necessity of vendor prefixes, so I thought it worth mentioning that I don’t think vendor prefixes are inherently bad. They serve a very important purpose: allowing implementors (the browser makers) to develop their implementations to track an evolving spec while giving them the leeway to get things wrong during that process.

eCSStender is not an attempt to get rid of this necessary step in the process (in fact it fosters more people’s involvement in the development of experimental CSS). This library does, however, allow us to even things out the authoring side when it comes to these disparate implementations, leaving it to the extensions themselves to deal with the juggling act of serving the appropriate rules to the appropriate browser. From an author’s perspective (that’s you and me), having to write the same thing umpteen different ways (especially when it involves having to manually overcome incomplete or botched implementations) is an issue we shouldn’t have to deal with. That’s where eCSStender really helps: it makes it possible to write a single rule and leaves it to the extension to make it work everywhere.

So, in summary, I’m not against vendor prefixes as a tool, I just think we have enough other things to worry about that we should not have to constantly tweak our stylesheets as vendor-prefixed implementations change (which they do). JavaScript is great at doing mundane tasks like that.

posted at 11:03 am on June 25, 2010 by Aaron Gustafson

36

Main problem: my Firefox freezes for 10 to 25 seconds when loading your website. Not a network/CDN issue.

Also: maybe you’re introducing “leaky abstractions” to prevent “forking”? ie, fixing the “CSS purity” problem with a tool that’s probably beyond the skillset of many a CSS coder if something goes wrong.

Using this to prototype CSS extensions sounds cool though.

posted at 08:15 pm on June 25, 2010 by Manuel Razzari

37 just doesn't work?

I don’t see the point in the eCSStender, since it doesn’t seem to work: IE7, IE8 don’t show rounded corners, neither on the eCCStender-site, nore on the ALA-demo-site.

posted at 09:38 am on June 26, 2010 by rubaff

38 Waste of time

I’m been a bit perplexed at why you would want to use any of these hack CSS3 declarations in the first place. Right now too many browsers don’t support CSS3, and therefore you shouldn’t use them.

I can’t imagine telling a client that their site looks great in modern browers but the people that visit the website that use older browsers will get a less aesthetically pleasing site. Clients just don’t accept this and furthermore I don’t. Each user should be given the best experience possible no matter what browser they use (unless it’s something like ie 5).

I ensure my websites look great in all browsers and therefore at this time you have to use background images for rounded corners etc (sprite them if you wish).

So overall eCSStender is a great plugin despite it not working that well and is slow. But the problem they it is solving is one that shouldn’t even be used in the first place.

posted at 04:49 am on June 27, 2010 by Wattzy

39 20kb minified js to avoid 5kb "untidy" CSS?

I mean, get serious! Most of the untidyness problems of those CSS forks are only of concern to the development. Therefore, the correct solution for this problem is not in the client, but in the deployment process.

So, what is really needed: a versatile filter framework for deployment of CSS, with the ability to expand those (and other) shorthands – and while we’re at it, to clean those comments you do not want the world to see, put multiple files together and minify the CSS if necessary. And btw, a JS version of such a framework would be useful, too.

posted at 09:45 am on June 28, 2010 by atk

40

If anyone was having issues with eCSStender in IE, there was a bug introduced in version 1.2.4 that has been fixed in version 1.2.5. Please visit http://test.ecsstender.org/ and post a message to the mailing list if you see any further errors.

posted at 10:12 am on June 28, 2010 by Aaron Gustafson

Pages

« First  <  2 3 4 5 6 >  Last »

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Remember me

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)