Proposing to reword Inputs and Buttons with Forms. This way we can cover more than just couple of elements. Select feels like an outsider and textarea too, even though it's technically an input.
This will also be a perfect match with the rest :)
N.B. Something went wrong with my last proposal, sorry about that.
Hey guys, I am proposing to remove li in front of the current_page_item and current-menu-item. It's slightly more efficient without and of course all works the same :)
* Update PHPDoc.
* Add periods to the end of comment sentences.
* Limit line length to 80 chars.
* Use C++-style PHP comments only for function and file documentation.
Proposing to remove html input from the button class. It overrides more than is needed. For example it will interfere with bbPress editor styles. It's safer to leave input[type="button"] as-is. Please see: http://i.imgur.com/Q98uqBH.png
(Introduced in b1d3b53)
While class attribute selectors are very powerful and might help in
keeping stylesheets concise and easier to maintain, they don't work very
well with a project like WordPress. Not only can third-party scripts
insert and rely on specific class names that get picked up by attribute
selectors for common class names. But more importantly WordPress passes
category and tag slugs on to post classes, which can result in
unpredictible results.
Fixes#284, fixes#309.
* Separate scoping and assignment so that a decision does not need to be made as to whether we should intermix spaces and tabs on the left
* Restore the previously removed nav-menu class addition to the first unordered list in `#site-navigation`.
* Restore the `.navigation-main.toggled-on .nav-menu` selector.
* Remove rules for the `.main-small-navigation ul` selector.
* Only set button and menu if container is not null.
* Break up the "return early" conditional into multiple parts.
* Shorten the name of the toggled class from `toggled-on` to `toggled`.
* Restore the "Hide menu toggle button if menu is empty." documentation.
* Remove the `nav-menu` class. The previous code would replace any custom custom classes applied via `wp_nav_menu()` or template file.
* Replace the `nav-menu` selector is style.css with selectors that will target both a custom nav menu and a page menu. These changes could use critical feedback. Do you know of an edge case where they might not work as expected?
With 3.6 introducing many HTML5 improvements the need for custom
searchform and comment templates will vanish. To cope with core's
.screen-reader-text class, let's make the switch early.
Commit also adds core's focus styles for screen reader texts, so they
can actually be used.
Selectors provide clearing out of the box for the site container,
header, footer, main container, content container, entry content, and
comment content.
Also, theme developers can optionally use .clear as a utility class. Or
delete it.
For more information about the philosophy behind the approach of
selecting class elements, see
http://24ways.org/2012/a-harder-working-class/Fixes#88.