23623 2013-10-24 13:52:01 +0000 Support [Clamp] for sequences 2017-03-30 16:21:36 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC Linux RESOLVED FIXED P2 normal --- 1 mvanouwerkerk cam annevk bzbarsky chris mike nbarth+w3bugzilla public-script-coord tobie.langel public-webapps-bugzilla oldest_to_newest 95304 0 mvanouwerkerk 2013-10-24 13:52:01 +0000 It would be very useful to clamp the contents of a sequence: [Clamp] sequence<unsigned long> We ran into the need for this in the Vibration API, where clamping of the contents of a vibration pattern would be more appropriate. 95307 1 annevk 2013-10-24 14:13:17 +0000 If you do not mean sequence<[Clamp] unsigned long>, could you please elaborate on what you are proposing here? 95308 2 mvanouwerkerk 2013-10-24 14:15:20 +0000 Hi Anne, not sure whether the syntax is the one I posted or the one you posted. But the idea is to clamp the values in the sequence. 95311 3 annevk 2013-10-24 14:24:40 +0000 Right, that should already work with the syntax I posted. 95312 4 cam 2013-10-24 14:50:56 +0000 The spec doesn't allow that currently though, right? [Clamp] goes on things like attributes, operation argument, etc. 95314 5 annevk 2013-10-24 14:53:17 +0000 Oh really? I guess it's only allowed at a syntax level then. Seems like that always ought to work though. E.g. if we have "[Test] DOMString" it should work regardless of context. 95329 6 nbarth+w3bugzilla 2013-10-25 01:40:37 +0000 Anne, it's tempting to attach extended attributes to types, but the grammar (and semantics) are significantly easier if we attach to operation arguments (and members) instead. Syntactically: [ExtAttr] sequence<long> foo ...instead of: sequence<[ExtAttr] long> foo This is b/c extended attributes appear at 3 levels: * definitions (interfaces etc.), * members (attributes, operations, etc.), * arguments (to operations). Extended attributes basically don't attach to types; if they did, we'd need to handle nesting, so these would have different meanings: [ExtAttr] sequence<long> foo sequence<[ExtAttr] long> foo ...and there would be ambiguity of whether an ExtAttr applies to a type or an argument (or an attribute etc.); this: [ExtAttr] sequence<long> foo parses 2 ways: ([ExtAttr] sequence<long>) foo [ExtAttr] (sequence<long> foo) ...which is pretty ugly. http://dev.w3.org/2006/webapi/WebIDL/#idl-extended-attributes Note that in the Candidate Recommendation, extended attributes are applicable to typedefs: typedef [Clamp] octet Value; http://www.w3.org/TR/WebIDL/#dfn-typedef ...so: sequence<Value> in principle expands to: sequence<[Clamp] octet> ...but this makes quite a mess (as above), and is not present in the Editor's Draft: http://dev.w3.org/2006/webapi/WebIDL/#dfn-typedef Hope this helps! 95335 7 bzbarsky 2013-10-25 04:34:02 +0000 So this is specifically talking about [Clamp] applied to a sequence<T> where T is a type that [Clamp] can currently be applied to, right? 95336 8 nbarth+w3bugzilla 2013-10-25 05:56:42 +0000 (In reply to Boris Zbarsky from comment #7) > So this is specifically talking about [Clamp] applied to a sequence<T> where > T is a type that [Clamp] can currently be applied to, right? Yes, exactly: we want |[Clamp] sequence<T>| to mean "clamp all terms of sequence". 95675 9 mvanouwerkerk 2013-11-01 13:17:18 +0000 This bug is one of the last dependencies for finalizing the Vibration API. Do you have an estimate for when it might be fixed? Is there anything I could help with? I'm not sure how much work it is, or how much time the Web IDL folks have available for looking at this. Thanks! 128516 10 tobie.langel 2017-03-30 16:21:36 +0000 Fixed by https://github.com/heycam/webidl/commit/faaaaa9ffb548a303db362a09e4b1504c4605e0c