Re: WebIDL Spec Status
On 24/06/14 20:50, Arthur Barstow wrote: On 6/23/14 4:04 PM, Glenn Adams wrote: What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We have now a two year old CR that appears to be stuck and a 2nd Edition that I'm not sure has made it to FPWD. Hi Glenn, All, I don't have any new info re v1 beyond what Boris said a few weeks ago in this thread: http://lists.w3.org/Archives/Public/public-script-coord/2014AprJun/0162.html. Cameron, Boris - please reply to Glenn's question. I've put Web IDL work on my list of Q3 goals, so I will resume work on it next month. I still think that before publishing another draft on TR/ that we should resolve the open issues that apply to v1. Boris and I will be dividing up the open issues to split the work.
Re: WebIDL Spec Status
On 25/06/14 09:02, Arthur Barstow wrote: OK, thanks for the update Cameron. Would you please remind us how the v1 bugs are designated at such? With [v1] in the status whiteboard field of the bug. (There's still a bunch of list email I need to go through and file bugs for so the list will grow.) All - if the progression of the v1 spec is important to you, then I presume Cameron and Boris would welcome PRs (spec is at [GH] and the bugs are at [Bugs]). Indeed, and please prefer to file bugs rather than raise GitHub issues, to avoid tracking in multiple places.
Re: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition?
Travis Leithead wrote: There’s 50 some-odd bugs under the bugzilla component for WebIDL. Many of them look like simple editorial fixes that could be applied to the CR draft, but others are feature requests, or issues related to new features added to the Second Edition. Are you currently tracking which bugs are for which spec(s)? No, I've just been making changes to whichever version they seemed to apply to as I got to them. Do you have any suggestions for making this easier to track going forward? IIRC the Version field in Bugzilla applies to the Product, not the Component, so I think we can't use that. How about just putting something in the Whiteboard field, like [v1]?
Re: [WebIDL] Representing functions that user code can call
On 9/12/12 1:51 PM, Boris Zbarsky wrote:
The relevant part of the spec is:
The result of converting an IDL callback function type value to an
ECMAScript value is a reference to the same object that the IDL
callback function type value represents.
which presupposes that there's an ECMAScript object being represented by
the IDL callback function type. But in this case there isn't. Such an
ECMAScript object needs to get created... Furthermore, the behavior of
this object, when called, needs to be quite different from the normal
behavior of ECMAScript function objects: it needs to convert its
arguments to IDL types and then invoke some algorithm defined on IDL
types. Right now, all of that would have to be described in prose
because there is no way to express it in WebIDL.
OK. For Document.register, the Function object that is returned is not
going to do anything with its arguments, so I don't think we gain much
in this case compared to (to make the IDL valid) replacing Function
with object.
But if we did have a special type that meant platform implemented
function, what would we use as the return type for the custom element
constructor function? Is the object returned from it a platform Element
object? I guess we do want it to be considered as one, but the
requirements for particular prototype chains that the Custom Elements
spec has will go against the requirement in
http://dev.w3.org/2006/webapi/WebIDL/#es-platform-objects that
[[Prototype]] of the object be the interface prototype object for the
object's primary interface. (In fact the primary interface for object
is probably not well defined.)
Anyhow, if we resolve that problem, then we could allow something like:
function CustomElementConstructor = Element ();
partial interface Document {
CustomElementConstructor register(DOMString name,
optional Options options);
};
Re: [WebIDL] Representing functions that user code can call
On 8/12/12 1:56 PM, Boris Zbarsky wrote:
We have a way to represent user functions that platform objects can
call: callbacks.
But I don't think there's really a good way to represent functions that
are not hanging off any particular object that user code can call. Or
can callbacks be used for that too?
Is this for
partial interface Document {
Function register(DOMString name, optional Options options);
};
? Despite the name callback function, I think they could be used
here. I don't think there's anything in the spec that prevents platform
objects from providing values of this type.
Note that right now the web components spec is using callbacks for this,
but they're not a great fit given how callback conversions between
WebIDL and ES are defined...
What about the conversion is a bad fit?
What's really wanted for this sort of use case is something closer to
how Constructors are defined: basically a standalone WebIDL operation,
not hanging off any object.
Maybe we could just rename callback functions to functions, and have
them work both for user-provided and platform-object-provided Function
values.
Re: IndexedDB: undefined parameters
Rick Waldron: Explicit undefined will trigger default values. (see: https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html) Great, thanks for the pointer.
Re: In WebIDL, should having a .prototype on interface objects be optional?
Boris Zbarsky: Should WebIDL change here? Should FileAPI change? Technically, it is not possible to implement File API without also implementing the URL specification, since if there is a partial interface URL then there must also be a interface URL in the set of IDL fragments that you implement. Some questions then: 1. Should we make it so that if you implement one or more partial interfaces but not the actual one, then an empty actual interface is implied? If not, then File API needs to define an empty URL interface for the partial one to latch on to. 2. Is it really important to avoid a prototype from existing on URL in this case? I think I'd rather just leave it exist.
Re: In WebIDL, should having a .prototype on interface objects be optional?
Travis Leithead:
I guess you'd check for URL.href then? Or try { new URL(/test); } catch (ex) {
console.log(not supported); }
I agree with Travis, you should be checking the particular features you
want to use, rather than checking the existence of the prototype as a
proxy for that test.
If URL.prototype was required to exist, you could just do (href in
URL.prototype). Since it currently doesn't, you could do (href in
(URL.prototype || {})).
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
Arun Ranganathan: I've pinged heycam to see if this is a proper use of the sequence type. I'm not sure it allows for such a variation in parameters. I agree with Boris, it makes sense to use sequence here. Whenever you just want to take a list of values in an operation argument, and you don't want to keep a reference to a platform array object, you should use a sequence. But I also agree with Glenn that if you did use T[], and the implementation knows that it will never use the temporary platform array object that gets created when converting the (for example) JS Array object, it should be able to skip the actual platform array object creation.
Re: Acceptable for CSS to add a window.CSS global?
Chaals McCathieNevile: Frankly, I am deeply sceptical that the CSS group has managed to solve the social problem sufficiently well to make the technical solution noticeably different from hasFeature. I think the biggest difference between hasFeature and supportsCSS is that the implementation of the former, for a given feature string, would be completely independent of the feature it is testing for. So someone must make a judgement at some point about whether to return true for a given feature string. With supportsCSS, I would imagine that it would return true or false by passing the string along to the CSS parser, so you would be much more likely to get an accurate answer out of it and there'd be no need for someone to make the judgement call.
Re: [IndexedDB] Problems unprefixing IndexedDB
Kyle Huey: PS. We're also going to run into this in the future with any other prefixed DOM APIs we add to the global, probably even if we don't tell people to do it wrong in our tutorials. This behavior is a pretty massive footgun. The problem seems to be because Web IDL moved properties from IDL attributes up to the prototype, and that changed `var attributeName;` behaviour. My bad, I didn't realise that'd break things. What if we change window's [[DefineOwnProperty]] so that if it would create a shadowing property for a name that corresponds to an IDL attribute on Window (or one of its mixed in interfaces), it doesn't do that? But not for operations.
Re: [IndexedDB] Problems unprefixing IndexedDB
Boris Zbarsky: Just for Window? What about interfaces Window inherits from? Them too. An why not for operations? Seems like exactly the same issue arises with: var requestAnimationFrame = window.requestAnimationFrame || ; I was thinking that properties for operations have always been on prototypes, so people would already be used to var shadowing them. You are right though that if people use that same pattern, they will fail similarly. Are there pages that rely on var shadowing for certain names and having the variable start off undefined? I can only assume there are. If so, then we might need to pick a set of names where shadowing still works despite there being a property on the prototype for an IDL attribute or operation.
Re: [WEBIDL] nullable dictionary
Hi Jungkee, Jungkee Song: While reading about dictionary from your Web IDL (Second Edition) draft, I found a part that needs clarification: -8- 3.3 Dictionaries If the Type is an identifier or an identifier followed by ?, then the identifier must identify an interface, *dictionary*, enumeration, callback function or typedef. -8- The spec allows dictionary type to go nullable here. -8- 3.10.22 Nullable types The inner type must not be any, a *dictionary* type, another nullable type, or a union type that itself has includes a nullable type or has a dictionary type as one of its flattened member types. -8- It does not allow nullable here. From the mail history I looked up, the intention is to not allow nullable dictionary type any more. It that right? That's right. I've corrected that description of allowable dictionary member types, as well as for operation return types and arguments. Thanks, Cameron
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
Arthur Barstow: 2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some attributes. If anyone considers this change as substantive, please speak up. Cameron - what's your opinion on this? [TreatNonCallableAsNull] attribute Function? should be equivalent to attribute EventHandler so I would class it as an editorial change.
Re: [XHR] Constructor behavior seems to be underdefined
Cameron McCormack: Would it make sense to require objects that are returned from a constructor be associated with the same global that the constructor itself is? Boris Zbarsky: That seems like the simplest approach to me, yes. It's what Gecko does in practice anyway at the moment, afaict. Adam Barth: Note: WebKit has bugs in this regard, but we've been (slowly!) converging towards Gecko's behavior, which we believe is aesthetically correct. OK, I've made this change. http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.519;r2=1.520;f=h
Re: CfC: Add warnings to old DOM specifications; deadline April 18
Arthur Barstow: All - If you have any comments or concerns about this proposal, please send them to public-webapps@w3.org mailto:public-webapps@w3.org by April 2 at the latest. April 18? +1 to the warnings, I think they're worded well and useful.
Re: [XHR] Constructor behavior seems to be underdefined
Boris Zbarsky: And just to be clear, the discussion about security and document.domain is somewhat orthogonal to the original issue. WebIDL requires that all objects be associated with a particular global and that any spec defining anything that creates an object needs to define how this association is set up. For the particular case of constructors, that means that either WebIDL needs to have a default (that particular specs may be able to override) or that any spec that uses constructors needs to explicitly define the global association (which is not quite identical to things like which origin and base URI are used). Would it make sense to require objects that are returned from a constructor be associated with the same global that the constructor itself is?
Re: [xhr] statusText is underdefined
Boris Zbarsky: For what it's worth, I would be reasonably happy if we had a non-DOMString IDL type to indicate raw byte sequence strings, with WebIDL defining byte-inflation as the conversion from such things to JS strings... Anne van Kesteren: That's an interesting idea. We could also use that for open()'s method argument (as doing the opposite, throw for higher than U+00FF, then deflate). OK, so just like DOMString is a raw 16 bit word sequence string, this new type would be a raw 8 bit byte sequence string. ByteString sounds like a good name for it. (Although it may be inconsistent with octet being unsigned and byte being signed...) Would the deflation from a JS String throw when it finds values 255?
Re: [DOM4] NodeList should be deprecated
Anne van Kesteren: Okay, annotated NodeList with [ArrayClass]. What about HTMLCollection? Should I add it there too? Could you take a look at NodeList and HTMLCollection for accuracy? It is probably not feasible to add to HTMLCollection, because it has a named property getter which is not [OverrideBuiltins]. That means that all the new properties on the prototype like concat, push, etc. would begin to shadow any named elements on the collection.
Re: [DOM4] NodeList should be deprecated
Cameron McCormack: It is probably not feasible to add to
HTMLCollection, because it has a
named property getter which is not [OverrideBuiltins]. That means that
all the new properties on the prototype like concat, push, etc.
would begin to shadow any named elements on the collection.
On the other hand it would be great to be able to do things like:
document.getElementsByTagName(span)
.map(function(x) { return x.clientWidth });
:(
I am a bit reluctant to special case the visibility of named properties
on HTMLCollection to be something other than the current
[OverrideBuiltins] or non-[OverrideBuiltins] behaviour.
Re: [DOM4] NodeList should be deprecated
Anne van Kesteren: Wasn't there a compatibility constrain with doing that? I don't remember -- the only difference it would make is that Object.getPrototypeOf(NodeList.prototype) == Array.prototype.
Re: [DOM4] NodeList should be deprecated
Ojan Vafai: We should make static NodeList inherit from Array though so that you can do regular array operations on it. Web IDL has the means to make (all) NodeList objects inherit from Array by annotating them with [ArrayClass], if we want to do that.
Re: Bug in http://dev.w3.org/2006/webapi/FileAPI
Pablo Moyano: In section Editorial Note under Abstract, it says This is revision $Id: Overview.html,v 1.119 2012-02-20 18:29:29 arangana Exp $. i think the $id is a programming error of this webpage No, it's just an automatically inserted CVS $Id$ tag listing the revision of the file. http://www.fluidthoughts.com/howto/cvs/keywords/
Re: [DOM4] Constructor for DOMException?
João Eiras: DOMExceptions have both a code and a message. Perhaps the constructor should be extended to include both. Anne van Kesteren: code is legacy, but name would be good to expose. The constructor has the same signature as the standard ECMAScript Error constructors, so we are being consistent there. I think it's fine for code and name to be assigned after creating the object, if JS needs to create a DOMException object (which I don't expect to be a common thing anyway).
Re: [DOM4] Constructor for DOMException?
Marcos Caceres: So… given that one can fake create a DOMException, and unless there is a valid reason not to allow this that I don't know of…. It would be nice if DOMException just defined a public constructor. This would allow clean prototyping of various APIs in ECMAScript (and give us poor saps who don't know C a chance to implement some Web APIs :) ). Web IDL already requires exception interface objects like DOMException to be constructable, due to this: http://dev.w3.org/2006/webapi/WebIDL/#es-exception-call and them being Function objects. The constructor should take a single argument which is the message. The name property will automatically be set to DOMException, but you can overwrite this once you've created the object. This is how the built in throw an exception algorithm works: http://dev.w3.org/2006/webapi/WebIDL/#es-throwing-exceptions
Re: IndexedDB: Extra properties in optionalParameters objects
Joshua Bell:
By my reading of the IDB and WebIDL specs, the optionalParameters
parameter is a WebIDL dictionary
(http://www.w3.org/TR/IndexedDB/#options-object-concept). The ECMAScript
binding algorithm for WebIDL dictionaries
(http://www.w3.org/TR/WebIDL/#es-dictionary) is such that the members
expected in the IDL dictionary are read out of the ECMAScript object,
but the properties of the ECMAScript object itself are never enumerated
and therefore extra properties should be ignored. Therefore, the
parameter property in the test code would be ignored, and this would
be treated the same as db.createObjectStore(name, {}) which should not
produce an error.
That's right.
Re: Web IDL sequenceT and item() method
On 11/12/11 11:55 PM, Marcos Caceres wrote:
I'm also unsure as to the purpose of sequence in practice. Perhaps some
examples of expected usage would help a bit?
Sequences are for pass by value lists of values. As with the array
type, they allow you to pass in a JS array to an operation:
interface A {
void f(sequencefloat xs);
};
getA().f([10, 20, 30]);
or indeed anything that feels enough like an array:
var o = { length: 3 };
o[0] = 10;
o[1] = 20;
o[2] = 30;
getA().f(o);
When used as an operation return type, a new JS array is created:
interface B {
sequencefloat f();
};
var a = getB().f();
assert(a instanceof Array);
var b = getB().f();
assert(a != b);
The array type T[] is used for array-like objects for which references
can be kept by platform objects or by user script, and possibly modified
by either of them.
If we were ever going to extend one of the built in types with item(),
it would be the array type T[], which corresponds to a platform object
that looks a bit like a JS array but is different in various ways (extra
prototype object in the chain, non-sparse, can be read only / fixed length).
To get an object that is like a T[] but with other custom members, you
currently have to use [ArrayClass] on an interface:
[ArrayClass]
interface FixedLengthWritableNodeList {
readonly attribute unsigned long length;
getter Node item(unsigned long index);
setter void (unsigned long index, Node value);
};
All [ArrayClass] means is that
Object.getPrototypeOf(FixedLengthWritableNodeList.prototype) will be
Array.prototype instead of Object.prototype. So you can see you need to
hook up the length and getters/setters yourself there.
Re: Web IDL sequenceT and item() method
On 12/12/11 2:21 AM, Boris Zbarsky wrote: Last I checked, defining an interface that takes an in parameter that can be a nodelist or JS Array of nodes needs to use sequence, no? Or am I confusing it with array again? The confusing thing is probably that for the case where you want to take in an array as a parameter, and the receiving object will not modify the array or keep a hold of it, both sequenceT and T[] will work.
Re: Component Model f2f: Actionable things
On 3/11/11 12:41 PM, Dimitri Glazkov wrote: First of all, thank you all for coming and participating. It was exhausting, and we just ran out of time. Stupid time! Would you be able to post the code from the blog post comment example?
Re: Enable compression of a blob to .zip file
On 31/10/11 10:50 AM, Mike Hanson wrote: Work in progress: http://mimesniff.spec.whatwg.org/ There's a section on Images in there which looks like it won't do sniffing for automatic gunzipping. Although perhaps if the SVG document were used as the top level document it would be, if it falls under the Web Pages case.
Re: QSA, the problem with :scope, and naming
On 31/10/11 1:56 PM, Alex Russell wrote: Live NodeList instances don't need to be considered here. They're the result of an API which generates them, and that API can be described in terms of Proxies. No need to complicate NodeList or imply that we need a different type. Making NodeList instances real array unifies them all. We can get that done too. Don't live and static NodeLists use the same prototype? If they are separate, I don't see any problem with making them real arrays, but I am not sure what the implications of that are. Array.isArray == true, I guess? Do we have that ability within the bounds of ECMAScript yet? Note that we can already make NodeList.prototype === Array.prototype if we want, using appropriate Web IDL annotations.
Re: QSA, the problem with :scope, and naming
On 31/10/11 2:18 PM, Charles Pritchard wrote: I don't understand what real array means, other than the prototype equivalence. There's also the [[DefineOwnProperty]] behaviour which is different from normal objects. That kind of behaviour doesn't *need* to be handled by making NodeLists real arrays, it can be done by making them proxies. Some people might prefer not to do require that though, if it is indeed possible to make them real arrays.
Re: Enable compression of a blob to .zip file
On 30/10/11 10:54 AM, Charles Pritchard wrote: One reason I've needed inflate is for svgz support. Browser vendors have consistently left bugs and/or ignored the spec for handling svgz files. SVG is really intended to be deflated. All major browsers have support for gzipped SVG documents through correct Content-Encoding headers, as far as I'm aware. gzipped SVG documents served as image/svg+xml without Content-Encoding:gzip should be rejected, according to the spec.
Re: Enable compression of a blob to .zip file
On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote: Then he probably means file system files and not HTTP files, and support there has indeed been spotty in the past. Ah, yes. Regarding data: URIs, someone should really just amend the RFC to allow specifying a content encoding.
Re: QSA, the problem with :scope, and naming
On 20/10/11 3:50 AM, Alex Russell wrote: I strongly agree that it should be an Array *type*, but I think just returning a plain Array is the wrong resolution to our NodeList problem. WebIDL should specify that DOM List types *are* Array types. It's insane that we even have a NodeList type which isn't a real array at all. Adding a parallel system when we could just fix the one we have (and preserve the value of a separate prototype for extension) is wonky to me. That said, I'd *also* support the ability to have some sort of decorator mechanism before return on .find() or a way to re-route the prototype of the returned Array. +heycam to debate this point. Late replying here again, apologies, but I agree with others who say that an actual Array object should be returned from this new API given that it is not meant to be live. What benefit is there from returning a NodeList?
Re: A proposal for Element constructors
On 25/10/11 8:54 PM, Adam Barth wrote: Another solution to that more than one tag per interface problem is to introduce subclasses of those interfaces for each tag. Instead of introducing more interfaces (which don't have additional functionality), and instead of introducing Element.create, I would rather see a pattern like: var e = new Element(div, ...); There is no requirement that the object returned from a constructor be an object that has the constructor.prototype as its [[Prototype]], so having the above constructor return an HTMLDivElement is fine. (Also note that the constructor text nodes should be Text rather than TextNode, according to the interface name in DOM Core.)
Re: Reminder: RfC: Last Call Working Draft of Web IDL; deadline October 18
Travis Leithead: Is there a comment tracking doc for this LC (e.g., lc2)? Art Barstow: I don't see one in CVS. (I think Cameron returns soon though.) I have begun tracking these comments now: http://dev.w3.org/2006/webapi/WebIDL/lc2.txt
Re: [selectors-api] Return an Array instead of a static NodeList
On 30/08/11 4:19 PM, Jonas Sicking wrote: Indeed! I think it's already been decided that all non-mutating functions should be added to NodeLists and other list-like DOM objects. I believe Cameron is still working on the specifics of that. Shortly before the LC#2 was published, I added an [ArrayClass] extended attribute that you can put on interfaces that are not defined to inherit from another. That causes that interface's [[Prototype]] to be Array.prototype instead of Object.prototype. It's then up to the designer of the interface to ensure that length and array index properties behave usefully (by defining a length IDL attribute and using indexed properties) so that the Array.prototype methods will do nice things. The other construct that uses Array.prototype is platform array objects. They too have Array.prototype as their [[Prototype]]. Web IDL defines how array index properties and length are exposed on platform array objects so that they work with Array.prototype methods as best they can.
Re: [selectors-api] Return an Array instead of a static NodeList
On 24/10/11 11:51 AM, Jonas Sicking wrote: I think we have three types of array-like objects: 1. Objects like the one returned from getElementsByTagName where modifications to the array just doesn't make sense. 2. Objects like the one returned from HTMLInputElements.files where modifications to the array could be allowed and where such modifications affect the DOM (i.e. the submitted value would be changed) 3. Object like the one returned from findAll where modifications don't affect anything other than the mutated object. It appears to me that [ArrayClass] helps with case 2. Yes. For case 3 I think we should simply return an Array. No need for anything more magic than that. Agreed. Case 1 appears to be unaddressed though. And I actually think that's the most common case in the DOM right now. Or were we hoping that [ArrayClass] would be used there too and all mutating functions would throw? Yes that is the hope. I should run through the mutation function definitions just to be sure. :) It is at least well defined. An alternative is to introduce a new prototype object in between Array.prototype and the mutable array-like object that has properties shadowing all of the mutating functions with a function that unconditionally throws. I would prefer to avoid having to update the spec whenever new Array.prototype methods are introduced in the ES spec if possible, though.
Re: [selectors-api] Return an Array instead of a static NodeList
On 24/10/11 12:14 PM, Jonas Sicking wrote: Based on my testing, many methods wouldn't throw for zero-size array-like objects. Similarly, methods like .push(), .unshift() and .slice() wouldn't throw if no entries were actually requested to be added or removed. And .reverse() wouldn't throw for single-sized array-like objects. May or may not be a big deal though. Yeah. IMO it's not. One thing that is difficult to reflect from the JS Array API to objects like HTMLInputElements.files which we might want to make mutable is that the former is designed to work with sparse arrays while we have typically considered DOM collection/list objects as dense. myFileInput.files.length;// let's say this is 1 myFileInput.files[2] = ...; // what does this mean?
Re: [indexeddb] New WebIDL Exception Model for IndexedDB
Replying late here, but: On 29/09/11 12:03 AM, Jonas Sicking wrote: From my understanding of the WebIDL spec, the idea is that specifications like IndexedDB should throw exceptions which use the DOMExceptions interface. The various errors would use different string values for .name which would replace the current codes that we have now. However, if existing ECMAScript errors can be used, we should use those. Cc'ing Cameron so that he can confirm that this is a correct understanding. That's not actually what the changes allow. The built-in Error types in ECMAScript are not available at the IDL level. But I think that it would be better if they are. I can lift them up to the IDL level, and define what it means to throw a TypeError in other languages.
Re: Proposal for a new Matrix API
On 20/10/11 10:39 AM, Igor Oliveira wrote: Currently CSSMatrix and SVGMatrix has an immutable API. None of the method calls change the Matrix, instead, it creates a new Matrix with the changed value. It can be a problem specially when CSSMatrix is used together with WebGL. [1] SVGMatrix is not immutable. You can modify the a, b, ..., f properties. http://www.w3.org/TR/SVG/coords.html#InterfaceSVGMatrix However the methods that perform operations do return new matrices rather than modifying the one the method is called on. We from WebKit are proposing a new Matrix API(simple as possible), see below or [2], where the standard methods change the matrix(in place operations) and additional methods (multipliedBy, scaledBy and so on) create a new Matrix as is done by CSSMatrix and SVGMatrix. The idea is make this class accepted where CSSMatrix and SVGMatrix is used and be the preferred class for all Matrix needs. [3] I agree that unifying CSSMatrix/SVGMatrix is a good idea, if that is possible. Will look at your specific proposal a bit later.
Re: [IndexedDB] Passing an empty array to IDBDatabase.transaction
On 17/10/11 7:19 PM, Jonas Sicking wrote:
I sort of like the short-cut since it seems like a very common case
for web developers to want to create a transaction which only uses a
single objectStore.
But I agree it's not a huge win for developers as far as typing goes
(two characters).
I *think* we can move the validation into the IDL binding these days.
Something like:
interface IDBDatabase {
...
transaction(DOMStringList storeNames, optional unsigned short mode);
transaction(DOMString[] storeNames, optional unsigned short mode);
transaction(DOMString storeNames, optional unsigned short mode);
...
}
The WebSocket constructor does something similar.
cc'ing Cameron to confirm that this is valid. It *might* even be the
case that DOMStringList passes as a DOMString[]?
The above IDL is valid (assuming you stick void before the function
names). Although DOMStringList is array like enough to work if you are
not overloading based on that argument (it has a .length and array index
properties), in this case because the function call is only
distinguished based on the first argument you will need those separate
declarations.
You can see what happens when a value is passed as that first parameter
here:
http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm
If it's a DOMStringList object, since that is an interface type, it will
definitely select the first overload. And if you pass an Array object
or a platform array object, then the second overload will be selected.
[IndexedDB] there should not be a message exception field on IDBDatabaseException
Web IDL forbids exception fields named message (and name). This property will exist automatically as an own property on the exception object if a message is specified when throwing the exception. So you just need to say, for example Throw an IDBDatabaseException of type VersionError with message Get with the times!.
Re: [selectors-api] Return an Array instead of a static NodeList
On 30/08/11 4:40 AM, Aryeh Gregor wrote: Oh, right. I misunderstood you. Yes, obviously we wouldn't expose things like .push or .pop on NodeList, since they wouldn't make sense. But we should expose things like .forEach, etc. Any reason not to? I should point out that on platform array objects (i.e., the JS objects you get from IDL T[] types, and not JS Array objects) can be designated as read only but they always have Array.prototype in their prototype chain. push/pop/etc. will just fail or do nothing, depending on whether the caller is in strict mode.
Re: [WebIDL] remove modules
Paddy Byers: WAC does refer to interfaces defined in one module from another module; however, we have not been using scoped names for these references - we use the unqualified interface name. More or less every WAC module does this. Cameron McCormack: If WAC is already considering these names globally, and incorrectly referring to them without using scoped names, then it seems like they are not actually using the functionality that modules affords them. WAC is using modules solely as a grouping mechanism, and not as a namespacing mechanism, as far as I can see. So it seems like no actual important functionality would be lost if we dropped modules from Web IDL. If all you need to do is group some definitions together and give them a name, you could simply say in your specs: The foo module comprises the following interfaces and exceptions: Foo, Bar, DontTouchThat, etc. If WAC specs already define an interface named, for example, Element, then it's going to be problematic if you want to have an implementation that supports both that WAC spec and the DOM spec. You can't have both interface objects living at window.Element. If WAC specs define an interface named Goober, and then in the future a Web platform spec comes long and defines an interface named Goober, then that's also going to be a problem, and you could of course request the relevant W3C WG use a different name. Paddy/Brian, do you agree with my assessment? I think we should focus on the fact that Web IDL is primarily to be used for defining Web platform features. If other ecosystems wish to use Web IDL, that's fine, but when there are conflicting interests we should favour the Web. (I think the future of JavaScript namespacing (in terms of avoiding name clashes across independently written codebases) is going to be ES Harmony Modules. They're not quite done yet, but when they are then I think it would be better to have a Web IDL module mechanism map to them.)
Re: [WebIDL] remove modules
On 13/08/11 10:49 AM, Paddy Byers wrote: WAC does refer to interfaces defined in one module from another module; however, we have not been using scoped names for these references - we use the unqualified interface name. More or less every WAC module does this. If WAC is already considering these names globally, and incorrectly referring to them without using scoped names, then it seems like they are not actually using the functionality that modules affords them.
Re: Element.create(): a proposal for more convenient element creation
On 2/08/11 3:36 PM, João Eiras wrote: However, Nodes need a ownerDocument, and that needs to be supplied, even if optionally. Doing document.createElement implies the document, Element.create does not. I figure the ownerDocument would be window.document (where the window object is the global object that window.Element lives on).
Re: Global variables and id lookup for elements
Ian Hickson: Is this still something I should do, or did this get resolved using another solution? http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 The proposed solution I made in the bug was to have the [[Get]] etc. internal methods of Window handle the resolution order of window named properties, rather than to use inheritance in the IDL to control the order. I made that change to Web IDL, which would require you defining which named properties are “resolved before prototype properties”, and that’d be the frame names; the (possible quirks mode only) ID lookups would be done last automatically, since Window isn’t [OverrideBuiltins]. However, Tony Ross on the bug there says he would rather an even simpler solution that resoles all frame names and ID lookups after everything else (i.e. like normal non-[OverrideBuiltins] interfaces). I haven’t made any spec changes since then. It would be good to get more input on the bug. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] remove modules
[I’m CCing public-script-coord and setting Reply-To to there. If future LC comments on Web IDL could be made there, I’d appreciate it. Thanks.] Anne van Kesteren: Having everything in the same module seems fine for the web platform. FWIW, I agree, it’s a complication I have come around to thinking we can do without. Two things to be aware of if we drop the feature: One, BONDI folks were using IDL modules, IIRC. Although I think their spec stabilised well before now, so presumably they’re dependent on an earlier WD of Web IDL, and thus it’s probably not a big deal to drop the feature, aside from the fact that we should focus on the Web and not other concerns. Two, certain Web platform interfaces have been in particular packages in the Java binding, e.g. DOM Core interface have been in org.w3c.dom, Events in org.w3c.dom.Events, and so on. I don’t think this arrangement has any particular benefits. If Java implementations of Web platform APIs need to keep interfaces from these specs in particular Java packages, this could be done out-of-band from the IDL. If ECMAScript Harmony modules gain traction, it might make sense in the future to reintroduce IDL modules and connect them to ES ones. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [FileAPI] FileReader.readAsXXX when pased null
Hi Arun, Adrian Bateman: The spec doesn't seem to state this explicitly and I can't tell if there is supposed to be an implicit requirement from WebIDL. Perhaps the expectation is that this falls into the error condition and should set readyState to DONE, result to null, and process the error steps? Any thoughts? Arun Ranganathan: My thoughts are that this should be an OperationNotAllowedException, and that this should be better defined. IMHO WebIDL doesn't touch on what happens when a method within a given API is called with null, so I think you're right to point this issue out (thanks!). There was a recent change in Web IDL which made interface types (like the readAsXXX argument types) not include null by default, and if you want to allow null, to write it as “Type?”. If you don’t change the type in the File API spec to include the question mark, then Web IDL defines it so that passing null means a TypeError will be thrown. If you want to do some additional processing beyond throwing an exception (e.g. setting readyState), then you would need to allow null by using “Blob?” as the type and then say what happens when null is passed in. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Component Model: Landing Experimental Shadow DOM API in WebKit
Anne van Kesteren:
How can Document inherit from TreeScope if it already inherits from Node?
Dimitri Glazkov:
TreeScope is a Node.
That doesn’t work now that Web IDL allows only single inheritance.
Here is how I would write the IDL, if I understand what you want
correctly:
// augment Element with these two attributes
partial interface Element {
attribute ShadowRoot shadow setraises(DOMException);
attribute String pseudo;
};
// a mixin
[NoInterfaceObject]
interface TreeScope {
readonly TreeScope parentTreeScope;
Element getElementById(in DOMString elementId);
};
// ShadowRoot is a new type of Node
interface ShadowRoot : Node {
attribute bool applyAuthorSheets;
readonly attribute Element shadowHost;
};
// which has TreeScope functionality
ShadowRoot implements TreeScope;
// augment Document with createShadow()
partial interface Document {
ShadowRoot createShadow();
};
// Documents also have TreeScope functioanlity
Document implements TreeScope;
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: I'm happy to report that WebKit's implementation of IndexedDB now follows WebIDL and throws TypeError on all functions when called with missing required arguments. We have grandfathered in all existing IDL files to use the old, looser code generator, but we are actively working on migrating *all* 521 IDL files to use the new, stricter generator (with [Optional] flags in places where we can't break compatibility). IndexedDB is the first success in this process; as an experimental API, we feel no need to maintain compatibility and have opted for the stricter semantics everywhere, matching the WebIDL and IndexedDB specs exactly. Next will be other experimental APIs like the web audio API and the File API, where we hope to have similar levels of success. Great work! I’m really happy to see some of the more complex requirements of Web IDL start to get implemented, so that we can find out sooner whether there are any problems that require spec changes. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
Israel Hilerio:
Great! I will work with Eliot to update the spec for the two APIs
below, including their Synchronous counterparts, with:
---
dictionary IDBDatabaseOptionalParameters {
DOMString keyPath = null;
That would need to be
DOMString? keyPath = null;
(or else just write “DOMString keyPath;” and state in prose what it
means if the dictionary member was not specified).
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: That is highly unintuitive. What's the point of listing the argument as not optional if it is, in fact, completely optional? It’s not optional in that if there were another method of the same name which doesn’t have that argument, you can distinguish between the two calls. For example if you had: void f(); void f(in DOMString s); then in JS if you called obj.f() it would behave as described for the first method, and if you called obj.f(undefined) or obj.f(whatever) it would behave as described for the second method. If you had void f(in optional DOMString); then prose describing the behaviour of f could distinguish between obj.f() and obj.f(undefined). And if you had void f(); void f(in optional DOMString); then it’d be ambiguous which one you’re calling with obj.f(). It’s also not optional in language bindings where function calls and declarations are stricter than in JS. But you are right that it’s confusing if you just have a single method void f(in DOMString s); since clearly you can call obj.f() in JS and it won’t throw a TypeError. (For that matter, why list it as non-nullable if null is treated like the empty string and the empty string is an acceptable value?) The “non-nullableness” is really a property of the type, not the argument, and it means whether null is one of the valid values of the type or not. So at the IDL level, the value can’t be null. If in JS you pass in null, the default coercion behaviour is to turn that into . For arguments of type DOMString, you can pass in pretty much any kind of value in JS and it’ll get stringified in some way. Jonas Sicking: Huh?? At least in the Gecko DOM implementation we always throw an exception if too few parameters are defined. Only if parameters are explicitly marked as [optional] are you allowed to not include them. I was under the impression that this was the case in most DOM implementations, with notable exception of webkit. WebKit and Chrome, I think, which have independent JS binding code. Adam Barth: WebKit is looser in this regard. We probably should change the default for new IDL, but it's a delicate task and I've been busy. :( What about for old IDL? Do you feel that you can make this change without breaking sites? One of the “advantages” of specifying the looser approach is that it’s further down the “race to the bottom” hill, so if we are going to tend towards it eventually we may as well jump there now. We saw that happen with addEventListener. Jonas Sicking: This is why it surprises me of WebIDL specifies WebKit behavior as the compliant behavior as Cameron seems to indicate. In the spec right now it’s listed as an open issue, and it was the WebKit behaviour that I was going to specify to resolve the issue this week. (So it’s not what the spec currently says.) This is what I mentioned in http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0094.html although I didn’t get any pushback then. I am happy to keep discussing it but I would like to settle on a solution soon. So I guess you are arguing for “throw if too few arguments are passed, ignore any extra arguments”. When we have overloads like void f(in long x); void f(in long x, in long y, in long z); we’d need to decide whether f(1, 2) throws or is considered a call to the first f with an extra, ignored argument. The former seems more consistent to me. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: Wait, does this mean that setVersion(null) is the same as setVersion(null)? It means it’s the same as setVersion(), per the recent changes to Web IDL which make that the default stringification of null. (To get the opposite behaviour, you now need to specify [TreatNullAs=String].) -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: What about setVersion() with no arguments? I ask because WebKit currently treats it like setVersion(undefined) and I'm in the process of fixing it in about 19 places. That’s the right behaviour. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Israel Hilerio: Are we saying that we should remove the TreatNullAs=EmptyString and keep the parameter restriction that version cannot be nullable? The [TreatNullAs=EmptyString] behaviour is now the default, so you definitely want to remove it. When you say “keep the parameter restriction that version cannot be nullable” do you mean keep the type as “DOMString”? If so, then that seems like the right thing to do. Only make it “DOMString?” if you want to distinguish between null being passed and being passed. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
timeless:
would having a field: mandatory which indicates which arguments (or
feature names) must be supported by the implementation assuage your
concern?
createObjectStore(car, { mandatory: [foreignKeys], keyPath: id,
foreignKeys: [{keyPath: brand, objectStore: car-brands}]);
Certainly that would work for this case, and I kind of like it.
I feel like there would be instances where you would need this fail-if-
property-not-specified behaviour and others where would don’t need it,
hence we needn’t require all unrecognised properties to cause the call
to fail. If we agree with that sentiment, then I think something like
the above is the way to go. A question would be whether we want to have
some IDL-level support for JS objects specifying properties that need to
be recognised for the call to succeed, or whether it’s OK for individual
specifications like IndexedDB to define their own, like
dictionary ObjectStoreCreationOptions {
sequenceDOMString mandatory;
DOMString keyPath;
// ...
};
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Israel Hilerio: What I meant was that on the method description of IDBDatabase.setVersion, there is a table that has a nullable column. In it the version parameter there is an x in the Nullable column, which implies that the version parameter cannot be nullable. I'm guessing we want to keep this setting and that the only thing we want to remove is the [TreatNullAs=EmptyString] from the WebIDL definition (as you described above) of the setVersion. I think the Nullable column is really just a reflection of whether the type is nullable, i.e. if the type has a “?” at the end of it. Having the type be “DOMString” yet having a tick in the Nullable column doesn’t make sense. I don't see any reason for changing the type of the parameter from DOMString. Right, unless you wanted to allow null to be passed as the argument and you wanted to distinguish that from . In that case, you would change the type to “DOMString?”, which would mean there’d be a tick in the Nullable column. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
Jonas Sicking: The one outstanding issue that I know about is that we want IndexedDB to throw if any unknown parameters are specified. I don't know if WebIDL dictionaries support those yet. Or if it's something that we can specify in prose. I was waiting to see if anyone else had any views on that in the other thread, but I guess they don’t. :-) I am still not quite comfortable with looking at the enumerability of the property to determine whether it will be used as a dictionary member value. It’s not consistent with how property descriptors are handled by Object.defineProperty and it doesn’t seem like a natural JS usage pattern for objects-as-property- bags. Throwing if there are unknown properties is also inconsistent with Object.defineProperty. Do you think this should happen for all users of dictionaries (if other specs used them)? -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
Jonas Sicking: I don't know about other APIs. But it does seem very unfortunate to simply silently ignore unknown arguments to IDBDatabase.createObjectStore. Though then again, extra (and thus unknown) arguments are ignored to all other DOM calls. Right (not as defined in Web IDL at the moment, but will be soon). -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
Jonas Sicking:
At least in the indexedDB case we need to enumerate the object anyway
since we want to throw if it contains any properties that we don't
understand. This is for forwards compatible reasons.
Hence we automatically limit ourselves to enumerable properties, so
toString wouldn't be a problem.
The way I’ve specified dictionaries, there is no way to know what other
properties might exist on the JS object. If you defined
dictionary ObjectStoreCreationOptions {
DOMString keyPath = ;
boolean autoIncrement = false;
};
then the (IDL level) dictionary value will only ever have a keyPath and
an autoIncrement entry.
I could add a flag to the dictionary that indicates whether “unexpected”
properties were on the (language level) object, so that IndexedDB can
act upon it by throwing an exception. I’m just not sure that this is a
common usage pattern of options objects in JS. To me, the simplest use
of the properties on the options object would be:
function createObjectStore(name, optionalParameters) {
optionalParameters = optionalParameters || { };
var keyPath = optionalParameters.keyPath || ;
var autoIncrement = optionalParameters.autoIncrement;
...
}
Doing:
function createObjectStore(name, optionalParameters) {
optionalParameters = optionalParameters || { };
var keyPath = optionalParameters.keyPath || ;
var autoIncrement = optionalParameters.autoIncrement;
for (var key in optionalParameters) {
if (key != keyPath key != autoIncrement) {
throw ...;
}
}
...
}
feels kind of unnecessary. Are you thinking that authors will feature
test for new options by doing something like the following?
try {
createObjectStore(test, { newOption: 123 });
} catch (e) {
if (e.code == IDBDatabaseException.NON_TRANSIENT_ERR) {
// fall back to something else that does use newOption
}
}
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
Lachlan Hunt: WebIDL currently specifies in the ECMAScript to IDL type mapping [1] that null stringifies to null by default, unless otherwise specified with [TreatNullAs=EmptyString]. … Recently, in order to resolve a site compatibility issue caused by us stringifying to null for some properties, we made all DOMString APIs consistent in their handling of null, such that they now stringify to an empty string. We believe this is compatible with other implementations for all other attributes and properties that we are aware of. But this fix also had the result of changing the way we handled null in selectors-api, for which we used to stringify as null. I've been informed that Cameron has plans to update WebIDL to make this the default too, but hasn't yet done so. FYI, I made that change yesterday. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
Israel Hilerio: For the optional parameters variable that is expected by the IDBDatabase.createObjectStore function, would it be possible to constrain the variable to have the keyPath and autoIncrement attributes as part of its instance members and not as part of its inheritance hierarchy? Jonas Sicking: For example we asked that it should not be allowed to implement the properties using getters as to avoid having to worry about javascript running from inside the createObjectStore implementation, however the feedback we got was unanimously strongly opposed that. One advantage of looking only at own properties is that it would make it easier if for example you were defining a dictionary type that had members named prototype, toString, etc. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248 There were two options I was considering in the bug. The first was to test whether the object the property like `keyPath in optionsObject`: keyPathSpecified = optionsObject.[[HasProperty]](keyPath) if keyPathSpecified then keyPath = ToString(optionsObject.[[Get]](keyPath)) else keyPath = default value for keyPath end if The second is to unconditionally get the property and compare it against undefined: keyPath = optionsObject.[[Get]](keyPath) if keyPath is undefined then keyPath = default value for keyPath else keyPath = ToString(optionsObject.[[Get]](keyPath)) end if Both of these would still find toString from the prototype, though. You could easily define it such that you do only look up own properties, but as Jonas says some people may think of that as less “JavaScripty” than the other options. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [websockets] Binary support changes
Ian Hickson: Consistency is good when it makes sense. However, I don't think XHR is a good parallel here. XHR has all kinds of additional complexities, for example it lets you get a string, whereas here string vs binary is handled at the protocol level and so can't ever be confused. However, if we want consistency here anyway, then I'd suggest we change XHR to use the actual type values just like WebSockets. It would IMHO lead to much cleaner code. The difference would just be specifying `ArrayBuffer` vs `ArrayBuffer`, right? I think the difference in cleanliness is minimal. Using strings as enumeration values is quite common in JS, but I don’t think I’ve seen this idiom of using interface objects before. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Global variables and id lookup for elements
Boris Zbarsky:
For what it's worth, the way Gecko implements this is by inserting
an object into the prototype chain of the Window that handles these
property gets. This means that |var| (which defines a prop on the
Window itself) will always shadow the named props, which is the
behavior you observe.
If we solve the problem in this way, with an extra object in the
prototype chain, then this could be defined in HTML without any special
prose.
[NoInterfaceObject]
interface WindowNames {
getter any (in DOMString name);
};
interface Window : WindowNames {
...
};
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
Jonas Sicking: However it appears that that extended attribute is not present in newer versions of the WebIDL spec. Cameron, is this something that is planned to be brought back? It seems like a useful feature to avoid having to define in prose this rather common requirement. We should also define which exception should be thrown if such a [NoNull] requirement was violated. I plan to make object types non-nullable by default, and to allow null you would write “MyInterface?”. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640. I will most likely make passing in null for a non-nullable object type result in a TypeError being thrown. -- Cameron McCormack ≝ http://mcc.id.au/
Re: More questions about contextual reference nodes
Lachlan Hunt: However, with the way in which the IDL is overloaded, it's not clear to me which of the two overloaded methods gets invoked when the parameter is null. The IDL says: querySelector(in DOMString selectors, in optional Element refElement); querySelector(in DOMString selectors, in sequenceNode refNodes); When the author invokes: x.querySelector(a, null); Does it invoke the method with refElement or refNodes? That is one of the unsatisfactory things about the way overloading is currently handled in Web IDL. In situations where null is a valid value for more than one overload, it needs to be described in prose, but only if it matters which of the two operations is considered to be invoked. See the blue box just below this footnote: http://dev.w3.org/2006/webapi/WebIDL/#distinguishable-interface-note Step 4 of the algorithm for the behaviour of Function objects that correspond to IDL operations http://dev.w3.org/2006/webapi/WebIDL/#es-operations says If S contains more than one entry, then the operation call is ambiguous. Remove all but one entry from S according to rules specified in the description of interface I, or arbitrarily if no such rules exist. Note that it is ambiguous if you have, say querySelector(in DOMString selectors, in optional Element refElement); querySelector(in DOMString selectors, in Node[] refNodes); since null is a valid value for both Element and Node[]. With querySelector(in DOMString selectors, in optional Element refElement); querySelector(in DOMString selectors, in sequenceNode refNodes); null is not a valid value for sequenceNode, so passing null calls the first of the two overloads. That is because in the overload resolution algorithm http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm step 3.2.2 only considers object, interface types, nullable types and array types when “null” is passed as an argument. -- Cameron McCormack ≝ http://mcc.id.au/
Re: More questions about contextual reference nodes
Lachlan Hunt: I reviewed WebIDL again, and I think I've started to understand the difference between sequenceT and T[] now. As I understand it, the algorithm to convert an ECMAScript object to an IDL sequence should work with any object that has a length property and indexed values containing Node objects. That is true for an Array of Nodes, NodeList, HTMLCollection and the above JQuery case, they can all be handled in the same way. Yes, that’s right. This seems to differ from the algorithm given for T[], which requires that the object be either an array host object or a native object, which would not handle the JQuery case. The sequenceT type seems more generic than that as the algorithm seems to be able to support any object with a length and indexed properties. Why wouldn’t it handle the JQuery case? Isn’t it a native object? I've updated and simplified the spec to handle the above case using the parameter sequenceNode. I still need to update the prose to say that while the collections may contain any Node, only Element nodes are added to the list of contextual reference elements. But the following cases should all work. Agreed, that works, according to Web IDL’s currenty definition of overloading. The issue of whether you want to throw eagerly if passed an array with elements of the wrong type to an operation taking a sequenceT is an interesting one, which probably still could bear some more discussion. On the one hand, it helps ensure implementations don’t diverge based on when during the course of running the method these elements from the sequence are looked up. I could mean a lot of useless checks, though. -- Cameron McCormack ≝ http://mcc.id.au/
Re: More questions about contextual reference nodes
Lachlan Hunt: OK. Then I'm not sure what the practical difference between the Element[] or sequenceElement would be then, nor which one to use. Boris Zbarsky: I'm not either. That's why Cameron is cced. If you are choosing between those two for the type of an argument, and you don’t have any way of getting an actual array host object Element[] (so will be passing in a native Array, or a NodeList, or…), and hence the method cannot cause a reference to a passed-in Element[] object to be kept, then the only difference is that with Element[] you can distinguish between null and an array of length 1, while with sequenceElement you can’t. While i n: Let x be the result of calling [[Get]] on V with property name ToString(i). Set Ei to be the result of converting x to an IDL value of type T. This step can throw (as part of the conversion process defined for converting to type T); seems like that would involve throwing from the whole algorithm. Yep. -- Cameron McCormack ≝ http://mcc.id.au/
Re: More questions about contextual reference nodes
Cameron McCormack: then the only difference is that with Element[] you can distinguish between null and an array of length 1, while with sequenceElement you can’t. Length 0, not 1. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Selectors API IDL Issues
Lachlan Hunt:
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
This adds another method to Element.prototype
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Element implements NodeSelector
Boris Zbarsky:
This adds a new interface called NodeSelector and says that any
instance of Element must implement this interface. But it does not
add to Element.prototype; the method goes on the mixin prototype
object. See
http://www.w3.org/TR/WebIDL/#host-object-mixin-prototype
Boris is right, that’s the difference, as it currently stands in Web IDL
(forgetting for a moment that [Supplemental] isn’t defined). What I
will do in the near future is implement the proposed changes to remove
multiple inheritance from Web IDL and add the “mixin prototype” concept,
which will allow you to specify the augment-an-existing-prototype
behaviour that [Supplemental] would have given you.
[NoInterfaceObject] just means there is no window.NodeSelector.
Yep. That’ll be the default for these mixin interfaces, too.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [FileAPI] Why is FileList a sequence?
Ian Hickson:
Web Apps 1.0 will change if you need it to. Don't constrain on my account
here. I'll do whatever you think we should do. The only places I use it
are in an argument to a method because I want to allow authors to pass in
literal JS Arrays of values, and on a NodeList descendant where I just
wanted the user of the API to be able to get a JS Array of values. I don't
think there's much implementation compatibility constraint here.
OK.
The latter isn’t a good use, BTW, as mentioned in the reply to Anne,
because it would mean a fresh Array object is constructed each time you
get the values property of PropertyNodeList. So for what you might
expect to be a common usage pattern,
for (var i = 0; i myPropertiesCollection.values.length; i++) {
doSomethingWith(myPropertiesCollection.values[i]);
}
it’s going to result in a lot of wasted work. To make it clear that’s
going to happen, I’d recommend making it a method instead.
Or if you want to retain the property style access, you could use T[]
instead, and state that it is a read only array. The object returned by
the property wouldn’t be a real JS Array, though.
(Or you could go the route of defining an interface with index getters.)
(Are the other two implemented by any browsers?)
Not that I’m aware of.
I think sequenceT is fine for the purpose of accepting a JS Array of
items as a method argument. Presumably the requirement to have
something like that in WA 1.0 isn’t going away, and there isn’t another
way to do that in Web IDL currently, so unless there are concrete
problems with sequenceT or anyone has ideas on how to do it better,
I’ll just leave it alone for now.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [FileAPI] Why is FileList a sequence?
Ian Hickson: Makes sense. What I really want is a NodeList-like interface, but ideally one that supports all the Array accessors, but I don't want to have to redefine it each time. Is there some way we could get a macro for that kind of thing? See also: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11195 Yeah, let’s see what comes out of that bug when I get to it. I think sequenceT is fine for the purpose of accepting a JS Array of items as a method argument. Presumably the requirement to have something like that in WA 1.0 isn’t going away, and there isn’t another way to do that in Web IDL currently, so unless there are concrete problems with sequenceT or anyone has ideas on how to do it better, I’ll just leave it alone for now. Is there some way we can make it only be allowed in arguments to host-implemented APIs? It might make sense to restrict it in that way, yes. (Plus as a return type.) Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=12287 for that. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Moving XBL et al. forward
Arthur Barstow: * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? I promised Dmitri some use cases from the SVG WG’s perspective, but haven’t managed to get to working on these yet. Whatever solution we have in the end – and I personally am not really fussed about whether it is XBL2 as it was, or is now, or something new based on Dmitri’s requirements document – I would like it to be able to work without an HTML document present. I want to be able to write a document like svg … star cx=100 cy=100 points=5/ /svg or svg … my:star xmlns:star=… cx=100 cy=100 points=5/ /svg or svg … g class=star cx=100 cy=100 points=5/ /svg or svg … g binding=star cx=100 cy=100 points=5/ /svg (choosing g here because it’s kind of similar to a div), one of those. Sorry for not having more concrete comments yet. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Moving XBL et al. forward
Cameron McCormack: svg … star cx=100 cy=100 points=5/ /svg Tab Atkins Jr.: svg x-star cx=100 cy=100 points=5/ /svg Or that. :) I have the feeling that we don’t have agreed upon rules on how authors are allowed to extend the platform. Whatever we deem is the “proper” way for them to do so would be how I’d like it to happen in SVG. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Bug 11406] New: [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid mode parameter
Jeremy Orlow: Similar with the direction for openCursor or anything that takes in an enum. I don't see any existing error that's a particularly good match for these. Maybe I should add an ENUM_ERR or something? Jonas Sicking: Would be great if WebIDL could help out here. Cameron, I seem to recall there being discussions about this, but I could be making that up. For specifying which DOMException code will be raised? There’s http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623 but I haven’t done anything with that yet. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Bug 11406] New: [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid mode parameter
Jonas Sicking: Specifying an exception to throw for functions that take enums if a invalid value is passed to the function. Ah, I misunderstood. Would you want a standard exception (like TypeError, or one of the DOMExceptions from DOM Core) or be able to have the IDL specify what exception is thrown? -- Cameron McCormack ≝ http://mcc.id.au/
Re: Discussion of File API at TPAC in Lyon
Jonas Sicking: Since I wrote the IDL for indexeddb above, WebIDL has gotten support for static which should do what we want. Though it's a bit unclear if using a real interface would cause there to be a .prototype property on the URL interface which we for now don't want, right. It's also unclear if static functions appear on URL objects as well. The new static keyword will cause the function property to exist on the interface object and not on the prototype. Thus you can’t access the function directly by getting a property on an instance of the interface. -- Cameron McCormack ≝ http://mcc.id.au/
Re: DOM collections index out of bounds and JavaScript.
(albeit inconsistently) while others have chosen to just use property access to return undefined. I’m not sure that implementations are slavishly following the Web IDL spec just yet. It is widely known and I've provided plenty of examples of this here and on WHATWG mailing list that implementations do use proxies. Some examples appear in Adding ECMAScript 5 array extras to HTMLCollection. So the question is not if but why: Why do implementations use proxies? By “proxies” do you mean “a host object with a custom [[Get]] and [[Put]] (or [[DefineOwnProperty]]) that responds to property names that are valid array indexes in a particular way”? I don’t think the proxy proposals are implemented yet. If I had to guess: it’s probably easier. You’d have to ask the implementors, though. […] I get that the spec requires ob[n] to delegate to item, and so for that a proxy is needed. But what type of situation is it really necessary for obj[n] to delegate to item? Which Collections really need a proxy to function as required by code? I’m not sure that proxies are required to make ob[n] delegate to item, So where `x.item( -1 )` and `x( -1)` each throw an error, how do you make x[ -1 ] do the same? You can't; not unless you use a proxy for specialized [[Get]] access, which then forwards the call to `item`. That is true. (Assuming you meant `x[-1]`.) Unless you wanted to have all 4 billion properties existing on the object. :) Some implementations do this for certain collections but others. It's wildly inconsistent. If it mattered at all, wouldn't we be seeing bugs on this and hearing implementors saying no, it cannot happen - ? It is possible it matters; my guess was that it wouldn’t. I haven’t researched too deeply. I am relying on implementors pushing back on how this is defined, if it does matter. as long as n is always the name of a property that exists on the object. That’s how the spec defines it at the moment: whenever there’s a “supported named property” (i.e., a value for n that is in range, as it were) then an accessor property must be defined on the object, where the getter calls item. It seems you've done as Ian has and overloaded the term range. Instead, I think you mean a value for n that is length or in the collection. And if I am right, I would rather that in the spec than an overloading of the term range. I don’t use the term “range” in the spec when talking about these indexed properties, only in the above email. The spec defines a term “supported property index”: http://dev.w3.org/2006/webapi/WebIDL/#dfn-supported-property-indices If the word “range” is confusing in HTML5 there, then I suggest you raise a bug to get it clarified. It’s the “define a property on the object at the right time” bit that could be tricky, though. East for static collections; Constructing native ES arrays is roughly the same process; why not make a method for internal use by implementations based roughtly on that? http://ecma262-5.com/ELS5_HTML.htm#Section_15.4.2 For live collections, it requires just writing precisely and succinctly what implementations do. Entirely possible, but not for me; not at this hour. Yes, basically Web IDL says that as soon as an index becomes a supported property index on the object, then a property needs to be defined on it. Depending on what the collection is a collection of, it might be easy to know when to do this, or it might not. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Questions about API Design, composability and multiple arguments
Hi Nathan.
I can give you some off-the-cuff personal opinions on the questions you
ask.
Nathan:
interface Store {
readonly attribute unsigned long length;
T get (in unsigned long index);
void add (in T t);
void merge(in Store store);
sequenceTtoArray();
Store filter (in TFilter filter);
void forEach (in TCallback callback);
};
(1) Adding multiple items
What's the best approach to allow adding multiple items?
- add(in T[] t)
would this allow a single T not in an array to be passed in?
can one define a function with WebIDL so that it accepts either a
single item of type T or an array of T?
It wouldn’t allow this. But you could overload to allow this:
void add(in T t);
void add(in sequenceT ts);
- add(in T... t)
is the variadic approach better?
also if at least one argument is required would the IDL have to be:
add(in T t, in T... ts) ?
The reason I don’t prefer variadic functions like this is that it makes
it more complicated to call if you already have an array of items built
up that you want to pass in.
var ts = getItemsToAdd();
store.add.apply(store, ts);
On the other hand, many built-in Array methods use the variadic
approach.
- addAll(??)
Would it be preferable to introduce an addAll function?
If so, then the above two approaches also apply here, which one?
If the question is whether to use a different name rather than overload
‘add’, I don’t have much of an opinion.
Also you'll note the toArray() method, if the advice above is to the
above is to take the variadic approach, then how should one address
importing an array - and further would the appropriate type for such
an argument be sequenceT or T[]? `addArray (in ?? t)`
If it’s just used an operation argument, then it won’t matter either
way. If an Array is passed to an operation expecting a sequenceT,
then a reference to that Array won’t be kept by the object (nor will it
modify the Array). The array type T[] is best used if you want to have
an array that both user JS code and the DOM objects can keep a hold of
and modify.
(2) Chaining by return
Should the method add(in T t) return Store, the current store to
which the T has just been added so as to allow chaining as such:
store.add(t1).add(t2).add(t3)
I’m not a big fan of that kind pattern. Some are, though. It obviously
breaks as soon as you want to return a meaningful value from the method.
Likewise the same question can be asked about merge()? - however
this adds in a twist because filter() will not modify the contents
of the store and return a new Store (it acts like Store is
immutable), whereas merge would modify the contents of the store and
then return itself.
Likewise again with forEach?
Right, you would have to judge when it makes sense to return the Store
and when not to. User of the API would then have to be aware of when
they can chain method calls and when they can’t.
(3) merge()
Where merge(in Store store) is a method which adds non duplicated
members of the store passed in to the current store, would this be
better named 'import' or something else?
No opinion.
Would it be wise to add a counterpart method which treated the store
as immutable returning a new store (as filter does)?
Maybe!
(4) counterpart methods
Finally, just a quick one, is it worth considering adding
counterpart methods for composability, as in given we have
Store.add(T t) would it also be wise to include a method
T.addTo(Store store) - and if so should it return the instance of T
or the Store with t added?
Those kinds of methods *could* be handy for higher order functions, I
suppose. Although in this specific case, it seems like you’d be more
likely to have an array of T objects rather than an array of Stores.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [IndexedDB] IDBKeyRange cleanup
Jonas Sicking: Unfortunately there is no way to express this in WebIDL, so I think we need to describe it in prose instead. I'll raise this with Cameron, but I think that since at this point only IndexedDB uses these static functions, it might not make sense to add support to WebIDL. I think it makes sense enough to add support for static operations, so I’ve added it: http://dev.w3.org/2006/webapi/WebIDL/#idl-operations http://dev.w3.org/2006/webapi/WebIDL/#idl-static-operations http://dev.w3.org/2006/webapi/WebIDL/#es-operations http://dev.w3.org/2006/webapi/WebIDL/#proddef-Qualifiers -- Cameron McCormack ≝ http://mcc.id.au/
Re: DOM collections index out of bounds and JavaScript.
Garrett Smith: Objects references are passed as value in ES but that doesn't mean the same thing you're intending here. Here, by pass by value, you mean to convey that a copy of value of the object is passed. Yes, sorry for the imprecise language. Obviously ES only has pass by value. A method that accepts an array can use that array without storing a reference to it. And if it needs those items, then it can make a defensive copy of the Array. Yeah, sequences are meant to be like that: methods would be required to take a “defensive copy” of the array, and not keep a reference to the object that was passed in. … The difference here is that the object that was passed in uses normal ES syntax; it's pass by value (value of reference) not referenced by the object. The effect is what you wanted, I think, and that is that 1) the method that accepts the array makes a defensive copy of it and 2) that the method (or getter) that returns the array always returns a new copy of it. Yes, that’s the intent. But where is the array host object used? That’s for arrays – type T[] – not sequences. That seems like the main issue to me. What are a Collection object's indexed properties? Are they real object properties or is there a proxy for [[Get]] and [[Has]]? Both behaviors can be seen in implementations but it varies, depending on the implementation and on the object. As currently defined, they are real properties. But where are proxies really needed? How important is it, for example, for document.styleSheets[-1] to throw an index out of bounds exception, or for document.childNodes(9) to return null instead of undefined? I think document.styleSheets[-1] returning null or throwing an exception is inconsistent with, say, regular ECMAScript arrays, so IMO that’s not something we should encourage. It seems that some implementations have gone out of the way to use proxies to adhere to the spec to fulfill the odd cases above (albeit inconsistently) while others have chosen to just use property access to return undefined. I’m not sure that implementations are slavishly following the Web IDL spec just yet. How important are those cases? Do we have any bug reports for implementations returning `undefined` instead of throwing/returning null? I don’t know of bug reports. I get that the spec requires ob[n] to delegate to item, and so for that a proxy is needed. But what type of situation is it really necessary for obj[n] to delegate to item? Which Collections really need a proxy to function as required by code? I’m not sure that proxies are required to make ob[n] delegate to item, as long as n is always the name of a property that exists on the object. That’s how the spec defines it at the moment: whenever there’s a “supported named property” (i.e., a value for n that is in range, as it were) then an accessor property must be defined on the object, where the getter calls item. It’s the “define a property on the object at the right time” bit that could be tricky, though. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Feedback requested on returning null/void or throwing an exception
Nathan: We're debating this at the minute, one person has said yes null could be a converted value for them, which means yes it could be - however it's also been suggested that null is a single value thus, we could disallow it / reserve it, because a TypedLiteral with a type of http://example.org/types/null; could only ever be null, thus detected and specified without needing any conversion functionality. OK. Anyway, whether you would want to return null or some other value (or throw an exception) to indicate that no converted value was available depends on the answer to the above question, I guess. Note that undefined isn’t a native value of any IDL type, so specfiying that that undefined is returned would be quite ECMAScript-specific. Returning null in these cases is quite normal (assuming null isn’t a value that could normally be returned, as above). -- Cameron McCormack ≝ http://mcc.id.au/
Re: DOM collections index out of bounds and JavaScript.
Cameron McCormack:
I don’t know that sequence is appropriate for this. They are meant
to be for pass-by-value lists.
Anne van Kesteren:
I'm not sure I follow this. Could you elaborate a bit?
As currently defined, sequence types are used solely to represent lists
of values, and not objects that have other methods on them. Also, those
lists are passed by value. If you had an operation that took a
sequencelong argument, then in ECMAScript you could pass an Array
object where each of the elements were treated as longs (and converted
appropriately). The object on which you called the method wouldn’t be
able to keep a reference to the Array.
This is kind of different from NodeLists etc., which are objects that
keep a list of values. You can pass references to these objects around
and not expect a copy of the elements to be taken each time you do that.
Array types are intended to be like these objects, in that copies won’t
be made of their element lists. They still don’t allow operations to be
defined on them, though, if you are looking for that.
Is the issue here that you can’t use a base interface because then you
would lose some type specificity, e.g.
interface Collection {
attribute unsigned long length;
getter any item(unsigned long index);
}
where you need to use “any” because you don’t know what the type of the
derived interface elements will be?
Well, and you would need to define that base interface somewhere and
all other specifications would need to use it.
A minor issue, I guess.
But I thought this was the point of sequence. I have been using it
that way in the CSSOM at least to replace all these dreaded
SomethingList interfaces/objects. Maybe we should introduce something
else for it?
Depends what you are using them for. For example if you have an
attribute of type sequenceT, that’s almost certainly not what you
want. (And in fact I should disallow it.) You don’t want a whole new
Array object constructed each time you get the property value.
So it sounds like array types are more appropriate here.
I don’t think anyone is using array types yet. Consequently, they could
do with some review. Have a read through
http://dev.w3.org/2006/webapi/WebIDL/#es-array to see how they’re meant
to be implemented in ECMAScript. Having funky [[DefineOwnProperty]]
behaviour, I’m sure some people will have issues with it. Maybe one day
it’ll be possible to define array-like proxy objects in ECMAScript, in
which case we could target them instead.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Feedback requested on returning null/void or throwing an exception
Hi Nathan.
Nathan:
We have the following interface:
[NoInterfaceObject]
interface TypedLiteral : RDFNode {
readonly attribute stringifier DOMString value;
readonly attribute IRI type;
any valueOf ();
};
If a converter is registered with the API for the specific `type`
then valueOf() returns the native type (for instance Date in the
case of xsd:dateTime).
We are currently looking for input on what valueOf() should return
when there is no converter registered. Choices we're looking at are:
1: unconverted value
2: throw an exception
3: return null
4: return void
What are the unconverted values? If they’re not values in the IDL value
space, you’ll need to define some sort of conversion.
1 and 2 aren't really any option tbh - 3 I prefer, 4 another member
of the WG prefers, but primarily we're looking for best practise in
this scenario, and whether 4 is even an option.
Well, the operation is defined to return “any”, so you have to return
something. You could define it so that undefined is returned in ES.
Could “null” ever be a converted value?
I guess I would need to understand the problem space a bit better.
BTW, I guess it is deliberate that you have a function named valueOf on
there, so that you get funky behaviour when you use these objects in
arithmetic expressions in ES?
It *may* be confusing. Since the TypedLiteral prototype will have both
a toString and a valueOf, you can get situations where converting the
object to a string by passing it to the String constructor function
results in different value from concatenating '' on to it:
var p = { toString: function() { return 'a string' },
valueOf: function() { return 123 } };
var a = Object.create(p);
alert(String(a)); // alerts a string
alert(a + ''); // alerts 123
--
Cameron McCormack ≝ http://mcc.id.au/
Re: DOM collections index out of bounds and JavaScript.
Anne van Kesteren:
Yeah, it would be nice if sequence mapped to that so that NodeList
could be defined as a sequence instead, same for StyleSheetList,
etc. And then Web IDL would take care of all the details rather than
each specification.
I don’t know that sequence is appropriate for this. They are meant to
be for pass-by-value lists.
Is the issue here that you can’t use a base interface because then you
would lose some type specificity, e.g.
interface Collection {
attribute unsigned long length;
getter any item(unsigned long index);
}
where you need to use “any” because you don’t know what the type of the
derived interface elements will be?
--
Cameron McCormack ≝ http://mcc.id.au/
Re: CfC: publish a new Working Draft of Web IDL; deadline October 18
Jonas Sicking: My gut reaction is to leave this out from the spec and not let WebIDL specify security aspects. Agreed. It’d be fine even for other specs (HTML5?) to define their own security-related extended attributes to avoid writing prose that defines when SECURITY_ERRs get thrown, but I don’t think the place to define such an extended attribute is in Web IDL itself. -- Cameron McCormack ≝ http://mcc.id.au/
Re: DOM collections index out of bounds and JavaScript.
Erik Arvidsson: The problem is that trying to get a non existing property in JS should return undefined. Not null and not an empty string. I understand that the spec used null since Java does not have undefined. Since we are trying to realign these specs with the web it would make sense to try to make them fit better with JavaScript and mandate that the JS bindings for collections should return undefined for getting an item out of bounds. Does it particularly matter that collection.item(999) returns null while collection['999'] evaluates to undefined? To me, it makes sense enough. Functions and properties that returns Nodes, and which have no Node to return, return null. I think for consistency with all of these other funtions and properties, it is preferable to return null from collection.item(). That’s a much bigger (better) consistency to strive for than one between collection.item(999) and collection['999'], IMO. -- Cameron McCormack ≝ http://mcc.id.au/
Re: CfC: publish a new Working Draft of Web IDL; deadline October 18
-minus various people Shiki Okasaka: You've been missed, Cameron! Just a reminder, my wish list is here (this doesn't have to be reflected in the very next WD, though): http://lists.w3.org/Archives/Public/public-script-coord/2010JanMar/0003.html A signed 8 bit integer type has been required in WebGL. Thanks for pointing these out. I’ve made sure they all have issue boxes in the spec. The one I can find the least information about is [DoNotCheckDomainSecurity]. What are its requirements – just allow property accesses that would normally be blocked because they are cross origin? Is it something HTML5 would use? Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting
Arthur Barstow: * Web IDL - Cameron - will you attend this meeting? I hadn’t considered it yet. Do you think there is an advantage in my attending (beyond progress that could be made on the mailing lists, once I’m back into the swing of things)? I think we should be putting a high priority on solving the issue of how arrays are exposed on the web, and whether we can still unify the WebGL typed arrays, CanvasPixelArray, Blob, and various other interfaces that take lists of things. (Whether it is possible at this point I am not sure.) One cross-group discussion point that has been at the back of my mind for a while is that of working out some shared design goals for the web platform, especially in the API space. For example, I see that the DAP interfaces quite often use property-bag-style parameters for functions. While this might be a fine design pattern in itself, it certainly isn’t consistent with the rest of the web platform. In other specs, some interfaces have [NoInterfaceObject] on them, some don’t, and I feel like there should be some general guidelines that we should be following to decide these kinds of things. I am concerned that decisions like these, made in isolation, could lead to the platform as a whole feeling less cohesive. I haven’t had time to think about this in detail at all yet, though. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Wanted: Editor for Web IDL spec
Hello Web Apps WG and TC39, Arthur Barstow: A few of WebApps' specs, as well as specs from at least one other WG, have a normative dependency on the Web IDL spec [WebIDL]. Lack of progress on Web IDL (last published in Sept 2009 and only minor editing since then) will eventually block the dependent specs from advancing. Additionally, Cameron reported recently that October is the earliest he will be available to actively work on Web IDL. It was pointed out to me that there is still some concern about the progress of Web IDL (understandably), so I just wanted to confirm that from October I will be allocating some time to working on the document. My plan of attack will be to: * finish the terminology porting to ES5 that Sam started * publish a WD * go through the mailing list archives for the time I’ve been away and gather up issues * resolve those issues and the ones that are currently identified in the document * publish a LCWD Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] Trying to understand IndexGetter/NameGetter
[Adding public-script-coord and bccing public-webapps, since Web IDL discussions are now meant to happen on the new list.] Hi Boris. Boris Zbarsky: In section 4.4.2 of WebIDL, there is the following language: As soon as a name N begins being able to be used to index the host object, a property called the corresponding named property MUST be created on the host object... IndexGetter has similar verbiage. I'm really not clear on this begins being able to be used thing. Is that something the interface needs to define? Yes, though the latest draft of the spec has changed the wording a little: http://dev.w3.org/2006/webapi/WebIDL/#indexed-and-named-properties Basically, the prose in the spec defining the interface would define what the set of “supported property indices” contains at any given time: http://dev.w3.org/2006/webapi/WebIDL/#dfn-supported-property-indices When a new index becomes a part of that set, then a property is created on the object. When it is removed from the set, then the property is deleted. In particular, consider using IndexGetter for NodeList. At what point can 1 be used to index the nodelist? Is it as soon as the nodelist is created? Once the length is 1? Something else? The spec for NodeList would state that the supported property indices for the object would be all of the integers in the range 0 ≤ index ≤ length, where length is the number of items in the node list. With this definition, yes it would be once the length is 1. In particular, the interaction with existing properties interests me. That indeed is the tricky bit. :-) If I set document.links[5] while the document has 3 links and then I add 3 more links, what is the value of document.links[5]? Per the spec as currently written, assigning to document.links[5] would create a property that is not one of the special ones automatically created. Then getting document.links[5] would get you the value you just assigned to it. If you then add three more links, then the value of the document.links[5] property would be set to the appropriate HTMLAnchorElement object, and you’d lose your original value. However, and this doesn’t seem sensible, because the 5 property already exists at the time the sixth link is added, it does have its attributes set appropriately (e.g. ReadOnly if there is no index setter), since they’re defined to be set only when such a property is created automatically. That seems like a bug with the current design. What if I had 6 links to start with? Then assigning to document.links[5] would fail silently, as the property would be ReadOnly (assuming NodeList not defined with an index setter). Anyway, all of this seems a bit complicated and if we can get away with a simpler model, such as how ES Array objects work, I’d rather that. The only reason the current design is defined somewhat indirectly, and defined as creating actual properties on the object (rather than handling all of it within the [[Get]] and [[Put]]), is so that ‘in’ and Object.hasOwnProperty() return true appropriately. There’s no spec hook in ES3 (or ES5 I think) to change how ‘in’ works on host objects. All that can be done is to make those properties actually exist. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
Allen Wirfs-Brock: The internal methods such as [[Delete]] aren't an actual extension mechanism. They are a specification device used to define the semantics of ECMAScript. As such they are subject to change (there are significant changes in the ES5 spec.) and could even completely disappear if some edition of the ES specification chooses to adopt a different specification technique (which has been discussed). OK, that is indeed what I’m hearing from you guys. “Host objects may implement these [internal] methods in any manner unless specified otherwise” in ES3 doesn’t sound like it’s particularly discouraging of the different behaviour that Web IDL prescribes. Another issue with using specification internal methods as if they were an extension mechanism is that the ECMAScript specifications doesn't define any abstract contracts for them. What are the invariants that every [[Delete]] methods must maintain in order for the entire language to remain sound? It isn't currently defined. Or, defined to be “you can do anything”. Which admittedly isn’t useful if you are indeed trying to maintain some invariants. Within the ES spec. this isn't a big problem because most of the internal methods only have one definition within the ES specification and if there are more than one they have been designed with a unified semantics in mind. Why is functionality that isn't available through native objects needed? For web compatibility, really. If it is possible to define Java bindings for WebIDL that don't require extending the Java language why isn't it possible to approach JavaScript in the same manner (for new APIs, I understand the legacy issues). Java really doesn’t have those compatibility issues. Ignoring the legacy issues, assuming we have ES5 to build on, then yeah it seems like most things can be done (from Maciej’s quick analysis). The array like objects do seem like a useful pattern for authors to use, though. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
Maciej Stachowiak: - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. Allen Wirfs-Brock: Seems like a strong reason to change to the proposed API to eliminate the need for a new ES language extension. When writing Web IDL originally, it didn’t seem at all to me that host objects were a disapproved of mechanism to get functionality that can’t be implemented with native objects. So having a [[Delete]] on a host object be different from the Object [[Delete]] or the Array one seemed fine to me. -- Cameron McCormack ≝ http://mcc.id.au/
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
Hi Brendan. Brendan Eich: The struggle to formalize ArrayLike, which seems like a common goal for ES the core language and for WebIDL's ES bindings, makes me want to give an exception to the catchalls considered harmful for new interfaces injunction. I agree that indexing into array-likes, with no liveness magic, seems containable and desirable. ES folks haven't nailed down ArrayLike yet (our fault) and we would benefit from collaboration with WebIDL folks here. So currently in Web IDL there are three ways to get objects with properties that have non-negative integer names: sequences, arrays and regular interfaces with index getters. The definitions for sequenceT and T[] types in Web IDL are relatively recent, but they are probably more in line with the kinds of thing you’re looking for with ArrayLike (without having re-read that thread yet). The main difference between sequences and arrays is that sequence types are effectively pass-by-value and use native Array objects, while array types are host objects that act similarly to native Arrays, but with appropriate IDL ↔ ECMAScript type conversions. IDL arrays have the native Array prototype object in their prototype chain. A given IDL array an be designated as read only, so that assigning to length or array index properties has no effect. There are no ES implementations of IDL sequences or arrays yet as far as I know. The third way, defining a regular interface with an index getter (and maybe a setter) is currently used. It’s implemented with special [[Get]] (and [[Put]]) behaviour, which I guess is what you would like to avoid. However it’s not just a simple catchall – such objects are defined to gain and lose properties with the appropriate index names as appropriate for the interface. This is done pretty much just so that ‘in’ and hasOwnProperty return true for array index properties, which is needed for HTMLCollection and the like. (Cross-posting to these three lists makes me feel funny, although I recognise that these issues involve all three groups.) -- Cameron McCormack ≝ http://mcc.id.au/
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
Maciej Stachowiak: Now, there may be pragmatic reasons for avoiding catchall getters and setters: … Mark S. Miller: Yes. As an obvious example of #3, what happens when a Storage http://dev.w3.org/html5/webstorage/ key is toString? It’s a good example of something that’s not obvious, though it is defined. If [OverrideBuiltins] is on the interface, then toString is taken as a a named property; otherwise, it’s the property from the Storage prototype object. This is handled by the host object [[Get]] method: http://dev.w3.org/2006/webapi/WebIDL/#get -- Cameron McCormack ≝ http://mcc.id.au/
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
Hi everyone. Sam Ruby: At the upcoming TPAC, there is an opportunity for F2F coordination between these two groups, and the time slot between 10 O'Clock and Noon on Friday has been suggested for this. I'm travelling at the moment, so apologies for the delay in replying. Unfortunately I won't be attending TPAC, but I am sure some useful discussions will come out of the meeting between those TC 39, Web Apps and HTML WG people who can attend. I will be in Mountain View from Saturday for 11 days (for SVG stuff), so I could probably find some time to meet with interested people if that's deemed to be a good idea. Some general responses to questions raised in this thread: • I agree that a better solution for the multiple inheritance problem is needed. • Web IDL is somewhat poorly written at the moment, so it would indeed be good to make it easier to follow. I do think the spec is aimed at implementors rather than authors, though. I look forward to increased collaboration with the ECMA folks on the spec!
Re: WebIDL roadmap?
Cameron McCormack: I’m open to suggestions on how to proceed. Splitting the spec into parallel 1.0 and 1.1 versions could be done, but not without a little effort. Robin Berjon: Based on what you've said I'd figure that the best might be to move it to LC soon, as planned, and if it gets stuck there and starts delaying too many other specs we can do the split thing. One advantage of having been to LC is that we'll have a very good view of where the issues really are. That sounds like the best way to proceed. -- Cameron McCormack ≝ http://mcc.id.au/
