Upgrade to Pro — share decks privately, control downloads, hide ads and more …

HTML semantics - The practical version

HTML semantics - The practical version

What is HTML really about? Why does it exist, what was it created for and why should you care? This slideset has practical information about how to write HTML that works better, by just understanding a few key principles and best practices.

Jerry Jäppinen

April 18, 2013
Tweet

More Decks by Jerry Jäppinen

Other Decks in Programming

Transcript

  1. What's HTML? It's hypertext markup language. It's a static markup

    language for preserving standardized structural information in platform-independent documents. This structure can then be rendered and used in diverse ways depending on user agent and operating system. Authors can write <select> and UAs can use a native dropdown menu to represent that.
  2. It's ancient! HTML really is for documents. NOT layouts or

    interfaces. When you write those things with HTML, you're using the language for something it wasn't developed for. The concept of hypertext has evolved to contain things like images and input, but it's probably not something we'd create now. C'est La Vie.
  3. What we mean by "semantics" Semantics concerns about what HTML

    means. What the meaning of tags, attributes and declarations in HTML documents is.
  4. Why semantics are important This question implies that semantics should

    have consequential value, any inherent value isn't enough. So we're mostly interested in how good semantics help us write more functional, robust and understandable documents and UIs for the web and other platforms. How they help us maintain and understand our work better.
  5. Does it help, then? Yes! Standardization usually does, we know

    that. You own code, not to mention plugins and styles written by someone else, won't work well with HTML that's not written with any common sense. HTML is not very strict, it's almost never a restriction unlike many other standards.
  6. Why do we need to train? HTML is loose, complex

    and looks easy on the surface. Just like CSS, it's easy to think you know it when you really don't. For this reason, it's easy to abuse HTML and not realize how much easier many things can be. That's why we do this.
  7. <tag attr="attribute value"></tag> Basically, that's it. It's an XML derivative.

    Tags can be nested. All tags should be closed, except in HTML5 that has void tags. Doctypes and other header stuff should just be copypasted from some guy that understands how the fuck they work. Basic syntax
  8. Tags A standardized set of valid elements. Each tag has

    a specific meaning. When you say <p>, you tell a browser that this here is a paragraph. It then knows that the element should be treated like one. HTML is old, and many tags never took off. They almost never break, but their specialties were never implemented. Read out references for more details.
  9. Attributes A standardized set of valid attributes. Different for each

    tag. For many elements, specs list attributes that are not really supported by user agents. HTML references usually include details on browser support.
  10. Classes and IDs • ID is a unique identifier for

    a specific element, a proper name (but not name=""!) to separate an element from others. • Classes (plural) are arbitrary labels of elements. They're a way to tap into HTML in other languages. Read the spec: http://www.w3. org/TR/html401/struct/global.html#h-7.5.2
  11. How to use classes However you please, really. HTML doesn't

    care. There are no rules, just what works and what doesn't, which usually is a concern for JS or CSS workshops. I'll just say one thing: semantic classes is an oxymoron. Classes never carry semantic info. HTML ideally only concerns structure, but being a purist about presentational classes isn't practical yet (because of how CSS works).
  12. Browser support Unlike with CSS, browser support is mostly not

    a problem with HTML. Practical problems are: • Semantic containers (<header>, <footer>...) ◦ Older browsers don't always know how to render them. Use CSS to force block rendering. Done. • New input elements ◦ Quick intro: http://www.w3schools. com/html/html5_form_input_types.asp ◦ Won't break on older browsers, they just degrade into regular text inputs
  13. No excuse If you use an editor plugin, a gem,

    a preprocessor or any other tool to generate HTML for you, your users still get only the output in their browsers. You're still responsible for the end result. (The same goes for CSS and JS)
  14. <h1>, <h2>, <h3>... • I.e. titles & subtitles • Use

    them! • PROTIP: "heading" and "header" are two different words with their own meanings • <header> is not the same thing ◦ Makes things a little bit more complicated ◦ Is not necessary for functional HTML ◦ Read about it in HTML5 intro articles (see references)
  15. • Text paragraphs • Use them! • ... • What

    more can I say? Most content in HTML documents are or should be paragraphs. <p>
  16. • Lists • Either ordered or unordered • Can be

    nested • Use them! <ul>, <ol>, <li>
  17. • Definition lists ◦ <dt> is definiendum, a thing that's

    being defined ◦ <dd> is definiens, a definition (zero, one or many) • You should probably use these more often. • Note "un-HTML-like" formatting ◦ No container for definitions ◦ Styling is sometimes tricky ◦ Less laborious to use than e.g. tables, though • Gives a very nice, functional and semantically pleasing result out of the box <dl>, <dt>, <dd>
  18. <div> A generic section of the document, a container. •

    Doesn't really mean anything. • Use more meaningful elements when possible. A generic part of inline content (basically text). • Doesn't really mean anything. • Use more meaningful elements when possible. <span>
  19. Tables • Table syntax is very powerful • No need

    to always use everything that's available • Should only be used for tabular data, not layout ◦ CSS support is pretty good nowadays, table abuse is hardly ever warranted ◦ ...but when it is, it's not the end of the world
  20. Forms • Inputs are inline elements • All semantic containers

    etc. can and should be used within forms • Use subtitles and labels! Use them right! • Order of elements within forms affect usability a lot. • Think twice before using fancy JS thingies over native form elements ◦ Native form elements work very well on all platforms ◦ They're not the sexiest and fanciest, but they work ◦ New form elements and features have been added lately, with varied browser support
  21. How much is too much? Obsessing about actual semantics doesn't

    really transfer to better UX or codebase. Placing some emphasis on not writing meaningless HTML does. Bad <div>Welcome</div> <div>By JJ<br> Call me: 0407188776 </div> Good <h1>Welcome</h1> <p>By JJ</p> <p>Call me: <em>0407188776</em> </p> Not significantly better <header><h1>Welcome </h1></header> <section><address><p> By JJ</p><p> Call me: 0407188776</p> </address></section>
  22. • Inline vs. block is the single most important thing

    that affects how things are laid out • When you enter a tag, know which one it's gonna be • Inlines, like links and input elements, are content that naturally work within text flow • Blocks are containers that naturally stack Read the spec: http://www.w3. org/TR/html401/struct/global.html#h-7.5.3 Understand inline vs. block (and don't fight it)
  23. "If I don't know what to write, I write <div>"

    - Half of the world's software developers, ever Wrong! Only use <div> when you know that no better alternative exists. Same goes for <span>, in inline contexts. Don't take my word for it: http://www.htmldog. com/guides/htmlintermediate/spandiv/ Divs & spans
  24. • Don't mix inline and block elements on the same

    level in a container • Often produces results that are not immediately clear • You can change inline elements to blocks with CSS ◦ But why make things the hard way? Use something that's already a block element. ▪ Unless you need specific functionality (e.g. <a>) Don't mix inlines and blocks
  25. Never* use • <b>, <i>, <center> ◦ Use CSS for

    styling ◦ Use <strong>, <mark>, <em>, <q>, <cite> etc. to mark specific kinds of important parts of text • <br> ◦ Line break ◦ Shouldn't even exist ◦ To stack items, use block items as containers ◦ Use CSS for margins • <hr> ◦ Horizontal line ◦ Shouldn't even exist ◦ Use CSS for borders
  26. • <p>, <td>, <li>, <h1/2/3>, <dt>, <dd> etc. • Think

    of <div>, <section>, <footer>, <footer> etc. as section containers, not semantic tags • Plain text without a semantic wrapper is just loose text ◦ Doesn't inherit any styles or behavior set for text paragraphs or list items ◦ Usually renders in unexpected places Wrap inline tags in semantic tags
  27. <p><div>This is some text</div></p> Never do this. 1. containers (<div>,

    <header> etc.) 2. then semantic blocks (<p>, <h1>, <li> etc.) 3. then inline content (<em>, <a>, <input> etc.) NEVER use containers inside semantic tags
  28. References • http://www.w3.org/ ◦ W3C, the actual standards body ◦

    Hardcore, you will never understand all of this stuff ◦ Go here for the true spec, to know how user agents should work • http://www.w3schools.com/ ◦ NOT a standards body ◦ Usable basic reference for common cases ◦ Oldschool, not the most cutting-edge • http://www.htmldog.com/reference/htmltags/ ◦ Tag list sorted by function ◦ For sane people
  29. Introduction articles • http://diveintohtml5.info/semantics.html ◦ A nice, fairly comprehensive introduction

    into HTML5 (the actual HTML part) • http://coding.smashingmagazine.com/2013/01/18/the- importance-of-sections/ ◦ Intro to using <header>, <footer>, <section>, <article> and other new sectioning elements correctly • http://www.htmldog.com/guides/htmlbeginner/ ◦ HTML for beginners (yes, you are a beginner) • http://www.htmldog. com/guides/htmlintermediate/spandiv/ ◦ Intro to <div> and <span>
  30. Tools • http://validator.w3.org/ ◦ Validate HTML ◦ First step to

    avoiding/fixing stupid pitfalls • Emmet ◦ Plugin for Sublime Text ◦ Write HTML fast