Won't be covering the basics of HTML (or CSS later). See tutorial links on the course web site if you need to brush up on the basics.
I want to bring up some important points about HTML that some developers miss…
People often make web pages and test only in their browser.
Which proves that it works in one…
We have to do better than that.
The Robustness Principle:
Be conservative in what you do, be liberal in what you accept from others. Jon Postell, RFC 761
i.e. be very careful to make the data you send out exactly right, but ignore as many problems as possible on the input.
The Robustness Principle ensures maximum compatibility.
Web browsers hold up their end: do their best to display slightly wrong/broken pages.
Authors (and other things that generate pages) need to do their part too: be careful with the HTML (and CSS and JavaScript) that you produce.
Helps ensure your site will work everywhere, not just the browsers you have tested.
Let's talk about how to do this with HTML…
HTML is a semantic markup language: it represents the meaning/purpose/role of the content.
You should use the language that way: ignore the way things look and concentrate on meaning.
e.g. Anything in a <p> should be a paragraph, and all paragraphs should be in a <p>.
e.g. Any newly-defined terms should go in <dfn> tags, and only newly-defined terms should be in a <dfn>.
Select a particular tag if and only if the content matches the tag's meaning.
Consequence: you need to know tags' meanings.
Find a reference that focusses on meaning not appearance. There are many crap sites with bad web dev documentation: be careful of your sources.
Suggestion: Mozilla Developer Network.
Sometimes, there is an obvious “correct” tag for some content.
e.g. you have a list of steps to complete a task. It's a list; order of things matter. ⇒ <ol> for an ordered list.
e.g. you're giving an example of code that needs to be typed ⇒ <code>.
Easy.
Sometimes, you want to more specific (so you can style differently with CSS later). Use a class or id attribute to distinguish the contents.
e.g. HTML code and Java code examples should be different colours ⇒ <code class="html"> and <code class="java">.
The class/id values should be meaningful too: class="interesting" is good; class="red" isn't.
Aside: the difference between class and id?
A particular id value (like id="menu") can only be used once on a page. Should be used for things you know will be unique.
Class values (class="example") may be used many times: use for things that might repeat.
Sometimes there is no “right” tag for a particular piece of content. What then?
e.g. a longer example of computer code, like a function definition: <code> fits shorter examples.
e.g. a change of language in the text like but that's life, c'est la vie.
We could twist an existing tag into service, like <blockquote class="code-example"> and pretend that code is really a “quote”. In general that won't always be possible.
There are two generic tags for this:
<div> for block-level content, and<span> for inline content (part of a block).These should (for me and this class, must) have a meaningful class or id.
Our examples would then become something like:
<div class="code-example python">
def add_one(n):
return n+1
</div>
<p>But that's life, <span class="otherlang" lang="fr">
c'est la vie</span>.</p>
… then in your CSS, make it look the way you want.
Not all browsers are graphical browsers on a desktop OS.
… but that's what you test your pages with, isn't it?
Always remember in web dev: you don't control the client. They might be using any technology configured any possible way.
Technically, we shouldn't think web browser
. The client might be any HTTP-fetching technology.
The HTTP geek term is user agent to remind you.
It's easier to use semantic markup in different situations.
Different users have different needs: colour blind, large font needed, small screen, slides/web page, etc.
Different styles can handle these needs if the markup isn't appearance-specific.
Even better… new corporate graphic design standards? Semantic markup can (hopefully) be restyled to the new design.
[I've done it.]
When writing markup, maybe think of the tags, class values, etc. as hints to automated processing. Natural language processing is hard: help it out.
It's easy for Google to figure out <h2> is a section heading. Text in a <p><font><b>? Who knows.
Want better search rankings? Start with good markup.
The goal throughout: pack as much meaning as possible into the markup.
Let the markup tell as much of the story of your content as you can. Hope that makes everything better later: styling, automated processing, use in a different context, ….
One more part of your “robustness principle” requirements: actually produce HTML. Remember that browsers will try to correct your mistakes, so you might not notice markup problems.
Will the next browser correct the same mistakes the same way? Will Google? You don't know, do you?
A validator will check your markup's syntax, because the browser doesn't. Makes sure your markup is correct, so you know every user agent will parse it the same way.
Would you hand in C++ that doesn't compile? Then don't do it with HTML either.
Course expectation: markup (both sent from server and constructed client-side) should be valid.
Bonus: Having valid(-looking) code will also trigger standards mode rendering in browsers. In summary, browsers will actually handle HTML and CSS the docs say it should.
Try it: HTML5 page and the validator.