You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1227 lines
67 KiB
1227 lines
67 KiB
<!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> <span class="cr">»</span> </li>
|
|
<li><a href="/standards/">Standards</a> <span class="cr">»</span> </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 → </li><li>
|
|
<a href="#w3c_overview">technology topics</a>
|
|
<span class="bullet">•</span>
|
|
</li><li>
|
|
<a href="#recent">news</a>
|
|
<span class="bullet">•</span>
|
|
</li><li>
|
|
<a href="#upcomingevents">upcoming events and 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 (“ontologies”) 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 » 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 “A Local Focus for the Multilingual Web”, 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 – 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 » 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 – 16 March 2012, Luxembourg</strong>. Co-located with
|
|
the European Commission’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 » 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’ 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 » 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 “Open
|
|
Space” 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 » 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 » 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 » 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’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>— 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’t load: without
|
|
working Javascript you couldn’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’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 “fragment/anchor
|
|
identifiers”, reflecting their original use which was to jump to an
|
|
anchor within an HTML page (indicated by an
|
|
<code><a></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 (“#”) 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’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’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’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’s have a look at how hash-bang URIs are used in a couple of
|
|
sites.</p><h3>Lifehacker</h3><p>First, we’ll look at lifehacker, which is one of Gawker’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’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’t a
|
|
<code>GET</code>table resource, I’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… hash-bang URIs…)</p><p>A browser that doesn’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’d want.</p><h3>Twitter</h3><p>Now let’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’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’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’s API:</p><ul class="show_items">
|
|
<li>
|
|
<a href="http://api.twitter.com/1/statuses/show.json?include_entities=true&contributor_details=true&id=35634274132561921">
|
|
|
|
<code>
|
|
http://api.twitter.com/1/statuses/show.json?include_entities=true&contributor_details=true&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=&screen_name=unhosted">
|
|
|
|
<code>
|
|
http://api.twitter.com/1/users/lookup.json?user_id=&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’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’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’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’m not, for example using curl, Twitter just returns a
|
|
normal HTML page that contains information about the tweet that
|
|
I’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’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’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’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 “search
|
|
<code>http://example.com/</code>with the keyword X and click on the
|
|
third link” or “access
|
|
<code>http://example.org/</code>with cookie X set to Y” or “access
|
|
<code>http://example.net</code>with the HTTP header X set to Y”
|
|
simply don’t work. You can’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’s possible to link to that content (the
|
|
web being nothing without links). At the other extreme, it’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&timeline=true">
|
|
|
|
<code>
|
|
/ukpga/1985/67/section/6?view=timeline&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’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’s an infinite
|
|
variety of free-text search terms, it’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 —
|
|
changing its domain, path or query — 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’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’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’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’re talking to). From within
|
|
the app’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’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’s server. This frees users to move to
|
|
different applications without losing their data.</p><p>This doesn’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 — the content of
|
|
the site. Since this content is going to be accessed through AJAX
|
|
anyway, there’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’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’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’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’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> “MUST NOT include a fragment”. 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’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’t change, if you use hash-bang
|
|
URIs as your primary set of URIs, you’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’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’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’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 ‘Copy Link Location’ 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’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’t
|
|
make it easy to get the hashless URI from a page or from links
|
|
within the page. Of course the mapping in Twitter’s case is the
|
|
straight-forward removal of the
|
|
<code>#!</code>from the URI, but as a human it’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 —
|
|
the application’s server can send back the same HTML page
|
|
regardless of the URI used to access it; Javascript can pull
|
|
information from a URI’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’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’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 “break the web”? Well, to
|
|
me, “breaking the web” 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’s when sites lie in HTTP. It’s when they serve
|
|
up pages with the title “Not Found” with the HTTP status code
|
|
<code>200 OK</code>. It’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’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 » 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…" 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…" 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 © 2012 W3C <sup>®</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>
|