- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 05 Jan 2010 06:17:33 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8236
Ian 'Hixie' Hickson <ian@hixie.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-01-05 06:17:32 ---
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
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 5 January 2010 06:17:34 UTC