This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23623 - Support [Clamp] for sequences
Summary: Support [Clamp] for sequences
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-24 13:52 UTC by Michael van Ouwerkerk
Modified: 2017-03-30 16:21 UTC (History)
7 users (show)

See Also:

Attachments

Description Michael van Ouwerkerk 2013-10-24 13:52:01 UTC 
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.
Comment 1 Anne 2013-10-24 14:13:17 UTC 
If you do not mean sequence<[Clamp] unsigned long>, could you please elaborate on what you are proposing here?
Comment 2 Michael van Ouwerkerk 2013-10-24 14:15:20 UTC 
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.
Comment 3 Anne 2013-10-24 14:24:40 UTC 
Right, that should already work with the syntax I posted.
Comment 4 Cameron McCormack 2013-10-24 14:50:56 UTC 
The spec doesn't allow that currently though, right?  [Clamp] goes on things like attributes, operation argument, etc.
Comment 5 Anne 2013-10-24 14:53:17 UTC 
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.
Comment 6 Nils Barth 2013-10-25 01:40:37 UTC 
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!
Comment 7 Boris Zbarsky 2013-10-25 04:34:02 UTC 
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?
Comment 8 Nils Barth 2013-10-25 05:56:42 UTC 
(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".
Comment 9 Michael van Ouwerkerk 2013-11-01 13:17:18 UTC 
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!