On May 25, 2008, at 11:40 AM, Jonas Sicking wrote:
Julian Reschke wrote:
Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke <[EMAIL PROTECTED]
> wrote:
Anne van Kesteren wrote:
Per the updated specification which uses Web IDL IE and Safari
are conformant here. (null and undefined are simply stringified.)
Not terrible useful, I would say. Is that something we have to
live with because of the IDL definition???
It matches two implementations and is the default behavior for
null/undefined when passed to something that accepts a string.
Apparently existing content does not rely on it (FF gets away with
implementing something that IMHO makes *much* more sense). So why
standardize it at all, or, when doing so, select something that
doesn't make sense in practice?
Or are you claiming that people who set a header to null *really*
want the specified behaviour?
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.
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.
Web IDL can be used to specify all sorts of different behaviors for
null and undefined. Its default setting is not really materially
relevant. To change the spec behavior we would just have to change the
IDL in the XHR spec.
I agree it is unlikely that content deeply depends on behavior for
null or undefined, but it might be worth doing some testing to
quantify this.
Regards,
Maciej
