- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 10 Feb 2011 05:40:26 -0500 (EST)
- To: Karl Dubost <karld@opera.com>
- cc: "ashok.malhotra@oracle.com Malhotra" <ashok.malhotra@oracle.com>, "www-tag@w3.org List" <www-tag@w3.org>
On Wed, 9 Feb 2011, Karl Dubost wrote:
>
> Le 8 févr. 2011 à 19:09, Karl Dubost a écrit :
>> Le 28 nov. 2010 à 15:02, ashok malhotra a écrit :
>>> I just checked in http://www.w3.org/2001/tag/2010/11/HashInURI
>>> This is a combination of Raman's hash-in-url writeup and my earlier writeup on
>> Yet another article about Hash in URI
>> http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs
>
> I wonder if these links have a better place than the list
>
> http://blog.new-bamboo.co.uk/2011/2/2/degradable-javascript-applications-using-html5-pushstate
>
> Using the location hash to keep track of current
> page state and enable back button navigation is more
> and more common with large, full featured, client
> side JavaScript apps. Whilst the behaviour this
> gives is definitely an improvement to the user
> experience, implementing this with the location hash
> has some shortcomings.
>
> Thankfully, as with everything else on the web,
> HTML5 is here to solve all your problems, with two
> methods and an event, pushState, replaceState &
> onpopstate.
Yes, I wanted HashInURI to become more "what to do and more important how
to avoid" document when using hash in URI.
The example of twitter, where the search is using a hash sign
(http://twitter.com/#search?q=foo) is a "good" example of the new syndrom
"everything is done in js, and I expose only one resource to the world",
with lots of consequences, including on caching. Another instance of "I
expose only one cgi for the whole site" or "one flash page that contains
the whole website", or even "one service enpoint in WS-* world".
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Thursday, 10 February 2011 10:40:31 UTC