document.URL functionality

[alu]

Could someone explain the discrepancies within and between the stated
definitions / usage of 'document.location' , 'document.URL' vs. their actual
functionality?
Should they be read-only when in fact they are not?
Is 'document.URL' also deprecated, and should therefore never be used?
What is the last word re: the proper syntax for returning and setting the
current window's location?
We have:
document.location
document.location.href
document.URL
window.location
window.location.href
location
location.href


The documentation:
-------------------------------

http://www.faqts.com/knowledge_base/view.phtml/aid/6702
"document.location is deprecated and should never be used.
Instead, either use document.URL or window.location.href."

http://webreference.com/programming/javascript/jf/column10/
"Location is not a property of the document object; its equivalent is the
document.URL property. The document.location property, which is a synonym
for document.URL, is deprecated. Instead, the 'location.href' or
'window.location.href' property should be used."


http://www.mozilla.org/docs/dom/domref/dom_doc_ref26.html#1025116
"document.location works the same as document.URL. Both are read-only
properties unlike window.location, which can be set."
"URL is a replacement for the DOM Level 0 document.location.href property.
However document.URL is not settable, unlike document.location.href."




Actual test results:
------------------------------

IE/Win local:

document.location: file:///T:/frameset/mainframe.html?test (settable)

document.URL: file://T:\frameset\mainframe.html (settable -
note lack of query string and backslashes)

------------------------------

IE/Win live:

document.location: http://home.prims.com/x/mainframe.html?test
(settable)

document.URL: http://home.prims.com/x/mainframe.html?test
(settable - note query string appears)

------------------------------

FF/Win local:

document.location: file:///T:/frameset/mainframe.html?test
(settable)

document.URL: file:///T:/frameset/mainframe.html?test
(read-only)


FF/Win live:

-----------------------------

document.location: http://home.prims.com/x/mainframe.html?test
(settable)

document.URL: http://home.prims.com/x/mainframe.html?test
(read-only)

 

[Robert]

Could someone explain the discrepancies within and between the stated
definitions / usage of 'document.location' , 'document.URL' vs. their actual
functionality?

document.location vs window.location

These are usually just pointers to the same object.

document.URL vs document.location.href

URL is readonly, href can be set

window.location vs location

location refers to window.location if no other in scope.
Just like alert refers to window.alert.

document.location vs document.location.href

Assigning to document.location will (usually) also update the href
property. Therefore there is not really any difference.

The most cautious way to set the location is probably through
window.location.href

 

[VK]

Could someone explain the discrepancies within and between the stated
definitions / usage of 'document.location' , 'document.URL' vs. their actual
functionality?
Should they be read-only when in fact they are not?

Originally (LiveScript - JavaScript 1.1) window.location was read-only
and document.location was read-write. Now they both are read-write.
This definitely makes easier to manupulated framed sites.

Is 'document.URL' also deprecated, and should therefore never be used?

It is not deprecated, just an opposite it is rather newly introduced as
substitution for document.location.href = newURL.
But I would not suggest to use it as being one of ugly and unwanted
children of W3.

What is the last word re: the proper syntax for returning and setting the
current window's location?

location is not a property. It's an object with a set of read-write
string properties:
href : the whole URL string
protocol : http:, shttp:, file: etc.
host : host name and port number (if presented)
hostname : host name (if no post number, then == host)
port : port number
pathname : all between host and including the actual http page
hash : anchor mark (what follows # sign)
search : CGI request (what follows ? sign)

All these parts can be read or change independently.
The default property of location is href. So if you assign:
document.location = newURL
internally browser will treat it as:
document.location.href = newURL

This way
document.location = newURL
document.location.href = newURL
document.URL = newURL
are alias of the same action.

From the other side location is in use since the beginning of script

and it allows you fine-graned access/change of of the URL parts.
document.URL is a rather late invention of someone bored mind. It
doesn't give you anything extra, but it takes out a lot. Just forget it.

 

[alu]

These are usually just pointers to the same object.

But document.location is deprecated.

URL is readonly, href can be set

Theoretically only. The tests I posted showed otherwise.

location refers to window.location if no other in scope.
Just like alert refers to window.alert.

That cuts down the confusion -thanks.

Assigning to document.location will (usually) also update the href
property. Therefore there is not really any difference.

But document.location is deprecated.

The most cautious way to set the location is probably through
window.location.href

That's what I was hoping.
-alu

 

[alu]

Originally (LiveScript - JavaScript 1.1) window.location was read-only
and document.location was read-write. Now they both are read-write.
This definitely makes easier to manupulated framed sites.

Not according to the Mozilla documentation, which states document.location
is read-only.

It is not deprecated, just an opposite it is rather newly introduced as
substitution for document.location.href = newURL.
But I would not suggest to use it as being one of ugly and unwanted
children of W3.

I agree, it's behaviour is flakey at best.

location is not a property. It's an object with a set of read-write
string properties:
href : the whole URL string
protocol : http:, shttp:, file: etc.
host : host name and port number (if presented)
hostname : host name (if no post number, then == host)
port : port number
pathname : all between host and including the actual http page
hash : anchor mark (what follows # sign)
search : CGI request (what follows ? sign)

All these parts can be read or change independently.
The default property of location is href. So if you assign:
document.location = newURL
internally browser will treat it as:
document.location.href = newURL

But document.location is deprecated - why use it at all?

This way
document.location = newURL
document.location.href = newURL
document.URL = newURL
are alias of the same action.

In practice they are definitely not the same. Check the tests I posted.

From the other side location is in use since the beginning of script
and it allows you fine-graned access/change of of the URL parts.
document.URL is a rather late invention of someone bored mind. It
doesn't give you anything extra, but it takes out a lot. Just forget it.

Excellent.
-alu

 

[RobG]

alu wrote:
[...]

Is 'document.URL' also deprecated, and should therefore never be used?

It is not deprecated, just an opposite it is rather newly introduced as
substitution for document.location.href = newURL.
But I would not suggest to use it as being one of ugly and unwanted
children of W3.

document.URL was in DOM 1, so it's no newer than DOM itself. You are
quite correct that it's not depreciated, however it is readonly and
therefore not really a substitute for document.location.href.

<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-46183437>

[...]

 

[Michael Winter]

On 03/08/2005 15:07, alu wrote:

[snip]

Theoretically only. The tests I posted showed otherwise.

The URL property /is/ read-only and should be treated as such,
irrespective of whether some browsers treat it otherwise. Use the global
location object to assign new URLs.

[snip]

Mike

 

[X l e c t r i c]

I too was under the impression that document.location was deprecated, or
at least not as compatible as window.location.

How do I know when to use either window.location or window.location.href
?

Later, Art.

 

[Robert]

I too was under the impression that document.location was deprecated, or
at least not as compatible as window.location.

How do I know when to use either window.location or window.location.href
?

Always use window.location.href
Although I do not know any case in which window.location does not work.

 

[Richard Cornford]

Always use window.location.href
Although I do not know any case in which window.location
does not work.

There were some versions of IE 4 that did not respond well to
assignments to location, but did work with assignments to location.href.
On the other hand, some early releases of IE 6 did not respond to
assignments to location.href, where they would work with assignments
directly to location.

Generally, I would go for assigning to location, and reading URLs form
location.href. That would be particularly true when trying to navigate
other frames or windows where the content may be from another domain
(less chance of provoking cross-domain security restrictions, and that
is also the main practical reason for never using document.location at
all (as the document will always be inaccessible cross-domain), apart
from the fact that document.locatrion is not as widely implemented as
the location property of the global/window object.).

Whether location needs additional qualification as a property of the
window object depends on the current scope. The additional property
look-up will add a (very) slight overhead, but avoid an unqualified
identifier resulting in an error in environments that do not provide a
location object (though nobody has ever been able to identify such an
environment). I would only qualify the location in cross-frame
scripting, where the qualifier would be something other than 'window'.

Richard.