Skip to content

Instantly share code, notes, and snippets.

@jesseleite
Last active August 29, 2015 14:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jesseleite/25588c68f29148525b25 to your computer and use it in GitHub Desktop.
Save jesseleite/25588c68f29148525b25 to your computer and use it in GitHub Desktop.
"Semantics" & Front-End

For several years now, many of us have been trying to keep our HTML as pure as possible. We did away with the inline style attribute (with good reason, as it was a maintenance nightmare), and we only added class attributes when absolutely necessary. CSS Zen Garden taught us that external stylesheets were cool, and that separation of concern was a good thing. "Semantic markup" became the new catch phrase.

Take the Bootstrap framework for example. Many criticize Bootstrap, claiming it's class-heavy CSS implementation taints their holy markup with too many CSS classes. However, I'd like to challenge your thinking on this. Why is Bootstrap hated? Does it really violate the concept of semantics? I would suggest most of Bootstrap's class names are semantic (ie. .form, .form-group, .btn, .btn-default, .btn-success, etc.) because they don't define the styles, but rather they point to our intended styles in plain English. This lends itself to the very definition of the word "semantic". We consider our content first class. We are okay with wrapping our content with <p> tags, <li> tags, <table> and related tags, yet we are not okay wrapping our content with .form-group or .btn-success? I think this view of semantics is flawed.

Another problem with pure HTML is that it creates a new kind of maintenance nightmare (funny, this is the very reason why we stopped using the inline style attribute in the first place). As developers, we spend exponentially more time switching back and forth between our HTML and CSS files, trying to figure out which element was styled and how. When we favour pure HTML, we cannot easily tell how our markup is styled without hunting through external CSS files. Our CSS becomes lacking in English descriptors, consequentially making it harder to read as well. Some might argue, "but that's what your web inspector is for". However, in an era of self-documenting code and readability, I think we can do better. When I read through Bootstrap markup, I can generally understand how everything is being styled, even though the styles themselves are still being defined externally via CSS.

Lastly, as developers, we are always trying to find ways to re-use code. We hate repeating ourselves. HTML is not something that we can easily reuse from project to project because it is tightly coupled to our project content. However, CSS is often something that we can reuse. Why not decouple our CSS from our content so that it can be reused? Bootstrap may not be perfect, but it does this well. If you are really worried about marrying your markup to a CSS framework's naming conventions, use your own class names along with SASS/LESS extends to inherit framework styles. I think this is overkill for smaller projects, but you be the judge.


#Sources:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment