(X)HTML Concepts (X)HTML :: webDev

XHTML Elements, Their Parent, Children, Attributes And Default Browser Presentation

1. Attributes: All elements accept the standard and internationalization attributes of id="", class="", title="", style="", dir="", and lang="" unless otherwise noted. The attributes column lists elements specific attributes and exceptions to the core attributes. Required attributes have been emphasized.

2. Even though the type="" attribute is not required by the specifications, always define type="" because IE is stupid.

3. Inline: <a>, <br>, <span>, <bdo>, <map>, <object>, <img>, <tt>, <em>, <strong>, <dfn>, <code>, <q>, <samp>, <kbd>, <var>, <cite>, <abbr>, <acronym>, <sub>, <sup>, <input>, <select>, <textarea>, <label> and <button>.

4. Block: <p>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <ul>, <ol>, <dl>, <pre>, <hr>, <blockquote>, <address>, <fieldset>, <table>.

5. Flow: text < form > and all the inline and block elements.

6. Empty: self closing element, include a slash (/>) before the end of the opening tag to self close. Contains no children.

7. <table> elements: 0 or 1 optional <caption> element, 0 or more optional <col> elements OR 0 or more optional <colgroup> elements, 0 or 1 optional <thead> element, 0 or 1 optional <tfoot> element, and REQUIRED either one or more <tbody> elements OR one or more <tr> elements.

Actually Put In Best Reference http://www.d.umn.edu/itss/support/Training/Online/webdesign/sites.html

Plain Ol' Semantic Markup (POSH)

37 Steps To Perfect Markup

HTML defines a number of element types. An element type assigns some semantic meaning to its content.

The purpose of HTML is to mark up the semantics of a document, and -- to some extent -- to show the structure of its content. HTML has nothing at all to do with the way this document looks in a browser (although browsers have a default style for each element type).

<br /> - 37 Steps To Perfect Markup

A line break (<br />) is mostly a presentational tool, and should be handled by CSS rather than HTML. However, there are a few cases where line breaks can be said to have semantic meaning, for instance in poetry, song lyrics, postal addresses and computer code samples. These can constitute legitimate uses for <br />, but using <br /> to separate paragraphs (<p>) is definitely an abuse of the <br /> element.

<<address>> - 37 Steps To Perfect Markup

A line break (<br />) <<address>> is used to mark up contact information for the page (or for a part of a page). This can be a postal address, an email address, a telephone number, or virtually any contact details. address is a block-level element that can only contain text and inline elements. The default rendering is italic in most browsers, but that can be changed easily with CSS.

A common misconception is that <<address>> is meant to be used to mark up only postal addresses, but that is not the case.

Forms And Interactions

But since <form></form> is a so-called block-level element, you can use all sorts of regular HTML markup inside it (like paragraphs and headings), turning forms into documents inside documents.

Fieldsets, Legends And Screen Readers

The grouping and labelling of thematically related controls within a <form> is an important aspect of providing semantic information so users can understand and complete a <form> successfully.

The <fieldset> and <legend> elements are a useful part of a web developer’s toolkit for making <form>s more accessible to people with disabilities. The support in Window Eyes is quite different from the advice given in UAAG1.0. Due to this, Window Eyes users will not be able to gain the full benefit of the additional information provided through the use of these elements. In fact no <legend> text will be announced to users unless they first enable an option to announce such information. Even when the option is enabled Window Eyes users will not receive this important information when they are inputting data into <form> fields. Furthermore if they use Window Eyes in conjunction with the Firefox browser no <legend> or <fieldset> information will be provided.

The situation for JAWS users is much better. The JAWS implementation is consistent with the advice in UAAG 1.0. The grouping of controls using the <fieldset> is not explicitly announced (as it is in Window Eyes), but the announcing of the <fieldset> is not advised in UAAG and may be of limited value or overly obtrusive for the users, which could be why it is not enabled by default in Window Eyes. Importantly the association of <legend> text with controls contained within a <fieldset> is reliably conveyed by the announcement of the <legend> along with a control’s text <label>. This behaviour works when the user is browsing or interacting with <form> fields and across supported browsers.

Due to the nature of the advice in UAAG 1.0 and its implementation in JAWS (l<legend> text being announced before a control’s <label> text), developers should be mindful of the length of <legend> texts, as lengthy <legend> texts have been found to make <form>s difficult to use. Another potential pot hole is the JAWS behaviour when headings are included within a <fieldset>. In this case JAWS will typically use the heading text in place of the <legend> text, this is a quirk or bug, which can lead to unexpected and problematic consequences. This needs to be fixed in JAWS, but until it is, perhaps the use of headings within <fieldset>s should be minimised.

The <fieldset> and <legend> elements are well supported by many user agents. While it is helpful to have knowledge of some of the quirks and failings of particular user agents, the poor support in software such as Window Eyes must not stop developers using these elements or accessibility practitioners recommending their use. Their use can make it easier for a wide range of disabled users to fill out forms. In order to improve accessibility for all disabled users, web standards must be adhered to so that developers can code for accessibility with confidence. It is the assistive technology vendor’s job in these cases to fix their implementations.

More On Naming Conventions, Microformats And HTML5

2.1.9 Don’t alter the widths or shapes of letters without cause

“In the world of digital type, it is very easy for a designer or compositor with no regard for letters to squish them into cattle trains and ship them to slaughter.”

CSS does not offer many opportunities for altering the width or shapes of letters. In fact only the letter-spacing property can be applied at all for this purpose, and that simply changes the width of the letters (but not their shape). The letter-spacing property can however be particularly destructive.


								<h2 class="squish">letterfit</h2>
							

								h6.squish {letter-spacing: -0.1em }
							

Resulting in:

Letterfit is important

The result may differentiate itself stylistically from other websites, and that might be fine if the words are not important; legibility is the real loser in this instance.

(X)HTML Concepts (X)HTML :: webDev