On Thu, 26 Mar 2009, Kartikaya Gupta wrote:
It seems that major browsers all support URL decomposition on
HTMLAnchorElement, but this doesn't seem to be stated anywhere in the
HTML5 spec. The jQuery/tabs library seems to depend on this
(specifically, on the hash property) being available.
On Fri, 27 Mar 2009 21:53:48 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
Kartikaya Gupta wrote:
The empty string falls under the anything else case in my suggestion
above and would work as you expect.
Null and empty string should, imo, have the same behavior here. It
doesn't make
Kartikaya Gupta wrote:
Do you agree that null and empty string should behave differently for search and
hash?
No, not really. Are they treated differently in current UAs (past null
being treated as null, possibly)?
To me, it doesn't make sense to treat null and the empty string
Interestingly, it looks like Opera doesn't support the hostname setter
at all. Safari ignores the call in this case. I don't have IE to test
offhand.
True. Opera currently does not support setting these values separately.
On Thu, 26 Mar 2009 23:01:34 -0400, Biju bijumaill...@gmail.com wrote:
On Thu, Mar 26, 2009 at 5:26 PM, Kartikaya Gupta
This behavior seems rather inconsistent and possibly buggy.
At first look I also thought it is inconsistent
But later I found Firefox is very consistent.
I think reason
On Fri, Mar 27, 2009 at 4:55 AM, Kartikaya Gupta
lists.wha...@stakface.com wrote:
On Thu, 26 Mar 2009 23:01:34 -0400, Biju bijumaill...@gmail.com wrote:
On Thu, Mar 26, 2009 at 5:26 PM, Kartikaya Gupta
This behavior seems rather inconsistent and possibly buggy.
At first look I also thought
On Fri, Mar 27, 2009 at 11:02 AM, Kristof Zelechovski
giecr...@stegny.2a.pl wrote:
Instead of setting the host name of a hyperreference to null, use the host
name (of the base) of the current document instead.
That seems pretty arbitrary. How about throwing or setting the whole
href to null
Kartikaya Gupta wrote:
I was trying different things to see what happens and came across some
particularly weird behavior in Gecko/2009021910 Firefox/3.0.7:
var a = document.createElement('a');
a.setAttribute('href', 'http://example.org:123/foo?bar#baz');
a.hostname = null;
On Fri, 27 Mar 2009 14:14:35 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
This case is more fun. It's an unknown scheme, so it's assumed to be a
no-authority non-hierarchical scheme and the URI is parsed that way.
This does cause issues, since RFC 3986 says that i there is no authority
Kartikaya Gupta wrote:
For unknown schemes, if the authority starts with //, doesn't it make sense to assume that the
scheme allows an authority? I would assume that for an unknown scheme, the generic URI syntax in RFC3986
should be followed, which would interpret the stuff between // and the
On Fri, 27 Mar 2009 22:40:08 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
This is an option, but it's not obviously correct, just as it's not
obviously correct (and in fact would break pages) to parse
http:foo.com/ without an authority.
Which pages would break? That URL does not work in
Anne van Kesteren wrote:
On Fri, 27 Mar 2009 22:40:08 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
This is an option, but it's not obviously correct, just as it's not
obviously correct (and in fact would break pages) to parse
http:foo.com/ without an authority.
Which pages would break? That
On Fri, 27 Mar 2009 17:40:08 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
Kartikaya Gupta wrote:
- Attempts to set pathname to null should throw, since the path is a
required
component of a URI. Setting pathname to anything else should be allowed
and
should update the path component
It seems that major browsers all support URL decomposition on
HTMLAnchorElement, but this doesn't seem to be stated anywhere in the HTML5
spec. The jQuery/tabs library seems to depend on this (specifically, on the
hash property) being available. Could the HTMLAnchorElement interface be
updated
Browsers also support partially setting each of the url fields separately,
although error handling between all of them is very inconsistent.
Note: if you specify this behavior, then you need to specify what happens for
http:, https:, data:, mailto: and unknown:
On Thu, 26 Mar 2009 19:32:46
João Eiras wrote:
Browsers also support partially setting each of the url fields separately,
although error handling between all of them is very inconsistent.
Note: if you specify this behavior, then you need to specify what happens for
http:, https:, data:, mailto: and unknown:
If you
Boris wrote:
If you specify the setters then you also need to specify how this
affects the value of the href attribute in the DOM. For example, in
Gecko if you have an a href=foo#bar which has base URI
http://example.com/; and you set anchor.hash on that anchor to baz,
then the attribute
On Thu, Mar 26, 2009 at 5:26 PM, Kartikaya Gupta
This behavior seems rather inconsistent and possibly buggy.
At first look I also thought it is inconsistent
But later I found Firefox is very consistent.
I think reason why it happening like that is because Firefox clean up
URL by removing extra
18 matches
Mail list logo
