How to deal with the need to change CSS class names

Question

I'm looking for people’s strategies to address the inevitable need to change or otherwise adapt the CSS class to accommodate new HTML elements. I often meet in this situation, so I hope that other people share my pain and can advise here.

Imagine you have a product table with a beautiful semantic name for the products class. This is correctly styled in your stylesheet. After a few months, your boss will ask you to create a list of employees on the site, "exactly the same as the list of products."

This immediately raises an important question: what to call the new full-time table. The only options I can think of are as follows:

• Give it a class name products . This is the quickest solution, but destroys semantics. Naming does not really matter, especially for future developers.
• Change the class name to something that can cover both products and staff lists. This will negate the usefulness of separating markup from style, as HTML will need to be changed. In addition, I cannot come up with a single non-presentation class name that could be applicable to products and staff lists.
• Enter a new class name and edit the CSS file so that .products { ... } becomes .products, .staff { ... } and .products thead th.number { font-weight: bold } becomes .products thead th.number, .staff thead th.number { font-weight: bold } etc. Another ugly decision that will get complicated over time.

What is the best course of action here?

NB I am sure that this problem is easily solved using frameworks such as LESS (I did not use it personally), but this solution puts me more as a "cover" than a real tool.

Answer 1

If you had to add your table style in a few words, what would it be? I am trying to use this to name the styles that I use gunna in more than one place. Then I have an idea of ​​how this will look if I use a class.

Example:

.table-striped {}

Answer 2

How about option 4:

Make a copy of the “products” as “personnel” and continue to work on them separately over time.

Answer 3

There are basically two schools of thought.

1) The style that follows the layout 2) The layout that follows the style.

You must figure out which one you want to make, and try to stick with one or the other. if you mix too much, then this is pointless, and you just have a huge mess.

In the first case, you have installed markup that does not change. You define the style so that it looks the way you want. It is in the css zen residential garden. This requires your markup to be very semantic. The disadvantage is that you often have many repeating styles, because when using this method it is not always possible to stylishly erase.

In the second, you create many common styles, and then adapt your layout to styles. For example, you could have classes "float", "thinBorder", "bold", then apply these styles to your markup. The disadvantage here is that if your style needs to be changed, you need to change the HTML (or bold, or some of them). The good news is that your CSS is much cleaner and easier to maintain.

It sucks, but you have to compromise.

Answer 4

Hm ...

The root of the problem is that your initial idea of ​​creating the first style class ( .products ) was too narrowly named. It is not always possible to know that you will need to reuse a significant part of the CSS definition at a later point, but based on your question, it seems that you are in this area of ​​the business.

There is no way in the basic CSS structure to say: "My new style ( .staff ) will be the same as another style ( .products ) with these overrides

But I believe that the LESS structure allows you to define a class ( .coolTable ) with all properties and reuse these properties in several other class definitions ( .products and .staff ) quickly.

The LESS structure is not a cover, but an extension of CSS.

Answer 5

This is one of the things I really dislike about CSS. With all the powerful languages ​​at our disposal, it just seems crippled in order to handle very common scripts like yours. I also struggle with this all the time and end up either copying the entire class associated with the product, either my own new one, or adding my own new one to .product. They could be pulled out later.

I need to learn from preprocessors because what I would like to do is that OOP-y defines b 'the base class' that both .product and .mynewone inherit from and come from.

But # 3 is your best IMO choice.

Answer 6

I am going with the first option , because if everything is the same, but simply changing the content. Therefore, it is better to use the previous products class for staff, and you can separately define your staff panel using the <-- staff plan--> comment inside the HTML page.

Answer 7

I would go with the first option to have a products class with this block .... or maybe like class="products staff"

That way, I will not have duplicate styles (even from future aspects where code / styles can change a lot), and any specific styles for products can be done as follows by a new class (or another way to use the parent class in styles so that give more specific styles).

Yes, the word product class does not make much sense here, but again, for future developers, this all the same means that you use personnel class styles that are not related to logic ...

But, nevertheless, yes, if it is possible to change the markup with ease from product to any other word, I would do it .. but not as such the main requirement in this case ...

Answer 8

Representing a separate class name for a new content type is likely to be the most correct solution. But unfortunately, the current CSS syntax is far from perfect and therefore makes us be too verbose in our CSS, listing the complete selectors one by one.

Thus, in practice, most supported solutions, as a rule, try to find a common name for different things in the style the same.