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.
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.
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.
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.
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.
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.
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
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.
tag. For many elements, specs list attributes that are not really supported by user agents. HTML references usually include details on browser support.
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
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).
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
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)
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)
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>
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>
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
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
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>
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)
- 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
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
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
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
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
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>
jerryjappinen
marcelgsantos
dunglas
m_seki
tmhirai
yue4u
92thunder
tanakahisateru
rickyban
utgwkk
kirik
chobishiba
osakatechlab
chriscoyier
brad_frost
nonsquared
smashingmag
bryan
eileencodes
quramy
colly
samanthasiow
rocio
