search

splorp / tersus

An achingly simple WordPress theme without all the usual cruft.
GNU General Public License v3.0
99 stars 6 forks source link

Got class? #30

Open cdharrison opened 12 years ago

cdharrison commented 12 years ago

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">

cdharrison commented 12 years ago

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.

splorp commented 12 years ago

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.

splorp commented 10 years ago

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.

splorp commented 10 years ago

I’ve added the aforementioned “required” classes to a core.css stylesheet per commit 0ffc96a527fd7b071516bf2b882cb0b4d638e4a3. Only the alignment classes have anything declared for now.

splorp commented 10 years ago

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.

cdharrison commented 10 years ago

I agree. I think limited, specific classes would be ideal.

splorp commented 10 years ago

Cool. Check it … 41103722a3cd6f55b9bca42a5d694f59e9008270

splorp commented 10 years ago

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.