That would be different behavior than what Location and HTMLAnchorElement do;
they unescape various componenents. Is the benefit worth the divergence?
As a side note, an out-of-document HTMLAnchorElement already provides most of
the functionality of this interface. Things it can't do:
-
hi
Is the word 'hash' for fragment identifiers common? I personally
prefer the attribute being called 'fragment' or 'fragmentID' over
'hash' - its the standard afaik in all the RFCs.
regards
devdatta
On 19 September 2010 15:47, João Eiras joao.ei...@gmail.com wrote:
That would be different
On Sun, Sep 19, 2010 at 5:03 PM, Devdatta Akhawe dev.akh...@gmail.com wrote:
hi
Is the word 'hash' for fragment identifiers common? I personally
prefer the attribute being called 'fragment' or 'fragmentID' over
'hash' - its the standard afaik in all the RFCs.
'hash' is the name given to the
On Fri, Sep 17, 2010 at 5:48 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth w...@adambarth.com wrote:
I've removed the searchParameters attribute from the URL interface for
the time being. We can consider adding it back at a later time.
;_;
Just
On 9/20/10 1:02 AM, Adam Barth wrote:
I've updated the document:
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en#
General comments based on a quick read (and ignoring various typos that
I figure we'll fix in due course):
1) The reference chain
1) There are now two methods for getting at the URL parameters. The
and none for setting them?
cheers
devdatta
2) The origin attribute is now readonly. Once I wired up the origin
attribute to the actual definition of how to compute the origin of a
URL, it became obvious that we don't
On Sun, Sep 19, 2010 at 10:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/20/10 1:02 AM, Adam Barth wrote:
I've updated the document:
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en#
General comments based on a quick read (and ignoring
