Slide 1

Slide 1 text

HTML SEMANTICS The practical version By Jerry Jäppinen @eiskis

Slide 2

Slide 2 text

Basics

Slide 3

Slide 3 text

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 and UAs can use a native dropdown menu to represent that.

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

What we mean by "semantics" Semantics concerns about what HTML means. What the meaning of tags, attributes and declarations in HTML documents is.

Slide 7

Slide 7 text

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.

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

HTML syntax

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Tags A standardized set of valid elements. Each tag has a specific meaning. When you say

, 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.

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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).

Slide 16

Slide 16 text

Browser support Unlike with CSS, browser support is mostly not a problem with HTML. Practical problems are: ● Semantic containers (, ...) ○ 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

Slide 17

Slide 17 text

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)

Slide 18

Slide 18 text

Common elements

Slide 19

Slide 19 text

,

,

... ● I.e. titles & subtitles ● Use them! ● PROTIP: "heading" and "header" are two different words with their own meanings ● 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)

Slide 20

Slide 20 text

● Text paragraphs ● Use them! ● ... ● What more can I say? Most content in HTML documents are or should be paragraphs.

Slide 21

Slide 21 text

● Lists ● Either ordered or unordered ● Can be nested ● Use them!
    ,
      ,

Slide 22

Slide 22 text

● Definition lists ○
is definiendum, a thing that's being defined ○
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
,
,

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Best practices

Slide 27

Slide 27 text

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
Welcome
By JJ
Call me: 0407188776
Good

Welcome

By JJ

Call me: 0407188776

Not significantly better

Welcome

By JJ

Call me: 0407188776

Slide 28

Slide 28 text

● 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)

Slide 29

Slide 29 text

"If I don't know what to write, I write
" - Half of the world's software developers, ever Wrong! Only use
when you know that no better alternative exists. Same goes for , in inline contexts. Don't take my word for it: http://www.htmldog. com/guides/htmlintermediate/spandiv/ Divs & spans

Slide 30

Slide 30 text

● 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. ) Don't mix inlines and blocks

Slide 31

Slide 31 text

Never* use ● , , ○ Use CSS for styling ○ Use , , , , etc. to mark specific kinds of important parts of text ●
○ Line break ○ Shouldn't even exist ○ To stack items, use block items as containers ○ Use CSS for margins ●
○ Horizontal line ○ Shouldn't even exist ○ Use CSS for borders

Slide 32

Slide 32 text

Never* use ● align="", valign="" etc. ○ Use CSS for styling

Slide 33

Slide 33 text

,

,
  • ,

    ,
    ,
    etc. ● Think of
    , , , 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

  • Slide 34

    Slide 34 text

    This is some text
    Never do this. 1. containers (
    , etc.) 2. then semantic blocks (

    ,

    ,

  • etc.) 3. then inline content (, , etc.) NEVER use containers inside semantic tags
  • Slide 35

    Slide 35 text

    Resources

    Slide 36

    Slide 36 text

    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

    Slide 37

    Slide 37 text

    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 , , , 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
    and

    Slide 38

    Slide 38 text

    Tools ● http://validator.w3.org/ ○ Validate HTML ○ First step to avoiding/fixing stupid pitfalls ● Emmet ○ Plugin for Sublime Text ○ Write HTML fast