index.html 66.7 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><!-- Generated from data/head.php, ../../smarty/{head.tpl} --><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><title>Web Architecture - W3C</title><link rel="Help" href="/Help/" /><link rel="stylesheet" href="/2008/site/css/minimum" type="text/css" media="handheld, all" /><style type="text/css" media="print, screen and (min-width: 481px)" xml:space="preserve">
/**/
@import url("/2008/site/css/advanced");
/**/
</style><link href="/2008/site/css/minimum" rel="stylesheet" type="text/css" media="handheld, only screen and (max-device-width: 480px)" /><meta name="viewport" content="width=device-width" /><link rel="stylesheet" href="/2008/site/css/print" type="text/css" media="print" /><link rel="shortcut icon" href="/2008/site/images/favicon.ico" type="image/x-icon" /><link rel="alternate" type="application/atom+xml" title="W3C News" href="news.xml" /></head><body id="www-w3-org" class="w3c_public"><div id="w3c_container">
<!-- Generated from data/mast.php, ../../smarty/{mast.tpl} -->
<div id="w3c_mast"><!-- #w3c_mast / Page top header -->
<h1 class="logo"><a tabindex="2" accesskey="1" href="/"><img src="/2008/site/images/logo-w3c-mobile-lg" width="90" height="53" alt="W3C" /></a> <span class="alt-logo">W3C</span></h1>
<div id="w3c_nav">
<form action="/Help/search" method="get" enctype="application/x-www-form-urlencoded"><!-- w3c_sec_nav is populated through js --><div class="w3c_sec_nav"><!-- --></div><ul class="main_nav"><!-- Main navigation menu --><li class="first-item"><a href="/standards/">Standards</a></li><li><a href="/participate/">Participate</a></li><li><a href="/Consortium/membership">Membership</a></li><li class="last-item"><a href="/Consortium/">About W3C</a></li><li class="search-item">
<div id="search-form"><input tabindex="3" class="text" name="q" value="" title="Search" type="text" /> <button id="search-submit" name="search-submit" type="submit"><img class="submit" src="/2008/site/images/search-button" alt="Search" width="21" height="17" /></button></div>
</li></ul></form>
</div>
</div>
<!-- /end #w3c_mast -->
<div id="w3c_main">
<div id="w3c_logo_shadow" class="w3c_leftCol"><img width="100%" height="32" alt="" src="/2008/site/images/logo-shadow" /></div>
<div class="w3c_leftCol"><h2 class="offscreen">Site Navigation</h2>
    <h3 class="category"><span class="ribbon"><a href="/standards/" title="Up to Standards">Standards <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" /></a></span></h3>
       <ul class="theme">
        <li><a href="/standards/webdesign/">Web Design and Applications</a></li>
        <li><a class="current">Web Architecture</a></li>
        <li><a href="/standards/semanticweb/">Semantic Web</a></li>
        <li><a href="/standards/xml/">XML Technology</a></li>
        <li><a href="/standards/webofservices/">Web of Services</a></li>
        <li><a href="/standards/webofdevices/">Web of Devices</a></li>
        <li><a href="/standards/agents/">Browsers and Authoring Tools</a></li>
        <li><a href="/TR/">All Standards and Drafts</a></li>
        <li><a href="/standards/about.html">About W3C Standards</a></li>
       </ul>
       <br /></div>
<div class="w3c_mainCol">
<!-- Generated from data/crumbs.php, ../../smarty/{crumbs.tpl} -->
<div id="w3c_crumbs">
       <div id="w3c_crumbs_frame">
        <ul class="bct"> <!-- .bct / Breadcrumbs -->
          <li class="skip"><a tabindex="1" accesskey="2" title="Skip to content (e.g., when browsing via audio)" href="#w3c_content_body">Skip</a></li>
          <li><a href="/">W3C</a>&#xA0;<span class="cr">&#xBB;</span>&#xA0;</li>
          <li><a href="/standards/">Standards</a>&#xA0;<span class="cr">&#xBB;</span>&#xA0;</li>
          <li class="current">Web Architecture</li>
        </ul>
     </div>
    </div>
<h1 class="title">
   <img src="/2008/site/images/theme-web-arch" alt="" />Web Architecture</h1>
<ul class="w3c_toc"><li class="toc_prefix">On this page &#x2192; </li><li>
    <a href="#w3c_overview">technology&#xA0;topics</a>
    <span class="bullet">&#x2022;</span>
  </li><li>
    <a href="#recent">news</a>
    <span class="bullet">&#x2022;</span>
  </li><li>
    <a href="#upcomingevents">upcoming&#xA0;events&#xA0;and&#xA0;talks</a>
      </li></ul>
<div id="w3c_content_body">
<div class="line">
<div class="intro">
<p>Web Architecture focuses on the foundation technologies and principles which sustain the Web, including URIs and HTTP.</p>
</div>
</div>
<!-- Generated from data/bucket_1_on_3.php, ../../smarty/{bucket_1_on_n.tpl} -->
<div id="w3c_overview">
   <div class="line">
      <div class="unit size1on3">
         <h2 class="w3c_topic">
            <a href="/standards/webarch/principles">Architecture Principles <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" />
            </a>
         </h2>
         <p class="tPadding0">
        Web Architecture principles help to design technologies by
        providing guidance and articulating the issues around some
        specific choices.
      </p>
      </div>
      <div class="unit size1on3">
         <h2 class="w3c_topic">
            <a href="/standards/webarch/identifiers">Identifiers <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" />
            </a>
         </h2>
         <p class="tPadding0">
        We share things by their names. URL, URI, IRI is the way to
        name things on the Web and manipulate them. Some additional
	addressing needs in the Web Services stack motivated some
	additional layers.
      </p>
      </div>
      <div class="unit size1on3 lastUnit">
         <h2 class="w3c_topic">
            <a href="/standards/webarch/protocols">Protocols <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" />
            </a>
         </h2>
         <p class="tPadding0">
        Protocols are the vehicle for exchanging our ideas.
	HTTP is the core protocol of the Web. W3C is also
	working on XML Protocols and SOAP in relation to Web
	Services.
      </p>
      </div>
   </div>
   <div class="line">
      <div class="unit size1on3">
         <h2 class="w3c_topic">
            <a href="/standards/webarch/metaformats">Meta Formats <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" />
            </a>
         </h2>
         <p class="tPadding0">
	  XML, the Extensible Markup Language, is used to build
	  new formats at low cost (due to widely available tools
	  to manipulate content in those new formats). RDF and OWL
	  allow people to define vocabularies (&#x201C;ontologies&#x201D;) of
	  terms as part of the Semantic Web.
      </p>
      </div>
      <div class="unit size1on3">
         <h2 class="w3c_topic">
            <a href="/standards/webarch/considerations">Protocol and Meta Format Considerations <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" />
            </a>
         </h2>
         <p class="tPadding0">
        Documents on the Web are loosely joined pieces by
        identifiers. It creates a maze of rich interactions between
        protocols and formats.
      </p>
      </div>
      <div class="unit size1on3 lastUnit">
         <h2 class="w3c_topic">
            <a href="/standards/webdesign/i18n">Internationalization <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" />
            </a>
         </h2>
         <p class="tPadding0">
        W3C has worked with the community on the internationalization
	of identifiers (IRIs) and a general character model for the
	Web.
      </p>
      </div>
   </div>
</div>
<div class="line">
<div id="recentnews" class="hierarchy hentry_list">
<h2 id="recent">News
<a title="Subscribe to News" href="http://www.w3.org/standards/webarch/news.xml" class="feedlink">
<img width="30" height="30" alt="Atom" src="/2008/site/images/icons/atom30" />
</a></h2>
<div class="hentry expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/QA/2011/12/w3c_tag_publishes_finding_on_i.html">
W3C TAG Publishes Finding on Identifying Application State</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-12-24">24
December 2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/tag/">W3C TAG
Lines</a></p>
</div>
<div class="expand_description entry-content"><p>The W3C TAG is pleased to announce the publication of a new TAG
Finding "
<a href="http://www.w3.org/2001/tag/doc/IdentifyingApplicationState">
Identifying Application State</a>."</p><p>URIs were originally used primarily to identify documents on the
Web, or with the use of fragment identifiers, portions of those
documents. As Web content has evolved to include Javascript and
similar applications that have extensive client-side logic, a need
has arisen to use URIs to identify states of such applications, to
provide for bookmarking and linking those states, etc. This finding
sets out some of the challenges of using URIs to identify
application states, and recommends some best practices. A more
formal introduction to the Finding and its scope can be found in
its
<a href="http://www.w3.org/2001/tag/doc/IdentifyingApplicationState#abstract">
abstract</a>.</p><p>The W3C TAG would like to thank Ashok Malhotra, who did much of
the analysis and editing for this work, and also former TAG member
T.V. Raman, who first brought this issue to the TAG's attention,
and who wrote earlier drafts on which this finding is based.</p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/blog/International/2011/12/14/video-links-now-available-for-limerick-multilingualweb-workshop/">
Video links now available for Limerick MultilingualWeb workshop</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-12-14">14
December 2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/International">
Internationalization Activity Blog &#xBB; w3cWebArchitecture</a></p>
</div>
<div class="expand_description entry-content"><div class="lMargin"><p>
<img src="http://www.w3.org/International/multilingualweb/images/mlw-logo.png" alt=" " />
</p></div><p>
<a href="http://www.multilingualweb.eu/documents/limerick-workshop/limerick-program">
Video recordings of speakers</a>at the MultilingualWeb workshop in
Limerick are now available, in addition to the previously uploaded
slides and IRC notes.</p><p>Entitled &#x201C;A Local Focus for the Multilingual Web&#x201D;, the workshop
surveyed and shared information about currently available best
practices and standards that can help content creators and
localizers address the needs of the multilingual Web, including the
Semantic Web. Attendees also heard about gaps that need to be
addressed, and enjoyed opportunities to network and share
information between the various different communities involved in
enabling the multilingual Web. The second day was given over to an
Open Space discussion with breakouts.</p><p>Work is under way on a summary report for the workshop, which
will be announced in due course.</p><p>Building on the success of the Madrid, Pisa and Limerick
workshops, preparations have now begun for the next workshop, to be
held in Luxembourg, at the European Commission, in March 2012. See
the
<a href="http://www.multilingualweb.eu/documents/luxembourg-workshop/luxembourg-cfp">
Call for Participation</a>.</p><p>Thanks to VideoLectures for hosting the videos.</p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/blog/International/2011/12/09/w3c-workshop-call-for-participation-the-multilingual-web-%e2%80%93-the-way-ahead/">
W3C Workshop, Call for Participation: The Multilingual Web &#x2013; The
Way Ahead</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-12-09">09
December 2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/International">
Internationalization Activity Blog &#xBB; w3cWebArchitecture</a></p>
</div>
<div class="expand_description entry-content"><div class="lMargin"><p>
<img src="http://www.w3.org/International/multilingualweb/images/mlw-logo.png" alt=" " />
</p></div><p>
<strong>15 &#x2013; 16 March 2012, Luxembourg</strong>. Co-located with
the European Commission&#x2019;s Language Technology Showcase Days, and
hosted by the Directorate-General for Translation (DGT) of the
European Commission.</p><p>The
<a href="http://www.multilingualweb.eu/">MultilingualWeb
project</a>is looking at best practices and standards related to
all aspects of creating, localizing and deploying the Web
multilingually. The project aims to raise the visibility of
existing best practices and standards and identify gaps. The core
vehicle for this is a series of four events which are planned over
two years.</p><p>After three highly successful workshops in Madrid, Pisa, and
Limerick, this final workshop in the series will continue to
investigate currently available best practices and standards aimed
at helping content creators, localizers, tools developers, and
others meet the challenges of the multilingual Web.</p><p>Participation is free. We welcome participation from both
speakers and non-speaking attendees. For more information, see the
<a href="http://www.multilingualweb.eu/register">Call for
Participation</a></p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/blog/International/2011/09/30/slides-and-irc-logs-for-limerick-multilingualweb-workshop-now-available/">
Slides and IRC logs for Limerick MultilingualWeb workshop now
available</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-09-30">30
September 2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/International">
Internationalization Activity Blog &#xBB; w3cWebArchitecture</a></p>
</div>
<div class="expand_description entry-content"><div class="lMargin"><p>
<img src="http://www.w3.org/International/multilingualweb/images/mlw-logo.png" alt=" " />
</p></div><p>The MultilingualWeb Workshop in
<a href="http://www.multilingualweb.eu/documents/limerick-workshop">
Limerick</a>was once more a success, thanks to the efforts of the
excellent speakers and the local organizers, but also thanks this
time to the participants themselves who enthusiastically took part
in the Open Space discussion organized by TAUS. This will hopefully
lead to some longer term initiatives, and most groups are already
planning to continue their discussions in Luxembourg, next Spring.
We had around 90 attendees.</p><p>The
<a href="http://www.multilingualweb.eu/documents/limerick-workshop/limerick-program">
program page</a>has now been updated to point to speakers&#x2019; slides
and to the relevant parts of the IRC logs. Links to video
recordings will follow shortly.</p><p>There will also be a page pointing to social media reports, such
as blog posts, tweets and photos, related to the workshop. If you
have any blog posts, photos, etc. online, please let Richard Ishida
know (ishida@w3.org) so that we can link to them from this
page.</p><p>A summary report of the workshop will follow a little later.</p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/blog/International/2011/09/08/registrations_are_filling_up_for_the_mul/">
Registrations are filling up for the MultilingualWeb workshop in
Limerick, 21-22 Sept.</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-09-08">08
September 2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/International">
Internationalization Activity Blog &#xBB; w3cWebArchitecture</a></p>
</div>
<div class="expand_description entry-content"><div class="lMargin"><p>
<img src="http://www.w3.org/International/multilingualweb/images/mlw-logo.png" alt=" " />
</p></div><p>
<a href="http://www.multilingualweb.eu/register">Register now</a>if
you want to ensure that you get a place.</p><p>Participation in the workshop is free, but spaces are limited.
We have another great
<a href="http://www.multilingualweb.eu/documents/limerick-workshop/limerick-program">
program</a>in place.</p><p>The keynote speaker will be Daniel Glazman, of Disruptive
Innovations, and co-chair of the W3C CSS Working Group. He is
followed by a strong line up in sessions entitled Developers,
Creators, Localizers, Machines, Users, and Policy. On the morning
of the second day Jaap van der Meer of TAUS will facilitate &#x201C;Open
Space&#x201D; style discussion sessions, where workshop participants
themselves will choose topics to discuss in several breakout
groups.</p><p>There will be a dinner reception on the evening of 21 September
(free of charge, workshop registrants only).</p><p>The
<a href="http://multilingualweb.eu/documents">MultilingualWeb
workshops</a>, funded by the European Commission and coordinated by
the W3C, look at best practices and standards related to all
aspects of creating, localizing and deploying the multilingual Web.
The workshops are successful because they attracted a wide range of
participants, from fields such as localization, language
technology, browser development, content authoring and tool
development, etc., to create a holistic view of the
interoperability needs of the multilingual Web.</p><p>This workshop is co-located with the 16th Annual LRC Conference,
and hosted by the LRC (Language Research Centre) and the University
of Limerick.</p><p>We look forward to seeing you in Limerick!</p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/blog/International/2011/07/29/initial_program_published_for_multilingu/">
Initial program published for MultilingualWeb Workshop in
Limerick</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-07-29">29 July
2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/International">
Internationalization Activity Blog &#xBB; w3cWebArchitecture</a></p>
</div>
<div class="expand_description entry-content"><div class="lMargin"><p>
<img src="http://www.w3.org/International/multilingualweb/images/mlw-logo.png" alt=" " />
</p></div><p>An
<a href="http://www.multilingualweb.eu/documents/limerick-workshop/limerick-program">
initial program has been published</a> for the upcoming W3C
MultilingualWeb workshop in
<strong>Limerick, Ireland, 21-22 September 2011</strong>.
(Co-located with the 16th Annual LRC Conference.)</p><p>The keynote speaker will be Daniel Glazman, of Disruptive
Innovations, and co-chair of the W3C CSS Working Group. He is
followed by a strong line up in sessions entitled Developers,
Creators, Localizers, Machines, Users, and Policy.</p><p>See the
<a href="http://www.multilingualweb.eu/register">Call for
Participation</a>for details about how to register for the
workshop. Participation in the workshop is free.</p><p>The
<a href="http://multilingualweb.eu/documents">MultilingualWeb
workshops</a>, funded by the European Commission and coordinated by
the W3C, look at best practices and standards related to all
aspects of creating, localizing and deploying the multilingual Web.
The workshops are successful because they attracted a wide range of
participants, from fields such as localization, language
technology, browser development, content authoring and tool
development, etc., to create a holistic view of the
interoperability needs of the multilingual Web.</p><p>We look forward to seeing you in Limerick!</p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/blog/International/2011/07/05/updated_working_group_note_working_with_/">
Updated Working Group Note: Working with Time Zones</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-07-05">05 July
2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/International">
Internationalization Activity Blog &#xBB; w3cWebArchitecture</a></p>
</div>
<div class="expand_description entry-content"><p>An updated version of
<a href="http://www.w3.org/TR/timezone/">Working with Time
Zones</a>has just been published as a Working Group Note.</p><p>Date and time values can be complex and the relationship between
computer and human timekeeping systems can lead to problems. The
working group has updated this version to contain more
comprehensive guidelines and best practices for working with time
and time zones in applications and document formats. Use cases are
provided to help choose an approach that ensures that
geographically distributed applications work well. This document
also aims to provide a basic understanding and vocabulary for
talking about time and time handling in software.</p><p>Editor: Addison Phillips, Lab126.</p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/blog/International/2011/07/04/multilingualweb_workshop_limerick_speake/">
MultilingualWeb workshop, Limerick, speaker deadline
approaching!</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-07-04">04 July
2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/International">
Internationalization Activity Blog &#xBB; w3cWebArchitecture</a></p>
</div>
<div class="expand_description entry-content"><div class="lMargin"><p>
<img src="http://www.w3.org/International/multilingualweb/images/mlw-logo.png" alt=" " />
</p></div><p>This is reminder to register for the upcoming W3C
MultilingualWeb workshop in
<strong>Limerick, Ireland, 21-22 September 2011</strong>.
(Co-located with the 16th Annual LRC Conference.)</p><p>See the
<a href="http://www.multilingualweb.eu/register">Call for
Participation</a>for details about how to register for the workshop
and propose a talk. Participation in the workshop is free.</p><p>The
<a href="http://multilingualweb.eu/documents">MultilingualWeb
workshops</a>, funded by the European Commission and coordinated by
the W3C, look at best practices and standards related to all
aspects of creating, localizing and deploying the multilingual Web.
The workshops are successful because they attracted a wide range of
participants, from fields such as localization, language
technology, browser development, content authoring and tool
development, etc., to create a holistic view of the
interoperability needs of the multilingual Web.</p><p>We look forward to seeing you in Limerick!</p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/QA/2011/05/hash_uris.html">Hash URIs</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-05-13">13 May
2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/tag/">W3C TAG
Lines</a></p>
</div>
<div class="expand_description entry-content"><p>
<em>Note: This was initially posted at
<a href="http://www.jenitennison.com/blog/node/154">
http://www.jenitennison.com/blog/node/154</a>.</em>
</p><p>There&#x2019;s been quite a bit of discussion recently about the use of

<a href="http://code.google.com/web/ajaxcrawling/docs/getting-started.html">
hash-bang URIs</a> following their
<a href="http://blogs.wsj.com/digits/2011/02/07/gawker-outage-causing-twitter-stir/">
adoption by Gawker, and the ensuing downtime of that site</a>.</p><p>Gawker have redesigned their sites, including
<a href="http://lifehacker.com/">lifehacker</a> and various others,
such that all URIs look like
<code>http://{domain}#!{path-to-content}</code>&#x2014; the
<code>#!</code>is the hash-bang. The home page on the domain serves
up a static HTML page that pulls in Javascript that interprets the
<code>path-to-content</code>and requests that content through AJAX,
which it then slots into the page. The sites all suffered an outage
when, for whatever reason, the Javascript couldn&#x2019;t load: without
working Javascript you couldn&#x2019;t actually view any of the content on
the site.</p><p>This provoked a massive cry of #FAIL (or perhaps that should be
#!FAIL) and a lot of puns along the lines of making a hash of a
website and it going bang. For analysis and opinions on both sides,
see:</p><ul class="show_items">
<li>
<a href="http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs">
Breaking the Web with hash-bangs by Mike Davies</a>
</li>
<li>
<a href="http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch">
Broken Links by Tim Bray</a>
</li>
<li>
<a href="http://blog.benward.me/post/3231388630">Hash, Bang, Wallop
by Ben Ward</a>
</li>
<li>
<a href="http://blog.tomgibara.com/post/3214368343/hash-bang-boom">
Hash-bang boom by Tom Gibara</a>
</li>
<li>
<a href="http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashbang">
Thoughts on the Hashbang by Ben Cherry</a>
</li>
<li>
<a href="http://lists.w3.org/Archives/Public/www-tag/2011Feb/0095.html">
Nathan&#x2019;s comments on www-tag</a>
</li>
</ul><p>While all this has been going on, the
<a href="http://www.w3.org/2001/tag/">TAG at the W3C</a> have been
drafting a document on
<a href="http://www.w3.org/2001/tag/2011/02/HashInURI-20110228.html">
Repurposing the Hash Sign for the New Web</a> (originally named
<a href="http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/">Usage
Patterns For Client-Side URI parameters</a>in April 2009) which
takes a rather wider view than just the hash-bang issue, and on
which they are seeking comments.</p><p>All matters of design involve weighing different choices against
some criteria that you decide on implicitly or explicitly: there is
no single right way of doing things on the web. Here, I explore the
choices that are available to web developers around hash URIs and
discuss how to mitigate the negative aspects of adopting the
hash-bang pattern.</p><h2>Background</h2><p>The semantics of hash URIs have changed over time. Look back at
<a href="http://tools.ietf.org/html/rfc1738">RFC 1738: Uniform
Resource Locators (URL)</a> from December 1994 and fragments are
hardly mentioned; when they are, they are termed &#x201C;fragment/anchor
identifiers&#x201D;, reflecting their original use which was to jump to an
anchor within an HTML page (indicated by an
<code>&lt;a&gt;</code>element with a
<code>name</code>attribute; those were the days).</p><p>Skip to
<a href="http://tools.ietf.org/html/rfc2396">RFC 2396: Uniform
Resource Identifiers (URI): Generic Syntax</a> from August 1998 and
<a href="http://tools.ietf.org/html/rfc2396#section-4.1">fragment
identifiers</a>have their own section, where it says:</p><blockquote>
<p>When a URI reference is used to perform a retrieval action on
the identified resource, the optional fragment identifier,
separated from the URI by a crosshatch (&#x201C;#&#x201D;) character, consists of
additional reference information to be interpreted by the user
agent after the retrieval action has been successfully completed.
As such, it is not part of a URI, but is often used in conjunction
with a URI.</p>
</blockquote><p>At this point, the fragment identifier:</p><ul class="show_items">
<li>is not part of the URI</li>
<li>should be interpreted in different ways based on the mime type
of the representation you get when you retrieve the URI</li>
<li>is only meaningful when the URI is actually retrieved and you
know the mime type of the representation</li>
</ul><p>Forward to
<a href="http://tools.ietf.org/html/rfc3986">RFC 3986: Uniform
Resource Identifier (URI): Generic Syntax</a>from January 2005 and
fragment identifiers are defined as part of the URI itself:</p><blockquote>
<p>The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource defined or described by those
representations.</p>
</blockquote><p>This breaks away from the tight coupling between a fragment
identifier and a representation retrieved from the web and
purposefully allows the use of hash URIs to define abstract or
real-world things, addressing
<a href="http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37">
TAG Issue 37: Definition of abstract components with namespace
names and frag ids</a> and supporting the use of
<a href="http://www.w3.org/TR/cooluris/#hashuri">hash URIs in the
semantic web</a>.</p><p>Around the same time, we have the growth of AJAX, where a
<a href="http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php">
single page interface</a> is used to access a wide set of content
which is dynamically retrieved using Javascript. The AJAX
experience could be frustrating for end users, because the back
button no longer worked (to let them go back to previous states of
their interface) and they couldn&#x2019;t bookmark or share state. And so
applications started to
<a href="http://www.contentwithstyle.co.uk/content/fixing-the-back-button-and-enabling-bookmarking-for-ajax-apps">
use hash URIs to track AJAX state</a>(that article is from June
2005, if you&#x2019;re following the timeline).</p><p>And so we get to hash-bangs. These were
<a href="http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html">
proposed by Google</a> in October 2009 as a mechanism to distinguish
between cases where hash URIs are being used as anchor identifiers,
to describe views, or to identify real-world things, and those
cases where they are being used to capture important AJAX state.
What Google proposed is for
<strong>pages where the content of the page is determined by a
fragment identifier and some Javascript</strong>to
<em>also</em>be accessible by combining the base URI with a query
parameter (
<code>_escaped_fragment_={fragment}</code>). To distinguish this
use of hash URIs from the more mundane kinds, Google proposed
starting the fragment identifier
<code>#!</code>(hash-bang). Hash-bang URIs are therefore associated
with the practice of
<a href="http://en.wikipedia.org/wiki/Transclusion">
transcluding</a>content into a wrapper page.</p><p>To summarise, hash URIs are now being used in three distinct
ways:</p><ol class="show_items">
<li>to identify parts of a retrieved document</li>
<li>to identify an abstract or real-world thing (that the document
says something about)</li>
<li>to capture the state of client-side web applications</li>
</ol><p>Hash-bang URIs are a particular form of the third of these. By
using them, the website indicates that the page uses client-side
transclusion to give the true content of the page. If it follows
Google&#x2019;s proposal, the website also commits to making that content
available through an equivalent base URI with a
<code>_escaped_fragment_</code>parameter.</p><h2>Hash-bang URIs in practice</h2><p>Let&#x2019;s have a look at how hash-bang URIs are used in a couple of
sites.</p><h3>Lifehacker</h3><p>First, we&#x2019;ll look at lifehacker, which is one of Gawker&#x2019;s sites
whose switch to hash-bangs triggered the recent spate of comments.
What happens if I link to the article
<a href="http://lifehacker.com/#!5770791/top-10-tips-and-tricks-for-making-your-work-life-better">

<code>
http://lifehacker.com/#!5770791/top-10-tips-and-tricks-for-making-your-work-life-better</code>
</a>?</p><p>The exact response to this request seems to depend on some
cookies (it didn&#x2019;t work the first time I accessed it in Firefox,
having pasted the link from another browser). If it works as
expected, in a browser that supports Javascript, the browser gets
the page at the base URI
<a href="http://lifehacker.com/">
<code>http://lifehacker.com/</code>
</a> , which includes (amongst a
<em>lot</em>of other things) a script that
<code>POST</code>s to
<a href="http://lifehacker.com/index.php?_actn_=ajax_post">
<code>http://lifehacker.com/index.php?_actn_=ajax_post</code>
</a>a request with the data:</p><pre>
<code>op=ajax_post
refId=5770791
formToken=d26bd943151005152e6e0991764e6c09
</code>
</pre><p>The response to this
<code>POST</code>is a 53kB JSON document that contains a bit of
metadata about the post and then its escaped HTML content. This
gets inserted into the page by the script, to display the post. As
this isn&#x2019;t a
<code>GET</code>table resource, I&#x2019;ve
<a href="http://www.w3.org/blog/files/lifehacker.json">attached
this file</a>to this post so you can see what it looks like.</p><p>(Honestly, I could hardly bring myself to describe this: a
<code>POST</code>to get some data? a
<code>.php</code>URL? query parameter set to
<code>ajax_post</code>? massive amounts of escaped HTML in a JSON
response? Geesh. Anyway, focus&#x2026; hash-bang URIs&#x2026;)</p><p>A browser that doesn&#x2019;t support Javascript simply gets the base
URI and is none the wiser about the actual content that was linked
to.</p><p>What about the
<code>_escaped_fragment_</code>equivalent URI,
<a href="http://lifehacker.com/?_escaped_fragment_=5770791/top-10-tips-and-tricks-for-making-your-work-life-better">

<code>
http://lifehacker.com/?_escaped_fragment_=5770791/top-10-tips-and-tricks-for-making-your-work-life-better</code>
</a> ? If you request this, you get back an
<code>200 OK</code>response which is an HTML page with the content
embedded in it. It looks just the same as the original page with
the embedded content.</p><p>What if you make up some rubbish URI, which in normal
circumstances you would expect to give a
<code>404 Not Found</code>response? Naturally, a request to the
base URI of
<code>http://lifehacker.com/</code>is always going to give a
<code>200 OK</code>response, although if you try
<a href="http://lifehacker.com/#!1234/made-up-page">
<code>http://lifehacker.com/#!1234/made-up-page</code>
</a> you get page furniture with no content in the page. A request
to
<a href="http://lifehacker.com/?_escaped_fragment_=1234/made-up-page">

<code>
http://lifehacker.com/?_escaped_fragment_=1234/made-up-page</code>
</a> results in a
<code>301 Moved Peramently</code>to the hash-bang URI
<a href="http://lifehacker.com/#!1234">
<code>http://lifehacker.com/#!1234</code>
</a> rather than the
<code>404 Not Found</code>that we&#x2019;d want.</p><h3>Twitter</h3><p>Now let&#x2019;s look at Twitter. What happens if I link to the tweet
<a href="http://twitter.com/#!/JeniT/status/35634274132561921">
<code>http://twitter.com/#!/JeniT/status/35634274132561921</code>
</a> ? Although it&#x2019;s not indicated in the
<code>Vary</code>header, Twitter determines what to do about any
requests to this hashless URI based on whether I&#x2019;m logged in or not
(based on a cookie).</p><p>If I am logged on, I get the new home page. This home page
<code>GET</code>s (through various iframes and Javascript
obfuscation) several small JSON files through Twitter&#x2019;s API:</p><ul class="show_items">
<li>
<a href="http://api.twitter.com/1/statuses/show.json?include_entities=true&amp;contributor_details=true&amp;id=35634274132561921">

<code>
http://api.twitter.com/1/statuses/show.json?include_entities=true&amp;contributor_details=true&amp;id=35634274132561921</code>
</a>: the details of the tweet</li>
<li>
<a href="http://api.twitter.com/1/statuses/35634274132561921/retweeted_by.json?count=15">

<code>
http://api.twitter.com/1/statuses/35634274132561921/retweeted_by.json?count=15</code>
</a>: details about retweets</li>
<li>
<a href="http://api.twitter.com/1/users/lookup.json?user_id=&amp;screen_name=unhosted">

<code>
http://api.twitter.com/1/users/lookup.json?user_id=&amp;screen_name=unhosted</code>
</a>: details about the twitter user
<a href="http://twitter.com/unhosted">@unhosted</a>, who was
mentioned in the tweet</li>
</ul><p>This JSON gets converted into HTML and embedded within the page
using Javascript. All the links within the page are to hash-bang
URIs and there is no way of identifying the hashless URI (unless
you know the very simple pattern that you can simply remove it to
get a static page).</p><p>If I&#x2019;m not logged on but am using a browser that understands
Javascript, the browser GETs
<code>http://twitter.com/</code>; the script in the returned page
picks out the fragment identifier and redirects (using Javascript)
to
<a href="http://twitter.com/JeniT/status/35634274132561921">
<code>http://twitter.com/JeniT/status/35634274132561921</code>
</a>.</p><p>If, on the other hand, I&#x2019;m using curl or a browser without
Javascript activated, I just get the home page and have no idea
that the original hash-bang URI was supposed to give me anything
different.</p><p>The response to the hashless URI
<a href="http://twitter.com/JeniT/status/35634274132561921">
<code>http://twitter.com/JeniT/status/35634274132561921</code>
</a> also varies based on whether I&#x2019;m logged in or not. If I am, the
response is a
<code>302 Found</code>to the hash-bang URI
<a href="http://twitter.com/#!/JeniT/status/35634274132561921">
<code>http://twitter.com/#!/JeniT/status/35634274132561921</code>
</a>. If I&#x2019;m not, for example using curl, Twitter just returns a
normal HTML page that contains information about the tweet that
I&#x2019;ve just requested.</p><p>Finally, if I request the
<code>_escaped_fragment_</code>version of the hash-bang URI
<a href="http://twitter.com/?_escaped_fragment_=/JeniT/status/35634274132561921">

<code>
http://twitter.com/?_escaped_fragment_=/JeniT/status/35634274132561921</code>
</a> the result is a
<code>301 Moved Permanently</code>redirection to the hashless URI
<a href="http://twitter.com/JeniT/status/35634274132561921">
<code>http://twitter.com/JeniT/status/35634274132561921</code>
</a>which can be retrieved as above.</p><p>Requesting a status that doesn&#x2019;t exist such as
<a href="http://twitter.com/#!/JeniT/status/1">
<code>http://twitter.com/#!/JeniT/status/1</code>
</a>in the browser results in a page that at least tells you the
content doesn&#x2019;t exist. Requesting the equivalent
<code>_escaped_fragment_</code>URI redirects to the hashless URI
<a href="http://twitter.com/JeniT/status/1">
<code>http://twitter.com/JeniT/status/1</code>
</a> . Requesting this results in a
<code>404 Not Found</code>result as you would expect.</p><h2>Advantages of Hash URIs</h2><p>Why are these sites using hash-bang URIs? Well, hash URIs in
general have four features which make them useful to client-side
applications: they provide addresses for application states; they
give caching (and therefore performance) boosts; they enable web
applications to draw data from separate servers; and they may have
SEO benefits.</p><h3>Addressing</h3><p>Interacting with the web is all about moving from one state to
another, through clicking on links, submitting forms, and otherwise
taking action on a page.</p><p>Backend databases on web servers, cookies, and other forms of
<a href="http://www.w3.org/TR/webstorage/">local storage</a> provide
methods of capturing application state, but on the web we&#x2019;ve found
that having
<strong>addresses</strong>for states is essential for a whole bunch
of things that we find useful:</p><ul class="show_items">
<li>being able to use the
<strong>back button</strong>to return to previous states</li>
<li>being able to
<strong>bookmark</strong>states that we want to return to in the
future</li>
<li>being able to
<strong>share</strong>states with other people by linking to
them</li>
</ul><p>On the web, the only addressing method that meets these goals is
the URI. Addresses that involve more than a URI, such as &#x201C;search
<code>http://example.com/</code>with the keyword X and click on the
third link&#x201D; or &#x201C;access
<code>http://example.org/</code>with cookie X set to Y&#x201D; or &#x201C;access
<code>http://example.net</code>with the HTTP header X set to Y&#x201D;
simply don&#x2019;t work. You can&#x2019;t bookmark them or link to them or put
them on the side of a bus.</p><p>Application state is complex and multi-faceted. As a web
developer, you have to work out which parts of the application
state need to be addressable through URIs, which can be stored on
the client and which on a server. They can be classified into four
rough categories; states that are associated with:</p><ol class="show_items">
<li>having particular
<strong>content</strong>in the page, such as having a particular
thread open in a webmail application</li>
<li>viewing a particular
<strong>part</strong>of the content, such as a particular message
within a thread that is being shown in the page</li>
<li>having a particular
<strong>view</strong>of the content, such as which folders in a
navigational folder list are collapsed or expanded</li>
<li>a
<strong>user-interface feature</strong>, such as whether a
drop-down menu is open or closed</li>
</ol><p>States that have different content almost certainly need to have
different URIs so that it&#x2019;s possible to link to that content (the
web being nothing without links). At the other extreme, it&#x2019;s very
unlikely that the state of a drop-down menu would need to be
captured at all. In between is a large grey area, where a web
developer might decide not to capture state at all, to capture it
in the client, in the server, or to make it addressable by giving
it a URI.</p><p>If a web developer chooses to make a state addressable through a
URI, they again have choices to make about which part of the URI to
use: should different states have different domains? different
paths? different query parameters? different fragment identifiers?
Hash URIs make states addressable that developers might otherwise
leave unaddressable.</p><p>To give some examples, on
<a href="http://www.legislation.gov.uk/">legislation.gov.uk</a>we
have decided to:</p><ul class="show_items">
<li>use the path to indicate a particular piece of content (eg
which section of an item of legislation you want to look at), for
example
<a href="http://www.legislation.gov.uk/ukpga/1985/67/section/6">
<code>/ukpga/1985/67/section/6</code>
</a></li>
<li>use query parameters for particular views on that content (eg
whether you want to see the timeline associated with the section or
not), for example
<a href="http://www.legislation.gov.uk/ukpga/1985/67/section/6?view=timeline&amp;timeline=true">

<code>
/ukpga/1985/67/section/6?view=timeline&amp;timeline=true</code>
</a></li>
<li>use fragment identifiers to jump to subsections, for example
<a href="http://www.legislation.gov.uk/ukpga/1985/67/section/6#section-6-2">

<code>/ukpga/1985/67/section/6#section-6-2</code>
</a></li>
<li>also use fragment identifiers for enhanced views (eg when
viewing a section after a text search)
<a href="http://www.legislation.gov.uk/ukpga/1985/67/section/6#text%3Dschool%20bus">

<code>/ukpga/1985/67/section/6#text%3Dschool%20bus</code>
</a></li>
</ul><p>The last of these states would probably have gone un-addressed
if we couldn&#x2019;t use a hash URI for it. The only changes that it
makes to the normal page are currently to the links to other
legislation content, so that you can go (back) to a highlighted
table of contents (though we hope to expand it to provide
in-section highlighting). Given that we rely heavily on caching to
provide the performance that we want and that there&#x2019;s an infinite
variety of free-text search terms, it&#x2019;s simply not worth the
performance cost of having a separate base URI for those views.</p><h3>Caching and Parallelisation</h3><p>Fragment identifiers are currently the only part of a URI that
can be changed without causing a browser to refresh the page
(though see the note below). Moving to a different base URI &#x2014;
changing its domain, path or query &#x2014; means making a new request on
the server. Having a new request for a small change in state makes
for greater load on the server and a worse user experience due both
to the latency inherent in making new requests and the large amount
of repeated material that has to be sent across the wire.</p><blockquote>
<p>
<em>Note: HTML5 introduces
<a href="http://www.w3.org/TR/html5/history.html#the-history-interface">
<code>pushState()</code>and
<code>changeState()</code>methods</a>in its history API that enable
a script to add new URIs to the browser&#x2019;s history without the
browser actually navigating to that page. This is new
functionality, at time of writing only supported in Chrome, Safari
and Firefox (and not completely in any of them) and unlikely to be
included in IE9. When this functionality is more widely adopted, it
will be possible to change state to a new base URI without causing
a page load.</em>
</p>
</blockquote><p>When a change of state involves simply viewing a different part
of existing content, or viewing it in a different way, a hash URI
is often a reasonable solution. It supports addressability without
requiring an extra request.</p><p>Things become fuzzier when the same base URI is used to support
different content, where transclusion is used. In these cases, the
page that you get when you request the base URI itself gets content
from the server as one or more separate AJAX requests based on the
fragment identifier. Whether this ends up giving better performance
depends on a variety of factors, such as:</p><ul class="show_items">
<li>
<strong>How large are the static portions of the page (served
directly) compared to the dynamic parts (served using
AJAX)?</strong>If the majority of the content is static as a user
moves through the site, you&#x2019;re going to benefit from only loading
the dynamic parts as state changes.</li>
<li>
<strong>Can different portions of the page be requested in
parallel?</strong>These days,
<a href="http://calendar.perfplanet.com/2010/thoughts-on-performance/">
making many small requests may lead to better performance than one
large one</a>.</li>
<li>
<strong>Can the different portions of the page be cached locally or
in a
<acronym title="content-delivery network">
CDN</acronym>?</strong>You can make best use of caches if the
rapidly changing parts of a page are requested separately from the
slowly changing parts.</li>
</ul><h3>Distributed Applications</h3><p>Hash URIs can also be very useful in distributed web
applications, where the code that is used to provide an interface
pulls in data from a separate, unconnected source. Simple examples
are mashups that use data provided by different sources, requested
using AJAX, and combine that data to create a new
visualisation.</p><p>But more advanced applications are beginning to emerge,
particularly as a reaction to silo sites such as Google and
Facebook, which lock us in to their applications by controlling our
data. From the
<a href="http://www.unhosted.org/manifesto.html">unhosted
manifesto</a>:</p><blockquote>
<p>To be unhosted, a website&#x2019;s code will need to be very ajaxy
first, so that all the servers do is store and serve json data. No
server-side processing. This is because we need to switch from
transport-layer encryption to client-side payload encryption (we no
longer necessarily trust the server we&#x2019;re talking to). From within
the app&#x2019;s source code, that should run entirely in JavaScript and
HTML5, json-objects can be stored, retrieved, sent, and received.
The user will have the same experience (we even managed to avoid
needing a plugin), but the website is unhosted in the sense that
the servers you talk to only see encrypted data and don&#x2019;t even know
which application you are running.</p>
</blockquote><p>The aim of unhosted is to separate application code from user
data. This divides servers (at least functionally) into those that
store and make available user data, and those that host
applications and any supporting code, images and so on. The
important feature of these sites is that user data never passes
through the web application&#x2019;s server. This frees users to move to
different applications without losing their data.</p><p>This doesn&#x2019;t necessarily stop the application server from doing
<em>any</em>processing, including URI-based processing; it is only
that the processing cannot be based on user data &#x2014; the content of
the site. Since this content is going to be accessed through AJAX
anyway, there&#x2019;s little motivation for unhosted applications to use
anything other than local storage and hash URIs to encode
state.</p><h3>SEO</h3><p>A final reason for using hash URIs that I&#x2019;ve seen cited is that
it increases the page rank for the base URI, because as far as a
search engine is concerned, more links will point to the same base
URI (even if in fact they are pointing to a different hash URI). Of
course this doesn&#x2019;t apply to hash-bang URIs, since the point of
them is precisely to enable search engines to distinguish between
(and access content from) URIs whose base URI is the same.</p><h2>Disadvantages of Hash URIs</h2><p>So hash-bangs can give a performance improvement (and hence a
usability improvement), and enable us to build new kinds of web
applications. So what are the arguments against using them?</p><h3>Restricted Access</h3><p>The main disadvantages of using hash URIs generally to support
AJAX state arise due to them having to be interpreted by
Javascript. This immediately causes problems for:</p><ul class="show_items">
<li>users who have chosen to turn off Javascript because:
<ul class="show_items">
<li>they have bandwidth limitations</li>
<li>they have security concerns</li>
<li>they want a calmer browser experience</li>
</ul></li>
<li>clients that don&#x2019;t support Javascript at all such as:
<ul class="show_items">
<li>search engines</li>
<li>screen scrapers</li>
</ul></li>
<li>clients that have buggy Javascript implementations that you
might not have accounted for such as:
<ul class="show_items">
<li>older browsers</li>
<li>some mobile clients</li>
</ul></li>
</ul><p>The most recent statistic I could find, about access to the
<a href="http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/">
Yahoo home page</a> indicates that up to 2% of access is from users
without Javascript (they excluded search engines). According to a
<a href="http://webaim.org/projects/screenreadersurvey3/#javascript">
recent survey</a>, about the same percentage of screen reader users
have Javascript turned off.</p><p>This is a low percentage, but if you have large numbers of
visitors it adds up. The site that I care most about,
<a href="http://legislation.gov.uk">legislation.gov.uk</a>, has
over 60,000 human visitors a day, which means that about 1,200 of
them will be visiting without Javascript. If our content were
completely inaccessible to them we&#x2019;d be inconveniencing a large
number of users.</p><h3>Brittleness</h3><p>Depending on hash-bang URIs to serve content is also brittle, as
Gawker found. If the Javascript that interprets the fragment
identifier is temporarily inaccessible or unable to run in a
particular browser, any portions of a page that rely on Javascript
also become inaccessible.</p><h3>Replacing HTTP</h3><p>There are other, less obvious, impacts which occur when you use
a hash-bang URI.</p><p>The URI held in the
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36">
HTTP Referer header</a> &#x201C;MUST NOT include a fragment&#x201D;. As
<a href="http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs">
Mike Davies noted</a>, this prevents such URIs from showing up in
server logs, and stops people from working out which of your pages
are linking to theirs. (Of course, this might be a good thing in
some circumstances; there might be aspects of the state of a page
that you&#x2019;d rather a referenced server not know about.)</p><p>You should also consider the impact on the future proofing of
your site. When a server knows the entirety of a URI, it can use
HTTP mechanisms to indicate when pages have moved, gone, or never
existed. With hash URIs, if you change the URIs you use on your
site, the Javascript that interprets the fragment identifier needs
to be able to recognise and support any redirections, missing, or
never existing pages. The HTTP status code for the wrapper page
will always be
<code>200 OK</code>, but be meaningless.</p><p>Even if your site structure doesn&#x2019;t change, if you use hash-bang
URIs as your primary set of URIs, you&#x2019;re likely to find it harder
to make a change back to using hashless URIs in the future. Again,
you will be reliant in perpetuity on Javascript routing to decipher
the hash-bang URI and redirect it to a hashless URI.</p><h3>Lack of Differentiation</h3><p>A final factor is that fragment identifiers can become
overcrowded with state information. In a purely hash-URI-based
site, what if you wanted to jump to a particular place within
particular content, shown with a particular view? The hash URI has
to encode all three of these pieces of information. Once you start
using hash-bang URIs, there is no way to indicate within the URI
(for search engines, for example) that a particular piece of the
URI can be ignored when checking for equivalence. With normal hash
URIs, there is an assumption that the fragment identifier can
basically be ignored; with hash-bang URIs that is no longer
true.</p><h2>Good Practice</h2><p>Having looked at the advantages and disadvantages, I would echo
what seems to be the general sentiment around traditional
server-based websites that use hash-bang URIs:
<strong>pages that give different content should have different
base URIs, not just different fragment identifiers</strong>. In
particular, if you&#x2019;re serving large amounts of document-oriented
content through hash-bang URIs, consider swapping things around and
having hashless URIs for the content that then transclude in the
large headers, footers and side bars that form the static part of
your site.</p><p>However, if you are running a server-based, data-driven web
application and your primary goal is a smooth user experience, it&#x2019;s
understandable why you might want to offer hash URIs for your pages
to the 98% of people who can benefit from it, even for transcluded
content. In these cases I&#x2019;d argue that you should practice
progressive enhancement:</p><ol class="show_items">
<li>support hashless URIs which
<em>do not</em>simply redirect to a hash URI, and design your site
around those</li>
<li>use hash-bang URIs as suggested by Google rather than simple
hash URIs</li>
<li>provide an easy way to get the sharable, hashless URI for a
particular page when it is accessed with a hash-bang URI</li>
<li>use hashless URIs within links; these can be overridden with
onclick listeners for those people with Javascript; using the
hashless URI ensures that &#x2018;Copy Link Location&#x2019; will give a sharable
URI</li>
<li>use the HTML5 history API where you can to add or replace the
relevant hashless URI in the browser history as state changes</li>
<li>ensure that only those visitors that both have Javascript
enabled and do not have support for HTML5&#x2019;s history API have access
to the hash-bang URIs by using Javascript to, for example:
<ul class="show_items">
<li>redirect to a hash-bang URI</li>
<li>rewrite URIs within pages to hash-bang URIs</li>
<li>attach onclick URIs to links</li>
</ul></li>
<li>support the
<code>_escaped_fragment_</code>query parameter, the result of which
should be a redirection to the appropriate hashless URI</li>
</ol><p>This is roughly what Twitter has done, except that it doesn&#x2019;t
make it easy to get the hashless URI from a page or from links
within the page. Of course the mapping in Twitter&#x2019;s case is the
straight-forward removal of the
<code>#!</code>from the URI, but as a human it&#x2019;s frustrating to
have to do this by hand.</p><p>The above measures ensure that your site will remain as
accessible as possible to all users and provides a clear migration
path as the HTML5 history API gains acceptance. The slight
disadvantage is that encouraging people to use hashless URIs for
links means that you you can no longer depend quite so much on
caching as the first page that people access in a session might be
any page (whereas with a pure hash-bang scheme everyone goes to the
same initial page).</p><p>Distributed, client-based websites can take the same measures &#x2014;
the application&#x2019;s server can send back the same HTML page
regardless of the URI used to access it; Javascript can pull
information from a URI&#x2019;s path as easily as it can from a fragment
identifier. The biggest difficulty is supporting the static page
through the
<code>_escaped_fragment_</code>convention without passing user data
through the application server. I suspect we might find a third
class of service arise: trusted third-party proxies using headless
browsers to construct static versions of pages without storing
either data or application logic. Time will tell.</p><h2>The Deeper Questions</h2><p>There are some deeper issues here regarding web architecture. In
the traditional web, there is a one-to-one correspondence between
the representation of a resource that you get in response to a
request from a server, and the content that you see on the page (or
a search engine retrieves). With a traditional hash URI for a
fragment, the HTTP headers you retrieve for the page are applicable
to the hash URI as well. In a web application that uses
transclusion, this is not the case.</p><blockquote>
<p>
<em>Note: It&#x2019;s also impossible to get metadata about hash URIs used
for real-world or abstract things using HTTP; in these cases, the
metadata about the thing can only be retrieved through interpreting
the data within the page (eg an RDF document). Whereas with the
<code>303 See Other</code>pattern for publishing linked data, it&#x2019;s
possible to use a
<code>404 Not Found</code>response to indicate a thing that does
not exist, there is no equivalent with hash URIs. Perhaps this is
what lies at the root of my feeling of unease about them.</em>
</p>
</blockquote><p>With hash-bang URIs, there are in fact three (or more) URIs in
play: the hash-bang URI (which identifies a wrapper page with
particular content transcluded within it), a base URI (which
identifies the wrapper HTML page) and one or more content URIs
(against which AJAX requests are made to retrieve the relevant
content). Requests to the base URI and the content URIs provide us
with HTTP status codes and headers that describe those particular
representations. The only way of discovering similar metadata about
the hash-bang URI itself is through the
<code>_escaped_fragment_</code>query parameter convention which
maps the hash-bang URI into a hashless URI that can be
requested.</p><p>Does this matter? Do hash-bang URIs &#x201C;break the web&#x201D;? Well, to
me, &#x201C;breaking the web&#x201D; is about breaking the implicit
socio-technical contract that we enter into when we publish
websites. At the social level, sites break the web when they
<a href="http://blog.tommorris.org/post/3512773108/channel-4-showing-the-fruits-of-content-lifecycle">
withdraw support for URIs that are widely referenced elsewhere</a> ,
hide content behind register- or pay-walls, or discriminate against
those who suffer from disabilities or low bandwidth. At the
technical level, it&#x2019;s when sites lie in HTTP. It&#x2019;s when they serve
up pages with the title &#x201C;Not Found&#x201D; with the HTTP status code
<code>200 OK</code>. It&#x2019;s when they serve non-well-formed HTML as
<code>application/xhtml+xml</code>.</p><p>These things matter because we base our own behaviour on the
contract being kept. If we cannot trust major websites to continue
to support the URIs that they have coined, how can we link to them?
If we cannot trust websites to provide accurate metadata about the
content that they serve, how can we write applications that cache
or display or otherwise use that information? On their own, pages
that use Javascript-based transclusion break both the social side
(in that they limit access to those with Javascript) and the
technical side (in that they cannot properly use HTTP) of the
contract.</p><p>But contracts do get rewritten over time. The web is constantly
evolving and we have to revise the contract as new behaviours and
new technologies gain adoption. The
<code>_escaped_fragment_</code>convention gives a life line: a
method of programmatically discovering how to access the version of
a page without Javascript, and to discover metadata about it
through HTTP. It is not a pretty pattern (I would much prefer that
the server returned a header containing a
<a href="http://tools.ietf.org/html/draft-gregorio-uritemplate-04">
URI template</a>that described how to create the hashless
equivalent of a hash-bang URI, and to have some rules about the
parsing of a hash-bang fragment identifier so that it could include
other fragments identifiers) but it has the benefit of
adoption.</p><p>In short, hash-bang URIs are an important pattern that will be
around for several years because they offer many benefits compared
to their alternatives, and because HTML5&#x2019;s history API is still a
little way off general support. Rather than banging the drum
against hash-bang URIs, we need to try to make them work as well as
they can by:</p><ul class="show_items">
<li>berating sites that use plain hash URIs for transcluded
content</li>
<li>encouraging sites that use hash-bang URIs to follow some good
practices such as those I outlined above</li>
<li>encouraging applications, such as browsers and search engines,
to automatically map hash-bang URIs into the
<code>_escaped_fragment_</code>pattern when they do not have
Javascript available</li>
</ul><p>We also need to keep a close eye on emerging patterns in
distributed web applications to ensure that these efforts are
supported in the standards on which the web is built.</p></div>
</div>
<div class="hentry closed expand_block">
<div class="headline">
<h3 class="tPadding0 bPadding0 entry-title">
<span class="expand_section">
<a class="uri url" href="http://www.w3.org/blog/International/2011/05/12/w3c_workshop_call_for_participation_a_lo/">
W3C Workshop, Call for Participation: A Local Focus for the
Multilingual Web</a>
</span>
</h3>
<p class="date">
<abbr class="published" title="2011-05-12">12 May
2011</abbr>
</p>
<p class="author vcard">from
<a class="fn org url" href="http://www.w3.org/blog/International">
Internationalization Activity Blog &#xBB; w3cWebArchitecture</a></p>
</div>
<div class="expand_description entry-content"><div class="lMargin"><p>
<img src="http://www.w3.org/International/multilingualweb/images/mlw-logo.png" alt=" " />
</p></div><p>
<strong>21-22 September 2011, Limerick, Ireland</strong>.
Co-located with the 16th Annual LRC Conference and hosted by the
University of Limerick.</p><p>The
<a href="http://www.multilingualweb.eu/">MultilingualWeb
project</a>is looking at best practices and standards related to
all aspects of creating, localizing and deploying the Web
multilingually. The project aims to raise the visibility of
existing best practices and standards and identify gaps. The core
vehicle for this is a series of four events which are planned for
the coming two years.</p><p>After two highly successful workshops in Madrid and Pisa, this
workshop will continue to investigate currently available best
practices and standards aimed at helping content creators,
localizers, tools developers, and others meet the challenges of the
multilingual Web.</p><p>Participation is free. We welcome participation from both
speakers and non-speaking attendees. For more information, see the
<a href="http://www.multilingualweb.eu/documents/limerick-workshop/limerick-cfp">
Call for Participation</a></p></div>
</div>
</div>
</div>
<!-- End news -->
<div class="line">
<div class="w3c_events_talks">
<div class="line">
<div class="unit size1on2">
<div id="upcomingtalks" class="w3c_upcoming_talks"><h2 class="category"><a title="More Talks&#x2026;" href="/2007/11/Talks/Web_Architecture.html">
	      Talks and Appearances
	      <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" /></a></h2><p>None. See <a href="/Talks/">full list of W3C Talks and Appearances</a>.</p></div>
</div>
<div class="unit size1on2 lastUnit">
<div id="upcomingevents" class="w3c_upcoming_events">
  <h2 class="category">
      <a title="More Events&#x2026;" href="/participate/eventscal.html">
      Events
      <img src="/2008/site/images/header-link" alt="Header link" width="13" height="13" class="header-link" />
    </a>
  </h2>
 <p>None. See <a href="/participate/eventscal.html">full list of W3C Events</a>.</p>


</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div><!-- Generated from data/footer.php, ../../smarty/{footer-block.tpl} --><div id="w3c_footer">
<div id="w3c_footer-inner">
<h2 class="offscreen">Footer Navigation</h2>
<div class="w3c_footer-nav">
<h3>Navigation</h3>
<ul class="footer_top_nav"><li><a href="/">Home</a></li><li><a href="/standards/">Standards</a></li><li><a href="/participate/">Participate</a></li><li><a href="/Consortium/membership">Membership</a></li><li class="last-item"><a href="/Consortium/">About W3C</a></li></ul>
</div>
<div class="w3c_footer-nav">
<h3>Contact W3C</h3>
<ul class="footer_bottom_nav"><li><a href="/Consortium/contact">Contact</a></li><li><a accesskey="0" href="/Help/">Help and FAQ</a></li><li><a href="/Consortium/sponsor/">Sponsor / Donate</a></li><li><a href="/Consortium/siteindex">Site Map</a></li><li>
<address id="w3c_signature"><a href="mailto:site-comments@w3.org">Feedback</a> (<a href="http://lists.w3.org/Archives/Public/site-comments/">archive</a>)</address>
</li></ul>
</div>
<div class="w3c_footer-nav">
<h3>W3C Updates</h3>
<ul class="footer_follow_nav"><li><a href="http://twitter.com/W3C" title="Follow W3C on Twitter"><img src="/2008/site/images/twitter-bird" alt="Twitter" width="78" height="83" class="social-icon" /></a> <a href="http://identi.ca/w3c" title="See W3C on Identica"><img src="/2008/site/images/identica-logo" alt="Identica" width="91" height="83" class="social-icon" /></a></li></ul>
</div>
<!-- #footer address / page signature -->
<p class="copyright">Copyright &#xA9; 2012 W3C <sup>&#xAE;</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>) <a href="/Consortium/Legal/ipr-notice">Usage policies
apply</a>.</p>
</div>
</div><!-- /end #footer --><!-- Generated from data/scripts.php, ../../smarty/{scripts.tpl} --><div id="w3c_scripts"><script type="text/javascript" src="/2008/site/js/main" xml:space="preserve"><![CDATA[
//
<!-- -->
//
]]></script></div></body></html>