- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 15 Nov 2013 15:24:48 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Ian Hickson <ian@hixie.ch>, Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Fri, Nov 15, 2013 at 3:14 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Fri, Nov 15, 2013 at 2:31 PM, Ian Hickson <ian@hixie.ch> wrote: >>> I would probably go even further and say that having string arguments >>> that default to something other than the empty string, or numeric >>> arguments default to something other than 0, or objects that default to >>> something other than null, in cases where empty string/0/null is valid >>> values, seems like a bad idea to me. >> >> That too. >> >> However, lest we decide therefore to make such things invalid in WebIDL... > > I don't think we should make it illegal in WebIDL. Like you say, there > are situations when using a non-empty string actually makes for a less > surprising API. > > Additionally, there likely will be situations where an empty string > won't be a valid value, but where we can't use enums. Mime types is a > good example of this. Agreed. > Likewise I could imagine APIs which take numeric values greater than > 0. Here too 0 would be an invalid value even if we use a numeric type > in WebIDL. These are illegal to specify in CSS, as they go against our design principles: <http://wiki.csswg.org/spec/limited-ranges> The reasons aren't specific to CSS, and so should apply to JS APIs too. > I could potentially see forbidding boolean values defaulting to true though. Yeah. ~TJ
Received on Friday, 15 November 2013 23:25:35 UTC