Roadmap to Markup Success
Understanding Structure and Style
Molly Holzschlag
Molly.com, Inc.
Eric A. Meyer
Netscape Communications
About web standards
- Series of specifications & recommendations provided by the W3C
- W3C is primarily a research and development consortium and not truly an authorotative standards body
- Web standards exist as much for designers/developers as for software developers (browsers, tools & utilities for web production)
- HTML, XHTML, and CSS all fall under the W3Cs leadership
- Grass roots groups such as The WaSP (Web Standards Project) and MACCAWS (Making a Commercial Case for the Adoption of Web Standards) have emerged to evangelize and educate
SGML, HTML, XML
- SGML: Standard Generalized Markup Language
- Metalanguage parent to HTML and later, XML
- HTML: Hypertext Markup Language
- HTML 4.0 - Introduction of separation of structure and style via style sheets; introduction of three separate DTDs
- HTML 4.01 - Minor editorial update but important because forms the basis of the XHTML 1.0 DTDs
- XML: Extensible Markup Language
- Metalanguage: Extensible, customizable, cross-platform with both server and client-side applications
XHTML, Modularization
- XHTML 1.0: Extensible Hypertext Markup Language
- Reformulation of HTML as an XML application
- XHTML 1.1 & Modularization
- Decomposition of languages into modules (text, tables, forms, etc.)
- XHTML 2.0: A very different future
object becomes ubiquitous, new elements are added, addition of XFrames
Important ideas common to HTML 4.0 & XHTML
- Separation of structure & presentation
- Accessibility
- Internationalization
- Document conformance & validation
- Improvement of document rendering
Document Type Definitions (DTDs)
- Strict Interpretations
- Transitional Interpretations
- Frameset Interpretations
Document conformance & validation
- Use of correct DOCTYPE and structure
- Validation of documents with good validator
HTML and XHTML declarations
Root Elements
Head and Body Elements
head element also must contain title element in HTML and XHTMLbody element combines with head element and any declarations to form the basis of the document
Logical markup for content
- Proper use of headers
- Paragraphs and breaks
- Lists, rules, etc.
Logical markup example
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>Working with Structure</title>
</head>
<body>
<h1>Welcome</h1>
<p>Welcome to the site where structure matters!</p>
<h2>Getting Into Structure</h2>
<p>In order to begin working with structure, you need to be aware of:</p>
<ul>
<li>DOCTYPE declarations</li>
<li>Properly structured head and body components</li>
<li>Logical structures for content markup</li>
</ul>
</body>
</html>
Viewing the document tree
- Document root:
html
head & body are children to the roottitle is child to the parent headh1 , h2, p, ul all children of body - Each
li constitutes a leaf node
XHTML rationale
- Bring rigor to web markup
- Accommodate new devices
- Facilitate accessibility
- Bring extensibility & customization features to developers
Initial requirements for an XHTML document
- Recommended but not required: XML prolog
- Required: DOCTYPE declaration
- Required: Root element of
html with namespace
- Required:
head, title, and body
XHTML syntax
- Case sensitivity
- All elements and attribute names in lower case
- Attribute values are not case sensitive
- Well-formedness
- proper nesting of elements
XHTML syntax continued
- Management of elements and attributes
- Non-empty elements must have a closing tag
- Empty elements close with a trailing slash
- All attributes must be quoted
- No attribute mimimization is allowed in XHTML
- Managing scripting and style
- Ideally scripts and style are external to XHTML documents
- Scripts require escaping certain character entities, such as the ampersand
Deconstructing the UI7 conference page
- Goal 1: to strip a conventionally designed page down to its structure, demonstrating some of the major concerns when structure and presentation are not separated
- Goal 2: to convert the page to valid XHTML
- Goal 3: to prepare the document for styling with CSS
- Goal 4: to add some accessibility features
view page
Deconstruction: Removing font tags and related attributes
- Remove all
font tags and related attributes
- Rationale:
font tags are wholly presentational and typographic concerns can be readily and more flexibly handled with CSS. Currently the page is using a combination of both. Let's get rid of it all and rebuild it better
- Found 39
font elements and removed them. Very few visual differences result. Reduced page weight by 1k
view page
Deconstruction: span tags
- Remove all
span tags and related attributes
- Rationale: span is being used to style header and body text that could be more logically styled
- Found 41
span elements and removed them. Significant differences now appear. 2k more shaved off of page weight
view page
Deconstruction: non-standard markup
- Remove all proprietary markup preparing document for conformance
- body margins and alignment attributes
- GoLive generated JavaScript elements in body and head
- Non-SGML character entities
- Added a complete HTML 4.0 strict DOCTYPE declaration and validated document
view page
Deconstruction: presentational markup
- Removed all remaining presentational markup including alignment attributes and table images.
view page
Deconstruction: clean up
- Removed all scripting. Also removed external style sheet references as this will be replaced later.
- Revalidated document
view page
Deconstruction: Viewed tables, re-engineered primary table
- Examined nested tables
- Re-engineered primary table and removed nests
view page
Conversion to XHTML 1.1
- Convert syntax
- Validate document
view page
Added Accessibility Features
- Table Summaries
alt attribute descriptions- Titles in anchors
view page
On over to you, Mr. Meyer
»»»
Disclaimers!
- We'll be talking about today and tomorrow, not yesterday
- Most of you know how to handle the old; let's look at the new
- Wish we had time to explore v4-era compromises, but...
- It is possible to balance new-browser styling and old-browser concessions
A Dash of Theory
- structure of a rule
h1
{color:
purple;
font-size:
175%;}
- embedded stylesheets
<style="text/css">...</style>
- external stylesheets
<link rel="stylesheet" type="text/css"
href="site-style.css">
@import url(page.css);
- inline styles
<p style="background: yellow;">...</p>
- We'll be using an external stylesheet today; that way I can just edit the stylesheet on its own and reload the HTML file to show the changes
- Some example files will use embedded stylesheets
- A good way to develop is with a single file with an embedded stylesheet, so you can do quick comparisons of style to markup; once you're done, you can take the stylesheet and move it to an external file
- Remember that NO HTML markup is allowed in external stylesheets!
- [[Add
<link rel="stylesheet" type="text/css" href="uiconf-style-workspace.css" /> to the file uiconf-style-workspace.css]]
Width differences
- Courtesy MSDN:
- We'll be assuming standards mode, and using the W3C
width model
- There are ways to balance the two modes, but it's becoming less necessary to do so
Starting from scratch
- Molly showed you how to take old-school markup and strip it down
- Of course, presentation is handled via CSS, not
font and its ilk
- So let's take away the CSS and see the results!
- With the palette clear, let's rebuild the styles to see how they work
- [[Start with final styled document, then load up unstyled document]]
Visualizing structure
- Use CSS to "sketch out" the structure of a page
- Good for diagnosing table-layout problems
- Great for knowing how elements are nested
- Borders are good, but can have layout implications
- Backgrounds avoid layout shifting, but can be jarring
- [[Use file
uiconf-borders-backgrounds.html to show the difference between the two; then combine them just for fun]]
- [[Check for familiarity with descendant selectors; explain if needed]]
- [[Point out shorthand hex notation]]
Choosing class and ID names
- Add classes to things that have common aspects—external links, asides, captioned pictures, etc.
- Classes are more commonly used because they were a little better supported in old browsers
- IDs are quite safe, and woefully underused
- Add IDs to unique elements—navigation sidebars, mastheads, footers, etc.
- Extensive use of IDs can give you the effect of writing "XML lite"
- "XML lite" view first mentioned by Zeldman in e-mail
- If you write your CSS so that class and ID names are given without their accompanying HTML, you're halfway to XML already
- Sometimes you need to include the HTML elements, though, so don't go overboard
- As always, use the tool in the best way
- Most of our work today will be with IDs, because those in combination with regular element names will handle almost all our needs
- This doesn't mean classes are useless; they're just not as necessary for this particular exercise
Adding class and ID names
- Some IDs (more will follow as we work):
| Top masthead | #masthead |
| Main table | #main |
| Left-side navigation | #nav |
| Current page link | #current |
| Main content | #content |
- [[Edit file
uiconf-style-workspace.html to drop in IDs:
- masthead
- main
- nav
- current
- content
- expertlist
- first
- hosted
- bottomlinks
- credits
]]
"Global" styling
- Look at the original HTML and find things in common
- Check the width of the original; set elements accordingly
- Set vertical alignment of cells
- The page background could stand some reduction
- With the new background, the main table needs a background
- The usual suspects: font and link styles; image borders
- The
body element is where you set the presentation originally attributed to the body; we'll take care of link styles a little later on
- The
width is set on the tables
- We are doing one thing different: instead of a 56KB background image meant to create the white background, we're using a repeated 143-byte image
- The white background is set on the relevant table cell itself
- We're also top-aligning the cells in the main table (one line does it all!)
The left navbar
- Is precise recreation really necessary?
- Set a width and background color
- Boldface the links; normalize the paragraphs
- Kill off paragraph margins
- Line height can affect spacing
- Remember to leave some "indentation" room
- In order to save weight (and to show off some CSS) we've replaced the image-and-Javascript links with regular text
- Rather than deviate too far from the original design, we'll set an explicit width
- A percentage width would make more sense for flexible design-- adjustments are harder if everything's in pixels
- Similarly the vertical separations are being set in pixels to emulate the spacing created by spacer GIFs; it would be more flexible to use ems
- The same is true for the text itself
Bullet time
- Images as bullets: CSS makes it easy, but we're turning off bullets here
- Instead, we're dropping these bullets into the link backgrounds
- Need padding to accomodate the images
- Use "hanging indent" to push the diamonds into place
- Add hover and "current link" styles (which are the same in this design)
- [[Replace bullets with images to show how that's done, then change the URL value to none and proceed]]
- We're actually not using bullet replacement because we want to recreate the tight spacing control found in the original design
- Bullet separation from text isn't controllable in current browsers
- [[Use a border to show how this works]]
- Placing the bullet in the background of the link means we need some extra padding
- We also need to do the highlight thing with a hover effect
Bullets in the main
- Here we use images as bullets; background tricks aren't needed
- Remember to give the bullets room to live
- Some extra vertical whitespace may be necessary for bullets
- Moved a rule from the printed notes to the next part; we'll get to it in a minute
- You need to set both padding and margin on lists in order to get consistent indentation (DE article)
- Vertical placement of small bullets like these require extra whitespace in the image itself, which is something of a drawback in terms of flexible design
Styling the content
- We can set width, or we can let it go
- Padding needed to recreate the spacer-GIF cell effects
- Paragraphs are all basically the same (and usually are)
- Spacing adjustments can happen on the fly, or wait until the end
- The spacer GIFs that held open the vertical space between "columns" is recreated by applying padding to the cell itself (dangerous in NN4.x!)
- We also set the width, but remember about width and padding being added together (padding is not subtracted from width)
- We set the font families and sizes for groups of elements, and the letter and word spacing helps us tweak the presentation for large-text elements
Styling main-text links
- We're actually going to style all links
- The specialized links (left nav, speaker list) have weightier styles
- Link - visited - focus - hover - active (LVFHA)
- These rules technically apply to every link in the entire document, even those which are linked images
- The specificity of the rules for the left navbar is higher than for these rules, so those rules override these
- These replace the
body attributes from HTML 3.2
Styling other pieces
- The titles were already converted to
h2, etc.
- Style these directly, using CSS to overcome margins and other default layout
- The registration area has some "special" hooks we can use
- Hang these styles on the class names
- Since the original markup had these class names and we kept them, we'll just recreate the original styles here
Recreating the expert speakers
- Remember we've ID'd the table cell itself
- Wrap the contents in a
div for ease of styling
- Borders and margins block out the containing box
- Use the
h3 to create the title
- Background, foreground, alignment, text—all in one element
- In this case, we're better off not styling the table cell directly
- A border on the table cell could throw off the width calculations of the entire table
- This is sort of like nested tables, except of course we don't have to nest two tables just to get a border
- The heading of the box is just an
h3 element with no margins
Setting up the links
- Each link has its own paragraph, so we'll use those
- Spacing and "indentation" happens on the
p element
- So do the separators!
- Throw in an ID to remove the first separator
- Let's use the
strong element to our advantage
- We're using an ID to mark the first paragraph because that's needed for less capable browsers like IE6
- The better way to do it would be to leave off the
first ID and use #expertlist p:first-child {...}
- Notice the use of margins on the paragraphs to keep the separators apart from the "outer walls"; affecting that separation is as simple as changing a single value
- We can't do it with padding on the
div because that would push the heading away from the borders [[show this]]
- The limitations of text become more obvious at this level-- no anti-aliasing, unpredictable line-wrapping, definite limits on how low you can go
- On the other hand, it's far easier to resize-- either as a designer or a user
- We've turned off underlining here explictly to make it look more like the original
Hovered experts
- Set the base color of the links
- Now we add in the hover style (just a color change)
- Why don't the names change color too?
- Beware hover styles that force layout changes!
- [[Use the doctree to show how styles are inherited or are blocked; thus the point that an explicit style always beats anything inherited]]
Fixing the footer
- Start with background colors where needed
- Links already have color, but the text doesn't
- We'll style the cell itself, and let that apply to the bits between the links
- Setting the background colors is a good start
- We use padding on the
credits cell to reproduce the extra yellow space at the bottom of the design
Compare and contrast
- Now that we've added the styles, the page weight is about 15KB
- Changes are a snap—want to make the expert speaker links purple on gold with an orange hover effect?
- The markup itself is simpler to read and edit
- The unstyled view is not as nice, but still readable
- So we've gone from 100KB originally to 15KB total; even without the background being considered, we've gone from 45KB to 15KB
- On the latter basis, assuming a page that gets 100,000 views a month, the bandwidth savings is 3GB for that page; on a site with 100 pages, that's a savings of 300GB per month
- Even on small sites, it adds up; a page that gets 5000 visitors a month that's reduced by 10KB will save 50MB per month, and that's for that single page
- The benefits go beyond bandwidth savings, with the flexibility that CSS provides; elements can be changed in almost any way quickly and conveniently, and using a compact notation that makes sense
- When you have one stylesheet (or a set of stylesheets) controlling an entire Web site, site-wide changes become a breeze
- The font-styling in this approach actually isn't very efficient; now that we're done, we can see that most pieces of the layout use the same font families, so we can set that at a "higher level" and reduce the number of times we set the font throughout the stylesheet [[set them on the
body and start converting other declarations to the minimum needed]]
- For those cases where the fonts don't match the "global" styles, we just leave the styles alone, and those will override the inherited styles from our "global" rule
Throwing out all the tables
- How far can we go?
- Let's try getting rid of all the table markup
- Browser compatibility is more of a concern
- Accessibility will increase, and the unstyled view will be less of a problem
- The point here is to show where we're headed, and give you some idea of how to work with simple positioning
- Not all current browsers will deal well with these techniques, and NN4.x definitely won't be happy with most of them
- However, the benefits are worth considering
- As the CSS we did before conferred great flexibility in terms of appearance, moving to non-table layout permits incredible flexibility in basic layout
Conversion instead of removal
- At this point, we'll end up converting tables to
divs
- Some cells become
divs as well
- Why not remove them? We need a way to place the pieces!
- At the end, we have only
div elements framing the layout
- One thing to watch out for is "
div soup," which is not too much better than table soup
- If you find yourself nesting
divs more than two or three deep, you're probably overdoing it and need to look for a simpler solution
Placing pieces
- The masthead can be left mostly alone, except for image placement in Gecko and the width
- Within the "main"
div, we have three "columns"
- We could float or position all three, but that has implications
- We'll float the sidebar and leave the main column in the normal flow
- The footer needs help; rearrangement is useful here
- Floats are dependent on source order-- a float can't be above another floated element that comes before it in the document source
- Thus to get this effect, we have to actually rearrange the document itself
- The advantage to floating is that it's a little better supported than positioning
- Note that we're NOT floating the content, but have given it margins large enough to give the floated columns room to live without overlap or pushing the main content text around
- The content isn't floated so that it "holds open" the height of the
main containing div; doing this keep the footer at the bottom, but more importantly prevents the main div from collapsing to zero height
Floats and height
- The drawback to floats is that they tend to auto-size their height
- In some cases, floats will stick out of their parents!
- We can force parents to wrap around floats
- Getting floats to stretch taller is much harder
- Floats are trickier than most people realize, although some careful thought about how floats have worked in the past helps understand them better
- Note that the sidebar doesn't match the height of the main content any more
- There isn't a reliable way to force a float to be as tall as its parent element (even though
height: 100% should work)
- You can get a parent to wrap around a float by inserting at the end a
clear: both element
Positioning to the rescue
- Instead of floating the navigation links, we'll position them
- We need to establish a containing block (a positioning context)
- With that done, we can place the navigation anywhere
- What about the background?
- Stretching the height is one option, or we could be sneakier and use a border instead
- With positioning, we don't have to rearrange the source order, as placement is almost completely divorced from source order
- The only constraint is the need for a containing block if you want elements to be placed in a common area [[explain containing blocks]]
- In fact, we could put the navigation AFTER the main content and expert speaker list in the document source and still place it right where we want it
- Note where we've placed the bottom links, however-- placing them in with the content makes sense because that's where they appear, inside the content box
- Also note that we're NOT positioning the main content, for the same reason we didn't float it before, only now it's far more important, because there's no such thing as
clear: both for positioning
- That's because it's too easy to get trapped in infinite loops if you let element placement be directly tied to other elements
Compare and contrast redux
- The page weight isn't much changed
- Layout flexibility goes up quite a bit
- There are obviously more wrinkles to floating and positioning
- Browser compatibility is reduced, though not too much
- The unstyled view is much improved