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 avail
> 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.
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 diff
On Fri, 27 Mar 2009 21:53:48 -0400, Boris Zbarsky 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 sense to tr
My MSIE (7) converts both http:foo and http:/foo to http://foo/. Same goes
for ftp while nntp:foo is passed intact to MSOE which reports bad URL format
error.
Chris
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 sense to treat them differently to me.
There are big scary comments in the Gecko
On Fri, 27 Mar 2009 17:40:08 -0400, Boris Zbarsky 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 o
Anne van Kesteren wrote:
On Fri, 27 Mar 2009 22:40:08 +0100, Boris Zbarsky 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 wo
On Fri, 27 Mar 2009 22:40:08 +0100, Boris Zbarsky 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 Opera.
--
Anne v
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 t
On Fri, 27 Mar 2009 14:14:35 -0400, Boris Zbarsky 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
> then the path
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;
> alert(a.ho
On Fri, Mar 27, 2009 at 11:02 AM, Kristof Zelechovski
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 instead.
/ Jonas
Instead of setting the host name of a hyperreference to null, use the host
name (of the base) of the current document instead.
HTH,
Chris
On Fri, Mar 27, 2009 at 4:55 AM, Kartikaya Gupta
wrote:
> On Thu, 26 Mar 2009 23:01:34 -0400, Biju 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
On Thu, 26 Mar 2009 23:01:34 -0400, Biju 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 why it happening
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 s
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 which has base URI
> "http://example.com/"; and you set anchor.hash on that anchor to "baz",
> then the attribute val
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 specif
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 +010
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
update
21 matches
Mail list logo
