Skip to content

Lab 7: Beyond Responsive Design with GTA4123

Overview

Building on their experiences on the recent prep, students will collaborate to add the following to a starting codebase:

  1. a new responsive “breakpoint” for a “tiny” viewport
  2. dark mode
  3. responsive images
  4. flow-relative layout

Starting Off

Work in pairs. Your instructor will tell you which of the choices below applies to you. Follow the corresponding starting instructions. (If you’re a trio, no worries. The Third is also legitimate, but for the next bit, they should follow the instructions for Gold Partner.)

  • GitHub
    1. Purple Partner: click here to instantiate a github repo from the starting code for this assignment
    2. Purple Partner: In the repo’s Settings → Collaborators, click the Add people button to add your partner
    3. Gold Partner: Possibly check your github-connected email to accept the invitation
  • GitHub Classroom
    1. Purple Partner: agree with Gold Partner on a name for your team
    2. Purple Partner: follow the link from your instructor to accept the GitHub Classroom assignment and enter the team name on which you agreed
    3. Gold Partner: follow the link from your instructor to accept the GitHub Classroom assignment and choose the team Purple Partner just created.

Getting to know git 😬

If you’re feeling a little uncertain about your git skills, no worries! We know you’re learning. You got this. That being said, consider installing a GUI for git. Even if you prefer to learn the command line commands (which is ultimately the best long-term choice, but shouldn’t block you getting started), having a GUI to aid you in visualizing and confirming your understanding of the state of your repo is so helpful!

  1. BOTH PARTNERS: clone the repo you just created (you should both be cloning the same repository)

    1. you can clone from the command line or with vscode source control pane:

      1. command line:

        Prerequisite to command line git

        To clone from the command line you should have already added an SSH key to github.

        1. find the clone url. see this screenshot:
          • screenshot of github repo page showing the code button's dropdown that shows the url to clone
        2. from a directory on your laptop (like your 343/lab/ directory or similar), but ideally not from a directory that is already a git repository, run 
          git clone git@github.com....git
        3. Proceed to step 2

      2. vscode source control panel

        1. In the left-most part of vscode there should be a sidebar with icons. The first icon shows pages and if you toggle it open it will show the heading Explorer and it is a file explorer.
        2. Click on the 3rd or 4th option which looks like a few nodes with a forking path between them
          • screenshot of vscode showing source control pane and its icon
        3. Click on Clone Repository, then in the pop-up choose Clone from GitHub. You may have to complete an authentication workflow with github.
        4. in the resulting search dialog, if you don’t already see your new repo as an option, search for lab-07 and choose the repository
        5. Next vscode will show a dialog to select the repository destination. Choose a place you’d like to put the starting code, ideally not within an existing repo. vscode is going to create a new directory with the name of your repo, so you likely don’t need to create a folder yourself, but just choose the folder that has other 343 activities in it (like 343/labs/).
        6. Proceed to step 2

  2. EACH PARTNER: On your laptop in your cloned directory, make a branch that you name as your EID, so like mine will be named stewarmc

    • you are both doing this on our own computers, so you will each have the main branch you cloned and then 1 more branch, named for your own eid.
    • You can do this in the Source Control view of vscode by hovering your mouse near CHANGES and finding the ellipsis (...) and choosing Branch → Create Branch... or from the command line with 
      git switch -C yourEID
  3. EACH PARTNER: Push your new branch to the github repo in a remote branch with a matching name.
    • You can do this in the Source Control view of vscode by hovering your mouse near CHANGES and finding the ellipsis (...) and choosing Branch → Publish Branch... or from the command line with 
      git push origin yourEID
  4. BOTH PARTNERS: Review the code
  5. BOTH PARTNERS: Review the SECTION (not the whole page!) of the MDN Guide above.
    • See the markup (index.html) and css (styles/gta-mdn.css) in your repo. These files correspond to the guide. Confirm that the code works as expected. Discuss each file with your partner, and make sure you both understand the starter code.
  6. BOTH PARTNERS: Review the sections below and edit the Plan section of README.md to identify who will complete each part. (If you’re a pair, whoever finishes their part first can take the responsive images or you can work on it together; else if you’re a trio, the Third should do the responsive images part.)

Tiny Viewports

The MDN’s guide uses two “breakpoints” to distinguish three layouts for a page. Add a third “breakpoint” to define a fourth layout for “tiny” viewports with a width <= 374px.

Did you know the original Gameboy screen was only 160px × 144px?!

JMU CS Logo in 4 shades of gray like OG Gameboy

Recent smart watch resolutions have been around 374px × 446px.

  1. Create a new CSS file named tiny.css and add it to styles/.

  2. Edit index.html to “link” the new stylesheet.

    This should be the only change you make to the html

    Other than this single line addition to index.html, the rest of your work for this part will be in tiny.css.

  3. Add the new breakpoint and make it so that on tiny viewports, there is a single column and “main article area” is displayed first, followed only by the nav.

  4. Commit and push your changes.

    Opinionated Person shares their guidance on authoring commit messages

    Use messages like the following:

    • chore: add Oyster build script
    • docs: explain hat wobble
    • feat: add beta sequence
    • fix: remove broken confirmation message
    • refactor: share logic between 4d3d3d3 and flarhgunnstow
    • style: convert tabs to spaces
    • test: ensure Tayne retains clothing

    In your case, the commit message might be like: 

    feat: add tiny breakpoint

Dark Mode

  1. Create a new file called dark.css in styles/.
  2. Create a directory called scripts/ adjacent to styles/.
  3. Add a javascript file called dark.js to the new directory.
  4. Add a script tag to the bottom of the body of the html file that loads your new script.

  5. Edit your index.html to include a link to dark.css in the head of the document just before it links to basic.css

    This should be the only change you make to the html

    Other than these two 1-line additions to index.html, the rest of your work will be in dark.css and dark.js

  6. Edit dark.css such that if the user has a “dark” preference, the page will be styled with a dark theme.

    • What the dark color scheme should be is your choice!
      • If you’re not feeling creative set the background of the whole page to black and the text color of the content of the whole page to white.
      • Else, do something nice (maybe with a slightly lower contrast than the above suggestion, see the JMU CS Colors on the wiki or try out these color resources:
        1. Paletton
        2. Adobe Color
    How do I test the color scheme preference?

    😉 This is in the DevTools video from earlier in the semester, but in the interest of time…

    Pop over here for a few secs.

  7. in dark.js, add an event listener such that when the user clicks any of the 3 nav items, the page will render with the selected color scheme.

    Dynamic Styling

    Most often, dynamic styling is best implemented via:

    1. defining style rules for corresponding classes in css
    2. adding/removing classes to the necessary elements via js when needed

  8. Commit and push your changes.

Responsive Images

This part requires changes only to your index.html

The previous two parts are primarily working in files referenced from index.html, but this part is implemented in index.html. That goes for both of its sub-parts.

The following sub-parts require you to implement two forms of responsive images. The prep reading on Implementing Responsive Images in HTML is an important prerequisite to these sub-parts.

Resolution Switching

Add an image to the page such that the browser will dynamically choose different a different source for the image based on the device’s capabilities (pixel density). The result is that it should look the same on devices with different pixel densities (but “sharper” on those with higher pixel densities).

  1. Add a new <paragraph> to the main article area.
  2. Add an <img> that shows Dr. Bowers’s circle-packing rendering of King Hall, but use resolution-switching to show the correct one for the device’s pixel density.
pixel density file
1x https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/bowers-KH-circles-750x250.png
2x https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/bowers-KH-circles-375x125.png
3x https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/bowers-KH-circles-1125x375.png
4x https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/bowers-KH-circles-1500x500.png

Art Direction

Add an image to the page such that the browser will dynamically choose different a different source for the image based on the viewport size (width). The result is that the image should be different in different viewport sizes, in this case, different regions of the largest image are cropped for display on different sized viewports.

  1. Add second new <parapgraph> to the main article area.
  2. Add a <picture> to the new paragraph.
    • Depending on the viewport’s width, an entirely different image should be shown, per the table below:
min-width file
414 https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/250505-ECDS-SteveAderton-mobile-portrait-1to1.jpg
896 https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/250505-ECDS-SteveAderton-mobile-landscape-1to1.jpg
1242 https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/250505-ECDS-SteveAderton-mobile-portrait.jpg
1620 https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/250505-ECDS-SteveAderton-tablet-portrait.jpg
2448 https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/250505-ECDS-SteveAderton-mobile-landscape.jpg
3240 https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/250505-ECDS-SteveAderton-tablet-landscape.jpg
5242 https://w3.cs.jmu.edu/cs343/s26/lab/07/assets/250505-ECDS-SteveAderton-full.jpg

Commit and push your changes.

Flow-Relative Layout

The responsive layout we’re working with in this lab (see illustration below), is hard-coded to best support sites where their content is written in languages that start at the top left and first proceed to the right until moving down to the next line of content, but there are several other writing-modes.

illustration of 3 layouts

Create a new css file in styles/ named i18n.css. In that file, make a few rules for the whole document. Set a few of the related properties: the writing-mode, direction, and text-orientation to some of thees combinations and see the resulting layout.

  • for اللغة العربية (arabic), השפה העברית (hebrew): 
    direction: rtl;
  • for 한국어 (korean), 日本語 (japanese): 
    writing-mode: vertical-rl;
text-orientation: upright;
What is necessary to change about your grid to adjust to the other writing modes?

Do you read or write a language with a different writing mode? How sensible is this approach to changing the layout for the direction of the language?