I pretty much completely disagree with the implicit critique here. The codebase I work on now has largely transitioned from "semantic" CSS (classnames based on feature) to CSS with classnames that describe what they <i>do</i>, visually, and the latter has made writing frontend code dramatically more straightforward - it's gone from something I dread and try to pass off to a specialist to something I can do easily. A night-and-day improvement.<p>I mean, nobody actually advocates translating every single possible style attribute into its own CSS class. But what's wrong with padding and margin utility classes that use a consistent set of widths? Is doing calculations on "1x" and "2x" when you want elements to line up really worse than doing calculations on pixel or em values in your CSS just because it's "unsemantic"?<p>Let's take the examples from the "maintainable CSS" book that's linked:<p><pre><code> <!-- bad [sic] -->
<div class="red pull-left">
<div class="grid row">
<div class="col-xs-4">
<!-- good [sic] -->
<div class="header">
<div class="basket">
<div class="product">
<div class="searchResults">
</code></pre>
Ask yourself, in which case can you read the code and tell roughly how it's going to render? In which case do you think you'll be able to re-use the classes on other pages? If you wanted to make another, visually consistent page that shows, say, seller search results instead of product ones, in which case do you think you'll be able to figure out which styles need to change more quickly?<p>Here's the backend equivalent:<p><pre><code> # "bad"
def cheapest_products_with_min_rating(rating)
products.
select { |p| p.rating >= rating }.
sort_by { |p| p.price }.
first(10)
end
# "good"
def products_for_category_landing_page(rating)
allowed = []
for p in products
if p.rating >= rating
allowed << p
end
end
# pretend I've implemented quicksort here
result = []
for p in sorted
break if result.length >= 10
result << p
end
result
end
</code></pre>
Ugh, that first example - using all these "unsemantic" components like "sort" and "select"! How do I know when I look at the implementation of any of them, or the function itself, what the intent is? What business problem is being solved?<p>The second example - so nice and "semantic". If we want to change what products show up on the category landing page, it will be easy!<p>...<p>In real life, nobody writes backend code like that. Why should we tolerate it in the frontend?