Do new features, updates, design use feat: in semantic commit message convention?

Question

I've decided to use semantic commit messages in my new toy project.
I saw kinds of types of semantic commit messages.

type	description
feat	new feature for the user, not a new feature for build script
fix	bug fix for the user, not a fix to a build script
docs	changes to the documentation
style	formatting, missing semi colons, etc; no production code change
refactor	refactoring production code, eg. renaming a variable
test	adding missing tests, refactoring tests; no production code change
chore	updating grunt tasks etc; no production code change

For frontend engineers
design, updates and new features, all of them use a semantic feat:?
Isn't there a semantic like design: or update:?

Answer 1

Following angulars contribution guidelines the style wouldn't be the right choice for design (html, css, etc.) changes here.

A few examples for frontend changes:

what you changed	commit type
you added html/css for a page footer	feat
you fixed a css glitch in IE6 (lol)	fix
you added a link to the footer	feat
you linted your css and fixed indentation issues and missing semicolons	style
you optimized css animations for higher framerates	perf
you added a print style	feat
you ported existing css and chose to use SASS from now on	refactor

Answer 2

Let's have a look at the motivation for semantic commit messages.

You’ll never again be tempted to include a bug fix and a feature in the same commit. My git log is now an easy-to-skim changelog.

1. Commits do one thing.
2. git log is easy to skim.

If you think some new tags would encourage small commits and readable logs for your particular project, add them. But first, consider if you need to.

update seems pretty ambiguous. Isn't everything an update? What are you updating and why? If it's to fix a bug, that's a fix. If it's to add a feature, that's a feat. If it's updating dependencies, that's a chore.

design... if this is a style change to images, fonts, CSS, etc... that could be style. Or it might be distinct and common enough to warrant a new tag. Perhaps assets for commits which only touch assets?