A LIST Apart: For People Who Make Websites

No. 308

Discuss: Stop Forking with CSS3

Pages

 1 2 3 >  Last »

1 Nice but slow?

I was just thinking why nobody has done something like this before while reading the Modernizr article.

I was just wondering, is the eCSStender website on a really slow server because everytime I load a page in Firefox it get’s stuck on your main.js file. Or does it just take so long to process the css?

I would love to use this script, but only if it is stable and fast enough for real-world use.

posted at 09:38 am on June 22, 2010 by Narfotic

2 Agreeing to Narfotic

The idea for eCSStender is really good. However, my FF suffers the same problem:

Skript: http://ecsstender.org/js/main.js?20100621162935:39

(which is the eCSStender core function)

posted at 09:48 am on June 22, 2010 by Boldewyn

3

Surely whether through Javascript or just normal CSS you are essentially just doing the same thing though. Making Javascript fork the css for you doesn’t make the problem go away.

posted at 10:03 am on June 22, 2010 by Noodlewitt

4

In line with Narfotics comment, how does Modernizr and eCSStender work together? Or on the other hand – do they cancel each other out? Looks like two nice solutions to the same problem, but in two very different ways. Would love to have the authors take on that.

Thanks for the nice article!

posted at 10:42 am on June 22, 2010 by niklasringdahl

5

Is the solution to forked CSS really to just to shove off the forking to Javascript? It seems like a method to just further obscure the problem.

posted at 10:57 am on June 22, 2010 by awesomerobot

6

I’m making some tweaks to the eCSStender.org site to move assets off to a CDN. Hopefully speed improvements are on their way to you now.

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

7 Looks interesting!

I like the look of this library. Reminds me of the old IE7 library (back before IE7 came out). But this library seems more modular and flexible.

I think the biggest concern is performance. Would love to see some numbers that address that concern. Also, does the library have a case of “flash of unstyled content” before the JS kicks in?

Your website mentions that border-radius is only supported on browsers that have native support. You might want to look at curved-corner which provides border-radius support for IE 6/7. It is not perfect but might provide a good start (I have noticed it is flaky on some layouts that using lots of CSS positioning, flaky on pages that dynamically change their content and doesn’t support asymmetrical corners but all that could be fixed).

posted at 11:41 am on June 22, 2010 by eric_programmer

8 This sounds great; can you cache stylesheets?

Great work Aaron! A solution like this is overdue – and represents the ideal from a development perspective; write clean CSS code and parse a mess to deal with browser quirks.

I have to agree with the other commenters on the pageload issues. Right now, it seems slow to render the CSS each time. Might it be possible to capture the final CSS rendered by browsers and serve the cached browser appropriate CSS files?

Looking forward to using your solution.

posted at 12:08 pm on June 22, 2010 by wingnutart

9

Has anyone else tried this? It looks like a miracle. But, the demo’s box-shadows don’t work in Safari 5. They work in Firefox, Opera, and OmniWeb. I tried implementing the border-radius extension on our company’s website, but it didn’t do anything in IE8 or Opera. Perhaps I’ve missed something along the way.

posted at 12:17 pm on June 22, 2010 by Ricky Irvine

10

While I think the idea is good, I don’t think it is necessary or efficient enough for use yet. Yes, it saves the developer some time and cleans up our CSS a bit, but we are now adding 12+ kb and the time it takes for the JS to parse possibly large CSS files.

Even on your site there is a long flash of unstylized content in Firefox for me. While this may get picked up by a few developers we can’t assume widespread adoption so can’t expect it to always be cached in the browser (like jquery). I don’t like the idea of adding new flashes of unstylized content to my designs.

Also, I don’t think the forking of css is nearly as bad as forking JS used to be. You can easily delete any of the browser-specific forks with a simple regex search-replace that many/most editors can do today.

Since a lot of people are already running their CSS through minifiers these days, I wonder if it is a better idea to create a minifier that automatically parses and adds your browser-specific definitions to a new css file. That way you will have your main CSS file, free of any forks, and can serve a minified, fleshed out (oxymoron, I know, but you get the idea) version of your CSS file to your users. No ugly forks in your main css file, no flash of unstylized content, and no added weight from new js files to your page.

posted at 12:24 pm on June 22, 2010 by bbeaudreault

Pages

 1 2 3 >  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?)