Anne van Kesteren wrote:
On Sun, 25 May 2008 20:40:48 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Agreed. We have in the past said that in the cases where it doesn't
seem like the web is depending on a certain behavior one way or the
other do what is most useful. I don't really think it matters much if
null is treated as 'remove' or as 'do nothing', but appending 'null'
seems pretty useless in pretty much all cases.
It's pretty common behavior for a lot of APIs though Firefox seems to do
it differently from everyone else quite often if I remember correctly.
Yes, we never convert null to "null" since per spec null is a valid
DOMString, so there should be no need to convert it at all.
We shouldn't let what webidl says dictate what we do one way or the
other. It's just a spec for the idl language, not a recommendation for
how interfaces should behave.
null/undefined are not really part of the setRequestHeader() method. We
just need to deal with them somehow and doing what similar APIs do in
such cases makes sense.
Agreed, but I think defining them to turn null into "null" is a weird
given that we can just leave it as null. If we should turn it into
anything it should be the empty string as that seems to me as what makes
sense.
FWIW I think the webidl spec should be changed here, but i'll raise
that in a thread for that spec.
I think it makes sense for Web IDL to specify the most common behavior
as default.
Agreed, but I think we disagree on what "most common behaviour" is :)
/ Jonas
