On CSS in a 'component world'
Earlier today I stumbled across an interesting post discussing the somewhat vestigial use of CSS classes to style web markup:
In this way, you can just use components in a template the same way you can use single element divs or spans. Just type the component tags and plug in the content. This already obviates the need for classes as a way to specify how content should look.
In other words you go from this:
<div class='square'>some content here</div>
// change to a circle
<div class='circle'>some content here</div>To this:
// some content in a drawer
<Drawer>some content here</Drawer>
// change to a Modal
<Modal>some content here</Modal> ~~~In modern web applications, it's pretty self evident that components are the right solution, the right abstraction. But even in a component world, CSS classes and external stylesheets hung around.
Why? Because in the old world, dominated by the old abstraction, there was a rule that you weren’t supposed to mix styles and markup. The reason for the rule was sound because as we've discussed, classes were components and the markup was content.
In a component world, though, that's no longer true, so the rule is redundant. But the rule lived on anyway without being questioned much because that’s what rules tend to do.
It piqued my interest because although the fact that CSS allows for completely custom selectors is, by now, fairly old news... most folks, myself included, tend to stick to the old-fashioned method of defining everything into .id and #class within a stylesheet. When selectors are custom-defined, it is usually likely you might find that mark has been defined, so that using <mark> will serve as a way to quickly apply highlighting as I just did in this sentence.
However, I think there is probably a bit more than simple tradition keeping this particular custom in place, and it was in thinking about how Markdown uses the <mark> tag that it occured to me what the reliance on the 'old' way is all about:
Degradability.
A big draw with Markdown itself is degradability: sans rendering, if you were to just simply view a text document marked with Markdown, it would still be fairly legible. And that's the point: it is able to gracefully degrade while remaining legible.
Sure, in today's world we could likely throw out the class and id selectors and start simply defining entire tags to wrap around content etc - but it would pose a very large issue if one were to then try to render the file in other ways - such as simply viewing as an HTML document.
Now, this article was written in the context of React development, but I think even in this case, a bit of graceful degradation would come in handy. Even fairly basic apps tend to accrue documentation over time, and any documentation within the application itself would be a pain to convert over to add into a README or Sphinx documentation project if the fully-custom selectors and tags had to be excised, or replaced.
Besides degradability, another simple advantage to CSS-as-normal is simply learning curve. For someone looking through your code for the first time, quite alot might be confusing - and with custom tags, perhaps too confusing. Alot of information can be conveyed via e.g. div class="content" - but on the flipside, seeing some code wrapped in a tag like <content> might raise more questions than anything - is this merely a piece of code I'm not familiar with? what does it do?. Of course with some experience, it becomes second-nature to flip over to the CSS to scan for relevant code, but still: it doesn't seem worth the small savings in typed characters when you look at the potential for confusion which has been introduced.
so ultimately...
Ultimately... just do what you prefer, obviously. but i think it's worth considering that there is more than simply arcane tradition which keeps developers in the habit of styling tags the way we've 'always done it', so to speak: by sticking with this method, code will tend to be both more 'portable' thanks to its use of a common format widely used by many applications, frameworks and environments. At the same time, for a world in which CSS remains one of the first learned languages for a wide variety of developers, continuing to write styling for your content with a reliance on the 'classic' setup is a way to maximize the understandability of your code, and reduce confusion for anyone looking at it for the first time.
These reasons might not matter as much for someone looking to minimize their codebase's overall size - and using custom tags might add up to a bit of savings in the long-run, and if you're not particularly worried about other users being able to quickly pick up on your code for further editing, the tradeoff is basically nothing.