--- title: HTMLHyperlinkElementUtils.pathname slug: Web/API/HTMLHyperlinkElementUtils/pathname tags: - HTMLHyperlinkElementUtils.pathname translation_of: Web/API/HTMLHyperlinkElementUtils/pathname original_slug: Web/API/URLUtils/pathname ---

{{ApiRef("URL API")}}

HTMLHyperlinkElementUtils.pathname 属性是一个 {{domxref("USVString")}} ,其中包含一个初始的'/'后跟URL的路径。

Syntax

string = object.pathname;
object.pathname = string;

Examples

// Let's an <a id="myAnchor" href="https://developer.mozilla.org/en-US/docs/HTMLHyperlinkElementUtils.pathname"> element be in the document
var anchor = document.getElementById("myAnchor");
var result = anchor.pathname; // Returns:'/en-US/docs/HTMLHyperlinkElementUtils.pathname'

Specifications

Specification Status Comment
{{SpecName('HTML WHATWG', '#dom-hyperlink-pathname', 'HTMLHyperlinkElementUtils.pathname')}} {{Spec2('HTML WHATWG')}} Initial definition.

Browser compatibility

{{ CompatibilityTable() }}

Feature Chrome Edge Firefox (Gecko) Internet Explorer Opera Safari
Basic support {{CompatVersionUnknown}} [1] {{CompatNo}} [2] {{CompatGeckoDesktop("22")}} [3][4] {{CompatNo}} [2] {{CompatNo}} [2] {{CompatNo}} [2]
Feature Android Webview Chrome for Android Edge Firefox Mobile (Gecko) IE Mobile Opera Mobile Safari Mobile
Basic support {{CompatVersionUnknown}} [1] {{CompatVersionUnknown}} [1] {{CompatNo}} [2] {{CompatGeckoMobile("22")}} [3][4] {{CompatNo}} [2] {{CompatNo}} [2] {{CompatNo}} [2]

[1] Starting in Chrome 52, this property was moved to {{domxref('URL')}}

[2] Though not grouped in a single abstract interface, this method is directly available on the interfaces that implement it, if this interface is supported.

[3] From Gecko 22 to Gecko 44, this property was on the URLUtils mixin. It has been moves either on the HTMLHyperlinkElementUtils mixin, or directly on the interface.

[4] Before Firefox 53, the pathname and search HTMLHyperLinkElementUtils properties returned the wrong parts of the URL. For example, for a URL of http://z.com/x?a=true&b=false, pathname would return "/x?a=true&b=false" and search would return "", rather than "/x" and "?a=true&b=false" respectively. This has now been fixed.

See also