This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8236 - 1) why a query is stored in the `search' attribute and a URL fragment is stored in the `fragment' attribute? The naming is a bit confusing. 2) Why the is no restrictions for the `port' attribute: an integer in a range [0-65535]; 3) The getter condition fo
Summary: 1) why a query is stored in the `search' attribute and a URL fragment is stor...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords: NE
Depends on:
Blocks:
 
Reported: 2009-11-07 22:30 UTC by contributor
Modified: 2010-10-04 14:45 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2009-11-07 22:30:57 UTC 
Section: http://www.whatwg.org/specs/web-apps/current-work/#interfaces-for-url-manipulation

Comment:
1) why a query is stored in the `search' attribute and a URL fragment is stored in the `fragment' attribute? The naming is a bit confusing. 2) Why the is no restrictions for the `port' attribute: an integer in a range [0-65535]; 3) The getter condition for the `port' attribute is unclear – how a port may be hierarchical and contain server-based naming authority? 4) The setter condition for the `port' attribute (“Remove any characters in the new value that are not in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9). If the resulting string is empty, set it to a single U+0030 DIGIT ZERO character (0).”) is extra and complex and may introduce ambiguities. For example, if the assigning string is `a1b2c3', then, according to the setter preprocessor for the `port' attribute, the string `123' will be assigned. Proposal: make `port' as a plain number of type short. 5) Why there is no restrictions for the `host' attribute: pattern like `^[a-Z0-9][-.a-Z0-9]{0,63}$ without the trailing `-'? 6) It is unclear how URI shall be represented, especially in the `host' attribute: either as it is (like `www.смешно.com') or in IDN representation (like `www.xn—e1aneel8b.com')? 7) The restrictions for the `host' attribute (loot at the setter condition: “The new value is not the empty string ”) makes it impossible to use data URL (like `data:,A%20a%20test'). 8) Why usre@passwords attributes are absent? Though, it is not encouraged to use them in URL, the are still in URL spec. 9) Proposal: the list of supported protocols may be defined explicitly maybe as a constants (HTTP, FTP, MAIL, HTTPS etc.)

Posted from: 84.215.175.98
Comment 1 contributor 2010-01-05 06:14:12 UTC 
Checked in as WHATWG revision r4471.
Check-in comment: Make location.port parsing more like IE8's.
http://html5.org/tools/web-apps-tracker?from=4470&to=4471
Comment 2 Ian 'Hixie' Hickson 2010-01-05 06:17:32 UTC 
Please file one bug per issue.

> 1) why a query is stored in the `search' attribute and a URL fragment is stored
> in the `fragment' attribute? The naming is a bit confusing.

We can't change this, it's just what browsers implement.

> 2) Why the is no
> restrictions for the `port' attribute: an integer in a range [0-65535];

Fixed. The spec now matches IE8 (the other browsers did comparatively less sane things).

> 3) The
> getter condition for the `port' attribute is unclear – how a port may be
> hierarchical and contain server-based naming authority?

Where does it talk about the _port_ being hierarchical?

> 4) The setter condition
> for the `port' attribute (“Remove any characters in the new value that are
> not in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9). If the
> resulting string is empty, set it to a single U+0030 DIGIT ZERO character
> (0).”) is extra and complex and may introduce ambiguities. For example, if
> the assigning string is `a1b2c3', then, according to the setter preprocessor
> for the `port' attribute, the string `123' will be assigned. Proposal: make
> `port' as a plain number of type short.

I've made the spec match IE (which was actually more complicated than what was there before, unfortunately).

> 5) Why there is no restrictions for the
> `host' attribute: pattern like `^[a-Z0-9][-.a-Z0-9]{0,63}$ without the trailing
> `-'?

What the spec describes now appears to be a superset of what browsers do. If there are compatibility reasons for adding restrictions, I would be happy to update the spec, but otherwise it feels safer all around to just not have any.

> 6) It is unclear how URI shall be represented, especially in the `host'
> attribute: either as it is (like `www.смешно.com') or in IDN
> representation (like `www.xn—e1aneel8b.com')?

This depends on the underlying string and on the parsing algorithms, and is out of scope of the HTML5 spec as far as I can tell.

> 7) The restrictions for the
> `host' attribute (loot at the setter condition: “The new value is not the
> empty string ”) makes it impossible to use data URL (like
> `data:,A%20a%20test').

There's no host component in a data: URL, since it's not a hierarchical URL scheme.

> 8) Why usre@passwords attributes are absent? Though, it
> is not encouraged to use them in URL, the are still in URL spec.

They are not supported by browsers.

> 9) Proposal:
> the list of supported protocols may be defined explicitly maybe as a constants
> (HTTP, FTP, MAIL, HTTPS etc.)

Could you elaborate on this suggestion?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given above
Rationale: see comments above