Preliminary Material - Coding For The Web

27/3/2014 Preliminary Material: Coding for the Web
http://classroom.w3devcampus.com/mod/book/tool/print/index.php?id=1581 1/19
Preliminary Material: Coding for
the Web
This material actually is the lecture for week 1 of this course. To give the opportunity for those who need more time on the
subject of HTML, CSS and best practices, the material is available right from the moment you registered on the course so that
you can make the most of it.
Site: Classrooms - Online training for Web developers
Course: Responsive Web Design - March 2014
Book: Preliminary Material: Coding for the Web
Printed by: anh det
Date: Thursday, 27 March 2014, 4:52 AM
Table of contents
1 Introduction
2 The Web on Mobile
3 Progressive Enhancement
4 Content First
5 HTML5
6 CSS3
7 Tables
8 Forms
9 Do's and don'ts
1 Introduction
Tools and Techniques
This may be a good moment for a look in our metaphorical toolbox.If you are less familiar with the tools and techniques which
we will use in this course, this preliminary material gives you the opportunity to dive into the subject before the lectures will
start.
If the material seems a little basic to you, beware of skimming too quickly over material you think you know: there are some
important points to remember in each lecture (or we wouldnt have bothered you with them!).
A lot of the tools and techniques you may be familiar with static design, apply just as much with responsive design. However,
you may need to use them a little differently as you take into account a range of factors that go with responsiveness.
As you read through, you should feel free to raise any questions or comments in the discussion forum. Other people are
reading the same material as you and everyone benefits from the conversation. Dont be shy, please!
2 The Web on Mobile
The Web on Mobile and Desktop
The notes below are provided as a background to the course. What are the important differences between designing for the
Web on mobile and on desktop?
The Web is available through a wide variety of devices and not just through the headline-grabbing smartphones. The networks
now routinely offer flat rate data tariffs in their packages too so that using the Web on the move is as normal as it is on the
desktop.
It's easy to see why the Web and mobile go together so well. Unlike the traditional "wired" Web, the mobile Web goes where
users go. Users no longer have to remember to do something on the Web when they get back to their computer, they can do it
immediately, within the context that made them want to use the Web in the first place. Mobile devices allow the Web to reach
a much wider audience, at all times, in all situations. It has the opportunity to reach into places where wires cannot go, to
places previously unthinkable (e.g., providing medical information to mountain rescue scenes) and to accompany everyone as
easily as they carry the time on a wristwatch.
Whichever survey you look at it, the trend is clear: Web-enabled mobile devices are becoming truly ubiquitous across the
world and people are using them more and more. Let's take a look at the challenges...
Input
Mobile device input is often difficult compared with desktop devices equipped with a keyboard. Mobile devices often have
only a very limited keypad, with small keys, and there is frequently no pointing device. Touch screens are all well and good but
all too often the user is asked to tap a 10 pixel square icon using a 40 pixel-square device (i.e. their finger). One of the
difficulties of the mobile Web is that URIs are very difficult to type. Lengthy URIs and those that contain a lot of punctuation
are particularly difficult to type correctly. Shortened URIs are only a partial solution since they include a mixture of upper and
lower case characters and are barely easier to enter by hand.
Because of the limitations of screen and input methods, forms are hard to fill in. This is because navigation between fields may
not occur in the expected order and because of the difficulty in typing into the fields. While many modern devices provide
back buttons, some do not, and in some cases, where back functionality exists, users may not know how to invoke it. This
means that it is often very hard to recover from errors, broken links and other similar issues.
Bandwidth and Cost
Mobile networks can be slow compared with fixed data connections and often have a measurably higher latency. This can
lead to long retrieval times, especially for lengthy content and for content that requires a lot of navigation between pages.
Although flat rate data packages are commonly available in many countries, mobile data transfer can still add significantly to
the cost of using a device, especially when roaming. The fact that mobile devices frequently support only limited types of
content means that a user may follow a link and retrieve information that is unusable on their device. Even if the content type
can be interpreted by their device there is often an issue with the experience not being satisfactory - for example, larger images
may only be viewable in small pieces and require considerable scrolling.
Web pages can contain content that the user has not specifically requested - especially advertising and large images. In the
mobile world this extra material contributes to poor usability and may add significantly to the cost of the retrieval.
User Goals
When using mobile devices, users typically have different interests to when they use desktop devices. They are likely to have
more immediate and goal-directed intentions, often to find out specific pieces of information that are relevant to their context.
An example of such a goal-directed application might be the user requiring specific information about schedules for a journey
they are currently undertaking.
Equally, mobile users are typically less interested in lengthy documents or in browsing. The ergonomics of the device are
frequently unsuitable for reading lengthy documents, and users will often only access such information from mobile devices as a
last resort, because more convenient access is not available.
Advertising
Developers of commercial Web sites should note that different commercial models are often at work when the Web is
accessed from mobile devices as compared with desktop devices. For example, some mechanisms that are commonly used
for presenting advertising material (such as pop-ups, pop-unders and large banners) do not work well on small devices.
Device Limitations
As already noted, the restrictions imposed by the keyboard and the screen typically require a different approach to be taken
to page design than for desktop devices. Various other limitations may apply and these have an impact on the usability of the
Web on a mobile device. Mobile browsers may not support scripting or plug-ins, which means that the range of content that
they support is limited. On many devices, the user has no choice of browser and upgrading it is not possible.
Some activities associated with rendering Web pages are computationally intensive - for example re-flowing pages, laying out
tables, processing unnecessarily long and complex style sheets and handling invalid markup. JavaScript interpretation, playing
videos and using the network all draw heavily on the CPU too and processing power can be quite limited on mobile devices.
This means that page rendering may take a noticeable time to complete. As well as introducing a noticeable delay, such
processing uses more battery power as does communication with the server.
Many devices have limited memory available for pages and images, and exceeding their memory limitations results in
incomplete display and can cause other problems.
One Web
Despite of the restrictions we need just one web site that can be used on all devices. That way one and the same URL can be
used no matter what device the user is on. That way the content of the site remains the same on all devices. Some
(minor, exceptional) changes can be made as long as the content at the utmost extent stays (thematically) the same.
Presentation Issues
Today still, many Web pages are laid out for presentation on desktop-size displays and exploit the capabilities of desktop
browsing software.
Accessing such a Web page on a mobile device often results in a poor or unusable experience. Contributing factors include
pages not being laid out as intended, and context and overview being lost because of the limited screen size and therefore
small amount of material that is visible to the user.
The limited screen size may require considerable scrolling or zooming to see the subject matter of the page, especially if the
top of the page is occupied by images and navigation links. In these cases the user gets no immediate feedback as to whether
their retrieval has resulted in the right content. It is particularly important in the mobile context to help the user create a mental
image of the site. This can be assisted by adopting a consistent style across pages en presentations and can be significantly
diminished by an uneven style.
3 Progressive Enhancement
Progressive Enhancement
Before we start to write any code for any Web page, we need to consider what are the most appropriate technologies for us
to use. HTML and CSS are evolving all the time, as are browsers and devices; new APIs are being defined and implemented;
and all this is increasing the power of an already powerful platform. We face a continual paradox:
if we only use code that works on every Web-enabled device, then we're producing content that is almost certainly
going to be unattractive and disappointing to users of more powerful devices.
if we only produce code that only works on the latest, most powerful smartphones, we're going to exclude a significant
proportion of our potential audience.
The answer to this is the theme that will run through the whole of the course: progressive enhancement. This means that all
the information and functionality you wish to provide should work for everyone. However, users of more advanced devices
should expect to receive a better experience.
Progressive enhancement and graceful degradation are basically the same thing. The importance of both is that all the
information and functionality you wish to provide should work for everyone. However, users of more advanced devices should
expect to receive a better experience. And there are two approaches to achieve this and shortly, progressive enhancement is
the way to go.
PE in CSS
With progressive enhancement (PE) in CSS you begin with the absolute basics that will be supported by all browsers and that
will create a good enough screen presentation. Then you start enhancing this with CSS3. The browsers that support this will
use it, the browsers that don't will ignore it. Of course you will always follow the basic principle of only use what you need.
For example you will not use position or display (low support on simple mobiles) when you can do the job with float (that may
have less complications when not supported).
Graceful degradation
Graceful degradation,the opposite of progressive enhancement, means that you start with the enhanced versions and add basic
functionalities to solve things for browsers with no support of the used CSS. This means in most cases more work. Though,
when you create rounded corners in the first place, the fact that in older browsers the corners will be square is a graceful
degradation as well, but does not cost you anything. When you add a javascript solution to create rounded corners in IE8 and
lower as well, this is time consuming example of graceful degradation. While, the fact that with JS disabled the corners still will
be square, you could label it with PE...
JavaScript
The same principle of progressive enhancement counts for javascript: don't make the functionality of the web page depend on
javascript, it is extra, it adds extra functionality for those who have javascript enabled. The way the web is developing this is
subject of discussion, what may be summarized to: don't use it when you don't need it (like for basic, infomative web pages),
and you cannot do without it for enhanced web pages like web apps.
More about progressive enhancement.
4 Content First
Where progressive enhancement is the way to deal with design (CSS) and functions (JavaScript), content first is the
recommended way to set up a website. With content first you start the project with the content that has to go in the website.
For one this way you avoid to force content in a not suitable design, because you have the content first. This spares you extra
work and lots of design frustrations.
Don't Think Design When Creating the Content Structure
In the former chapter of this book you could read about one Web and how one Web site with one and the same URL will be
used on all devices. As result it may be clear that when coding the Web site any thought on what part of that content will be
presented in what column, or what column will go left or right, is quite useless or in the least hard to oversee. This means that
adapting the order of the content in favor of the layout has become quite useless.
Structure and Semantics First
The Web s about content. The people the content is created for use screens or assistive technologies. Search engines index
the content and apps use the content for their tasks. While the screen design will be made for only part of the users, the
structure and the mark up of the content is important for all users. Good reason to first focus on the best semantics and
structure of the content in HTML instead of forming the HTML in favor of the screen design, only for the users with screens.
For design purposes you may need to add extra div-tags in the HTML in the layout process to group elements so that you
can call them with CSS.
In the lecture of next week you will read about the promising new CSS3 layout techniques that facilitate the content first work
flow. Once these techniques will be enough supported to start fully using them, there is absolutely no reason left to move
content around for design purposes. They will give you the tools to change the order of the content with CSS for each different
layout width.
Content Model
Content structure is another subject and definitely not part of this course. Nevertheless to give you a small lead on this
challenging (and important) subject you can read this article about content modeling.
5 HTML5
Document Type
The doctype declaration appears at the beginning of the document and basically tells parsers and validators that the document
is an HTML document and should be treated as such. With simply the HTML5 DocType your web page will be backwards
compatible with the older browsers. The HTML5 doctype is to be written as:
<!DOCTYPE html>
Structural Semantical Elements
If you don't use them already then start today: the structural semantical HTML5 elements like header, nav, main, section,
article, aside, footer and more. Remy Sharp's HTML5 shim' makes these elements work in older browsers, including
IE6. A solid alternative with no need for javascript is adding extra div elements as container for or nested in the HTML5
elements, and style the divs instead of the HTML5 elements.
And better safe than sorry... good to set display: block for the semantical HTML5 elements in CSS to cover the older
browser versions that don't have this by default set.
Even though HTML5 is still evolving and is not a done deal as of today, the main parts are stable and HTML5 is backward
compatible with previous versions of (X)HTML in any case. Besides, there is no doubt that upcoming versions of mobile Web
browsers will support more and more features of HTML5.
Beware though, new functionalities introduced in HTML5 (such as the <video> and <audio> tags) are not available in all
mobile Web browsers yet. This yields the question: what can you take for granted when you also want to take mobile devices
into account?
So how should we proceed? Progressive enhancement! (see the book in this lecture named with this title). The right
approach with progressive enhancement will make sure that the other HTML5 features are extra, that the web page does
not depend on it, so that when a browser does not support these features, the web page will still work and the content is still
accessible.
Sectioning Elements
The following HTML5 elements are sectioning elements: nav, section, article, aside what means they markup their
content as sections. As you will read below not headings but sectioning elements are responsible for the document outlines in
HTML5.
Headings
With the new HTML5 Document Outlining Algorithm, a correct use of headings needs some extra attention.
This is how it was before HTML5:
Use headings and paragraphs and dont jump from H1 to H4;
Use preferably just one H1 per page (in favor of legacy screen readers), and use that one as heading for the main
content (so it will differ per page).
See Creating Semantic Structure to understand the basic correct ranking of headings for legacy browsers.
HTML5 is much more flexible on the subject of headings as you can read on the W3C site.
The difference is that modern browsers that support the HTML5 Document Outlining Algorithm use the sectioning elements
(nav, section, article, aside) for the document outlines. The first heading inside the sectioning element will be used as
the title of that element.
The first heading in the body that is not nested in a sectioning element will be used as document title (i.e. title for the body), no
matter where it will be placed in the HTML i.e. this can even be on the last line of the body! Since a header (or a footer)
are not sectioning elements, a heading nested in a header (or footer) can serve duty as document title.
Good reads on this subject can be found at:
https://developer.mozilla.org
http://coding.smashingmagazine.com
http://html5doctor.com/outlines/
Still it is highly recommended to use the appropriate rank of the sections nesting level for the headings, in favor of
legacy browsers. In practice this means that if the section is on a 2nd or 3d level in the outlines, it is recommended to use a
corresponding H2 or H3. This way the document structure will be backwards compatible for the legacy browsers that don't
support the HTML5 document outlines algorithm i.e. don't recognize sectioning elements as outlines. More about this in this
article on the Paciello Group Blog.
Main
The main element is relatively new in HTML5 and marks the main content of a web page. It can only be used once per page
and is not a sectioning element i.e. it does not affect the document outlines.
This leads to the conclusion that main should not be used to markup asection or an article since this will lead to a missing
outline. The main element is meant to group principally sectioning elements.
Syntax
HTML5 is more than a definition of available elements, attributes, and scripting interfaces. It also defines the syntax that you
can use to write your documents. HTML5 defines two possible syntaxes for the price of one: the HTML syntax and the
XHTML syntax. The HTML syntax is lax in that it allows many omissions in the resulting document. For instance, the
following is valid according to the HTML syntax:
<p id=p1>Some text in a paragraph. <BR>
A second line.
<P>Some more text in another paragraph.
The XHTML syntax is much stricter, forcing you to be explicit about things and to use strictly defined separators. The same
example as above would be written in XHTML as:
<p id="p1">Some text in a paragraph. <br />
A second line.</p>
<p>Some more text in another paragraph.</p>
Theoretically there may be some older mobile Web browsers (e.g. on feature phones) active that may require that you respect
XML rules more thoroughly. Since they are a true minority, we decide to ignore them. Modern mobile Web browsers will
parse content that follows the HTML syntax correctly. The result is that we don't see the need of writing XHTML syntax in
HTML5.
Nevertheless we advise, to make sure that your content will work on the vast majority of devices, to stick to just some basic
main rules of XHTML:
use lower case element and attribute names;
enclose attribute values in double quotation marks;
close elements.
That's all. Apart from that there is no need to write <br /> , just <br> will do, same with other so called 'empty' elements like
the <img> and <meta> element.
Media Type
HTML documents should be served with the text/html media type. Some very old mobile Web browsers (the same ones
we mentioned above and decided to ignore) may require you to use the more XHTML-friendly application/xhtml+xml
media type, but this should be viewed as exceptions to the rule (and has too much disadvantages).
Type attribute
In XHTML we write link and script elements like this:
<link href="screen.css" rel="stylesheet" type="text/css" />
<script src="functions.php" type="text/javascript"></script>
In HTML5 you can leave out the type attribute:
<link href="screen.css" rel="stylesheet">
<script src="functions.php"></script>
Resources and References
Since this course is not about HTML5 (we have a course that dives deep into the subject!) you can find some links below
that can help you further on this subject. And if you know some nice CSS-based layout tutorials or resources, feel free to post
the relevant links to the forum to enrich this course and help your course-mates.
The services of HTML5 Boilerplate and Modernizr can be of great help, but only use it when you need it and what you need
of it! For the assignments in this course we prefer you to experience how far you can come without the use of
either one.
And in case it is new for you, in the links below you will find a tutorial that may help you further with HTML5 Boilerplate.
Start
Yes, You Can Use HTML5 Today!
5 Reasons Why You Can Use HTML5 Today
Building Web Pages With HTML5
HTML5 Content Model
List of HTML elements from W3C
Beginners
HTML FAQ's
Semantics
Semantic Code: Importance & Relevancy to SEO
Semantics and sensibility
Semantic HTML and Search Engine Optimization
HTML5 Structural Sementical Elements
Creating Semantic Structure (for legacy browsers)
Links about the HTML5 Document Outlining Algorithm:
w3c.org about headings and sections
https://developer.mozilla.org
http://coding.smashingmagazine.com
http://html5doctor.com/outlines/
Forms
Learning to love forms by A. Gustafson
A Form of Madness, Chapter 9 of Mark Pilgrim's Dive Into HTML5
Slides about HTML5 Forms
HTML5 Form Features
Resources
HTML5 Shiv
HTML5 Rocks
HTML5 Doctor
Accessibility
The HTML5 structural elements are an enormous improvement and they do have an overlap with some ARIA landmark roles
for assistive technologies (like screen readers), but not all landmark roles have equivalents in HTML5 yet. This means that for
the time being you benefit users that depend on assistive technologies by adding (landmark) role attributes to your code. For
this reason you will be expected to make use of the role attribute in your assignments:
WAI-ARIA landmark roles
Sample file with landmark roles
Browser Support
html5accessibility.com
Test your browser
Can I Use
QuirksMode
Miscellaneous
Lesser Known Semantical Elements
HTML5 Shiv and Serving Content From Code Repositories
HTML Form Basics
Various Articles from Smashing Magazine
Projects
HTML5 Boilerplate
Modernizr
6 CSS3
Levels and Layers of CSS
Separation of content and style is a fundamental principle of good Web design and is even more critical when developing
content for presentations on different screen sizes.
CSS does not have standard versions but works with levels: every level is the base for the next level, CSS Level 2 continues
where CSS Level 1 stops and CSS3 continues on both underlying levels. Perfect for the approach of progressive
enhancement! So basically if you ensure yourself that the content is well presented with styles form CSS Level 2 and add
CSS3 on top of that to enhance the presentation - you will be fine.
Onliest lack in this approach is that you cannot rely on the support on all mobile devices of certain styles from CSS Level 2
like display, position, float and even table. This will be mostly the case on (older) devices with such small screens that -as long
as you use them thoughtful- nobody will really miss their styling. An of course you can expect these styles to work on smart
phones.
Resources and References
This is not a course on CSS there are many resources available to help you learn this critical technology but we will look
at some aspects in this course as they relate to responsive design. Below you find links that may be helpful if it is new for you.
It is not that you need to read it all, all you need for this course is some basic understanding of CSS3. It may be good to know
where to find more when you need it...
Generators
CSS3 Generator
Background Gradient Generator
CSS3 References
CSS3 Tutorial
css3.info
Sitepoint CSS Reference
Wikibooks
Browser Support
When can I Use
Quirks Mode
CSS3 Tutorials
Background Images
Multiple Backgrounds
Rounded Corners
CSS Animations
CSS Transitions
Form with HTML5 and CSS3
Vendor Prefixes
Safari Developer Centre
Advanced Selectors
Stephen Bradley - How To Use Structural Pseudo Classes and Pseudo Element Selectors
Sitepoint - :nth-child(N) |
Sitepoint - Understanding :nth-child Pseudo-class Expressions
CSS Tricks - How nth-child Works
Tutorials - Additional
:target
Stickies
CSS3, SVG, Canvas & WebGL Animations
Selection of Articles from Smashing Magazine
The following articles with lots of practical information and inspiration, can also be found bundled in the CSS Essentials ebook
available at the Smashing Magazine Webshop:
Start Using CSS3 Today by Vitaly Friedman
Connecting The Dots With CSS3 by Trent Walton
Create a Poaroid Image Gallery by Zurb
Sliding Vinyl Albums With CSS Gradients by Zurb
Sweet Overlays With Border-Image by Zurb
CSS 3D Transforms by Peter Gasston
How to use CSS3 Pseudo-Classes by Richard Sepherd
The Guide to CSS Animation: Principles And Examples by Tom Waterhouse
Using CSS3: Older Browser And Common Considerations
7 Tables
As Web professionals fully realize, tables should not be used for layout. But there's more to it than that. Mobile presents
additional reasons that should make you wary of using tables unless you have a very specific reason for doing so and the
chances are you don't. Many data in tables can just as good (or even better) be placed in a list.
At the beginning of the Web, HTML was a very simple markup language with little focus on design or rendering. Aligning text
and images, or different fields of a form, was not possible. In order to make more attractive pages and Web sites, some
designers quickly found some workarounds and "hijacked" some of the features of the language to make cool design. Using
tables for layout is one of the most well-known examples of these techniques.
Tabular Data
Originally, and fairly obviously, tables were introduced to display tabular data, but then with the ability to remove the border
(border="0"), it became a virtual grid upon which designers could lay out images and text. But even today designers abuse
tables, like for image galleries or forms.
As said, and it cannot be repeated often enough: tables are meant for tabular data. But what exactly are tabular data?
Any information that is likely to be placed in a spreadsheet, is almost certainly tabular data;
Data that need header fields at the top of columns plus at the left of rows, are tabular and need a table.
Alternatives
As the W3C site explains:
the table element represents data with more than one dimension, in the form of a table.
One way of looking at the data you are about to place in a table could be to check if they can be rather presented in a linear
fashion. Description lists (before HTML5 named as definition lists) are just one way you might use to do so. The main
alternatives for description lists are ordered ol and unordered lists ul . (list tutorial)
A simple rule of thumb is that if the table contains empty cells, there is a fair chance that the data may just as good (or even
better) be presented in a linear fashion.
In the last week of this course, when responsive tables are part of the subject, you will realize how tables cause extensive
scrolling on small viewports. This only supports the theory that tables should be avoided to the extreme.
Activity
If you have an example of a table that you have used in your own work, think about how you might present the same
information in a linear fashion. If you don't have an example to hand, think about how you might present any of the
following without using a table:
A travel itinerary
Sports results
A calendar
This is not an assignment, we're not asking you to actually create the presentation, but please post ideas on how you would do
so to the discussion forum.
Are Tables Ever Justified?
Yes. There are some types of data that cannot sensibly be presented any other way but you should try hard to avoid tables
with lots of columns if they can be avoided, especially when older devices in mind.
An example where tables would be appropriate is something like a drug-dispensing dosage chart where both the type of drug
and the time of day are variables that affect a third factor: the dosage to be given.
Bottom-line: when the content really is tabular data it semantically should be marked up as table.
8 Forms
While we all are very well aware that tables are not meant to be used for layout, is this awareness suddenly disappeared
considering forms.
Yes, a table is an easy and solid way to position the label and the input field inline. But (1) form elements are no tabular data,
(2) we are not supposed to use HTML for design and (3) it is so much harder to position the label and the input field in a
linear layout on a small viewport when they are in a table.
Content First
Since we have enough options in CSS to position anything anywhere (even in any viewport width as we will see later in this
course), we are free to concentrate on the HTML and semantics first. The following basic HTML may be well-known, but for
those who are not familiar with it, it is too important to leave out. Plus that the following HTML directions offer you good
means to address your styles to:
It has become general use to sort the form controls in either a list or in paragraphs. When we look at the form as a list
of form rules this seems semantical the best choice. In that case place each label + input (or textarea and others) in a list
item;
Make use of the label element in combination with the for attribute to make semantically clear to what form element
the label belongs.
Like so:
<..>
<li>
<label for="email">Email Address</label>
<input name="email" id="email" type="text">
</li>
<..>
The li elements can be helpful later for the CSS. Though if you choose them for that reason only, div elements would be
the better choice.
You always have the option to group parts of the form with fieldset elements in combination with a legend element.
The fieldset element will automatically result in a border around it's content, but you can easily change that with CSS.
Accessibility
Apart from the label element, we dispose of the aria-labelledby attribute, as part of the WAI-ARIA, the Accessible Rich
Internet Applications Suite that: '"defines a way to make Web content and Web applications more accessible to people
with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax,
HTML, JavaScript, and related technologies'". You can read more about the aria-labelledby attribute in this Wiki page
from the working group. The aria-labelledby attribute can be used as progressive enhancement of the label element and
should not replace it since it is not supported by legacy browsers and screen readers.
As you can read in this article in the section about Optimal Positioning Of Form Field Labels, the ideal position for a form label
is before the input field or textarea.
Landmark Roles
There are 2 role attributes relevant for forms: role="form" and role="search".
Since landmark roles provide navigation features for users with screen readers and helps them to understand the content
structure, the form role attribute may be preferably placed in the form element and the search role attribute in the element that
contains the search controls, but what element suits their purpose best, depends on the HTML structure.
In case you missed the information about landmark roles in the former books, best to read this article from the Paciello
Group and study this sample where you can easily see how the landmark roles are used.
HTML5
There are several new form attributes and values in HTML5. The placeholder attribute for input and textarea elements is
one:
<input name="email" type="text" placeholder="Place your email address here">
The required attribute on the input, select, and textarea elements indicates that a value must be supplied:
<input name="email" type="text" required placeholder="Place your email address here">
With the autofocus attribute it is possible to specify that a form control should have input focus when the page loads. It can
be applied to input, button, select, and textarea and just to one object per document:
<input name="email" type="text" required autofocus placeholder="Place your email address here">
The type attribute has new values for the input element: search , tel , url , email result in automatically stripping of line
breaks and/or whitespaces. For the tel attribute on mobile the numerical keyboard should automatic appear.
<input name="email" type="email" required autofocus placeholder="Place your email address here">
Read more about forms at:
Learning to love forms by Aaron Gustafson
A Form of Madness, Chapter 9 of Mark Pilgrim's Dive Into HTML5
9 Do's and don'ts
Best Practices
These general do's and don'ts are here to help you get into good habits and can be used as checklist for the first assignment of
this course. If you follow the various guidelines, your code will be much more robust and efficient, is more likely to work
cross-browser and give confidence to other professionals that you really know what you're doing. If you're already familiar
with a lot of the ideas here, so much the better, but it's worth at least a quick read through to make sure!
HTML
Use a validator to check your code (for instance, the W3C Validator);
Choose your doctype:, preferably HTML5;
Dont forget to add the charset meta tag for HTML5 (versus the content-type meta tag together with the UTF-8
charset in XHTML);
Keep the head section small and clean: don't stuff it with redundant information;
Write your HTML5 code according the following XHTML rules: lower case for element names and attributes, enclose
attribute values in double quotation marks and close the elements;
Do not use empty elements, spacer images, break tags and non-breaking spaces to create white space for layout
purposes: layout needs to be done in CSS;
Avoid inline styles (i.e. style attributes on HTML elements);
Do not include any design attributes in your markup (HTML) such as the now depreacted center and font elements;
Open external links by default in the same window (i.e. don't use the target attribute on hyperlinks): allow the user to
decide if the external link should be openened in a new window. And if you really cannot resist to open the external link
in a new window, make this clear to the user beforehand;
Use HTML5, CSS3 and javascript according the approach of progressive enhancement;
Place scripts in an external file for ease of maintenance and re-use, actually, don't use any javascript at all inside the
HTML;
Place preferable all javascript in just one external file with a link to it on the last line in the body;
No JavaScript pop-ups.
Semantics
Use HTML5 structural semantical elements like header,nav, main, section, article, aside, footer etc. and
don't forget to add the HTML5 shim or an other solution to solve the fact that IE8 and lower don't support these
elements.
Avoid untitled sections (check the document outlines in the browser!) and use headings in the recommended way
(see the HTML5 book in this lecture for more) ;
Make use of the role attribute to benefit screen readers;
Use tables for tabular data only, never for forms and other layout purposes;
Use a list for the menu (see List Tutoral for more);
Use label elements for forms (see Use the label element to make your HTML forms accessible for more);
Use em and strong only to (sporadically) emphasize text, otherwise use i and b to mark it as offset or use CSS to
make text italic or bold;
CSS
Use relative sizes for text: % or em;
For reasons of flexibility use CSS for uppercase text, don't write text in uppercase in HTML (of course this does not
count for capitalized text);
Be aware that display: none will also hide the content for screen readers. So if you first place a heading for the
benefit of screen readers and next hide it with display: none, this will not be very productive. Better use another
technique like described in this article from Zeldman;
For the benefit of all people that use the tab key for navigation, make a (good!) habit of always styling a:focus. This
means to define an a:focus variant for each a:hover selectors like this: a:hover, a:focus, a:active.
Layout
A good starting point is always to keep it simple, stay as close to the flow of the page as you can, only generate HTML and
CSS that is really needed and avoid an overkill of divs.
Use an external stylesheet for all CSS;
Let the content generate the height of the site, dont set a fixed height;
Start with the flow of the web page, next use float and only use position if float cannot do the job, in this order;
Use relative sizes for layout: % or em;
Dont rely on javascript (dont use it for links and buttons), just use it to add extra functionality that can be missed if JS
is disabled (according the principles of Progressive Enhancement);
Developer Tools
There are several good developer tools available that offer you indispensable help like Chris Pederick's Web Developer Tool
and Firebug for Firefox. Chrome and Safari have native developer tools, in Safari you need to activate them by turning on the
Developer menu in Safari Preferences. If you don't use them yet, they are worth checking out!
Summary of the Links Mentioned Above
W3C Validator
HTML5 shim (and maybe you should read this article too)
Landmark Roles
List Tutoral
Use the label element to make your HTML forms accessible
Tab key navigation sample
Web Developer Tool Bar
Firebug

Preliminary Material - Coding For The Web

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Preliminary Material - Coding For The Web

Uploaded by

Copyright:

Available Formats

27/3/2014 Preliminary Material: Coding for the Web

You might also like