Emerging Antipatterns from the First Project
I finished commenting on students' first project in the course--a basic project more aimed at getting everyone familiar with the basics of the file system, Git, and of course HTML5 and CSS. I averaged about 800 words of comments per student, and after all of that writing, here were the problems (I'm calling them antipatterns) that showed up again and again:
HTML5 <header> and <head> Confusion
One pattern I saw numerous times was a global structure that looked like this:
<html> <head> </head> <body> </body> <foot> </foot> </html>
In that case, students were confusing the new HTML5 <header> tag (which often appears inside of <article> or another new semantic construct) with the long-standing <head> tag. For some students, that meant including a malformed and misplaced <footer> tag as above (clipped to <foot> in some cases, perhaps to match <head>).
One thing I strive for in teaching is to be clear between the document <head> for page metadata, the <header> tag for grouping "introductory information and navigational aids", and the 6 levels of heading tags (<h1> through <h6>) for marking waypoints in documents as headings do. (Even the MDN documentation above stumbles about between header and heading). But, obviously with these kinds of errors creeping up numerous times, I need to better reinforce those distinctions. It would probably also help to spend additional time talking about the parallel appearance of <header> and <footer> as components of a global structure living within the <body> tag.
(Additionally, I need to make sure students in future projects are more religious about using the W3C validator service, which would have quickly tipped these students off to issues with any elements appearing outside of <head> and <body>.
Meaningful Commit Messages
I was impressed that students took to Git and GitHub as well as they did; only three or four students had ever worked with a version-control system before, only two of which had used Git.
It's probably unreasonable to expect such beginners to write meaningful commit messages, but there were a lot of messages like "Changed CSS" or "Fixed HTML." Or the one-word messages like "Revisions" and "Fixes." I'll work to better model commit messages in my own work along with students, and point out good examples as they appear in the class.
Shallow font-family Stacks
My students are an eager bunch; although we'll cover CSS3 @font-face and other new, sophisticated approaches to Web typography later in the semester, a number of students were already employing Google Fonts and, in one case, TypeKit.
But whether using Web fonts or system fonts, it wasn't unusual to see font-family: Helvetica; from Mac users, for example. I've since been pointing students to the quite excellent CSS Font Stack for solid font-family declarations, and even pointing out the new Font Family Reunion site that allows someone to enter in different font-family declarations (e.g., "Times New Roman", Times, Roman, serif) and get a listing of which of the fonts will be displayed on which platforms (no Linux yet, however).
And Of Course, The Usual Suspects
Those three issues were the standouts, but there are other matters I found myself regularly commenting on as I do every time I offer this class:
Source Formatting: Line breaks and indentation, especially indentation with two spaces per level of indent (as opposed to actual tab characters). Stylistically I need to also give guidance to students for breaking text content and indenting longer passages another level inside tags, e.g.,
<p> Longer paragraph text can be indented another level and lines broken with actual line breaks to keep text content readable in the source view and of course to add to the value of git-diff. </p>
HTML Doing CSS's Job: Attack of the empty sets of <p></p> tags and the <b>ed and <br />eakfast HTML of bold and break tags. Interestingly, I saw fewer uses of old saws like target="_blank"--but the single-page nature of the first project may have limited that somewhat.
