Its been a long week. I completed my 2nd Sprint Challenge at Lambda School. We covered a lot of material in the past few days, and I was mostly able to keep up, although I’m still probably the slowest person in my group. I wrote more in-depth about Week 2, Day 1 on Monday, but haven’t had a chance to blog about the rest until now. Here’s a recap of the 2nd day of the week:
Monday & Tuesday (Week 2, Days 1 & 2)
So, this week’s unit is called Advanced CSS. We spent two days on Responsive Design and two days on Preprocessing. On Monday, we learned about things like the differences between fixed, fluid, adaptive and responsive layouts; media queries and breakpoints; and built our first responsive website.
On Tuesday, the focus was on responsive units of measurement. We created another responsive website and made use of responsive units of measurement like em and rem (relative-length units), instead of pixels, which are absolute-length units.
Pixels, em and rem
Pixels don’t traditionally change size based on their surroundings, although modern browsers can scale them when zoomed in, which in a matter-of-speaking changes their size, but doesn’t necessarily affect layout. The amount of real-estate they occupy on a screen also varies more, based on screen size.
An em is a unit of measurement. Its basically the height of a character on a web page. I think the name is derived from the letter M on old metal printing blocks or printing presses. Ems can adjust their size to their surroundings, so they can scale if needed. 1em is equal to the height of whatever a medium character is in a browser, so from the start, they’re flexible and based on user settings.
If a user goes into their browser’s settings and makes their font size larger, the em will adjust proportionally to the new font size. When coding, if a font-size is set to 10px, then 1em = 10px. Adjusting font size is then based on an em multiplier: like a heading might be 1.6em (16px) or 2.4em (24px).
The issue with em is that its size is based on inheritance. So, if a parent object has text with a font-size of 1em, then the font-size on child objects will be based on that. Because font size is based on multipliers from the parent object, its harder to keep track of and maintain a consistent font-size throughout a page. If text is moved, the font size has to be adjusted.
Rem, or root em is like a centralized em. Its size is based on the user’s font settings, like an em, but the difference is that its based on a single size – either the size selected in the browser’s settings, or a size defined by the person who wrote the web page. It can be adjusted using a multiplier, just like an em, but since its based on a single, pre-defined font size, its infinitely easier to control. There’s no need to check em size on a per-paragraph or container basis. If we know that the base value is the user’s “medium” font size, or the web page’s pre-defined 16px, then that’s the rem’s base value for the entirety of the page or site. So, a 1.6rem or .75rem is the same throughout the page.
Rem seems to have become the choice in controlling font size for reactive web pages, and after seeing how simple it is to implement and control them during this week’s projects, I can understand why. Also, apparently, although they’re new concepts to me, em and rem have been largely used in printing, typography and design for years now.
- Sitepoint: Understanding and Using rem Units in CSS
- Engage: EM vs REM vs PX – Why you shouldn’t “just use pixels”
Percentages and viewport size
Percentages can also be used to control font sizes, but they’re more commonly used for responsive layout and scaling element and container sizes instead. For example, a <div> might have a width value set to 100% (width: 100%;) in CSS, which would allow it to stretch horizontally to either the left and right edges of the browser window, or the left and right sides of the element that contained it. Changing that to 90% would shave it in a little, letting it almost make it to full width. Changing it again to 50%, naturally, makes it half as wide as it can potentially be.
With nested elements, percentages can become tricky. Its important to make sure that the total % width of sibling nested elements don’t exceed 100%, or the layout can break and horizontal scrolling might become necessary. I also had many experiences this week in which nested objects weren’t responding to width adjustments or Flexbox layout commands. This is because I was working on the elements themselves and not the parent elements, which were restricting the child elements growth (be aware, helicopter parents!).
For example, if I have a <section> that has a 60% width, and in that section is a <div> with an image and a <nav> with 4-5 navigation items, and I try to give the <div> a width of 40% and the <nav> a width of 60%, we’d expect them to fill the parent <section> and give 40% of the width to the picture and 60% to the menu. I had crunched menus with no spacing several times and was trying to adjust the <div> and <nav> elements, and even the individual <nav> menu item widths, and horizontal justify properties in Flexbox, and other things. It turned out that I had to adjust the parent <section> to make it wider! It makes sense on hindsight, but at 3AM, the answer isn’t always evident.
Its also important to keep minimum widths in mind, because %-based widths can, and will shrink down as much as needed, based on screen size. This means that people on small screens can find themselves squinting at a webpage with text or images that have become so small that they resemble desktop icons of themselves. Most people don’t like to read microdots.
vw and vh (viewport width and viewport height, respectively) rely on the size of the viewport (viewable area of the screen) to render webpages. They can be used anywhere other size units can, but we were cautioned to only make use of them in specific cases, like full-screen layout. I remember our instructor, Britt, using vw to make a border or margin element stretch across the entire screen, not just the 100% of the browser, minus the padding it reserved.
There are some other units of measurement available as well, but we didn’t make use of them in our projects. w3schools has information about them:
Project
Our Week 2, Day 2 project was to modify a template of our choosing from html5up.net and make a portfolio. We had to examine the CSS and note where responsive units and media queries were used, update placeholder content and showcase projects we’ve worked on, including GitHub links. We also had to maintain proper attribution under the creative commons license, since the main designs weren’t our own. Then, we hosted the websites using GitHub Pages and shared it for our cohort to see. It was a fun project that I’ll likely update as I go on with more content and (hopefully) more advanced coding and design. This blog is one of the links on my “Selected Works”. ;)
We were also told that we could use sites like Pexels for free stock images. Other people shared more sites with free stock images as well. I cobbled together some images of my own, using my 20-year-old version of Photoshop. I hear Adobe has been working to force people to give up their local installations of their Adobe programs in favor of using their cloud solutions, but that’s probably a topic for another day.
Here’s my portfolio website, on GitHub Pages: Vish Singh – Portfolio Website
REDO FROM START 
One thought on “Lambda School: Full Stack – Week 2, Day 2”