Shared publicly  - 
#Web #development.

I got the question the other day on why we went to create a new HTML/CSS framework for a new design that we were deploying, and why that framework had to have a different name than the design that triggered its creation.

My (shortened) answer had two parts:

1) Normally you want to work with your existing infrastructure, i.e. maintain the HTML/CSS framework you’re already using. However, if you’re dealing with major content and thus structural changes, it can well be justified (and more economic) to create a new framework. (We had another good reason but it’s not related to the point I’m trying to make.)

2) CSS, and thus HTML/CSS frameworks, are design-agnostic. You do not want to name a framework (or simply a style sheet) the same way you name your design because it should be your sincere goal to use the same framework for the next design iteration (and the next, and so on), all of which may have different names again. (Note that you could also end up having two or more frameworks for the same design—I’ve had this case, also in a complex environment—which could obviously not have the same name. As frameworks are design-agnostic, this is fine, though maintaining two or more frameworks is pure luxury.)
Jens Grochtdreis's profile photoJens Oliver Meiert's profile photo
Is this new framework documented? And what are the benefits compared to the myriads of existing? Most of them are very similar, YAML being the sole exception. And while CSS is not as complex as any prgramming language I don't see the basis for heavy differences in CSS-frameworks. So your framework ma be "just another blueprint or yui" as they all are (except YAML).

If not I would be really thrilled and excited.
Add a comment...