tersus
tersus copied to clipboard
splorp
Got class?
Targeting some of the elements on the page is proving difficult without a class or id to target. Would you all be opposed to adding a class to the <p> surrounding post meta on posts? e.g. <p class="meta">
I was almost hesitant to add this, knowing our goal is to eliminate as much cruft as possible, but I think having a very small number of classes/IDs to target might not be a bad thing.
I’d like to consider that we provide a completely “classless” flavour as the default version of Tersus. We could then provide “some” classes and additional IDs in the advanced layouts only.
Since starting to use the Theme-Check plugin, I’ve noticed that WordPress “requires” the following classes:
.aligncenter
.alignleft
.alignright
.bypostauthor
.gallery-caption
.sticky
.wp-caption
.wp-caption-text
Some of these make complete sense, like the image alignment classes. I would consider adding these to the stylesheet, whether or not the decrufted code includes them right now. At least they’d be there for the child themes to hook onto.
I’ve added the aforementioned “required” classes to a core.css stylesheet per commit 0ffc96a527fd7b071516bf2b882cb0b4d638e4a3. Only the alignment classes have anything declared for now.
Also according to the WordPress Theme Check Guidelines, inclusion of the body_class() call inside the <body> tag is required. In previous releases of Tersus, we opted to remove the call completely because of the massive cruftiness that it spews out.
To illustrate this, the following list of CSS classes was obtained from post-template.php in the WordPress core and shows all possible classes that body_class() can insert by default (not all at once, of course).
admin-bar
archive
attachment
attachment-<mime_type>
attachmentid-<post_id>
author
author-<author_id>
author-<user_nicename>
author-paged-<page>
blog
category
category-<slug>
category-<term_id>
category-paged-<page>
custom-background
date
date-paged-<page>
error404
home
logged-in
no-customize-support
page
page-child
page-id-<page_id>
page-paged-<page>
page-parent
page-template
page-template-<slug>
page-template-default
paged
paged-<page>
parent-pageid-<post_parent>
post-type-archive
post-type-archive-<post_type>
post-type-paged-<page>
postid-<post_id>
rtl
search
search-no-results
search-paged-<page>
search-results
single
single-<post_type>
single-format-<post_format>
single-format-standard
single-paged-<page>
tag
tag-<slug>
tag-<term_id>
tag-paged-<page>
tax-<taxonomy>
term-<slug>
term-<term_id>
Now, that’s a lot of cruft.
I recommend that we reintroduce the body_class() call, but filter its output so that only one or two classes are inserted per page. The classes I suggest that we include are as follows:
home
page
single
attachment
archive
search
error404
Optionally, we could expand the list to include these somewhat benign (but related) classes.
blog — indicates when the home page is a list of recent posts vs a single page
date — type of archive
category — type of archive
tag — type of archive
admin-bar
logged-in
rtl — right to left text
Your feedback is appreciated.
I’ve updated the labels for this issue to reflect that it requires documentation. Case in point, I’d like to add a section to the read me which lists which core classes we have included in the theme.