Syntax Style for HTML5 Markup: some best practice recommendations

The people involved in the WaSP InterACT Curriculum are organizing to do some updates to the free online course materials the curriculum provides to web educators (and self-taught learners). This is part of an ongoing effort to keep the InterACT web standards based curriculum up to date.

In preparing to update the Web Design 1 course to bring in some material about HTML5, I surveyed the members of the WaSP education task force and others involved in InterACT as to what style of syntax we should recommend as a best practice for HTML5.

As you may know, the options for syntax style in HTML5 are wide open. Tags can be upper case, lower case, or camel case. Attribute values can be quoted, or not quoted. Empty elements can have a closing forward slash, or not. Other elements can be closed, or not.

I didn’t want to add modules for HTML5 to the Web Design 1 curriculum that simply said, “Do whatever you feel like in terms of syntax,” although that is pretty much what HTML5 allows. And I didn’t want to write something that was merely “Virginia’s ideas on HTML5 syntax.”

So, the survey of the WaSP education task force members went out. Consensus was reached. Here are the recommendations for HTML5 syntax. This is how we think it should be taught and written.

  • Use lower case for tags
  • Quote attribute values
  • Don’t use the XML style trailing forward slash on empty elements (e.g., <br> not <br />
  • Close all non-empty elements (e.g., <p></p> and <li></li> etc.)

What we’re advocating as a best practice is using syntax associated with strict doctypes in past iterations of (X)HTML. However, HTML5 is not XHTML, so there’s no need to retain the trailing forward slash on empty elements.

Here’s your chance to add your voice to the mix. Are there any reasons why this style of syntax should not be used as a best practice for HTML5? Can you add anything else that you think is important that hasn’t been included?

WebAIM’s Screen Reader User Survey

You can see the full set of results of the WebAIM Screen Reader User Survey #3. I hope you’ll study them with interest.

I want to highlight a few of their findings here.

ARIA Landmarks

Chart showing usage of ARIA landmarks

ARIA (Accessible Rich Internet Applications) introduces something called landmarks. These provide quick access to page areas, such as navigation, search, and main content. Which of the following best describes your use of landmarks?
Response # of Respondents % of Respondents
I didn’t know this functionality existed 342 30.9%
I do not use landmarks for navigation 287 25.9%
I sometimes use landmarks for navigation 277 25.0%
I use landmarks for navigation whenever they are present 161 14.5%
My screen reader does not support landmarks 40 3.6%

Awareness of landmarks has increased – 42% were unaware of this functionality in October 2009. However, these data continue to show mixed levels of usage.

In spite of that finding, I think its important to teach people how to use ARIA roles, particularly in HTML5. In HTML5, we’re still dealing with levels of support for various new elements, and any help that a front-end developer can add to the code is a good thing.

Other findings important to front-end developers:

  • JAWS is still the primary tool, although others are increasing in number
  • Almost 95% of users have JavaScript enabled
  • A majority of users are using a screen reader on a mobile device, too
  • The main method for navigating a page is using headings
  • The use of “skip links” and access keys is decreasing
  • The heading structure found most useful by a big majority of screen reader users: Two first level headings, one for the site name and one for the document title
  • Users indicate strong usefulness of the longdesc attribute, which may not make it into HTML5

Foundational HTML talk from Emily Lewis

Get to know Emily Lewis, who will be on a panel at SXSW Interactive this year. This is a recent talk she gave to a local tech group called Webuquerque. She talks about the basics of good markup, semantics, and new concepts in markup. It’s about an hour long.

I think it would make a good resource or assignment for web education students.

A text summary and the slide deck are available on the Webuquerque site.

Other speakers and talks from Webuquerque meetings are available on Vimeo.

Media queries 101

Media queries are part of the CSS 3 recommendations that worked beginning with HTML 4 and CSS 2. Lately they have been touted as a solution to designing for mobile devices. The trend has earned the label “responsive web design.” I thought it was time to look at the basics of media queries.

When you use media queries, you can set up style rules that are based on the media environment of the output device. You might have one set of styles for devices using landscape display, and another for devices using portrait display. Or you might write rules specific to the color bit depth of the output device.

The W3C explains,

A media query consists of a media type and zero or more expressions that check for the conditions of particular media features. Among the media features that can be used in media queries are ‘width’, ‘height’, and ‘color’. By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself.

“A media type and zero or more expressions that check for the conditions of particular media features.” What does that look like in practice?

Start with an @media declaration that sets up the device and the conditions you want to meet. One way to do this is to create a specific stylesheet for various conditions and link to it. For example:

<link rel="stylesheet" media="screen and (color)" 
   href="example.css" />

This uses the familiar stylesheet link to set up a media type – screen – and a condition – the screen displays in color – and links to a stylesheet specific to those conditions. The same thing can be accomplished with the @import method of linking to a stylesheet.

@import url(color.css) screen and (color);

A more manageable solution is to link to a single stylesheet, and put @media rules in that one stylesheet. For example,

@media screen and (max-device-width: 480px) {
  .sidebar {
    float: none;
  }
  body {
    background-color: #fff;
  }
}

With @media rules in a stylesheet, the example style rule specifies a media type – screen – and sets up the conditions with terms and values in parenthesis – (max-device-width: 480px). Then, nestled in curly braces {}, one or more selectors and rule declaration blocks are used to create the desired style. The rules inside the enclosing curly braces will be applied only when the conditions are met. Otherwise, they are ignored.

Beyond the basics, you can get more specific and/or complex. You can use commas to set up a number of media types and conditions. There are operators such as and, not, and only that can set up more precise sets of parameters for applying styles.

The media types

  • all
  • handheld
  • projection
  • screen
  • tv
  • tty
  • braille
  • print

The media features

  • width
  • height
  • device-width
  • device-height
  • orientation (portrait or landscape)
  • aspect-ratio (the ratio of the value of the device-width media feature to the value of the device-height media feature)
  • device-aspect-ratio
  • color (bit depth of the device)
  • color-index
  • monochrome
  • resolution
  • scan (for tv)
  • grid (for tty or some phones)

Values

Values can be expressed in pixels, ems, dpi (dots per inch) and dpcm (dots per centimeter)

Further reading

Useful links: CSS selectors, OS X shortcuts, Postel’s law, Bob’s Birthday

Understanding CSS Selectors at Script Junkie. Great explanation of attribute selectors, including how to style with attribute selectors when using ARIA roles and forms. The article also explains how to use more than one attribute selector to create styles.

Want to look like a real computer whiz on your Mac? Study A selection of Mac OS X keyboard shortcuts at 456 Berea Street for some lesser known shortcuts that will speed up your day.

Adactio was talking about Going Postel today. He said,

As long as we use progressive enhancement, the front-end stack of HTML, CSS, and JavaScript is remarkably resilient. Remove JavaScript and some behavioural enhancements will no longer function, but everything will still be addressable and accessible. Remove CSS and your lovely visual design will evaporate, but your content will still be addressable and accessible.

I had to go look up Postel’s Law to see what he was referring to. Just in case you’ve never heard of it either, here’s how Wikipedia describes it:

In computing, the robustness principle is a general design guideline for software:

Be conservative in what you send; be liberal in what you accept.

The principle is also known as Postel’s Law, after Internet pioneer Jon Postel, who wrote in an early specification of the Transmission Control Protocol that:

TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

Today’s is Bob Marley’s birthday. And I cannot resist an occasional foray into the off topic land of iconic music. The wonderful organization Playing for Change has given us this in celebration of the day.

Useful links: Screen readers, Ada Initiative, HTML versioning

Videos of screen readers using ARIA at zomigi.com is enlightening. Watch.

The Ada Initiative is dedicated to increasing participation of women in open technology and culture, which includes open source software, Wikipedia and other open data, and open social media.

HTML as a Living Standard – For and Against is must reading at HTML5 Doctor. Taking on the two sides of the debate are Bruce Lawson and John Foliot.

Useful Links: Webcraft, Mint in classrooms, Useful vs. Delicious

Mozilla’s School of Webcraft is taking names and keeping lists in anticipation of the opening of registration for the new classes on Jan. 8 2011. Learn HTML, CSS, and Javascript.

Mint.com is taking a personal finance class into middle schools, according to TechCrunch. I know this isn’t the first time commercial concerns have developer curriculum materials, but this one caught my eye because Mint has lived its entire existence online.

Useful vs. Delicious. The Useful Links feature of this blog is my own personal Delicious bookmarking method. I know I’ve written about using Tumblr to store bookmarks, but the things I save there are things I don’t think I’ll use more than once. When I mention something here in the Useful Links, it is a link I think I may need myself at some point. I tend to remember what I’ve talked about in the Useful Links, too, and can come to the blog and search for it when I want  it. Maybe cataloging Useful Links is only helpful to me, but I hope readers find them useful too.