There are two kinds of HTML:
- HTML that makes up templates
- HTML that is content
I feel like some discussions about HTML are clouded by not making this distinction.
For example, I like Harry Roberts approach to classes on header elements. Harry was talking about “apps”, so perhaps it was implied, but let’s put a point on it: those classes are for headers in HTML templates, not HTML content.
(This is just a little random example I thought of, this concept applies to broadly.)

If it’s a chunk of HTML that goes in a database, it’s content
It’s not impossible to change content, but it’s likely much harder and more dangerous.
Websites can last a long time. Content tends to grow and grow. For instance on CSS-Tricks there are 2,260 Posts and 1,369 Pages. Over the years I’ve sprinkled in classes here and there to do certain stylistic things and over time I always regret it.
Why the regret over classes in content?
Maybe you’ll find you named the class wrong and start hating it.
Maybe you’ll change the class to something you like better.
Maybe you’ll stop using that class.
Maybe you’ll forget that class even existed, and not address it in a redesign.
Maybe you’ll use that old name again, only it does something new now and messes up old content.
Those are just a few possibilities.
But the pain comes when you decide you’d like to “fix” old content. What do you do? Find all old content that uses those classes and clean them out? Try to run a database query to strip classes? Tedious or dangerous work.
Content in Markdown Helps
Markdown is comfortable to write in, once you get the hang of it. But its best feature is that it doesn’t put, or even allow you to put, classes on any of the HTML it generates. Unless you write HTML directly in the Markdown, which always feels a little dirty (as it should).
Styling Content
How do you style the content then, without classes? Hopefully content is fairly consistently styled. You can scope styles to content.
.content h2 { }
.content figure { }
.content table { }
Say you absolutely need different variations of things in content
If you have to break the “rule” of no classes in content, perhaps you can still apply some smarts to how you handle it.
- If you’re using a CMS, perhaps it has some default classes that are likely to stick around. For example, WordPress spits out classes like
align-right
on images if you choose it. - Can you insert the content in such a way it isn’t just a part of a “blob” of content? Like a custom field?
- Can you insert the content via an abstraction? In WordPress parlinance, like a shortcode?
[table data="foo" style="bar"]
- If you have to use a class, can you name it in a way that feels forever-proof-ish?
Templates are easy to change
That’s what they are for! You probably have a handful of templates compared to how many pages they generate. Change them, and all content using them is updated. The HTML that surrounds the content will all have whatever useful classes you use.
So
- HTML for templates = classes, yay!
- HTML for content = keep it raw!
Do you completely abandon HTML elements that require CSS in content then? Surely such a rule is more the exception, than the case. It favours sites using images for graphically more interesting elements, and could hurt the accessible web.
I Think my way is easier. Migrating content as I view it; is mostly the task of taking the DOM output as it is rendered outside of the DB, map that to a separate copy of the DB. Well marked-up, addressable templates are a win here!
Once you have it from A->B, if you need to, you can make your template more complex, add via CPT, & shortcode. Maybe add to a category (add something to the data so we know it’s from iteration X. (let’s face it, it’s dead or dying anyway, sometimes it’s kinder to kill it, or mark for re-visiting).
Lol what
I didn’t understand a single word you just said.
I lost your after the first paragraph. What do you mean Lewis?
I’m from that group that’s been building website for about 15 years, and was greatly improved by reading Zeldman’s classic about 10 years ago. Thanks to that book, is seems we all developed a basic appreciation of semantic mark-up, keeping style separate from content, and writing css.
Has that lesson been lost to the younger generation, and “professional front-end devs” all just using huge complex libraries w/o understanding much of the basic underpinings? To the point, they know what “float: left” or display: inline-block” means?!
E.g. “@jensimmons stop using javascript, bootstrap/foundation for layout. Use basic css. Keep it simple!” https://twitter.com/RaineDe/status/705772029832732672
I suppose the first-wave of those using (or inventing) a technology has to remember that the next wave wasn’t able to learn it (or make-it-up) as they went, and thereby don’t have the deep understanding of the basics that we take for granted.
Damn! That’s a drag, because now I suppose we’re obliged to teach them :\
I agree that having classes in content is generally bad, but we are also trapped in a way with WYSIWYG editors.
The alignment issue is the big one. I do NOT want inline styles to do left/center/right alignment. So we are forced to use classes for this.
Since I started working on client driven sites, I’ve run into only one scenario where using classes in content is needed and is actually helpful.
There is a very large company I did the technical work for building the site. And the design agency had a lot of formate d content. Stuff like boxes inside of boxes with different styled lists in each different box. They got paid a pile of cash to build this design, so that is the only reason I can fathom they needed to do this.
Now, consider trying to tell the content editors (often times secretaries or other non-web office workers) to select drop down menus to style things. Or jump through complicated hopes of any kind to style a box, and then be sure to use the right style for the list inside that box, just to match the design specs from the design agency. Yuck.
So, I built html snippet/templates that the WYSIWYG editor inserted as a whole block. Then the content editor just goes around and replaces the text where needed.
Will this be a CSS nightmare down the road? I don’t think so. The reason being is that by the time these styles get reviewed, it will be done through a whole site redesign anyways.
But for content that lives on for a long time, like a blog, where the content is not revised when the design is. I agree, classes would be messy bad news.
But considering a simple SQL query could find all your uses of a class fairly easily, maybe it’s not so bad if it really, really helps solve a complicated or difficult problem.
Now that would be a perfect moment for a CCK driven CMS. If you let all the markup in your template you, and your users, would only punch in Content (C). With lots of chunks of content you Construct (C) your page. Such Kits (K) are very common among the known CMS out there, and there is absolutely no need of using markdown or any other document language in order to store your content.
Of course,a CCK asks for a detailed content strategy, but it will provide you with a lot of benefits:
– flexibility (you can add new content chunks anytime to existing content)
– stability (your design will be in your hands, and not in the hands of a unpredictable WYSIWYG-editor.)
– conversion (use the same content for different outputs or layouts)
– safety (it’s easier to safe your raw content into the future, if you don’t have to regex for classes or tags at a later stage)
Just my two cents
Bernhard
Exactly! Content needs to be structured on any but the simplest sites. I give my editors a simple WYSIWYG that allows for semantic markup. The rest is built with extra fields and powerful templates.
Advanced Custom Fields WordPress plugin, ’nuff said – http://www.advancedcustomfields.com/
You should never have a single WYSIWYG field in WordPress. That forces you to cram layout in there.
That’s a pretty drastic statement. Unfortunately many of us live in a world where a client would occasionally like an easy way to make a list or italicize something without learning HTML first.
There seems to be a commonly-recognized divide in the CMS world between what this article is expressing (page content via one massive content editor/field where it’s purely content and no classes or such) and more “structured” content via custom fields/sections/etc (eg: the “Advanced Custom Fields” approach to content management in WP).
Both approaches seem to have their cons (content creators have to go between different fields when creating/editing, the content is stored in multiple DB of flat-file fields which can make site migrations tricky, etc) and pros (lots of powerful templating potential, no badly-formatted structural-related html coming from one massive WYSIWYG field, etc).
Now try this: Go to Medium, create an account, and create a draft post to experience their content editor. It’s sublime. Truly the best of both above-mentioned words. Content creators/editors have a single-unified-majestic content-editing experience. Developers/Designers have magical powers to work with this content in uber-powerful ways.
Just a thought.
Isn’t that what Google developers like Jens Meier are writing about for years? Everyone should know this by now, and still the so-called experts can’t keep themselves from contaminating HTML–worse, yelling at others to contaminate their code too, or being behind thousand years and selling their wisdom as their own.
Edit: e.g. http://meiert.com/en/blog/20140722/docs-and-apps/. Keep it simple.
Snook:
I had a couple of content strategy courses in the fall, and was introduced to the concept of “content types”, which sound a lot like the “objects” Snook is talking about here. A big part of the CS assignments we had was developing a strategy document that outlined what the content types were, what all their parts were, and what kind of CMS “templates” (woefully named and distinct from the HTML templates you’re talking about) would be required to allow authors to create and maintain those types. I feel like if we took the time to think through the content strategy, in many cases, we could get buy-in for more graceful solutions that meet the needs of the authors but don’t allow them to throttle the designs with full WYSIWYG control.
One way I’ve found to implement this in WP is to use ACF together with shortcodes. You create a group of fields in ACF and a “widget” file you throw somewhere in your theme directory, and a shortcode function which binds the two together.
It’s by no means a perfect solution – I’ve toyed with wrapping it up into a plugin but I don’t see any way to do it that doesn’t involve copying a lot of ACFs functionality or depending on it by demanding user’s install it.
This is actually the exact approach we’ve started to take with our WordPress sites – using “content objects” in place of the single body field with flat custom fields approach.
We have a tool called Layout Builder (shameless plug) which lets us drop these “content objects” (we just call them “elements”) into rows of columns.
For example, based on Snook’s article, you define a “pull quote” element:
Then you create a view for it:
Then you go into Layout Builder, decide where you want a pull quote, and drop it in. Fill in the content, fill in a byline (if you want it), and it’ll show up (WYSIWYG). When you’re happy with it, save the “layout”, and put this in your page/post/article/whatever:
[layout slug=example]
This solves the whole problem with different screen sizes, too, because the columns in Layout Builder are based on a responsive grid, just like your front-end. What you see is what you get – if you want to check your page on a smaller screen, just resize the Layout Builder interface to be smaller.
In case you want to mess around with the idea, run
public/example/builder.php
(see here) – there’s no dependence on a database or any sort of CMS, it’s just a standalone demo.Very true! Templates are easy to change. Content usually isn’t.
#comment
{ a very good post;
}
Yeah Awesome POST