Week 5

Session Recording#

You’ll need to be signed in to your New School account to see this recording in-page! Safari prevents Google Drive embeds—so you’ll need to go to the original! ↗

Briefly, Feedback#

You should have all received some initial HTML feedback via GitHub Issues.

_{This is a common tool to comment on and track code tasks⁠—another one of the reasons many organizations use GitHub.}

Now let’s check off those task lists! We’re not writing them to be ignored; we want to see that you’ve tackled them. Some common threads:

Many folks are still pretty far behind.

You know who you are! If we say we need to see more effort/engagement from you, we mean it. As we’ve said, this course requires more than “half-hour before class.”

You now have one week to catch up. </stern-teacher>
Give yourself more material.

Some folks still hadn’t pulled in their source text (or nearly enough of it), or their response⁠—the base concept of the project is to “typeset [your] selection and reply together.”
Beyond content, we need more document structure and semantic elements.

Almost all the projects need more varied/unique HTML elements to work with.

Pull out some <blockquote> “pull quotes,” add links and “metadata” around our text, put in some other page “furniture” with a header and footer ! Look for block elements for more structure, and appropriate inline elements, for style “hooks” to make our text more expressive.

“Flat” (like <body><h1>… ) structure will be difficult/impossible to bring to life. Enrich these documents semantically, then also stylistically. Make it interesting; make it yours!
We’re still using elements for their user-agent styles, not their meaning.

Pulling in the reset.css should have immediately negated this; let’s correct/update our HTML:
- Don’t use <br> for spacing! Unless we’re writing poetry, we shouldn’t see these⁠—use margin or padding instead (as we’ll see today).
- Don’t use <h#> for sizing⁠—headings are for our semantic structure, not size. Think about headings like a document outline.
  
  <h2> does not mean smaller than <h1> ; it means a new section of content nested under it.
- Likewise, immediately-nested tags:
```
						<h3><em><strong>What am I?</strong></em></h3>

		
		
```
  …are usually a bad sign⁠—which one is it meant to be? We are probably conflating the style with semantics, again. It probably should be one tag and the rest will be in CSS!
- Only reach for a div when no other semantic elements are appropriate⁠—we probably shouldn’t see any of these in your code, this project! Unless absolutely necessary for some styling trickery.
Mind our HTML syntax!

Some things to keep in mind as we get more familiar:
- It’s best/easiest to keep id and class names lowercase, and they can’t have spaces. You can always kebab-them!
- Likewise, No spaces around our tags and attributes:
```
						< element attribute = "value" >

		
		
```
  …should be:
```
						<element attribute="value">

		
		
```
  The browser might interpret things how you want with them, but it can only introduce errors.
- Line-breaking around text, like this:
```
						<p>
	I am some text!
</p>

		
		
```
  …will collapse into an extra space, which can only get us in trouble later. Cinch the tag to the text:
```
						<p>I am some text!</p>

		
		
```
- Also, don’t bother “ragging” your source code:
```
						<p>
	Make no little plans. They have no magic to stir [our] blood and
	probably themselves will not be realized. Make big plans; aim
	high in hope and work, remembering that a noble, logical diagram
	once recorded will never die.
</p>

		
		
```
  …should just be:
```
						<p>Make no little plans. They have no magic to stir [our] blood and probably themselves will not be realized. Make big plans; aim high in hope and work, remembering that a noble, logical diagram once recorded will never die.</p>

		
		
```
  These will be easier to move around, adjust the indent/hierarchy, and see your document structure with less chance of mangling your text.
  
  If you want to see the whole block, to do some inline work⁠—toggle VS Code word wrap: ⌥/Alt+Z
Build up from a comfortable base type size!

In the styles we’ve seen so far⁠—the too-small type continues! Set our :root / html type size larger:
```
						:root {
	font-size: 150%; /* Adjust this! */
}

		
		
```
This is what all our rem values are then based off of⁠—play around with that percentage until our base paragraph feels right/easy/comfortable for readability.
Let’s be talking!

More activity in the Slack would always help. Include your links! “Check out this cool thing.” Triumphs and tragedies! We’re all in this together.

We’re going to try and get another round of more-visual/style feedback in this weekend, if we can! But also don’t wait for it; we’ll respond to wherever folks are at.

About Next Week#

Your first projects are due next week! (We know.) Let’s talk about the format for your presentation and critique:

Project 1: Notes on Format

Some Proper Layout#

You’ll need more than font and color to make your designs work. Today’s main topic will give us some tools:

The Box Model

Demo Time!#

We’ll spend the remainder of our time working through some of these things together:

We’ve added some color/type styles to our example, akin to where you should (at least) be at. Let’s glance through this together:

manuscript Template
Some more ergonomic adjustments:
- Side-by-side editing for your HTML/CSS
- Enable the minimap for context, if that is your jam
- Toggle breadcrumbs and sticky-scroll
- A proper find-and-replace: ⌘/Ctrl+F and ⌘/Ctrl+⌥/Alt+F
- Even multi-cursor editing: ⌥/Alt-click and ⌘/Ctrl+D
Right, right, some actual code:
- Define some common --variables!
- margin for spacing between elements⁠—take off earlier body / * stuff
- padding for the elements with a background, lists
- border to maybe accentuate quotes, separate areas
- max-inline-size for body text
- sticky article headers
- fixed Top link
- absolute on header pseudos

For Next Week#

Thoroughly read through our topic from today! And think about how these things can apply to your design:

The Box Model
You’ll be using it to complete the last phase of your Manuscript projects:

Project 1: Spacing and Refinement

Layer in the box-model/layout material from today, and second, refine your design and code based on our overall (and your individual) feedback. You should emphasize both of these efforts toward your final deliverable.
We completely recognize that we are very early in our technical progression⁠—so we know that your finished pages will only be approximations or even interpretations of your sketches.

Don’t let this discourage you; it’s inherent to our medium! Our process here is meant to inform our design.

We’re looking for you to try and problem solve towards your designs. There is often no single correct way, and we want to see your engagement here in discovering your own solutions towards your needs. Designers are problem solvers, if nothing else.
Update your README.md in the root/base of your repo⁠—describing the project, your readings, how you made it, things you want to remember, etc.

This is good GitHub/collaboration practice! Both for others, and always Future You. These are written in Markdown, a mark…up lingua franca which gives us some basic formatting.

_{The entire course site is written in Markdown!}
When you are done, submit a link to your URL⁠s:

Submission Form

_{Please check that these work outside of your own, signed-in browsers⁠—particularly your @font-face !}

Finally, review the project requirements and our expectations, and prepare for your presentations:

Project 1: Notes on Format

We’re looking forward to seeing your stuff!