Added a calendar.

public/code/Calendar.css

@@ -0,0 +1,37 @@
+content {
+  display: flex;
+  flex: flex-shrink;
+  flex-grow: 1;
+  justify-content: center;
+}
+
+calendar {
+  display: grid;
+  grid-template-columns: repeat(7, 1fr);
+  grid-template-rows: auto;
+  max-width: 300px;
+  outline: 1px solid var(--color-accent);
+}
+
+calendar day {
+  background-color: var(--color-bg-secondary);
+  font-weight: bold;
+  padding-left: 0.3rem;
+  padding-right: 0.3rem;
+}
+
+calendar month {
+  grid-column: span 7;
+  font-size: 1.5em;
+  font-weight: bold;
+  text-align: center;
+}
+
+
+calendar date {
+  padding: 0.3rem;
+}
+
+calendar date:hover {
+  background-color: var(--color-bg-secondary);
+}

public/code/Calendar.html

@@ -0,0 +1,7 @@
+<calendar>
+  <month>December</month>
+  <day>Sun</day><day>Mon</day><day>Tue</day><day>Wed</day><day>Thu</day><day>Fri</day><day>Sat</day>
+  {#each make_dates() as date}
+    <date>{date}</date>
+  {/each}
+</calendar>

src/Home.svelte

@@ -25,6 +25,10 @@
     padding-left: 4rem;
     padding-right: 4rem;
   }
+
+  h1#faq {
+    font-size: 3em;
+  }
 </style>
 
 <hero>
@@ -45,7 +49,7 @@
   <aside>
     <h3>Add Flexbox + Grids</h3>
     <Icon name="box" size="64" />
-    <p>Using <a href="https://css-tricks.com/snippets/css/a-guide-to-flexbox/">flexbox</a> and <a href="https://css-tricks.com/snippets/css/complete-guide-grid/">CSS grids</a> you can layout anything you want without tons of divs.</p>
+    <p>Using <a href="https://css-tricks.com/snippets/css/a-guide-to-flexbox/">flexbox</a> and <a href="https://css-tricks.com/snippets/css/complete-guide-grid/">CSS grids</a> you can layout anything you want without structure divs.</p>
   </aside>
 
   <aside>
@@ -76,11 +80,11 @@
   <section>
   <aside>
   <pre>
-&lt;div class="grid col-1">
-  &lt;div class="card">
+&lt;div class="grid col-1"&gt;
+  &lt;div class="card"&gt;
   ...
-  &lt;/div>
-&lt;/div>
+  &lt;/div&gt;
+&lt;/div&gt;
   </pre>
   </aside>
   </section>
@@ -90,9 +94,9 @@
   <section>
   <aside>
   <pre>
-&lt;card>
+&lt;card&gt;
   ...
-&lt;/card>
+&lt;/card&gt;
   </pre>
   </aside>
   </section>
@@ -106,23 +110,44 @@
   </section>
 
   <hr>
+  <section>
+    <h1 id="faq">FAQ</h1>
+  </section>
+
+  <h1>Why did you do this?</h1>
+
+  <p>It started as an attempt to relearn modern CSS for myself so I can teach others.  As I did this I realized that most of the things I learned have been completely replaced with flexbox and grids, and if I just use those then CSS becomes much easier to understand. Specificity works as expected.  When I change a component with <b>class</b> or <b>id</b> it actually changes.  The layout flows correctly and is easier to create.  Nearly everything works better and is easier to understand.
+  </p>
+
+  <p>This website became a demonstration to others that <b>layout</b> doesn't need <b>div.class</b> structure, subverting <b>ul/li</b> tags, and other CSS hacks.  You can use simple <b>truly semantic</b> HTML and simple CSS to accomplish 90% of what you're doing today with more reliable results faster.
+  </p>
+
+  <h1>Why is this site in black and white?</h1>
+  <p>I used an entirely monochrome simplified design because I'm not a designer, and I want people to focus on the visual structure of each demo, not whether my use of Cornflower Blue was appropriate for a button.  
+  </p>
+
+  <p>I'm also an experienced oil painter and a fundamental teaching in realist art is that color does not matter for visual comprehension. What matters most is the "drawing", or monochrome aspects of visual experience.  If you can't make something work in monochrome then no amount of color will help.  Make it visually understandable in monochrome and any color scheme you choose should work (barring a few rules about color perception's relationship to monochrome values).
+  </p>
+
   <h1>What's wrong with classes?</h1>
 
-  <p>There's nothing wrong with classes in CSS. How they're used in recent CSS subverts the normal specificity rules making CSS unecessarily difficult.  The original specificity rules put the base design of a component at the tag level, then a <b>class</b> can be used to modify and extend the design, and an <b>id</b> can make this even more specific.  In today's use of <b>div.class</b> heavy markup you lose this ability to alter the design as needed where its used, and instead you have to resort to <b>!important</b> and specificity hacking to change how something looks, or add more <b>div</b> with more <b>class</b>.</p>
+  <p>There's nothing wrong with classes in CSS. How they're used in recent CSS frameworks subverts the normal specificity rules making CSS unnecessarily difficult.  The original specificity rules put the base design of a component at the tag level, then a <b>class</b> can be used to modify and extend the design, and an <b>id</b> can make this even more specific.  In today's use of <b>div.class</b> heavy markup you lose this ability to alter the design as needed where its used, and instead you have to resort to <b>!important</b> and specificity hacking to change how something looks, or add more <b>div</b> with more <b>class</b>.</p>
 
-  <p>The other problem with <b>div.class</b> is it's more difficult to debug problems with the layout.  Because you're relying on specificity that can come from anywhere in the cascade it's much more difficult to find exactly <b>what</b> bit of CSS is overriding your local decisions.  If you've ever had to open the inspector in your browser to troll through CSS locations looking for the culprit then that's why.  If the base design decisions are at the tag level, then your local <b>class</b> and <b>id</b> specifics will work as expected.  You can also replace many uses of class as design modifiers with scoped CSS variables and reduce the use of <b>div.class</b> even further.</p>
+  <p>The other problem with <b>div.class</b> is it's more difficult to debug problems with the layout. There's the obvious problem of debugging failures in layout through a forest of divs, but you're also relying on specificity that can come from anywhere in the cascade.  It's much more difficult to find exactly <b>what</b> bit of CSS is overriding your local decisions.  If you've ever had to open the inspector in your browser to troll through CSS locations looking for the culprit then that's why.  If the base design decisions are at the tag level, then your local <b>class</b> and <b>id</b> specifics will work as expected.  You can also replace many uses of class as design modifiers with scoped CSS variables and reduce the use of <b>div.class</b> even further.</p>
 
-  <p>Finally, using <b>div.class</b> heavy layout systems polutes your markup with structure that's difficult to maintain and change over time.  When you focus on using <b>truly</b> semantic named tags and follow specificity as intended then your HTML is lighter and easier to understand because it isn't full of <b>div.grid.col-1.col-mx-auto</b> class rules that really have nothing to do with the actual meaning of that particular visual element.  With <b>flexbox</b> and <b>CSS grids</b> you don't need any layout divs, and can keep the HTML clean and semantic.  This also ends up being more flexible with less or the same effort as using a pre-made grid system full of divs.</p>
+  <p>Finally, using <b>div.class</b> heavy layout systems pollutes your markup with structure that's difficult to analyze and maintain.  When you focus on using <b>truly</b> semantic named tags and follow specificity as intended then your HTML is lighter and easier to understand because it isn't full of <b>div.grid.col-1.col-mx-auto</b> class rules that really have nothing to do with the actual meaning of that particular visual element.  With <b>flexbox</b> and <b>CSS grids</b> you don't need any layout divs, and can keep the HTML clean and semantic.  This also ends up being more flexible with less or the same effort as using a pre-made grid system full of divs.</p>
 
   <h1>Should we ban div.class?</h1>
 
-  <p>Hell no.  The current problem of <b>too much</b> class based CSS is because of trends in recent years calling for everyone to irrationally ban some practice.  Remember when everyone decided tables were evil?  So then we banned tables and <b>grids</b> completely?  Then nobody could do a layout without crazy tricks and JavaScript?  Nobody wants a repeat of the anti-tables "semantic markup" war, so please don't ban div.class.</p>
-
-  <p>All this website does is demonstrate that you don't need <b>so much div.class</b>.  You can scrap a lot of what you're using now to do layout and go with clean easy to read HTML that has a nicer flat structure and is easy to maintain, then judiciously add in any extra things you find you need like <b>div.class</b>.  Treat <b>div.class</b> like salt. Right now you're pouring a whole box of it on your HTML when a little bit makes it taste better.</p>
+  <p>Hell no.  The current problem of <b>too much</b> class based CSS is because of trends in recent years calling for everyone to irrationally ban some practice.  Remember when everyone decided tables were evil?  So then we banned tables and <b>grids</b> completely?  Then nobody could do a layout without crazy tricks and JavaScript?  Nobody wants a repeat of the anti-tables "semantic markup" war, so please don't ban <b>div.class</b>.</p>
 
-  <h1>How did it get like this?</h1>
-  <p>Before flexbox and CSS grids there really was no choice but to use <b>div.class</b> to make grids for layout.  Since everyone in the CSS design world irrationally banned tables as a layout mechanism your only choice was to invent another table but call it <b>div.grid.col-1</b>.</p>
+  <p>All this website does is demonstrate that you don't need <b>so much div.class</b>.  You can scrap a lot of what you're using now to do layout and go with clean HTML with flatter structure, then judiciously use <b>div.class</b> as needed.  Treat <b>div.class</b> like salt. Right now you're pouring a whole box of it on your HTML when a little bit makes it taste better.</p>
 
-  <p>Today we don't have to use divs for layout anymore.  It's entirely possible to use flexbox and CSS grids to solve many layout problems, and to do it without too many irrelevant alterations to the meaningful HTML. You no longer have to wrap an <b>img</b> with 5 <b>div</b> tags just to overlay it on a background. You can write the <b>img</b>, maybe a <b>figure</b> and then use CSS to do anything you want to it.</p>
+  <h1>Do these demos work on phones?</h1>
+  <p>They could but I haven't taken the time to make them adapt.  That may come in a later release.  Try it anyway
+    as you may be surprised how well the layouts still work on smaller screens.</p>
 
+  <h1>Can I suggest a challenge?</h1>
+  <p>Yes please.  If you find an example of a layout that you think is impossible with flexbox and CSS grids then tell me on <a href="https://twitter.com/lzsthw">Twitter at @lzsthw</a> and I'll attempt a replica. My only requirement is that you also have to tell me what trick the challenge is using.  This is an exercise in replicating layouts, not reverse engineering devious hidden CSS tricks.  Also keep in mind that I am not invested in "winning" and only curious about the limits of flexbox and CSS grids.  If you find something I can't do, that means I found a useful limit to avoid.  It doesn't mean that we throw out all of flexbox and CSS grids so you can go back to the float-clear-div-class 1990s.
+  </p>
 </rationale>

src/demos/Calendar.svelte

@@ -0,0 +1,64 @@
+<script>
+  import CodeView from '../components/CodeView.svelte';
+  import Icon from '../components/Icon.svelte';
+
+  // I'm sure there's a fancy way to do this but whatever
+  const make_dates = () => {
+    let days = [];
+    for(let i = 0; i < 31; i++) {
+      days.push(i);
+    }
+    return days;
+  }
+</script>
+<style>
+  content {
+    display: flex;
+    flex: flex-shrink;
+    flex-grow: 1;
+    justify-content: center;
+  }
+
+  calendar {
+    display: grid;
+    grid-template-columns: repeat(7, 1fr);
+    grid-template-rows: auto;
+    max-width: 300px;
+    outline: 1px solid var(--color-accent);
+  }
+
+  calendar day {
+    background-color: var(--color-bg-secondary);
+    font-weight: bold;
+    padding-left: 0.3rem;
+    padding-right: 0.3rem;
+  }
+
+  calendar month {
+    grid-column: span 7;
+    font-size: 1.5em;
+    font-weight: bold;
+    text-align: center;
+  }
+
+
+  calendar date {
+    padding: 0.3rem;
+  }
+
+  calendar date:hover {
+    background-color: var(--color-bg-secondary);
+  }
+</style>
+
+<content>
+  <calendar>
+  <month>December</month>
+  <day>Sun</day><day>Mon</day><day>Tue</day><day>Wed</day><day>Thu</day><day>Fri</day><day>Sat</day>
+  {#each make_dates() as date}
+    <date>{date}</date>
+  {/each}
+  </calendar>
+</content>
+
+<CodeView source="/code/Calendar" />

src/demos/Tabs.svelte

@@ -68,7 +68,7 @@
     <a>Tab3</a>
   </tabs>
 
-  <h1>Interactive Demo</h1>
+  <h2>Interactive Demo</h2>
   <tabs>
     {#each panels as panel, i}
       <a class:active={ panel.active} on:click={ () => activate(i) }>{panel.title}</a>
@@ -93,4 +93,3 @@
 </content>
 
 <CodeView source="/code/Tabs" />
-

src/demos/index.svelte

@@ -11,6 +11,7 @@
   import NavBar from '../thumbs/NavBar.svelte';
   import Tabs from '../thumbs/Tabs.svelte';
   import GridOverGraphic from '../thumbs/GridOverGraphic.svelte';
+  import Calendar from '../thumbs/Calendar.svelte';
 
   import {push} from 'svelte-spa-router';
   import { holder } from '../../lib/imgholder.js';
@@ -117,6 +118,12 @@
   <GridOverGraphic />
   <figcaption>Grid Over Graphic</figcaption>
 </figure>
+
+<figure on:click={ () => push('/demos/calendar') }>
+  <Calendar />
+  <figcaption>Calendar</figcaption>
+</figure>
+
 </images>
 
 

src/routes.js

@@ -16,6 +16,7 @@ import Panels from "./demos/Panels.svelte";
 import Modal from "./demos/Modal.svelte";
 import NavBar from "./demos/NavBar.svelte";
 import Tabs from "./demos/Tabs.svelte";
+import Calendar from "./demos/Calendar.svelte";
 import GridOverGraphic from "./demos/GridOverGraphic.svelte";
 
 export default {
@@ -34,6 +35,7 @@ export default {
   "/demos/pinterest": Pinterest,
   "/demos/navbar": NavBar,
   "/demos/tabs": Tabs,
+  "/demos/calendar": Calendar,
   "/demos/gridovergraphic": GridOverGraphic,
   "/demos/xoracademy": XorAcademy,
   "/demos/xoracademy/watch": XorAcademyWatch,

src/thumbs/Calendar.svelte

@@ -0,0 +1,62 @@
+<script>
+  import Icon from '../components/Icon.svelte';
+
+  // I'm sure there's a fancy way to do this but whatever
+  const make_dates = () => {
+    let days = [];
+    for(let i = 0; i < 31; i++) {
+      days.push(i);
+    }
+    return days;
+  }
+</script>
+<style>
+  content {
+    display: flex;
+    flex: flex-shrink;
+    flex-grow: 1;
+    justify-content: center;
+  }
+
+  calendar {
+    display: grid;
+    grid-template-columns: repeat(7, 1fr);
+    grid-template-rows: auto;
+    max-width: 300px;
+    outline: 1px solid var(--color-accent);
+  }
+
+  calendar day {
+    background-color: var(--color-bg-secondary);
+    font-weight: bold;
+    padding-left: 0.3rem;
+    padding-right: 0.3rem;
+  }
+
+  calendar month {
+    grid-column: span 7;
+    font-size: 1.5em;
+    font-weight: bold;
+    text-align: center;
+  }
+
+
+  calendar date {
+    padding: 0.3rem;
+  }
+
+  calendar date:hover {
+    background-color: var(--color-bg-secondary);
+  }
+</style>
+
+<content>
+  <calendar>
+  <month>December</month>
+  <day>Sun</day><day>Mon</day><day>Tue</day><day>Wed</day><day>Thu</day><day>Fri</day><day>Sat</day>
+  {#each make_dates() as date}
+    <date>{date}</date>
+  {/each}
+  </calendar>
+</content>
+