Slide1: Web 2.0
(Getting it Right the Second Time)
Matt Sweeney
Where We’ve Been - WWW: Where We’ve Been - WWW “We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities.” – Tim Berners-Lee original WWW proposal
Where We’ve Been - HTML: Where We’ve Been - HTML
1992 - Tim Berners-Lee introduces HTML as “marked-up text to represent a hypertext document for transmission over the network” – HTML abstract
“Authors can include limited presentation hints, and further control may eventually be possible via associated style sheets.” – HTML+ discussion document
Where We’ve Been – HTML 1: Where We’ve Been – HTML 1 , , , , , , ,
, , ,
, ,
, ,
Where We’ve Been – HTML 2.0: Where We’ve Been – HTML 2.0 1995 - HTML 2.0 working draft published as RFC1866
“a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains.” – HTML 2.0 abstract
Where We’ve Been – HTML 2.0: Where We’ve Been – HTML 2.0 , , , , , , ,
, , , ,
, ,
, ,
, , , ,
,
, , , ,
, , ,
, ,
Where We’ve Been – HTML 3.2: Where We’ve Been – HTML 3.2
1997 - HTML 3.2 proposed for “documents with generic semantics that are appropriate for representing information from a wide range of applications.” – HTML 3.2 abstract
Where We’ve Been – HTML 3.2: Where We’ve Been – HTML 3.2 , , , , , , ,
, , ,
, ,
, ,
, , , ,
, , , ,
,
, , , ,
, , , , , , , , , , , ,
, , , ,
,
,
Where We’ve Been – HTML 4.01: Where We’ve Been – HTML 4.01
1998 - HTML proposal that “…supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. … takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.” – HTML 4.0 abstract
Where We’ve Been – HTML 4.0: Where We’ve Been – HTML 4.0 , , , , , , ,
, , ,
, ,
, ,
, , , , , , , , ,
, , , , , , , , ,
, , ,
,
, , , , , , , , , ,
, , , , , , , , , , ,
, , , , , , , ,
, ,
Where We Are – Development: Where We Are – Development
Cleaning up the past
Simplifying markup layer
Using CSS for presentation
Making heavy use of Javascript
Where We Are – Cleaning Up: Where We Are – Cleaning Up
•News
•Senate Approves Patriot act Renewal
•Mine Rescuers Still Waiting for Interviews
More news stories
Legacy markup
Where We Are – Cleaning Up: Where We Are – Cleaning Up
News
Senate Approves Patriot act Renewal
Mine Rescuers Still Waiting for Interviews
More news stories
No better
Where We Are – Cleaning Up: Where We Are – Cleaning Up
News
Senate Approves Patriot act Renewal
Mine Rescuers Still Waiting on Interviews
More news stories
Much better
Where We Are – Web 2.0: Where We Are – Web 2.0
Content sharing
Open APIs
Mixing code bases
Where We Are – Web 2.0?: Where We Are – Web 2.0?
Semantic markup
Progressive Enhancement (bottom up)
Separation of concerns
Encapsulation
Semantics - HTML: Semantics - HTML
Choose markup based on meaning
Avoid presentation in markup (defer to CSS)
Core functionality should not depend on JS
Should not have to change between designs
This is the “wireframe” for your application
Semantics – ID Attribute: Semantics – ID Attribute
Choose names that describe content
Avoid presentational and behavioral names
Should be meaningful without CSS or JS present
Naming:
Bad – “left-col”, “top-nav”, “redbox”
Good – “nav”, “main”, “news”, “calendar”
Semantics – ID Attribute: Semantics – ID Attribute
Triple Duty: The ID Attribute
HTML:
News
CSS:
#news { border:1px solid #000; }
Javascript:
var news = document.getElementById('news');
Semantics – Classes: Semantics – Classes
When to use:
Extending semantics (Microformats)
Supplementing selector support (“first-child”)
Managing state (“selected”)
Naming:
Bad – “red”, “float”, “pad20”, “drag”
Good – “error”, “date”, “review”, “calendar”
Semantics – Example: Semantics – Example
Today in the News
please correct the error
Meaning is lost without CSS
Meaning is lost to screen reader, web crawlers
Today in the News
please correct the error
Meaningful at the markup level
Leverages existing semantics (header, emphasis)
Semantics – Why bother?: Semantics – Why bother?
Markup is the foundation
Search Engine Optimization
Accessibility
Simplifies styling and scripting
CSS and JS rely heavily on elements and ID/class names
Names and markup must live beyond presentation and behavior
Semantics: Semantics
Markup should standalone
Should have meaning without styles or behavior
Core functionality should not depend on Javascript (forms and links work)
Choose names that will last
Test: “Do the names make sense without CSS and JS?”
Progressive Enhancement: Progressive Enhancement
Search for:
Progressive Enhancement: Progressive Enhancement
#video {
background-color:#ccc;
width:20em;
}
#video label {
text-indent:-9999px;
}
#video input {
font:120%/1.22 arial;
}
Progressive Enhancement: Progressive Enhancement
var video = document.getElementById(‘video’);
video.onsubmit = function() {
sendForm(this);
return false;
};
Progressive Enhancement: Progressive Enhancement
Requires:
Withholding CSS and JS from some agents
Thoughtful markup and naming
Not depending on JS for core tasks
Testing without JS
Progressive Enhancement: Progressive Enhancement
Benefits:
Works for ALL HTML readers
Enables reuse and code sharing
Functional prototype early in development
Allows parallel tracks for design and development
Simplifies debugging
Simplifies maintenance
Encapsulation: Encapsulation
Code needs to play nicely together
Do not pollute global namespace (CSS, JS, attributes, etc.)
Use descendent selectors
Use JS namespaces
Don’t invent your own markup
Encapsulation - CSS: Encapsulation - CSS
#news h2 {
background:#dcdcdc;
}
#news h2 em {
color:red;
}
#news li.selected {
background:#999;
}
Encapsulation - JS: Encapsulation - JS
Namespaces (YAHOO.util, dojo.bind)
Avoid global variables
Protect yourself from others
Protect others from you
Preparing for the Future: Preparing for the Future
More HTML-enabled devices
More media types (print, aural, screen, handheld, etc.)
More code sharing
Preparing for the Future: Preparing for the Future
Assume only HTML support
Do not depend on CSS for meaning
Do not depend on JS for core functionality
Cross these line reluctantly and thoughtfully
Thanks!: Thanks!
Have a nice day