It seems to me the first part of building a framework is learning what is essential to the cart system, dissecting that from the current design elements.
The demo cart has a great layout appearance, I for one haven’t looked too much at the code yet. Doing that right now…

Thanks for joining Tzcart, and good suggestion.

I know all of us design differently… the idea behind the framework is to create a common framework of css that we can all can build from… sort of stepping-stone to theme building. 

I’d like to get some people along with myself on this to discuss ideas, techniques, and really general needs for building a intuitive magento site.

Is this a project we should pursue?

Instead of builting a complete own framework I would suggest integrating the YAML framework. More details at http://www.yaml.de/en/

Danieln,
YAML is sweet. I came across it not too long ago while i was doing some reading on ruby on rails.  It’s really smart.  Good suggestion. 

I think whatever framework we build from, or create ourselves, should seamlessly integrate with the templating architecture of the current magento engine.  By this I mean we build upon the current magento engine, and as Magento becomes production ready and the templating APi finalized, then we’ll have a solid “blueprint” that anyone can use to begin frontend design.  Just download the framework, read a few wikis, maybe a theme or two to dissect, and then begin their own design, you know?

I think we can definitely use YAML as a model example, and tweak it to our needs. Is that a good idea? 

Lets keep this going.

I think once a framework is chosen or developed, it would be a good idea to also add some functionality to Magento that concatenates, compresses, and then caches the CSS files.  I like to split up my CSS files by purpose, which many frameworks already do.  The problem with that is that you are forcing multiple HTTP requests.  It’s best in my opinion to have all of the CSS in one file and compress it down as much as possible.  I personally use PHP CSS Compressor to do this.  The downside is that it’s done on the fly, although the performance hit is minuscule for today’s servers.  Caching the then compressed CSS file would eliminate that problem, but I haven’t figured out that part yet.  Another good compressor is CSS Optimizer.  This one does a better job because it also converts all longhand CSS into shorthand CSS.  However, it’s not written in PHP.  They have an online version or a command line version.  While this tool would give better results, it wouldn’t work for most people, especially not on a shared host.  I haven’t looked yet to see if someone has made a PHP version.

I would also like to propose the same treatment for Javascript, as those files can be quite heavy.  I prefer Dean Edwards Packer because it results in the smallest file size and also obfuscates the code if you choose the Base62 encode option.  There

My post got cut off. 

Basically the last part talked about JSMIN and Dojo ShrinkSafe as alternatives to Packer, because they are safer.

Also I mentioned that my post went a bit off topic, but I think we should definitely think about this while choosing or developing a CSS framework.

Magento already uses a reset.css stylesheet with some base styles, the boxes.css is awfully large for a css file at 42kb, and the js files are an awfully list of files with scriptaculous leading the way at 94kb.
Simplifying what is there now would be educational and easier to design around. I’ve never worked with Yaml, I’m sure I’ve looked at it.
Focusing on incorporating the lightweight jquery would be a good thing also, but I know I don’t have the js skills for doing that.

I think I would prefer the blueprint.css framework if the project goes forward with a framework.
Anyone using this framework in the past?

I haven’t used Blueprint before, but I just downloaded it, and I really like what I see so far.  My vote goes to that one unless something better comes along.  I’m going to restyle my website with Blueprint to get the hang of it and find out if there is anything I don’t like.

It’s funny you both mention using Blueprint, I’ve been using it alot...especially with Magento. There was some CSS conflict , but only small ones so I can honestly say it works well with Magento. Blueprint is a good example, I think we could use it as a model but build in more specific classes and selectors for magento’s data needs.

I’d rally for building off Blueprint as well, but we definitely need to create more specific css for the different parts of Magento (i.e One-Page Checkout, Customer Account, and Search Results) . Each of these should be within the framework ,and easy to style. You know?

I just finished redoing my website with Blueprint.  I didn’t do the whole site or mess with styling it really.  I just converted the structure/layout to Blueprint.  I like it a lot, and I can see itself working well with Magento.  It actually solved some problems I had with my site and removed some hacks I previously had to use.  When I get some more free time I’ll actually implement it on my live site (I just did a test locally), and then strip out anything I don’t need and compress the css.  I like the fact that it comes with pre-compressed files, but I would prefer to manually strip out some parts I know I’ll never use and then re-compress them myself.

What I really like about it is the fact that everything is broken up into a grid, which could allow for some very advanced layouts that are typically done with tables.  The typography is also very nice.  It definitely has my vote.

BTW, here’s a cheat sheet that I’ve found useful for learning:

http://www.digitart.net/blueprintcss/bluebrintcss.pdf