Edit and update README to reflect changes to jeffstrap.css

Author: webdevjeffus

README.md

@@ -65,7 +65,7 @@ I'll begin by creating my **jeffstrap.css** file, and setting up some commented-
 ```
 
 ### Resets
-In this section, we'll add style rules that fix a few things that browsers do to render pages oddly or inconsistently. This includes setting the document to size block elements, including the header, main, footer and any divs, using **border-box** sizing, instead of the frustrating default, content-box. We'll also set all **margins** and **padding** to 0, since different browsers use different defaults for these properties. When we want margins or padding, we'll add them explicitly.
+In this section, we'll add style rules that fix a few ways that different browsers render pages oddly or inconsistently. This includes setting the document to size block elements, including the header, main, footer and any divs, using **border-box** sizing, instead of the frustrating default, content-box. We'll also set all **margins** and **padding** to 0, since different browsers use different defaults for these properties. When we want margins or padding, we'll add them explicitly.
 
 ```css
 /* RESETS */
@@ -92,11 +92,11 @@ h1, h2, h3, h4, h5, h6, p {
 
 In the **body** rule, we first set the left and right **margin** to **auto**, so that the app content will be centered on the page. We'll also set **min-width** and **max-width** values to keep our page within a range in which our styling works. If you want a fully-responsive site, you'll need to add media queries—but that's a separate talk.
 
-Finally, in the "Resets" section, we'll add a bottom margin of 0.5rem, to put just a bit of vertical whitespace between elements on the page. (I'll talk more about rems in section on header styles, below.)
+Finally, we'll add a bottom margin of 0.5rem to our headers and paragraphs, to put just a bit of vertical whitespace between elements on the page. (I'll talk more about rems in section on header styles, below.)
 
 
 ### Design Styles
-Design styles apply throughout the website, across all pages and in all sections; they determine the look of the app. Here, we'll set our font choices, as well as the colors for everything in the site. Fonts and colors are all we need to change to completely alter the styling from one project to the next. By pulling those rules together at the top of the file, we make it easy to make changes.
+Design styles apply throughout the website, across all pages and in all sections; they determine the look of the app. Here, we'll set our font choices, as well as the colors for everything in the site. Fonts and colors are all we need to change to completely alter the look from one project to the next. By pulling those rules together at the top of the file, we make it easy to make changes.
 
 ```css
 /* DESIGN STYLES */
@@ -136,11 +136,15 @@ main {
 ```
 
 #### Colors
-We're using a deliberately simple color scheme here—four shades of gray for our backgrounds and font colors, and a contrasting red for links which stands out well against both light and dark shades of gray. Even so, there are several CSS rules that need to include color properties, so this section _looks_ kind of long. Thats because I've moved _all_ the rules which specify color to this section, for ease of maintenance. This probably isn't how you'd set up a stylesheet for the production version, but it makes this quick-and-dirty stylesheet easier to change.
+We're using a deliberately simple color scheme here—four shades of gray for our backgrounds and font colors, and a red for links which contrasts well with both light and dark shades of gray. Even so, there are several CSS rules that need to include color properties, so this section _looks_ kind of long. That's because I've moved _all_ the rules which specify color to this section, for ease of maintenance. This probably isn't how you'd set up a stylesheet for the production version, but it makes this quick-and-dirty stylesheet easier to modify.
 
-The **html** and **body** rules set up the background-color and font color for the site. The **html** background is a medium shade that contrasts with both the dark color of the **header** and **footer**, and the light shade in the **main** element. I've added the **header nav input[type="submit"]** selector to the **body** rule, since we will want the background color for the "Logout" button on our nav bar to match the surrounding header. More on the "Logout" button in the "Header Styles" section, below.
+The **html** and **body** rules set up the background-color and font color for the site. The **html** background is a medium shade that contrasts with both the dark color of the **header** and **footer**, and the light shade in the **main** element. The **body** rule assigns a near-black gray as the background, and a near-white gray as the font color. These colors will appear in everything _except_ the **\<main>** element, which is to say the **\<header>** and **\<footer>** elements. I've added the **header nav input[type="submit"]** selector to the **body** rule, since we will want the background color for the "Logout" button on our nav bar to match the surrounding header. More on the "Logout" button in the "Header Styles" section, below.
+
+The **main** rule sets the light background and dark font color for the **\<main>** element, which includes everything _except_ the **header** and **footer** of the app.
 
 ```css
+/* Colors, con't. */
+
 a:link,
 a:visited,
 header nav input[type="submit"] {
@@ -169,14 +173,11 @@ main td {
 
 ```
 
-
-
-The **main** rule sets the light background and dark font color for everything except the **header** and **footer** of the app.
-
 The next two rules, which start with **a:link** and **a:hover**, style the links throughout the page. The first rule, for inactive links, assigns a rich, dark red which contrasts nicely with both the light and dark backgrounds in the site. This rule also sets link text to bold, with no underline; these properties are inherited by active links as well. The second link rule highlights active links a vivid red, which is noticeably brighter than the dark red of the inactive links. The other selectors in these rules, which include **input[type="submit"]**, style the "Logout" button to use the same colors as other links.
 
 Since the logo **\<h1>** in the header is also a link, it will automatically be styled with the contrasting color, helping it grab the user's attention. If red is too bold a choice for the contrasting color, try two shades of turquoise, gold, blue, green, or even pink. Just be sure that both shades contrast well with both the light and dark shades in your background. Readability trumps aesthetics for an MVP.
 
+The last rule in the "Colors" section assigns the colors for any tables that are included in the **\<main>** element. The table borders should be the same color as the **background-color** of the **body**; the background-color for the table elements should be a shade lighter than the **\<main>** background, so that it stands out on the page.
 
 ### Header Styles
 In this section, we'll set up the rules for the elements in our **\<header>** section. It is here that we see the flexibility of our type-based CSS selectors coming into play.
@@ -208,14 +209,8 @@ header nav input[type="submit"] {
   font-weight: bold;
   width: auto;
   border: none;
-  background-color: #222;           /* dark gray */
-  color: #c00;                      /* darker contrasting color */
 }
 
-header nav input[type="submit"]:hover,
-header nav input[type="submit"]:active {
-  color: #f22;                      /* brighter contrasting color */
-}
 ```
 
 #### header
@@ -227,24 +222,26 @@ In the **header h1** rule, we specify any and all **\<h1>** elements in the **\<
 #### header nav
 The rest of the styles in the Header Styles section deal with the components of the header's **\<nav>** element. To be sure that we don't affect list or nav elements elsewhere in the app, we begin each selector with a mention of both the **\<header>** and the **\<nav>** types. The **header nav ul** rule eliminates the bullet points that appear by default on unordered lists.
 
-The **header nav li** rule changes the links in the nav bar to appear on a horizontal line, instead of as a vertical list; the "border-left" property establishes a vertical border between each pair of links. The **header nav li:first-child** rule _turns off_ that border to the left of the first link on the nav bar.
+In the **header nav li** rule, **display: inline-block;** changes the links in the nav bar to appear on a horizontal line, instead of as a vertical list. The "border-left" property establishes a vertical border between each pair of links, and the **header nav li:first-child** rule _turns off_ that border for the first link on the nav bar.
 
 #### header nav input[type="submit"]
-The remaining rules, which deal with **header nav input[type="submit"]** elements, are necessary because HTML and Sinatra all but _require_ the "logout" link to be created as a button. Since ending the current session requires a POST route with a hidden "delete" object, it is usually created as a single-button form, rather than as a simple link. The last few rules in the Header Styles section are necessary to remove the border and background from the button, so that it looks and behaves like the other links in the nav bar.
-
-**Color Note:** If you change the colors for the app in the Design Styles section, be sure to make the corresponding changes to the links here in the header nav bar. For this reason, it's a good idea to include my comments pointing out color properties in your CSS file.
+The last rule in this section, which styles **header nav input[type="submit"]** elements, is necessary because HTML and Sinatra all but _require_ the "logout" link to be created as a button. Since ending the current session requires a POST route with a hidden input to carry the "delete" action, it is usually created as a single-button form, rather than as a simple link. This rule removes the border and background from the button, so that it looks and behaves like the other links in the nav bar; recall that we set the colors for this input in the "Colors" section, above.
 
-**Performance Note:** Selectors like this one, that depend on an attribute of an html tag, are just about the slowest possible CSS selector. We use them here because we are deliberately trying _not_ to have to add classes to our html file; in the deployed version of the app, you'd be better off to use a class as a selector, even if it's unique.
+**Performance Note:** A selector like this one, that depends on the value of an attribute of an html tag, is just about the slowest possible CSS selector. We use it here because we are deliberately trying _not_ to have to add classes to our html file; in the deployed version of an app, you'd be better off to use a class as a selector, even if it's only used that once.
 
 ### Main Styles
-In **main** styles section, we see our type-based selectors really pay off: they let us write an unlimited number of pages, partials, and forms which look decent (not great, but decent) with absolutely zero time spent on styling. Again, I'll show you the basic CSS code first, then break it down rule by rule.
+In **main** styles section, we see our type-based selectors really pay off: they let us write an unlimited number of pages, partials, and forms which look decent (maybe not great, but certainly decent) with absolutely zero time spent on styling. Again, I'll show you the basic CSS code first, then break it down rule by rule.
 
 ```css
+/* MAIN STYLES - Yield Block */
+
 main {
   padding: 1rem;
   clear: both;
 }
 
+/* Lists */
+
 main ul { margin: 0 auto 1.5rem; }
 
 main ul li {
@@ -253,13 +250,18 @@ main ul li {
   font-size: 1.25rem;
 }
 
+/* Forms */
+
 main input {
   display: block;
   margin-bottom: 0.75rem;
   width: 100%;
 }
 
-main input[type="text"] { padding: 0 0.5rem; }
+main input[type="text"],
+main input[type="password"] {
+  padding: 0 0.5rem;
+}
 
 main textarea {
   width: 100%;
@@ -272,12 +274,12 @@ main input[type="submit"] { width: 12rem; }
 ```
 
 #### main
-The padding in the **main** rule just pushes the text in from the edges of the **main** element a little bit; we use rems instead of pixels here so that the width of the padding scales automatically. The **clear: both** property is necessary to clear out the floats we used in the header; again, this isn't how we'd do it in the production version of our app, but it works fine for this quick-and-dirty stylesheet.
+The padding in the **main** rule just pushes the text in from the edges of the **main** element a little bit; we use rems instead of pixels here so that the width of the padding scales automatically with the fonts. The **clear: both** property is necessary to clear out the floats we used in the header; again, this isn't how we'd do it in the production version of our app, but it works fine for this quick-and-dirty stylesheet.
 
 Headers, paragraphs and links in the **main** element use the defaults set in the Resets and Design Styles, so we generally don't need to add anything for them here. If you decide to increase the size of your headers from the default&mdash;and you very well might&mdash;do that in the Resets section of this stylesheet.
 
-#### main ul and main ul li
-Almost every index view in a Sinatra or Rails app is going to display some sort of list of objects in the data base, but the default presentation of unordered lists is very 1994. To bring our stylesheet into the current century, we'll set **list-style** to **none**, to eliminate the bullets. The **margin** properties are necessary to get the list back into the right spot once we've taken out the bullets. I like to set the font-size for list items to 1.25rem, because these lists tend to be pretty important on our pages, and we want them to be prominent.
+#### Lists: main ul and main ul li
+Almost every index view in a Sinatra or Rails app is going to display some sort of list of objects from the data base, but the default presentation of unordered lists is very 1994. To bring our stylesheet into the current century, we'll set **list-style** to **none**, to eliminate the bullets. The **margin** properties are necessary to get the list back into the right spot once we've taken out the bullets. I like to set the font-size for list items to 1.25rem, because these lists tend to be pretty important in our Sinatra apps, and we want them to be prominent.
 
 #### Forms: main input and main textarea
 Forms are also very common in Sinatra and Rails apps, but again, the default styling for them is generally pretty ugly and unfriendly. We'll handle this mostly by styling the form input elements.
@@ -288,9 +290,9 @@ First, we'll set the **display** property of **main input** elements to **block*
 main label { display: inline; }
 ```
 
-The margins and padding we set for **input** and **textarea** elements add a bit of whitespace to the form, while setting the **width** of each to **100%** makes each field wide enough to display most input data without scrolling. Remember that **\<input>** elements can only display a single line of text. For this reason, you'll want to use a **\<textarea>** form element for any field where users will be entering more than a few words, such as blog posts or comments.
+The margins and padding we set for **input** and **textarea** elements add a bit of whitespace to the form, while setting the **width** of each to **100%** makes each field wide enough to display most input data without scrolling. Remember that **\<input>** elements display only a single line of text. For this reason, you'll want to use a **\<textarea>** form element for any field where users will be entering more than a few words, such as a blog post or comment.
 
-The **main input[type="submit"]** rule sets **Submit** buttons to 12rem, which is wide enough to display the full text on the button in most cases. If you need more space, just up the rem in this rule.
+The **main input[type="submit"]** rule sets **Submit** buttons to 12rem, which is wide enough to display the full text on the button in most cases. If you need more space, just up the rem in this rule. Also, note that since we styled these buttons using **main** along with **input**, this rule does not effect the Submit button that we used to log out the user in the **header nav** element.
 
 ### Tables
 If your app displays complex user or game data, you'll probably want to show it in a table. Here are the rules to add to your stylesheet to automatically style a simple table: