document.URL functionality

[alu]

Could someone explain the discrepancies within and between the stated
definitions / usage of 'document.locat ion' , '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.locati on
document.locati on.href
document.URL
window.location
window.location .href
location
location.href
The documentation:
-------------------------------

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

http://webreference.com/programming/...t/jf/column10/
"Location is not a property of the document object; its equivalent is the
document.URL property. The document.locati on property, which is a synonym
for document.URL, is deprecated. Instead, the 'location.href' or
'window.locatio n.href' property should be used."
http://www.mozilla.org/docs/dom/domr...6.html#1025116
"document.locat ion 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.locati on.href property.
However document.URL is not settable, unlike document.locati on.href."


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

IE/Win local:

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

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

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

IE/Win live:

document.locati on: 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.locati on: file:///T:/frameset/mainframe.html? test
(settable)

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

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

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

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

[Robert]

alu wrote:

Could someone explain the discrepancies within and between the stated
definitions / usage of 'document.locat ion' , 'document.URL' vs. their actual
functionality? document.locati on vs window.location These are usually just pointers to the same object.
document.URL vs document.locati on.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.locati on vs document.locati on.href

Assigning to document.locati on 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]

alu wrote:

Could someone explain the discrepancies within and between the stated
definitions / usage of 'document.locat ion' , '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.locati on 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.locati on.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.locati on = newURL
internally browser will treat it as:
document.locati on.href = newURL

This way
document.locati on = newURL
document.locati on.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]

"Robert" <ro****@noreply .x> wrote

alu wrote:
Could someone explain the discrepancies within and between the stated
definitions / usage of 'document.locat ion' , 'document.URL' vs. their actual functionality?

> document.locati on vs window.location

These are usually just pointers to the same object.

But document.locati on is deprecated.

> document.URL vs document.locati on.href

URL is readonly, href can be set

Theoretically only. The tests I posted showed otherwise.

> window.location vs location

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

That cuts down the confusion -thanks.

> document.locati on vs document.locati on.href

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

But document.locati on is deprecated.

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

That's what I was hoping.
-alu

[RobG]

VK wrote:

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.locati on.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.locati on.href.

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

[...]

--
Rob

[Michael Winter]

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

[snip]

document.URL vs document.locati on.href

URL is readonly, href can be set

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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[alu]

"VK" <sc**********@y ahoo.com> wrote

alu wrote:
Could someone explain the discrepancies within and between the stated
definitions / usage of 'document.locat ion' , '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.locati on 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.locati on
is read-only.

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.locati on.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.

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.locati on = newURL
internally browser will treat it as:
document.locati on.href = newURL

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

This way
document.locati on = newURL
document.locati on.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

[X l e c t r i c]

I too was under the impression that document.locati on 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]

X l e c t r i c wrote:

I too was under the impression that document.locati on 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]

Robert wrote:

X l e c t r i c wrote:

I too was under the impression that document.locati on
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.

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.locati on at
all (as the document will always be inaccessible cross-domain), apart
from the fact that document.locatr ion 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.