ryanve / action Goto Github PK

Current (1.5) entry templates

• entry.php
• entry-content.php
• entry-footer.php
• entry-header.php
• entry-summary.php

Separate templates facilitate granular overrides. I rarely have needed to override these ones. Loading files hinders performance. I'd like to remove these templates in favor of a faster implementation that only uses hooks. Devs could still override via these hooks.

In 1.0 I used l- as a prefix for layout modifiers (applyable via skins).

• .l-lheader - aligns <header role="banner"> to left
• .l-rmenu - floats .site-nav to right
• .l-rsidebar - floats .main-widget-area to right

l- is somewhat standard and terser than layout- but is it enough?

Versions 1.1- have included <a class="assistive" href="#main"> . It seems like this could be redundant for screenreaders with proper WAI-ARIA support.

WP's built-in Custom Menu widget allows users to pull menus created in Appearance > Menus into widget areas. With this available, is it be better to provide no menu locations? Users can use widgets to place custom menus wherever they want via the widget interface. We'd want to determine how to filter that widget to use nav rather than div.

action should use the CSS file setup that best enables child-theme flexibility while still remaining maintainable and performant. The parent CSS is organized and modular. For performance it is usually ideal for all CSS to be combined in 1 file. 2 files is reasonable and easier to maintain. It helps separate base from theme styles.

0.x file structure

• base.css (base styles agnostic to WordPress)
• style.css (WordPress theme styles)

1.0 file structure

• style.css (not loaded, but must exist for header info)
• css/
  • base.css (base styles agnostic to WordPress)
  • main.css (WordPress theme styles)

Both queue setups (0.x, 1.0) allow any file to be overrided by a child theme. A WP problem is that child themes must contain style.css. The setups above allows modular overriding without needing @import. They rightfully nudge child-theme devs towards cascading rather than editing base styles.

What setup provides the easiest usage to child themes?

One alternative is manually combine everything into style.css and not use a css folder. If a child wants to use the parent stylesheet, it can enqueue it via its functions.php. It'd simplify the parent file structure and improve front-end performance. But it'd make customization less modular and the parent CSS messier. The 0.x setup hybridizes the 2 extremes.

Action uses #2 stylesheets for mainly for maintainability and modularity. A positive side-effect is that the 2nd sheet is only loaded on applicable media types.

<link rel='stylesheet' href='/wp-content/themes/action/base.css'>
<link rel='stylesheet' href='/wp-content/themes/action/style.css' media='screen'>

Maybe [media="screen, projection, print, tv"] is appropriate but its hard to decide without access to other types. Which types should the theme include by default? Test media types and the demo site.

HTML5 microdata is more systematic and resilient than class-reliant microformats. Microdata is supported by major search engines. It seems redundant to duplicate the same data. Test some URLs here. Are there any reasons to include both? Microdata seems sufficient.