Actually, part of Day 5’s work of setting up Grunt, Sass, and Autoprefixer* for development carried over into Day 6. So, I did little more coding and more work on the overall project housed on GitHub. Part of this work included adding a README file that would stand as the GitHub project’s “front page”. There are at least 3 things I like to include in GitHub README files:
A main project image (and possibly some other images)
A description of the project: what it is and how to use it
A Changelog that shows the various updates to the project over time (I have considered adding this as a separate CHANGELOG.md file, but decided for the time being to leave it in my “front page” README.md)
*Actually, Autoprefixer is now deprecated in favor of grunt-postcss so I will probably take some time to set that up later as well.
Add a GitHub Issue for Images
Adding an image to a GitHub README is relatively easy: all you need is a link to an image that already resides online. You can add this with a ! in front of the image link:
However, if you do not HAVE an image online yet, and you were intending to use an image directly from the GitHub repository itself, you may run into some trouble because you can’t just “Upload Image” anywhere easily. But there is one easy “hack” I stumbled across online some time ago that I’ve been using for a while:
Create a GitHub Issue and upload an image there. GitHub will let you drag and drop an image from your desktop into the Issue reporter textarea, and from there you can grab the link to the uploaded image to use in your README.
This could be a little “messy” because now you will always have at least 1 Issue open for that repository (unless you move your image link offsite), but it works. (I’d tried to do the same thing with GitHub’s Wiki for the repository, but it also won’t allow you to upload an image. Rather it requests the Image URL.)
Finally, I decided to add a LICENSE to the repository.
Since I’ve been developing WordPress stuff for many years now, I’ve come to know and enjoy the GPL license quite a bit. But, I didn’t know if I wanted to just go with that right off the bat, or if perhaps there was something else I might choose. So, I started investigating things and stumbled upon an excellent website that let me compare the different Open Source licenses easily. I considered two choices:
I decided to use the MIT License as it seemed to be a little simpler and had less Conditions.
*Side note: After getting my first WordPress theme approved for the WordPress.org Theme Directory, I realized how important keeping track of the resources you use in a project is. Before approval, I needed to list all the projects, sources, and licenses of every additional piece of software or code I used in my theme (like any Google Fonts I used, FontAwesome, the Foundation Framework, and so on). This is something I may decide is important to do for this project as well.
After coding for 1-2 hours each day for 4 days, I found my code getting quite long:
HTML: 344 lines
SCSS: 602 lines
JS: 187 lines
This quickly starts to become a lot to manage within a Codepen – given that the 3 editors are all small boxes to the side of the screen. I prefer to work on bigger projects in a good code editor like Atom or Brackets (I use Netbeans for really big projects like WordPress themes or plugins). So, I decided it was a good time to upgrade the project to “bigger” and continue development primarily in Atom (which has a convenient Live Server package that really aids in development).
I’ll continue to update the Codepen with my code updates – at least for now.
Setup a Grunt Taskrunner
Codepens are nice in that the Sass, or Less, or PostCSS is instantly compiled and usable as CSS as soon as you write it. But, things don’t work like that in stand-alone projects. So my first step after pulling my files from Codepen and creating a GitHub repository for them was to start preparing to use Grunt.js as a taskrunner to watch and compile my Sass into web-browser-readable CSS. Here are the steps I took (which will be outlined in further detail in a later post):
Finally, in order to begin attempting to get the WP-API running well on this site, I needed some content on a WordPress site to begin pulling from – hence the creation of this series of blog posts.
As mentioned previously, I’m also hoping to create a 25-day series for Advent that highlights my favorite typefaces. The goal is to allow users to switch the series of posts that the REST API pulls from. They’d be able to either load the “Coding an Advent Calendar” series, or the “Advent Typography” series.
Thus, theoretically, the clock should start all over again on January 1 EACH year with a value of 358 or so days. I guess we’ll see in about a month~~
The next step was to create a slider that would literally “slide” through the daily presents as I clicked on the available ones, or the “previous” and “next” arrows. Again, I looked atmanyCSS sliders on Codepen, and used one as inspiration to help make my slider functional as well.
The only problem was that, for some reason, something in my CSS or design was causing each “slide” to be offset an extra 5px to the right. I’d used 100% (or even 100vw) width for the slides – which was 1089px at that time. Yet, when I scrolled to the following slide, the offset was 1094px – and this kept up for ALL 25 days! (Needless to say, that was a pretty noticable mistake by the time Christmas came ’round.)
So, this is an area that will need to be revisited. I have 3 options so far:
Use Bootstrap: except I haven’t yet used it, so it messes up some of my CSS when I import those CSS styles – and I don’t want to depend on it for everything
Use hidden input radio buttons: I’ve seen this done in some othersliders and it looks like it might provide a good option
CSS bow & ribbon
I wanted to make a bow for the present entirely out of CSS, so I went back to CSS-Tricks.com’s “The Shapes of CSS” example page and found an infinity loop. I created an extra <div> for it and played around with the code a bit to get the shape right (flatter, less round, slightly more angled like it was sitting on top of the box), then changed the border colors to create a multi-colored look.
For the ribbon underneath the bow (I decided a bow alone looked a little weird), I used some similar transform: rotate() techniques from the bow and also applied different border colors to the shape to give it a similar multi-colored look like the bow.
From the beginning of this project, I knew I wanted to create some kind of horizontal, side-scrolling effect: either to display the presents in a type of slideshow, or to scroll the background as a white winter wonderland scene. I decided to add FontAwesome gift icons denoting each day leading up to Christmas in the footer that people could click on to open the present for that day.
A couple ideas for continued development:
Make the presents either disabled or inactive (non-clickable – error message pops up) if that day has not yet begun
Initially, I set the colors for the CSS present to green and maroon but was quite unsatisfied with that combination. Eventually, after checking some other color palettes on ColourLovers.com and Dribbble.com, I settled on the following (similar to this Codepen):
Dark Red: #9D1313
Light Red: #F17259
Dark Green: #0B8972
Light Green: #65C0A5
Dark Blue: #2A6FB0
Light Blue: #CAE4F2
Along with various other alpha shades, tones, and tints of these colors as well as Black and White.
Since the color palette I chose would need to be used and reused in the various elements I created on the page, I decided the best way to keep track of those (and easily call them up later) would be to switch my CSS stylesheet to Sass. I stored the color (and other) variables at the top of the stylesheet and was able to easily use them at will throughout the page.
I may yet do something else with Sass mixins or functions (like a @for loop), and I intend to rewrite the stylesheet using Sass nested selectors later.
The goal here is to add a little bit (1-2 hours of coding) to this each day of December leading up to Christmas (at which point it should be a completed project). I may then add some bells and whistles in the week after Christmas as well to make it more fun for New Year’s too.
The following are some initial notes (and inspirational links) I made to help guide my design decisions as I started creating this site.
I searched through a number of Codepens and sites that were using a (surprisingly wide) variety of jQuery plugins to “Let it snow” on websites. I settled on a plugin from MadeByMagnitude.com that showed snowflakes at different sizes and fell lightly over my page. Here are others:
The first font I selected was for the headings of the site. I wanted something that would have good thick, stylized numerals that I could use for the dates I marked on the packages. Then, I wanted looked for a body font to complement it. I thought something with rounded edges would look nice, but I found a very nice old and rounded serif font that fit the Christmas theme very nicely as well.
And, actually, it’s because of my time spent choosing typefaces that I decided to use this Advent Calendar design to highlight some of my favorite all-time typefaces. In a separate blog series, I’ll post One typeface per day that I’ve really enjoyed using in other designs.
I’ve recently been working with SVGs and SVG animation, but I haven’t done a whole lot with CSS shapes (i.e. using a bunch of <div> elements and strange border-radius settings to draw something interesting). Therefore, I decided to create the Christmas presents (and ribbons) in pure CSS and HTML.