DEV Community: Benjamin McShane

Phase 5 Project Introspective

Benjamin McShane — Thu, 17 Nov 2022 11:18:02 +0000

** My thoughts **

Phase 5 was a very interesting time to say the least, it was our first real time unchained as individual full-stack devs with the intent of creating something good entirely by ourselves.

CSS: My Toolbox

Benjamin McShane — Wed, 12 Oct 2022 21:17:16 +0000

What is this?

This blog post is the final part of my "CSS: A Beginner's Guide", and it's where all my miscellaneous tips and tricks can be found. These are presented in no particular order, and are just various things I've learned over the past few weeks that have improved my CSS game.

Layered Backgrounds

If you ever find yourself trying to have multiple images layered on top of each other, you may be immediately tempted to use something like the position: property. Instead, I would recommend trying background layering first.

In my first project, I found myself trying to impose our sites logo on top of another image:

To do that, we implemented background layering:

When trying to layer multiple background images, all you have to do is provide two values for every background property!

If you use this method, remember that the first value will always be the one on top of the others.

Z Index

Another way to do image stacking is by using the 'z-index:' property. This property tells your code which "layer" an element should be on. Unfortunately this property only works on elements affected by the 'position:' property, which in my experience can be difficult to work with.
https://www.w3schools.com/cssref/pr_pos_z-index.asp

Blend Modes / Filters

If you ever find yourself trying to alter an image as it is displayed on your page, then blend modes and filters are for you.

Using filters, you can change all kinds of things about your images: blur, grayscale, contrast, etc.
https://www.w3schools.com/cssref/css3_pr_filter.asp

Using blend modes, you can merge images, apply color filters, and more.
https://css-tricks.com/basics-css-blend-modes/

Active Buttons

If you want to make a button seem more active, then I highly recommend using the :hover and :active Selectors liberally. Having a button change to a darker hue while a cursor is over it, and then having an even darker hue when pressed, is a sure fire way to tell your users that something is happening when they use your site. Additionally, you can use the 'border-style:' property to have a button change from an outset border to an inset border while clicked. This gives the illusion of clicks actually pushing the button.

Visually unresponsive buttons are not just incredibly dissatisfying, but they can also make it seem like a site just isn't functioning properly.

Importing Fonts

While 'Arial' and 'Times New Roman' are great fonts for seeming professional, they are also incredibly visually boring, which makes importing fonts an excellent way to make your site stand out.

I personally recommend using https://www.cdnfonts.com/ when searching for good custom fonts. Not only do they have a massive free library, but they also will give you the exact code snippets you need to use when importing your font into your HTML, and how to call them in your CSS.

Changing your Website Icon

If you want to change the Icon on your page

You can do that by importing and setting the icon in your HTML like so:

There are plenty of free libraries for .ico files on the web, but if you can't find what you want, it's none too difficult to make your own. If I remember right, for my phase 2 project I just manually changed the file type of the image we wanted to use in VS Code.

Text Borders

Visually dense backgrounds can make text very hard to read. The best way to directly combat this is by adding a contrasting border to your text:

The code to apply this kind of property is simply:

    -webkit-text-stroke: (Pixel Value) (Color);

While this can be hard to apply on small text, it is perfect for titles and headers.

Color Picking

If you are having difficulty finding the hex code or rgb values for the colors you want, then I would recommend just googling 'hex color picker'. Google has this tool built right into their search engine, and you can use it to quickly and easily find what you are looking for.

Additionally, you can use VS code to adjust your colors by simply clicking on the box that appears after writing a color:

The ensuing pop-up lets you adjust your colors on the fly!

Letter Spacing / Line Height

When using HTML header elements, you may realize that the text takes up a lot more space than it needs. If you want to get rid of this trait, or apply it elsewhere in your code, you can do that using the 'line-height:' property. This property can be used to adjust the amount of space a line of text will take up.
https://developer.mozilla.org/en-US/docs/Web/CSS/line-height

Also on the subject of text spacing, the 'letter-spacing:' property can be used to make the space between individual letters bigger or smaller. This property is particularly useful when using custom fonts.

https://developer.mozilla.org/en-US/docs/Web/CSS/letter-spacing

rem

While learning CSS, you may start to notice people using things like 'rem' when declaring values instead of 'px' or '%'. Theres actually a whole slew of different measurements you can use in CSS, you can learn more here:
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Values_and_units#:~:text=To%20recap%2C%20the%20rem%20unit,does%20not%20keep%20getting%20larger.

These measurements won't always be useful, but some are. 'rem', for example, can be used to set the size of an object based on the parent container's font size.

Floats

Sometimes it can be difficult to make your elements go where they are supposed to. As a standard, all elements will try to hug the left side of your screen, which can prevent elements from lining up properly. If you want to change the base direction an element will try to go, you can do that using the "float:" property.
https://developer.mozilla.org/en-US/docs/Web/CSS/float

Padding vs Margins

Something that may prove useful while working on CSS, is understanding the difference between 'padding:' and 'margin:'. Padding changes how much space an element takes up, while margin creates an invisible space outside of your element. In most scenarios, these are essentially the same thing, but occasionally the distinction can be important.

White Space

The 'white-space:' property can be used to change how a text element collapses its text. This can be used to prevent your text box from cutting off lines or text or words.
https://developer.mozilla.org/en-US/docs/Web/CSS/white-space

Opacity

If you want to make an element less visible, the best way to do this is using the 'opacity:' property. This can be used in a number of ways, but mainly it is used to make sure things like background images are still visible through your images.

Linear Gradient

Mostly, gradients are used to create colorful backgrounds that slowly transition between two or more colors, but if you get creative, then can be used to do amazing things. In my phase two project, I used a linear gradient to create a reusable line break element that looked like this:

I did this by making a horizontal gradient that shifted from having no color value, to white, to no color value again. Here is what that looked like:

Justify Content

The justify content tool is occasionally very useful in changing how items are aligned on the page. At times this tool can be used in place of something like 'text-align:'. Sadly, this tool tends to break in the presence of flex properties. Even so, I think it can be important to learn more about it.
https://developer.mozilla.org/en-US/docs/Web/CSS/justify-content

CSS: Flexible Design

Benjamin McShane — Wed, 12 Oct 2022 20:55:08 +0000

Flexible Design

Making your CSS be flexible is as important as it is infuriating. Having your code grow to fill up the screen when too small, having it shrink when it is too big, having it change shape based on its contents, and having its contents change shape based on their container. These are all amazing examples of flexible design, and each offers a new and unique kind of torture. When I said earlier that "CSS does not make sense", at least 50% of that confusion comes from the difficulty of creating flexible design.

Unfortunately for anyone looking to make good CSS, we don't really have the choice to not make our code flexible. This struggle is inevitable, and it will serve you well to treat it with the respect it deserves.

So what is flexible design? Basically, it's making your code dynamically decide what shape to take based on a number of different values. One of the most common reasons you would make an element flexible is because you don't know what size screen your website will be viewed with. A program made with good flexible design will be just as legible on a phone screen as it is on a flatscreen.

The Woes of "flex"

So why is making flexible design such a nightmare? This is mainly because most of the properties that will allow flexible design do not seem to play well with other properties, and the properties they don't work with aren't always consistent. This can make using any flex property feel like a game of "what's gonna break this time?".

Besides breaking other properties, the main issue with flex properties is when you start having to nest flex elements within each other. Most flex properties will require a more concrete parent element to contain their changes, but what if the parent element also needs to be flexible in a different way? The result is programmer suffering.

My few tips

Here are a few tips I've learned that might help you in your quest to conquer flexible design, use them well.

1 - Use Soft Values

When writing CSS, you might be tempted to use hard values, like coding an element to be "400px" tall, or "250px" wide. These hard values are antithetical to the idea of flexible design, and you should try to avoid them as much as possible. Instead, try to use soft values like percentages as much as possible. If you tell your code that an element should be "50%" wide, then regardless of the size of the screen or browser, your element will always be half its width. You can also use percentages when declaring margins and padding, so be sure to use them to better shape your elements. The only issue with using percentages in this way is when you apply properties to an element that HAVE to have a pixel value, like the border property.

2 - Consult the Display Property

The display: property has a lot of different tools to help you shape your content as you need: tables, grids, lists, blocks, etc. These properties can be hard to use / implement, but when you can get them to work, they will do a lot of the work for you.

3 - Familiarize yourself with the Flex property

The flex: property is the tool designed around making content flexible. Used properly, it is the best tool for creating flexible design, but it can also be a headache to implement. As I understand it: flex-grow: will have your contents grow to fill its container, flex-shrink: will do the inverse, and flex-basis: will have your contents always be a certain percentage of your container's size. Unfortunately, these properties can be very persnickety about when and where they will work.

4 - Check out the Overflow property

The Overflow property can be very useful. At the most basic level, most HTML elements will automatically grow to be just slightly larger than their contents, but making an element flex will often cause this to stop working. When using flex containers, you will run into issues where your contents will expand outside their containers. There can be many ways to fix this, but one to consider is the overflow: property, which tells your code how to handle contents overflowing from their containers. If 'overflow:' doesn't do what you want, you can also try 'flex-wrap:' as it does a pretty similar thing.

Summary

Making good flexible design is one of the biggest headaches of CSS design, and it likely will be the cause of most of your troubleshooting. Trying to get a grip of the flex properties before you implement them anywhere will save you a lot of headache. Besides that, use soft values as much as possible. Having flex: elements inside of containers with set percentage sizes is the most basic way to make flexible design.

CSS: Clear Design

Benjamin McShane — Wed, 12 Oct 2022 20:00:08 +0000

Clear Design

In big projects, poorly managed CSS files can become impossible to read very quickly. Assuming you are doing all of your CSS in a single file, then a complete project can easily top 1,000 lines of code, and that can be very hard to sort through. This is why it is very important to utilize clear design techniques while writing CSS. Now a few of the techniques I'll be going over in this post are just things I've started doing, and they've made CSS far more hospitable for me.

Naming

So first off, the main way you can make your CSS easier to read is to just write less of it. In the CSS:Naming blogpost, I talked a lot about proper naming conventions, and more importantly, how much they can be used to cut down on bloat in your project. Here is the link to that post in case you missed it:
https://dev.to/bmmcshane/css-naming-elements-4c8p

In short, using good naming practices can allow you to cut out a lot of unnecessary code. Another thing to keep in mind when naming your elements is trying to use short but descriptive names. If every element's name is at least four words long, your CSS is gonna suck to write. Conversely, if every element is named '1', '2', '3', '4', etc. you are going to be constantly referring back to your HTML to even remember what elements you are working on.

Grouping/Organizing

One of the things I've started to do in my code, is to organize and group closely related parts of my CSS together. Doing this allows me to easily recognize where my code is going and where I can find it.

For example my last project looked like this:

All of our elements were split into three separate columns:

And here is how I organized the code for that:

By writing my CSS left-to-right, top-to-bottom, I was easily able to keep track of all of my code based on its positional relationship to the rest of the code. Additionally, by tactically using black space in my code, I was easily able to partition my CSS into more manageable chunks.

While we are on the subject of Naming, check this out:

When changing the CSS of different elements specific to their containers, I always try to put that code directly under the CSS for the parent container.

Finally, I find CSS a lot nicer to read when individual properties are grouped up by similarity.

That just makes CSS a lot easier to look at in my opinion.

Minimize your Code!

After organizing your code like above, another step you can take to make your code clearer is to take advantage of code minimization.

These little tabs will allow you minimize code you aren't currently working on, which takes obtrusive code like this:

and turns into clean code like this:

Clean out the trash

This might sound like common sense, but if your code isn't working, delete it. Pretty often while troubleshooting CSS issues, I will fill the problem element with all kinds of properties until something works. While doing this, I will frequently comment out non-functional code in case I find out I still need it later. If you manage to solve your problem, I highly recommend deleting commented-out code.

Additionally, if you are looking to clean out even more trash, I highly recommend using the elements tab in the DOM to deactivate properties in your CSS and seeing if it changes literally anything. Many times, after solving an issue with your CSS, there WILL still be 'active' code that is literally doing nothing. Going through and clearing out these useless bits of code can really trim down the size of your CSS files.

Separating your CSS

The final CSS clean design technique I have for you is actually something pretty new to me. Essentially the idea is to create a separate CSS file for each React component, and then import each individual CSS file into its respective component.

As I understand it, this allows you to apply CSS properties to HTML elements for each individual component without having them overlap. If used properly, this can allow you to seriously cut down on things like ClassNames and IDs, all while perfectly partitioning your CSS into its own file entirely!

CSS: Frameworks and Extensions

Benjamin McShane — Tue, 11 Oct 2022 21:46:05 +0000

What are CSS Frameworks?

CSS frameworks are packages of code, usually installed via NPM in the terminal, that change how a document will read its CSS. Usually these tools will attempt to make writing CSS 'easier' in various ways. For example, the Tailwind CSS framework allows you apply many different properties to an element in a far more succinct way:

#credit-box {
@apply m-5 items-center flex
}

In the above code, I am using Tailwind CSS to apply three CSS attributes in a single line of text. I am setting the margin of the element to 5px, I am center-aligning the item, and I am assigning the flex display type to the element. In terms of cutting down on unnecessary code, these tools are excellent for trimming the fat of your CSS files.

CSS Framework limitations

Unfortunately these frameworks often have some pretty glaring limitations. In general CSS frameworks don't handle custom properties particularly well. For example, Tailwind CSS, as far as I am aware, does not accept custom hex codes when coloring elements. If you want to color an object with Tailwind, you'd have to choose from one of their preset colors.

Now this isn't a nail in the coffin for Tailwind, it just means that you can't use it for everything. In my last project a lot of my CSS wound up looking like this:

#item {
  background-color: #323432;
  @apply mx-0 center-align basis-1/2 
}

The above text uses both Tailwind CSS as well as manual CSS to achieve what I wanted out of it.

CSS Extensions

Separate from frameworks are CSS expansions, which can serve to expand the capabilities of CSS in new and interesting ways. For example in my last project, I installed a CSS extension called Sass, which allowed me to create custom designed borders for my elements. Unfortunately, due to the broad nature of extensions, it can be difficult to talk about them in broad terms, I just find it important to remember that if you find your CSS feels limited in its capabilities, there is likely an extension that can help you get the job done.

Summary

CSS frameworks are good for cutting bloat out of a project, but bad for customization. You are unlikely to find one that does everything you want it to do, but that doesn't mean you shouldn't use them. Find one that you like, use it to do what is simple, and then do the rest yourself. As for extensions, they won’t always be helpful or necessary, but they are a good thing to keep in mind if you ever find base CSS limiting.

CSS: Naming Elements

Benjamin McShane — Tue, 11 Oct 2022 21:03:03 +0000

Naming:

Naming elements in HTML is the best way to specifically apply CSS to your page. By using these names, we can put all of our page styling into our CSS files, which makes our HTML far easier to read. There are two main ways of naming your CSS, ClassName and ID. The primary difference between these two conventions mostly comes down to how they interact with your JS, but for CSS purposes the difference is this: ClassName is something you apply to multiple different elements, ID is something you apply to lone instances of an element. It might not cause you issues all the time, but it is good form to try and avoid repeating element IDs in your code, lest you start to form any nasty habits.

IDs ought to be unique.

ClassName

To start off, here is how you identify a HTML element with a ClassName:

<p className="example" >Lorum Ipsum</p>

And here is how you would then call that className in your CSS:

.example {

}

From there, you can apply your CSS properties to any item with that ClassName by simply typing your CSS into those curly brackets.

ID

IDs are pretty similar in how you declare them. Here is how you would assign an ID to an element:

<p id="specific-item" > Specific Lorum Ipsum </p>

And here is how you would call that element into your CSS by it's ID:

#specific-item {

}

As with your ClassNames, you can then directly apply your styling onto your item by writing those properties within the curly brackets.

Applying CSS directly to Element Types

Another thing to keep in mind with naming your elements, is that sometimes it's entirely unnecessary. If the idea of naming elements is to cut down on wasted space, then applying ClassNames and IDs to every element can be counter-productive. Sometimes you can save space by applying CSS attributes directly to your HTML element types.

The syntax to do this is very simple. Say you want to make every paragraph element on your page have white text and a black background. You can do that by putting this into your CSS:

p {
  background-color: black;
  color: white;
}

The above code would apply to every single paragraph element in your code, and it is an excellent way to save time while naming things.

Another great way to apply this technique is by using it to apply a design 'standard' to your whole page. By adding attributes directly to your body element, you can create a standard all other elements will naturally follow unless specifically over-written. For example:

body {
  font-family: "Times New Roman", Times, serif;
  text-align: center;
}

The above code will cause all of the text on your page to have the 'Times New Roman' font, and force text to be center-aligned by default.

Applying CSS to Elements depending on their Containers

But what if you want to apply properties to specific types of HTML elements within a specific kind of container? Say you want to apply a certain font to paragraph elements inside a specific type of class. You can do it like this:

.example p{
  font-family: "Times New Roman", Times, serif;
}

The above code will cause any paragraph tag to have the 'Times New Roman' font, so long as it is nested with an element with the 'example' ClassName.

Applying CSS to Elements when Interacted with via Selectors

Finally, you can use these things called Selectors to apply CSS to elements, but only while certain things are true. For example, by using :hover, we can cause an element to have different CSS properties while a cursor is over the object. Here is some example code for that:

button {
  color: red;
}
button:hover {
  color: blue;
}

The above code will cause a button element to change from red to blue while a cursor is above it. Similarly, :active can be used to apply CSS attributes to an element, but only while it is being actively clicked. There are many different situation specific selectors you can use, like :link or :visited for example. Using these selectors makes your CSS look and feel like its actively responding to your users. Be sure to look more into them if you are trying to make your CSS more dynamic!

CSS: The DOM

Benjamin McShane — Tue, 11 Oct 2022 20:04:28 +0000

What can the DOM do for me?

If you want to spend a lot of time working with CSS, then allow me to introduce you to the DOM, your new best friend. Through the elements tab of the DOM, you can look at each individual element on your page, what it contains, what contains it, what properties it inherits, how much space it takes up, margins, padding, etc. The DOM will even allow you to write CSS, and have it load onto your page in real time. In this way, the DOM is fantastic at telling you what is working, what isn't, and what might. It won't save your changes to your code, but it provides the perfect playground for testing different tools.

Guide

The first step to using the DOM is obviously opening it:

On Mac, the default command to do so is: Option + Command + J

On Windows/Linux, the default is: Ctrl + Shift + J

After inputting this command, your page should change to look like this:

From here, navigate to the elements tab via the dropdown menu next to where it says console.

This should cause your DOM to start looking like this:

Now Google's HTML might be a little too complicated to understand, so I'll be going to something a little simpler before explaining what all is occurring in the DOM elements tab. For the purpose of this guide, I'll be using: http://www.columbia.edu/~fdc/sample.html

This is a lot easier to understand.

So starting off, this top box in the DOM elements tab will allow us to look at our websites HTML directly.

Using the HTML drop downs, we can find the contents of any HTML element on our page, including elements contained within other elements. Hovering over these elements will highlight them on the page, showing us exactly what space they take up as well as how many pixels tall and wide it currently is.

Clicking on an element in this menu, selects it for the box below:

In this box we can see what CSS properties are being applied to each element, what the element is inheriting from its containers, etc. In this box we can even change the elements CSS properties manually.

Now these changes won't save to your code, but they are a fantastic way of testing different CSS properties without having to actually change your code.

As a side note, you may notice that opening the DOM causes your page to resize, which may affect the spacing of your CSS elements, making it hard to tell if your changes are working like you want them to. The simple way to fix this is by using these black bars,

and this view percentage drop down,

to change how your page is displayed in the DOM.

In my experience, these tools are more than enough to fix any problems caused by the DOM resizing your page.

Summary

The DOM is the main tool I use when troubleshooting my CSS. It gives me a perfect view of how my page is interpreting the code I am passing it, and it even allows me to change it straight from the browser, so I can test different kinds of fixes to any problem I have. As far as I'm concerned, using the DOM effectively is super important to making good CSS!

CSS: A Beginner's Guide

Benjamin McShane — Tue, 11 Oct 2022 19:45:11 +0000

Background:

Over the last few weeks, I seem to have accrued a reputation for quality CSS design. Thanks to this reputation, a few of my classmates have begun asking me for tips on working with the language, which has led me to making this: a beginner’s guide to CSS based on what I’ve learned so far. CSS is by far my favorite thing to code so far, and I have a lot of strong opinions regarding UI design / how a site should look. That said, I am only a beginner, and there are a lot of gaps in my knowledge. The purpose of these blog posts are to share my thought processes regarding CSS design, as well as some of the tools I have learned so far. This will not be the definitive guide to the language, it is intended as more of a jumpstart for anyone looking to get a grasp of the CSS Design.

How to think about CSS:

Before I get too into the nitty gritty of how to actually use CSS, I would like to start by explaining my thought process regarding CSS.

CSS does not make sense most of the time.

Oftentimes you WILL run into situations where two different CSS properties will conflict, generally with one attribute entirely negating the other. It can be very hard to understand why these issues occur, how to fix them, and how to prevent them in the future.. Each time you run into this kind of issue, the only option you really have is to try different properties, values, and locations until your code finally looks the way you want it too. Occasionally there will be solutions online that seem to apply to your situation, but in my experience, a lot of the time those solutions won't work either. These difficulties have convinced me of this: the best way to troubleshoot CSS that I know is to try all kinds of different ‘tools’ until one manages to fix your problem. Unfortunately, the only way to make this school of thought work is to have a large ‘toolbox’.

"When all you have is a hammer, all of your problems begin to look like nails"

What I mean by having a large toolbox is this: there are many properties in CSS that seem to do largely the same thing, and all of them will have their own unique array of properties that they will and won’t get along with. By working to remember and understand these seemingly similar bits of code, whenever you run into a problem you can just swap these properties for one-another until something works. For me, this process is far more preferable than trying to keep track manually of which properties play nice. After running through all of your known ‘tools’, you can either try to expand your toolbox by learning a new trick, or you can try to restructure your code around the ‘tools’ you do have. Overtime, you are likely to get a far better feel of what things will work together, and the process will begin to pick up speed, almost like building muscle memory. Following this school of thought, your code will always eventually look how you want it too, even if it takes a little longer to get there.

As far as I am aware, there will always be a way to make your code look how you want it to.

Now CSS isn't all powerful, many of the more complicated aspects of UI design require your CSS to work closely with your HTML and JS, like using your JS to import google maps, or using your HTML to import fonts and logos. That said, CSS used properly is capable of most things you will want out of UI design. I can say this confidently because...

...almost every site on the web uses CSS, and that means most of the amazing designs you can find online are in large part thanks to CSS and its many tools. If you want to make those same kinds of amazing designs, you have to have a large repertoire of CSS ‘tools’, and the experience in how to use them.

TLDR: CSS is complicated, and trying to provide blanket solutions for any CSS problem will rarely be helpful. Instead, this guide will try to guide you through my thought process of how to make troubleshooting CSS less awful, all while sharing some of the techniques, tools, and properties I’ve learned so far.

Author's Note:

After writing that last block of text, I've realized that trying to compile all of my thoughts about CSS into one post would be a massive disservice to anyone actually trying to read it. Because of this, I will be separating my thoughts into a number of separate text posts and then linking them directly here. Hopefully this will make navigating this guide easier for y'all.

Additionally, if anyone reading through these posts has anything to add, please feel free to post it in the comments and provide any insight you may have. All coding starts with crowdsourcing knowledge from strangers, and I invite all of you to throw your lot in.

The DOM:

The DOM provides many tools that can and will help you make your CSS better, and I strongly encourage anyone looking to improve their design abilities to become familiar with it.

In this blogpost, I will guide you through the elements tab of the DOM, and how it makes coding CSS much easier:
https://dev.to/bmmcshane/css-the-dom-22ei

Naming Elements:

Despite largely occurring in your HTML, 'Naming' your code is a very important part of CSS design.

In this blogpost I go in depth about where and how to apply ClassNames/IDs, as well where to just apply properties straight to your HTML elements:
https://dev.to/bmmcshane/css-naming-elements-4c8p

CSS Frameworks and Extensions:

As one of the most broadly employed coding languages, CSS has a number of different frameworks and extensions that change how you use CSS or expand upon its capabilities. These tools are separate from my previous metaphor about toolboxes, these frameworks and extensions are actual code you can install on a project that make coding CSS generally easier. Even though my experience with these tools is limited, I still think it's an important topic to broach.

In this blogpost I go more in depth about CSS frameworks/extensions and how you might employ them:
https://dev.to/bmmcshane/css-tools-1lp5

Clear Design:

On bigger projects, CSS can quickly become very hard to read, especially depending on often how you apply ClassNames and IDs.

In this blogpost I go over a few tips and tricks I've started using to make my CSS more readable, as well as some theory that can help separate your code into more manageable chunks:
https://dev.to/bmmcshane/css-clear-design-fbd

Flexible Design:

One of the biggest hurdles in CSS design is making your code fit whatever screen it occupies. Getting this right can be pretty difficult, but it's a very important aspect of CSS design, especially if you actually intend to use the site you are making.

In this blogpost, I share what I've learned so far about making flexible design:
https://dev.to/bmmcshane/css-flexible-design-4lj5

My Toolbox:

Finally, this blogpost is where I will be talking about the individual tools/properties that I have come to understand, and I'll be sharing them with you all, lest you have to struggle in the same ways I had to:
https://dev.to/bmmcshane/css-my-toolbox-34eb

Footnote:

That's just about everything I have for you all right now. Again, if you have anything to add, feel free to add it in the comments, or you can try and get in contact with me directly about whatever it is. Additionally, feel free to ask me any questions you might have. I can't guarantee a solution, but I can certainly try to point you in the right direction.

With that said, thanks all for reading my blog!

Understanding Limitations and Managing Expectations

Benjamin McShane — Tue, 11 Oct 2022 18:22:58 +0000

Project Week

Last week was project week here at Flatiron, and it was absolutely the most informative and most soul-crushing experience I've had in this program so far. Our project deliverables were simple: a simple, single page React frontend connected to a Ruby backend. The real difficulty came from our own decision to make something way more complicated than the expected scope of the project. We decided to try and create a farmville/tamogachi style game, where you would be able to create an account, plant plants, watch them grow, harvest them, and buy upgrades. This idea would fall far outside the scope of the project requirements, still meeting them of course, but also being way harder than was necessary.

The start of the project seemed to go very well, enough that I became very optimistic that we would be able to achieve all of our stated goals. Unfortunately by that time, the seeds of our demise had already been planted. Between some initial confusion in our initial designs, mismanaged division of labor, and some overconfidence in our abilities, we had already cemented some pretty extreme flaws into our project, flaws that would only rear their heads as we approached what I thought would be the finish line.

Managing Expectations

The first of the two major lessons I learned this project was the importance of managing expectations, and had I employed this skill at the beginning of our project, it is very likely that we would have been a lot more successful in our goals.

At the start of the project, I had worked with my teammates to create a division of labor that I had thought fair, one partner would begin work on the ruby backend, the other would begin work on creating JS functionality, while I would work on the structure/design of our frontend. Unfortunately this breakdown of labor left both of my partners struggling for air, while I worked ahead largely unaware. If I had been paying more attention, I might've been able to work with them, co-code as it were, to help overcome some of our struggles and save us major time. In this regard, and in the least condescending way possible, I put too much expectation on my partners, expecting them to be able to just 'handle' their own assigned tasks, and that come week end, we would just be able to slot all three individual pieces into each other and have a complete and functional project. This was naive of me, and this failure of 'management' is something I will be sure to take with me into future projects.

Another thing that caused me to learn this lesson, was when my overconfidence lead me into a dead-end. For context, my previous project week had my team creating a React based quiz game, and our relative success in that project made me believe that it could be easily replicated and expanded upon. I thought that, so long as I kept forging ahead, solving one problem and then the next, that eventually I would solve all of our problems, even if it required pure brute force. Sadly, brute force can only get you so far, by the time the week was almost over, I had unknowingly built a system with a number of functional aspects, that couldn't be completed as it was because it was structured in a way that made it exceedingly difficult to implement the final pieces. All in all, I should have taken a slower, more precise pace, and I should have spent more time planning the structure.

Understanding Limitations

The other major lesson I learned this past week, was of understanding the limitations of the tools you have available to you; namely, React is not a game engine, and trying to use it as one is likely to cause you a lot of difficulty. At the end of the day, React did not come with the tools we needed to solve all of our problems, and while we could brute force it into doing what we wanted, we were creating A LOT more work for ourselves. I thought the reason I couldn't find anyone with my problems on sites like StackOverflow, was because I wasn't searching hard enough. Now, I think it is a lot more likely that this problem was caused by us trying to do things that were incredibly unintuitive for a React project. React isn't very friendly in regards to dynamically doing most things. We ran into so many issues regarding scope and order of functions occurring that I would honestly blame less on ourselves, and more on React not being built to function as we were trying to use it, unless inside specific circumstances. These issues with React did not become apparent until the very end of project week, and it quickly became clear that to solve them, almost everything would have to be restructured ground up to make up for React's weaknesses.

I don't want to misconstrue this as a bad workman blaming his tools, but more of case of "everything looks like a nail, if all you have is a hammer". The only tool we had was React, and while it could work with enough effort, we were causing ourselves a lot of headache by not using something better suited. In the future, I will be a lot more hesitant to make plans with my tools, until I better understand what all they might be capable of. Hopefully, working to understand these kinds of strengths and weaknesses will drive me to expand the amount of tools in my toolbox, not to discourage me from trying new and interesting things.

Flatiron Phase 2

Benjamin McShane — Mon, 19 Sep 2022 16:31:09 +0000

Over the last three weeks we learned all about React. In short, it's an interesting tool used to split a project into multiple bite sized pieces to make it more easy to individually interact with aspects of the code/design. This comes with a whole host of new issues however, as you have to learn how many of these 'components' to use, how to pass code and variables between them, and where to put your code to make it the most effective. In short, a whole host of new logic that is difficult to wrap your head around.

Links in a Chain

One of the most difficult aspects of React for me, was learning how much I needed to split my code between different components. Coming into React from a pure JS/HTML/CSS background meant that I was already more than comfortable putting every individual component onto the same page, which I admit, makes code hard to read.

Above is a very rough draft of the component tree for my phase two project. Part of this messiness comes from our initial confusion on how client side routing actually works, and part of it comes from a weak concept of what our end project would actually look like. The final component tree of our project wound up looking something like this:

A whole lot cleaner and nicer to look at. Though this final component tree doesn't manage to include the amount of times we deleted components, thinking they were unnecessary, only to bring them back with an entirely different purpose. I think working through a big project like the end of phase project was a very valuable teacher on the benefits of components, and how to create them effectively. With this skill more developed, I look forward to including it in more projects going forward.

Infinite Rendering

Another massive struggle of React for me, was learning to have JS code inside my HTML, and more importantly, when/how to have that code working. Up until this point, I never had any issues like this because a page would load its HTML, its CSS/JS, and then stop. With React, the page would constantly bounce between loading aspects of the HTML and JS, and with these two regularly calling on and altering one another, errors on load were very common.

The single biggest example of this was when I was trying to code an answer shuffler for our quiz game. All I wanted to do, was on question load, create an array with the correct and incorrect answers, shuffle it, and then have it populate the questions inputs. This was harder than it seemed.

The only way I could think of reasonably calling the function that did the above, was to have it nested within the return for the HTML. The issue came when I realized the HTML would load before function had done its job, and so the answers would be populated with blanks. I thought to get around this issue by simply using a setState. That really didn't work. Having a setState called in the HTML was causing the page to reload each time the state was set, which would cause the function to be called on again, leading to an infinite loop of renders that kept breaking our webpage. Thankfully, watching this error occurs in the thousands in my DOM, was at least humorous enough that I didn't want to throw my mac into the middle of the street. In the end, I would up using a let statement and a 'id.textcontent' to fix my problems, so at least it wound up working.

Finding Answers

My final notable React Struggle, was getting individual responses from a '.map' of our generated questions. In each '' that was mapped out, I needed to get a single answer from each of them, with a single click in their parent component. I couldn't make it so that each answer was immediately added to an array, on the off chance that someone might change their answer. This meant that on the click of the submit button in the parent component, I needed to grab an individualized answer from each of the children.

Initially I had the idea to take the id key from each individual question, name an object that, and populate that with the selected answer, and have it be overwritten with a new answer if one was selected. Then I could just grab the contents of every object named after the question ids, and I would be home free. It was then that I learned that JS has no good way to name a variable without strictly knowing the variable name, which sucked.

Eventually I came up with a solution where I had a hidden '

' element at the end of the return which had an id of the question number (something I also had to implement for this solution to work), and on answer change, that element would be populated with the chosen answer. Then on the submit event in the parent component, all I had to do was a line of 'document.getElementById('')' and push them all into an array. This had the unintended side effect of meaning that unanswered questions were automatically counted as wrong, which is nice, because I was worried about running into some 'undefined' errors.

The Project

The Phase 2 project was a really good time for me and my partners I think. We put in a lot of effort to keep organized and to split our efforts between us, playing to our strengths as much as possible. At the start of every day, we would sit together and using a Trello board, we would examine our needed work and our wanted implementations, and then we would divvy our work for the day. This kept us from repeating work, and often prevented us from working on aspects of the code that would wind up conflicting. By carefully managing our merges and our pushes, we were constantly able to keep each other on the newest version, and we never wound up losing any work, which is nice. At the end of the day, my only regret about the project was not having a little longer to work on it. While the end result was (in my opinion) pretty impressive, we did wind up dropping a number of features that I think would have been very good. If I manage to keep the motivation, I might actually do a little more work on it to include these things.

JavaScript from a Novice Perspective.

Benjamin McShane — Thu, 25 Aug 2022 15:45:41 +0000

It quickly became apparent in class that JavaScript was to be our main focus. If we wanted to become good frontend developers, then we had to engross ourselves into the vague and sometimes nonsensical logic of this language.

It is an interesting challenge, to say the least. Each day I feel like I’m mastering something, that the day before was absolutely alien to me. On the other hand, I frequently find myself positively stumped by something I had thought to be incredibly basic. When it comes to JavaScript, the lows are low, but the highs are high. There are very few things I have ever experienced that compare to the immense satisfaction of your code finally working.

I'm certain there is no possible way to do this better.

Truly the only way to be sure something works.

CSS from a Novice Perspective.

Benjamin McShane — Thu, 25 Aug 2022 15:42:00 +0000

We didn’t spend too much time learning about CSS, it was always kind of an afterthought when compared to our studies in JavaScript. Playing around with it now, I kind of understand why this was the case. CSS is incredibly intuitive, and incredibly easy. Unless there is a massively secret set of mechanics inside CSS, that no one has decided to share with me, then all the language does is allow you to apply stylistic information outside of your html. Theoretically, you absolutely could do most (if not all) of the same stylistic detailing directly inside your HTML document.

You shouldn’t, obviously, that would be impossible to look at. It just fascinates me that, CSS is primarily just used as a notepad for your HTML script to reference when deciding how things look.

Outside of how it’s mechanically used, I’ve found myself having a ton of fun using CSS. It is very gratifying to make a page look good, and that is the entire purpose of the language. It is also incredibly simple and intuitive; half the time, whenever I’m trying to do something new, I can just type something adjacent into the console, and it will autocomplete the exact command I’m trying to do. Between the satisfaction of good looking U.I. and the simplicity of use, I have to say that CSS is my favorite part of front end design so far. I wish it was organized a little nicer however.

^
I'm certain there has to be a nicer way to organize all this.