tag cutting

Tag cutting is an old habit, people were already doing it as long as 10 years ago. The idea is very simple, just remove the tags from html that you don't "need". Practically speaking, this means checking whether a tag has any css and/or javascript tied to it. If not you can safely remove the tag from your code, saving a couple of bytes from your total page size. Faster is better, right?

I find the image above to be one of the best examples that illustrates this debatable technique. Just imagine that container 1 is the page header, container 4 is the page footer and container 2 and 3 are simple content containers. The difference between the two examples lies with the extra wrapper around container 2 and 3 in the second example. Many people will label this extra wrapper as redundant, but it does make a big difference.

on html and structure

Ask a couple of front-end developers what example they prefer and before you know it you'll find yourself wrapped in a discussion about css positioning. While this is clearly something to take into account, the problem should first be approached from an html point of view as it is unrelated to any kind of css shortcomings. Writing html is more than providing a couple of hooks for css and javascript.

The real question is how container 2 and 3 are related to container 1 and 4. In the first example all four containers exist on a single dom level, which is a bit odd when marking up a typical header - main - footer structure. In the second example container 2 and 3 are grouped together. The header and footer now function as a header and footer of this entire group, which makes a lot more sense. From a structural point of view, this is a major difference which should not be ignored.

It's true that in many cases the wrapper is unnecessary from a css perspective, but that's no reason to simply remove it, especially when it has a clear structural function.

future-proof coding

Another problem with tag cutting is that it is based on a single snapshot of your project. It only takes into account current project specifics. There are unmistakable connections between structure and design and because of that it is safe to assume that there is a very real chance that future updates of your site might require the use of this wrapper after all.

When that happens, it's a lot easier to have the html ready and just upload a new version of the css, rather than to incorporate an extra html rework trajectory. It decreases dependencies, at the same time reduces the chance of unexpected errors.

conclusion

Next time you wonder whether to remove a html tag, think about its semantic or structural value rather than its css/javascript feasibility. Of course css and javascript restrictions might still affect the final html, but they should never be the reason for removing a certain tag, they can only account for extra tags.

Tag cutting comes with maintenance costs and reduces the future-proofness of your html code, a drop in quality you shouldn't be willing to risk, especially if you consider the minimal impact of this technique. Performance is important, but there is more to web design than just speed alone.