- 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>
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 UTC