D.I. von Briesen's Dapper Innovative Vicuña Buck

Teaching con von Briesen

Web Standards - what every page you build must satisfy

Web Standards

These apply in every web-development course I teach - WEB115, WEB215, WEB250, and ITIS3135 - and to the web work you do in ITSC1110, which builds pages without being one. They are the letter of the law: each one is checkable, and the checker actually checks each one. Course Standards covers how you work, as opposed to what you build.

Why These Standards Exist

Everything below this is the letter of the law - every rule checkable, and checked. These are the spirit: the developer you become by following them, which no script can measure.

A Script Checks Them, Not Me

Every page on this site loads the Vicunadator - the llama in the corner. Right side up means every rule passed; upside down means something failed, and clicking it tells you exactly what. The same script runs on your pages, so you can see your grade forming before you submit.

Add it to any page you build, and link this copy rather than saving your own, because a copy goes stale the moment a standard changes: 

<script src="https://divonbriesen.github.io/teaching/tools/standards-check.js" defer></script>

The Rules Come in Three Layers

The checker reports them in this order, and it's worth understanding why a rule applies before you argue with it.

The authoritative list isn't this page - it's standards/rules.json, which is what the checker actually reads. If this page and the checker disagree, the checker is right, and tell me so I can fix the prose.

The Rules People Miss

Rules the Checker Can't Test

The Vicunadator catches structure. These four it can't see, and they cost people points every term.

Course Site Standards

Everything in this section applies to your course site - the one whose name is your name, your adjective-animal mascot, a divider, and the course ID. It doesn't apply to the other sites you will build along the way: client projects, personal portfolios, hobby sites, design firms, mascot companies. Those are different kinds of site with their own rules.

The llama sorts this out automatically. The Vicunadator works out what kind of site a page belongs to from where it lives, and applies that site's rules - so a hobby page gets hobby rules, a design firm page gets design firm rules, and your course site gets everything below. The standards for those other site types also live inside the assignments that create them, which is where you should look when building one.

Before the Course Site: Your Root Site

Your webspace root has an index.html that isn't course work. It introduces you and points onward. From there, an obvious relative link leads to the course, labelled with the course ID in capitals and no spaces - "Click to go to WEB250" - and it points at the course folder, named for the course ID in lowercase, not at a particular page inside it.

The Footer, in Order

Every page's footer has a nav with these seven links, as absolute URLs, because they point to fixed homes whichever copy of your site a reader is on:

  1. Your webspace
  2. Your GitHub.com account
  3. Your GitHub.io root page
  4. Your GitHub.io page for this course
  5. freeCodeCamp public profile, showing your timeline
  6. Codecademy public profile, showing completed lessons
  7. LinkedIn profile

Plus a "Designed by" credit naming your company and linking to it, an HTML validation link, and a CSS validation link.

The Three Pages Every Course Site Starts With

Your Brand, and Where It Has to Show Up

Your site has a brand identity, and every page shows some of it. That means all six of these, picked by you and used consistently:

Consistency is what counts. Headers, footers, navigation, colors, and type should make any two pages of your site look like they belong to each other, and anything you customize should suit the theme - a candy-shop site says "Good Morning, Sweeties", not "Good Morning".

Requirements Specific to Your Course Site

These rules apply to your ITIS3135 course site on top of the site-wide rules. Where the two overlap, both apply.

  1. The course site meets every rule on the Web Standards page.
  2. Site name = your name (possessive) + your adjective-animal mascot, followed by a divider of your choosing, followed by the course ID (all caps, no spaces).
    Example:
    • Jane Doe's Jazzy Dolphin | ITIS3135
    This site name is your h1 and starts the title element on every page. The general rule still applies: title = h1 + divider + h2.
  3. Footer includes a designer credit such as "Site Designed by", "Created by", "A Product of", or "Brought to You by", followed by your design firm, linked to your design firm page.
  4. Footer includes a "Certified in ..." line with your earned certificates (e.g. freeCodeCamp Responsive Web Design), linked.
  5. The intentionally bad assignment pages (e.g., the CRAP page) go in a stuff/ folder. Pages inside stuff/ are exempt from these standards - they're supposed to be bad - but the rest of the site isn't excused for linking to them.

Introduction Webpage Standards

Every course except CIS110 eventually migrates the "Shared Introduction" you write in the course's Google Doc onto its own page on your course site - introduction.html. WEB115, WEB215, WEB250, and ITIS3135 build the full version, links line included; ITSC1110 builds it without the links line, since it isn't a web-development course. This is checked automatically, the same way the rest of your course site is.

A finished introduction webpage should look exactly like your entry in the shared Doc - the differences are only in the underlying code: a real <figure>/<figcaption> for the photo and caption, a real <blockquote> for the quote, and CSS handling spacing instead of blank lines. The one real difference: leave out the horizontal-rule separators and the Doc's Table-of-Contents-linked heading - both exist only to organize the shared document, and a page with one entry needs neither.

  1. Your full name is the page's one h2, in Last Name, First Name Middle Initial. format, left-aligned like normal text - not centered, and not a link.
  2. A public-acknowledgment sentence right after the heading, same content as the Doc: state that this is a public page, then sign it with your initials and the date after a dash or tilde (- JAD 5/18/26).
  3. A centered display-name line: First M. "Nickname" Last ~ Adjective Animal.
  4. Your photo in a real <figure>, centered, with a centered, italicized <figcaption> beneath it.
  5. A personal statement of at least three complete sentences, left-aligned like normal text.
  6. A bulleted list with these seven bold labels, each followed by its content: Personal Background, Professional Background, Academic Background, Primary Work Computer (type, OS, and version), Primary Work Location, Alternate Computer & Location, and Courses I'm Taking, & Why - itself a nested list, each item formatted CODE101 - Course Name: reason for taking it.
  7. A favorite quote in a real <blockquote>, centered, with attribution starting with a dash or tilde. Don't type the word "Quote" as a label before it.
  8. Web-development courses only (WEB115, WEB215, WEB250, ITIS3135): a centered links line with dividers, carrying CLT Web, GitHub.io, GitHub, freeCodeCamp, Codecademy, and LinkedIn - CPCC students in the WEB courses skip CLT Web and include the other five. ITSC1110 skips this line entirely.

The Checklist, in Full

The compressed rules above cover what trips people most. This is the complete human-readable enumeration - the prose version of what the checker reads from rules.json. When in doubt, run your page against every item here.

Standards Checklist

Use this list to validate page structure, naming, and compliance. Some rules demonstrate examples in subbullets. These rules apply to all pages you build; your course site has additional requirements.

  1. Site
    • All images are in an images folder, with clear names that say what they're (sunset_beach.jpg, not img7.jpg or DSC0042.jpg).
    • Every page has at least one image - the favicon doesn't count, no matter how it's included.
    • Linked stylesheets (other than font services like Google Fonts) go in a styles folder, and the site's stylesheet is called default.css - if there are several, default.css must be first. A single page using only embedded styles needs neither the folder nor the file.
    • All scripts are in a scripts folder.
    • Any unused files sit in a folder called z_archives
    • re-usable code is in a components folder
    • Absolute URLs are for any site that's not part of the site you are linking from.
    • Relative URLs are for any page that's part of the same site you are linking from. Standard navbars should all be relative. An absolute URL that points back into your own webspace (links, images, stylesheets, or scripts) is a failure - make it relative. Exception: footer site links. Your CLT and GitHub copies are identical files, so the footer's home/site links (CLT Web, GitHub, etc.) must be absolute - they point at a fixed home no matter which copy the reader is on.
    • Relative links should NOT open in new windows/tabs - unless they point into another directory (a separate site or subproject).
    • An href contains only the link itself - no spaces before or after it (stray spaces make hover and underlines look wrong).
    • Any divider - like | or • or ~ - has a space between itself and the things it separates, everywhere on the page.
  2. File name is meaningful, has no capital letters or spaces, and is consistent with other pages in site (if applicable).
    Examples:
    • introduction.html
    • course_contract.html
    • crap_website_evaluations.html
  3. Title combines the h1 (name of site) with the h2 (name of page) with a divider between. Close/clear page-name variants are fine - Home vs. Welcome, About vs. About Us.
    Examples:
    • Billy Jean's Emporium | Contact
    • Wilber Jackson's Wild Jackal | ABC123 | Course Contract
    • Foggy Bottom Enterprises ~ Welcome
  4. There's a legible favicon that matches the site name and/or theme, when viewed on the browser tab. The favicon file goes in the images folder, unless it's embedded (a data URI).
  5. Page Validation with the script from Accumulus (cloud) 
    <script src="https://lint.page/kit/4d0fe3.js" crossorigin="anonymous"></script>
    • Script is last line within head element
    • Every page also has the Vicunadator script before the end of body - both validators, on every page, while you code.
    • Cloud appears on web page all green
    • Manual check of cloud -> WCAG shows no warning/errors
  6. General Page Layout/Structure
    • Page has header/main/footer in body.
    • Header and footer match across entire site, to the pixel
    • Header
      • Starts with one h1 containing the site name only (an image before the h1 is fine)
      • Includes navbar with site navigation
      • Two or more similar/related links belong in a nav element.
      • Any navigation leading outside of site is a secondary navbar
      • Ok to put navbar between header and main if it's standalone and not part of header (i.e off to side)
    • Main
      • Starts with one h2 containing the page name - an image before the h2 is fine. (SPA-style pages may have multiple h2s, one per page name.)
      • If appropriate, includes subsections with h3 as section titles
      • If further divisions are needed, use article elements with h4 as article titles
    • Footer
      • A site tagline in italics or quotes (but not both) appears in the header or the footer.
      • Footer goes from widest to narrowest to avoid xmas tree effect.
  7. Styles
    1. Don't use white or black without good reason - explain the reason in a CSS comment.
    2. Use at least 2 fonts (check google fonts) and avoid using complex/serif fonts for small text
    3. override default link colors and styles - no blue, purple, green, or red links, and visited links stay the same color as unvisited ones
    4. Use a color palette that's cohesive and not jarring (check coolors)
    5. Don't align paragraphs, unless you intend for them to be one line (it's ok to for small devices), but not for normal screens.
  8. Test, test, test - readability, different browsers and devices, and someone who didn't build it (your grandma counts).
  9. Comments & Justifications - each of these, when present, needs a comment explaining why it's necessary. One comment on the first of a same-reason group is sufficient.
    1. divs and spans
    2. classes and ids
    3. inline styles
  10. Apply CRAP Design Principles
    1. Contrast: Text and important elements have sufficient contrast with background and other elements.
    2. Repetition: Design elements (colors, fonts, spacing, etc.) are used consistently across the site to create a cohesive look.
    3. Alignment: Elements are aligned in a way that creates a clear visual connection between them, improving readability and organization.
    4. Proximity: Related items are grouped together, while unrelated items are spaced apart to create a clear structure and hierarchy.
  11. DO NOT
    1. DO NOT use divs or spans when a more semantic element is available. For example, use header for the page header, nav for navigation, main for the main content area, and footer for the page footer. The litmus test should be - "Is there a more specific element that could be used here instead of a div or span?" If the answer is yes, use that element instead of a div or span. If not, make the div or span meaningful by adding appropriate classes or attributes, but be ready to justify why you're using a div or span instead of a more semantic element.
    2. DO NOT use inline styles instead of CSS classes for styling unless there are only two or less instances of said styling. This logic is similar to that of avoiding divs and spans - if there's a more efficient way to apply the styling across multiple elements, use that instead of inline styles.
    3. DO NOT add classes you aren't using. Avoid things like main class = "main".
    4. DO NOT use code that serves little purpose, or that you just pulled from an example or AI without need.
    5. DO NOT use more than one h1 and one h2 on any page with the h1 as the site name and the h2 as the page name. The exception is a multipage site (aka SPA Single Page Application) where you might use a section to deliniate each page and then use an h2 for the page name within each section.
    6. DO NOT overcomplicate your CSS and HTML; you can build a nice page with only about 10 lines of CSS, and no classes or divs or spans or ids whatsoever. Start out with that, and begin to add those other items as NECESSARY to achieve the design you want. If you find yourself adding a lot of code, stop and ask if there is a more efficient way to achieve the same result.
    7. DO NOT use black or white, or Times New Roman, or Comics Sans or Papyrus. Doing any of these shows ignorance, or laziness, or both.
    8. DO NOT use colors that clash or are too similar to each other. If you aren't sure about your color choices, use a tool like Coolors to generate a palette for you, and then adjust as needed.
    9. DO NOT center paragraphs. Centering is generally hard to read and should be reserved for very specific use cases, such as a short tagline or a call to action. For normal paragraphs of text, left-aligning is usually the best choice for readability. If you want to center text on smaller screens, you can use media queries to apply center alignment only on those devices, but be cautious about using it too much as it can still affect readability.
    10. DO NOT center bullets. Centering bullets can make them harder to read and can disrupt the visual flow of the content. It's generally best to left-align bullet points to maintain readability and a clean layout. If you want to create a more visually interesting design, consider using other styling techniques such as indentation, custom bullet icons, or spacing, rather than centering the bullets themselves.