W3C home > Mailing lists > Public > www-tag@w3.org > November 2010

Re: HashInURI

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 30 Nov 2010 10:00:13 -0500 (EST)
To: ashok malhotra <ashok.malhotra@oracle.com>
cc: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <alpine.DEB.1.10.1011300940440.25839@wnl.j3.bet>
On Sun, 28 Nov 2010, ashok malhotra wrote:

> 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
> Client-side Storage.  Please review and comment.

In 2.1.3
I see
"What if the returned HTML contains an element that has the same fragment 
ID as the one being used as a client-side parameter? Who wins?"

Why is that a conflict in the general case? It is a conflict when the 
processing the same fragment by different code paths affect the same 
things.
In the case of HTML, if you have a js that scrolls the page to a place 
that is different than an existing idref, the there is a conflict.

If the fragid is used to start a video and is an existing idref, then both 
are executed in parallel.


Also I don't understand "Given that the fragment identifier leads to a 
subsequent request, who should process the error response if one should be 
raised by that subsequent request?"

It is not in the general case, but in the specific case of the CNN example 
(which is a bit misleading here, as the conneg point above is more 
general), but the fact that is it depends on how the 'subsequent request' 
is generated, by the script? by the fact that it's an automatically 
retrieved content once added in the DOM tree of the encapsulated document?


-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves
Received on Tuesday, 30 November 2010 15:00:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:29 GMT