3 ms·

The problem I see with that approach is that it doesn't leave a lot of room for reusability in different types of design components. Many times in larger web a

The problem I see with that approach is that it doesn't leave a lot of room for reusability in different types of design components. Many times in larger web applications, designers will have similar design themes that span multiple pages (more than just simple things like forms). So there may be a callout with a border and all text inside is blue across 5 separate pages. You may approach this as #homepage .callout at first but it begins to become hard to manage when you realize you need to refactor it into a side wide style. Generally I approach everything in attempts to make it re-usable. And organize what I can into components. I'd rather write more css classes in the markup than have to specify names for certain cases where 'this heading is bold here but underlined in this case' yada yada, when I can just write .bold .underline .h5.

seanwilson 9y ago
> You may approach this as #homepage .callout at first but it begins to become hard to manage when you realize you need to refactor it into a side wide style. So one approach would be to have a "callout" css file, nest everything under ".callout" and have several callout styles you can use inside that file (e.g. ".callout .warning")? > Generally I approach everything in attempts to make it re-usable. And organize what I can into components Personally, I find very little CSS can be reused between different projects as designers want completely different looks so I let things like Bootstrap take care of the basics and customise from there. It takes time and effort to make things reusable (same with code) so you need to weigh up how likely you are to actually reuse things and how much time that would save you. Sometimes duplication between projects saves time compared to maintaining the code for some generic widget that has to work in many scenarios. For me, I don't think it would save much time as each component is usually small and simple but I could understand if you were to create e.g. a calendar widget where it involves a lot of complex styling and code.

seanwilson 9y ago

> You may approach this as #homepage .callout at first but it begins to become hard to manage when you realize you need to refactor it into a side wide style. So one approach would be to have a "callout" css file, nest everything under ".callout" and have several callout styles you can use inside that file (e.g. ".callout .warning")? > Generally I approach everything in attempts to make it re-usable. And organize what I can into components Personally, I find very little CSS can be reused between different projects as designers want completely different looks so I let things like Bootstrap take care of the basics and customise from there. It takes time and effort to make things reusable (same with code) so you need to weigh up how likely you are to actually reuse things and how much time that would save you. Sometimes duplication between projects saves time compared to maintaining the code for some generic widget that has to work in many scenarios. For me, I don't think it would save much time as each component is usually small and simple but I could understand if you were to create e.g. a calendar widget where it involves a lot of complex styling and code.