in web pages. Though the term is not formally defined, its basic
principles are generally understood to include:
Separation of functionality (the "behavior layer") from a Web page's
structure/content and presentation
programming (such as browser inconsistencies and lack of scalability)
Progressive enhancement to support user agents that may not support
1 A new paradigm
2 Separation of behavior from markup
4 Degrading gracefully
5 Best practices
6 See also
A new paradigm
language unsuitable for serious application development. This
has been largely due to inconsistent implementations of the language
itself and the
Document Object Model
Document Object Model (DOM) in various browsers, and
the widespread use of buggy copy-and-paste code. Runtime errors were
so common (and so difficult to debug) that few programmers ever tried
to fix them, as long as the script behaved more or less the way it was
supposed to; scripts often failed completely in some browsers.
Some web developers have been promoting graceful degradation since
frameworks and high-quality debugging tools have made organized,
interfaces has made it desirable. Whereas
for relatively simple and non-critical tasks such as form validation
and decorative novelties, it is now being used to write large, complex
codebases that are often part of a site's core functionality. Run time
errors and unpredictable behavior are no longer minor annoyances; they
are fatal flaws.
Advocates of unobtrusive
standards movement; much as the demand for cross-browser compatibility
has driven the increasing emphasis on standardized markup and style,
the increasing demand for rich Internet applications is driving the
concept of unobtrusiveness in relation to
coined in 2002 by Stuart Langridge in the article "Unobtrusive
DHTML, and the power of unordered lists". In the article Langridge
argues for a way to keep all
handlers, outside of the HTML.
Stuart Langridge has since expanded
upon this thought in book and article format.
Other authors have tried to refine and define the essential elements
Definitive Guide says that while there is no specific formula, there
are three main goals:
HTML markup, as well as keeping modules of
be available without all or any of the
HTML, and ideally should improve it, whether the user has personal
disabilities or are using an unusual, or unusually configured,
Web Standards Project describes four benefits of unobtrusive DOM
scripting in their
Usability: An unobtrusive DOM script does not draw the attention of
the user - visitors use it without thinking about it.
Graceful degradation: Unobtrusive DOM scripts never generate error
messages, in any browser, even when they fail. If features cannot be
presented properly, they silently disappear.
Accessibility: If any script fails, the page still delivers its core
functions and information via the markup, stylesheets and/or
Separation: For the benefit of other and future web developers, all
files of script, markup or code.
For the Paris Web Conference in 2007, Christian Heilmann identified
Do not make any assumptions:
Defensive programming techniques should
allow for the possibilities that
may not support expected methods, the
HTML may have changed,
unexpected input devices may be in use and other scripts may either
not be present or may be encroaching on the global namespace.
Find your hooks and relationships, such as IDs and other aspects of
the expected HTML.
Leave traversing individual DOM objects to the experts, such as to the
CSS handler built into the browser where possible.
Understand browsers and users, particularly how they fail, what
assumptions they make, and unusual configurations or usages.
Understand events, including how they 'bubble' and the features of the
Event object that is passed to most event handlers.
Play well with other scripts by avoiding global function and variable
Work for the next developer by using self-explanatory variable and
function names, creating logical and readable code, making
dependencies obvious, and commenting any code that still might
Separation of behavior from markup
HTML document's markup. For example, the following is a typical way to
<input type="text" name="date" onchange="validateDate()" />
The purpose of
HTML markup is to describe a document's structure, not
its programmatic behavior. Combining the two can negatively impact a
site's maintainability, like combining content and presentation.
HTML can be harder
to use and maintain, for example when setting handlers for several
events on a single element, when setting the same event handler on
several elements, or when using event delegation.
The unobtrusive solution is to register the necessary event handlers
programmatically, rather than inline. Rather than adding an onchange
attribute explicitly as above, the relevant element(s) are simply
identified, for example by class, id or some other means in the
<input type="text" name="date" id="date" />
A script that runs when the page is first loaded into the browser can
then look for each relevant element and set it up accordingly:
object or global namespace of the environment in which it runs. Other
scripts may override any variable or function that is created in the
global namespace, and this can lead to unexpected failures that are
difficult to debug.
namespace mechanism, but the desired effects are easy to produce using
the language's facilities. Flanagan suggests the use of the
developer's own domain name, dotted segments reversed, as a single
global name to publish that is very likely to be unique, in the style
developed in the Java language.
org = ;
else if (typeof org != 'object')
throw new Error("org already exists and is not an object.");
org.example = ;
else if (typeof org.example != 'object')
throw new Error("org.example already exists and is not an
While variables, functions and objects of all kinds can be further
defined within such namespace objects, it is usually recommended to
use closures within the namespace to further isolate what will become
private variables and functions, as well as to export what will be the
public interface of each module of functionality. The code above could
be followed directly by the following:
org.example.Highlight = function()
// Define private data and functions
var highlightId = 'x';
document.getElementById(highlightId).style.color = color;
// Return public pointers to functions or properties
// that are to be public.
goGreen: function() setHighlight('green'); ,
goBlue: function() setHighlight('blue');
(); // End closure definition and invoke it.
From any other module, these public methods could be invoked in either
way as follows
var h = org.example.Highlight;
In this way, each module-writer's code is contained in private or in a
unique namespace and cannot interfere with or intrude upon any other
code at any time.
Main article: graceful degradation
Writing an event listener that detects the loading of the
and then adds relevant listeners to other events on the page, as well
as other behaviors as required, can solve the problem of separating
HTML markup. The use of client-side
MooTools or Prototype can
simplify this process and help ensure that individual browser and
browser version implementation details are hidden and catered for.
Keeping most of the
ensure that it is as unobtrusive as possible in that sense. A further
criterion of unobtrusive
that added behavior degrades gracefully on those browsers with
unexpected configurations, and those on which the user may have
This requirement is a basic tenet of web accessibility, to ensure that
abilities and disabilities but that all users - whatever their
computing platform - get equal access to all the site's information
and functionality. Sometimes there is extra work involved in achieving
this, but web accessibility is not an optional extra in many
countries. For example, in the UK, the Equality Act 2010, while it
does not refer explicitly to website accessibility, makes it illegal
to discriminate against people with disabilities and applies to anyone
providing any service in the public, private and voluntary
sectors. While a lot of effort may be put into designing and
implementing a slick client-side user interface in unobtrusive
client-side scripting if they find that they cannot access published
information. To meet this goal, it is often necessary to implement
equivalent, albeit clunkier, server-side functionality that will be
available without the use of
behaviours so that full-size images will appear in front of the page
when the mouse is rolled over them or they are clicked. First,
server-side markup should ensure that the relevant full-size image is
served to users without
case the basic
HTML markup may look like the following, for each
<a href="fullsize-image-001.png" class="manual-link" title="Click
for full-size image">
<img src="image-001-thumb.png" class="thumb" width="50"
height="50" alt="Image 1 shows... etc">
this case, during page-load, could find all the a elements that have a
class of manual-link and remove them from the page DOM. It could then
find all the images of class thumb and attach an onmouseover or an
onclick event handler that is specified in-line to provide the slick
behaviour. For example, when invoked the event handler may send an
Ajax request to the server for the full-size image, then add a div to
the page DOM invoking existing
CSS so it appears in front of existing
content, which itself may become partially greyed out. The div will
need a close button, perhaps a visual 'spinner' to show that data is
loading, etc. Finally, when the Ajax data arrives, the handler hides
the spinner and inserts the full-size image into the new div for
This way, all the client-side functionality depends on the same
the basic, manual behavior, and goes on to add the client-side
scripted behavior. If the script fails for whatever reason, the manual
behavior remains in place and remains functional.
Though the essence of unobtrusive
added separate behavior layer, advocates of the paradigm generally
subscribe to a number of related principles, such as:
DOM Scripting, i.e. adherence to the W3C DOM and event model, and
avoidance of browser-specific extensions.
Capability detection, i.e. testing for specific functionality before
it is used. In particular this is seen as the opposite of browser
other programming languages, such as encapsulation and abstraction
layers, avoidance of global variables, meaningful naming conventions,
use of appropriate design patterns, and systematic testing. Such
principles are essential to large-scale software development, but have
not been widely observed in
from a "toy" language to a tool for serious development.
^ Keith, Jeremy (2006-06-20). "Behavioral Separation".
^ Olsson, Tommy (2007-02-06). "Graceful Degradation & Progressive
^ Crockford, Douglas (2007-01-24). "The
^ Crockford, Douglas (2006-10-20). "An Inconvenient API: The Theory of
^ Aaron Gustafson. "Understanding Progressive Enhancement". 2008.
^ "Building dynamic websites". 2006-08-09. Retrieved 2010-05-18.
^ Langridge, Stuart (November 2002). "Unobtrusive DHTML, and the power
of unordered lists". Retrieved 2008-08-07.
^ Langridge, Stuart (2005). D
HTML Utopia:Modern Web Design Using
(Reference to the first edition, since it shows how the author
pioneered the concept.)
^ E.g.: Langridge, Stuart (2005-06-01). "D
HTML Utopia: Modern Web
ed.). O'Reilly & Associates. p. 241.
^ a b Heilmann, Christian (2007). "The seven rules of Unobtrusive
^ "The web standards model -
Standards Curriculum. W3C. 2014. Retrieved 16 May 2016.
ed.). O'Reilly & Associates. ISBN 0-596-10199-6.
^ "Equality Act 2010". Her Majesty’s Stationery Office. Retrieved 7
^ "Dev.Opera — Using Capability Detection". Retrieved 19 October
Google Closure Compiler
Google Web Toolkit
Microsoft Script Debugger
Microsoft Script Editor
Visual Studio Express
Visual Studio Code
Visual Studio Team Services
Comparison of layout engines
Cascading Style Sheets
Document Object Model
Active Server Pages