[whatwg] Fwd: Don't throw for HTMLInputElement.files

[Jonas Sicking]

On Tue, Jun 15, 2010 at 4:01 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> Jonas suggested I fwd these comments to the list.
>
> ---------- Forwarded message ----------
> From: Garrett Smith <dhtmlkitchen at gmail.com>
> Date: Tue, 15 Jun 2010 15:04:16 -0700
> Subject: Re: [whatwg] Don't throw for HTMLInputElement.files
> To: Jonas Sicking <jonas at sicking.cc>
>
> On 6/15/10, Jonas Sicking <jonas at sicking.cc> wrote:
>> Hi All,
>>
>> Currently HTMLInputElement.files throws if accessed when type !=
>> "file". I think it would be better to return null or an empty list. We
>> generally try to avoid throwing in general, and in particular things
>> like HTMLInputElement.checked doesn't throw even if the value doesn't
>> apply. So for consistency I don't think HTMLInputElement.files should
>> throw either.
>>
>
> The calling code can perform a check - if(x.type == "file") -. I can't
> see a good reason for not having x.files be designed to return
> `undefined`. Besides, throwin an error there is totally inconsistent
> with other state-specific properties (like `valueAsNumber` or
> `valueAsDate` etc). On those, both of those are needless complexity
> anyway; +inp.value is a common-use alternative to valueAsNumber and
> valueAsDate can be gotten by using the Date constructor, which,
> although buggy in Firefox, is specified in ES5 to parse a superset of
> the ISO8601 formats in HTML5.
>
>> Another reason not to throw is that people every so often enumerate
>> all the IDL attributes of element using |for each| constructs in
>
> The for-in loop. |for each| is a spidermonkey syntax extension. It is
> not widely implemented and nobody uses it.

Yeah, my bad. I meant a |for (i in ...)| loop. This doesn't change
anything about my argument though.

/ Jonas