A default background color is needed for any time there is no custom background color.
This happens to use the browser's default `#fff`, and is meant more as a reminder for theme authors.
See #515.
We can safely increase the textarea width from 98% to 100%.
```box-sizing``` handles the layout nicely and it won't allow the overflow.
If more details is needed, please see: http://davidwalsh.name/textarea-width this is the best example I could find.
Minor CSS optimization for border and border color.
For the border itself, we don't need to include the color in ```border: {}```, color is already added in ```border-color: {}```.
Since the Theme uses shorthands for padding/margins, why not do the same for the border colors as well.
The leading whitespace is needed to replace this `_s` instance with the theme name.
It's obviously a hack, since it also leaves the theme name with a leading white space, but short of adding a new replace logic for this specific line in `style.css`, it's the easiest way to achieve that.
See #304, where this was brought up before.
Since HTML5 captions removed the additional 10px that HTML4 versions
come with, the `max-width: 98%;` rule made images blurry. This slightly
simplifies caption styles while still providing support for both HTML4
and HTML5 versions.
See #443.
It consolidates the duplicate `.gallery` selectors, and removes image
styles that needlessly override their earlier defined styles.
Also switches to use inline-block over floats, and adds documentation
for caption styles, to be coherent with documentation for gallery
styles.
```*vertical-align: middle; /* Improves appearance and consistency in all browsers */``` does not apply to all browsers.
Selector hack ```*``` is IE6/IE7 only. See https://gist.github.com/necolas/983116
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.