Re: [whatwg] Document.title for SVG documents
Ian Hickson wrote: I'm all for handling it in one place. What precisely do you want the behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- the first svg:title element may come after the firsthtml:title element, and vice versa. Also consider when one or the other is primary but the relevant element is absent.) OK, how about: if the document element is an html:html, we choose the first html:title in document order; if the document element is an svg:svg, we choose the first child svg:title of the document element; otherwise, null. This still is going to produce incorrect results for things like: !DOCTYPE html svg foreignObject titleblah/title /foreignObject /svg but arguably you shouldn't be using title in there anyway.
Re: [whatwg] Document.title for SVG documents
Jonas Sicking wrote: An even simpler solution would be to say we choose the first html:title orsvg:title in document order. That has the nice property that we align SVG and HTML more. Although as Dirk pointed out, SVG distinguishes title elements that are children of the root element vs children of other elements. The title that is a child of the root element gives the title of the entire element, while a title child of another element in the document describes only that element (like title= does in HTML).
Re: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus
Cameron McCormack wrote: Document.activeElement is currently defined to return the body element if there is no element with focus, or null if there's no body element. I think it needs to return the root element when the document isn't an HTML document (like an SVG document). Anne van Kesteren wrote: You mean when there's no body element? When the document isn't an HTML document and when there is no element with focus. Browsers agree on returning null in an HTML document when there is no element with focus, no body element, but still a document element.
[whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus
Document.activeElement is currently defined to return the body element if there is not element with focus, or null if there's no body element. I think it needs to return the root element when the document isn't an HTML document (like an SVG document).
[whatwg] Document.title for SVG documents
Currently, HTML defines Document.title on SVG documents to defer to whatever the SVG specification defines for SVGDocument.title. The SVGDocument interface has gone away, so this will need to be updated. From some basic testing, it looks like SVG needs the same behaviour as HTML -- first title element in the document, plus the white space collapsing behaviour. Do you want to just handle that all in HTML? I'm not sure there's much value to duplicating either the searching for the title element or the white space collapsing behaviour in SVG itself.
Re: [whatwg] Document.title for SVG documents
On 1/02/2014 9:01 pm, Cameron McCormack wrote: Do you want to just handle that all in HTML? I'm not sure there's much value to duplicating either the searching for the title element or the white space collapsing behaviour in SVG itself. Oh, and for the setter, it looks like implementations don't do anything when assigning to document.title in SVG documents. (Chrome does something funny where it remembers what you assign to document.title, but it doesn't affect what's in the title element.) I don't have a strong opinion on whether we should make the setter do something useful or nothing at all. If we do, any newly created title element should be appended to the document element.
Re: [whatwg] Document.title for SVG documents
On 1/02/2014 10:01 pm, Dirk Schulze wrote: Could you be more specific about that? It is not just the first title element in the document, but the first direct child of the element root. That is what the spec says but that is not what implementations do. A title nested in a group or graphical element has a different meaning and shall not be used as title. If there is a nested title element but no direct title child of the SVG root, then the document has no title. This distinction is important for accessibility. Sure. I'd be happy with keeping the special SVG behaviour here too. Ian, if you still would prefer a hook in the SVG spec for you to refer to, rather than including this behaviour -- first title child of the document element -- then I can define for example SVG title element that represents that element.
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On 22/01/2014 3:09 pm, Boris Zbarsky wrote: Or neither, if desired. In Gecko we don't expose the SVG* properties in IDL at all... We decided against requesting adding an onzoom attribute to GlobalEventHandlers to avoid any complications with whatever solution comes out of the CSSWG who are looking into new zoom related functionality (which possibly could come out with an event named zoom, which then might be incompatible with SVGZoom).
Re: [whatwg] Form data append behavior on null type
Tingan Ho wrote: Wouldn't it be good to specify the behavior of type null in *append* method of Form data? Right now Safari sends string* null.* Chrome sends empty string . I think Chrome's implementation is more right, because in a html form you can't send null value, just empty strings http://www.w3.org/TR/XMLHttpRequest2/#the-append-method The specification, through the use of Web IDL, requires that null be sent. Unless there is a clear majority of implementations that send , I don't think we should change from the default stringification behaviour.
Re: [whatwg] Range.createContextualFragment in SVG contexts
Hi Victor, Victor Costan wrote: I'm trying to re-implement Range.createContextualFragment in Blink following this whatwg spec: http://domparsing.spec.whatwg.org/#extensions-to-the-range-interface There are two issues I'd like to discuss, related to the use of createContextualFragment in SVG contexts. 1) If a Range's context is ansvg element, I think the XML parsing algorithm should be selected, so the elements in the resulting DocumentFragment would get the SVG namespace. This way, inserting the fragment in ansvg tree would have the intended effect. Examples: https://bug711821.bugzilla.mozilla.org/attachment.cgi?id=582654 (the red circle should be completely covered by a black circle) https://codereview.chromium.org/115693010/diff/70001/LayoutTests/fast/dom/Range/create-contextual-fragment-from-svg-element-range.html I think it would be unexpected that XML parsing is used here, when HTML parsing was used to get the SVG fragment in the document in the first place. Maybe the HTML fragment parsing algorithm should be changed to push the svg element on to the stack of open elements so that the parser will interpret the circle .../ as foreign content?
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
Cameron McCormack wrote: OK. I propose then that we allow [Unforgeable] on the interface, which means: * attributes get own, non-configurable accessor properties (with setters if they are not readonly attributes), and no property on the prototype * operations get own, non-configurable, non-writable properties, and no property on the prototype * the stringifier gets an own, non-configurable, non-writable toString property, and no property on the prototype * there is an own, non-configurable, non-writable valueOf property that just returns this I think that's the least amount of crazy. I've done this now: http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.632;r2=1.633;f=h http://dev.w3.org/cvsweb/2006/webapi/WebIDL/v1.xml.diff?r1=1.80;r2=1.81;f=h
Re: [whatwg] Why are we merging Document and HTMLDocument again?
Dirk Schulze wrote: We can not eliminate SVGDocument until you want to have SVG specific attributes on Document ;). This was not the discussion on the SVG WG. But we do want to share all methods with HTMLDocument where is makes sense, which are most of them. HTMLDocument, as noted by Boris, have specific methods as well that we do not necessarily want in a general scoped Document object. We did discuss and agree to this last year: http://www.w3.org/2012/09/19-svg-minutes.html#item04 and Erik made the change shortly afterwards. https://svgwg.org/svg2-draft/struct.html#InterfaceSVGDocument The only interesting attribute there is rootElement. And that isn't particularly interesting, though people do use it, so we can't get rid of it. I don't think there's any real downside to having rootElement exist on all Document objects.
[whatwg] supporting HTMLElement.dataset on SVG elements
As part of aligning SVG with some not-so-HTML-specific features of HTML, the SVG WG would like to support data-* attributes on SVG elements. In mixed HTML/SVG documents, it seems like you would want to be able to use these attributes regardless of whether the elements are HTML or SVG, or indeed MathML. Does it make sense to move HTMLElement.dataset up to Element, so that all elements can benefit from it? If not, could this attribute be split out on to a separate interface that we could have SVGElement implement? (I'm also going to be looking at the other global attributes that HTML elements have to see if any make sense in SVG too.) Thanks, Cameron
Re: [whatwg] proposal: Add support for masking to canvas
On 30/01/13 6:28 PM, Ian Hickson wrote:
That's weird. heycam, can you elaborate on this? The addHitRegion() case
in particular never makes sense to be called without a dictionary
containing at least one member. Do we have to allow it?
This is to encourage (require, really) API design that allows the
dictionary object to be not specified at all. Remember that all
dictionary members can be not specified anyway.
Do you want addHitRegion() to throw just like addHitRegion({}) would
throw? That will happen if you already have wording to say that
addHitRegion({}) will throw.
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 16/12/12 9:34 PM, David Bruant wrote: WebIDL needs to embed in some way the notion of origin to enable throwing for security reasons in the right places. One idea would be to add an [OriginAware] extended attribute: * On operations (like in Boris case), an origin check would be performed before calling the core of the operation Why would this need to be on specific operations and not just be enforced on every operation? Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? * On attributes, both the getter and setter would throw if this is not of the right origin. * On interfaces, it would apply to everything (might be necessary for Window and Document) For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from.
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On 8/01/13 7:31 AM, Ian Hickson wrote: heycam, did we resolve this at the WebIDL level by any chance? Or is this still open? (If the latter, is there a bug# for it? Or is this an HTML problem I need to fix myself?) No, this didn't get resolved. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20225 is the open bug. I will respond there. On Mon, 3 Dec 2012, Boris Zbarsky wrote: I have to ask: are there languages or runtime systems that have that sort of behavior on method calls (as opposed to in method implementations in special cases where the operation is nonsensical)? It seems weird to be requiring this behavior, in general. Most languages, if you invoke the method of a superclass on an object of a subclass that overrides that method in an incompatible way, will just let you crash the application. This isn't an option for us. It might crash, but I'd say that's a bug in your class design that a superclass method cannot be called on a subclass.
Re: [whatwg] Styling details
I'm wondering if anybody has had any further thoughts on how summary and details should be made stylable. My initial feelings were along the lines of Tab's -- the disclosure widget feels very much like something that is created like a list bullet and matched with ::marker. But reading Ian's reply I'm beginning to think that this is inadequate, as some platforms may not use a small separate widget for expanding/collapsing the details at all, and thus at some point in the future a binding should be used to define the element's native behaviour, and authors could switch that off with binding:none to get a stylable element. But I also feel that authors should be able to get a useful, stylable presentation of the element without having to construct it themselves, e.g. by using the UA styles that Lachy suggested. Would it be feasible to have a native presentation of the element, which you could opt out of with binding:none, and to have something like Lachy's styles apply when the native binding isn't being used? When the native appearance is being used, should it be possible to target the disclosure widget with ::marker, or to be able to use list-style-type to change from the default disclosure widget, if the natural presentation of a details/summary for the platform is like a list bullet? If that is not the way the platform would present a details/summary, should attempting to style the bullet automatically turn off the native rendering? One thing that I don't like about thinking of the disclosure widget as a list bullet is that it requires the element to have display:list-item. I am not sure how useful it would be to have a summary element be inline or inline-block for example, but I feel like it would be good to support the creation of the ::marker in a manner independent of the display type. But I am drawn to the idea of using list-style-type to specify the plain CSS disclosure widget appearance. It seems natural to me for authors to use list-style-image to supply a custom image.
Re: [whatwg] Canvas: dash list API
On 22/12/12 10:06 PM, Anne van Kesteren wrote: Is there not some way we can have a lineDash attribute that returns a manipulatable object that inherits from Array rather than the current Java-like API? I remember this was discussed when getLineDash() and setLineDash() were added, but I think it's worth taking another look at this. (For URLs I want something similar for path segments and I'd rather not introduce get/set methods.) Does it need to inherit from Array? I think we can do this as long as the canvas context object does not need to watch the Array object for changes. (This is technically already possible by just using object as the type, and handling assignments of non-Array objects in the attribute definition.) We could have an Array type in Web IDL, which just means a reference to an Array object and which also doesn't do any type coercion when assigning to array elements or anything.
Re: [whatwg] Canvas: dash list API
On 23/12/12 12:40 AM, Anne van Kesteren wrote: I guess dashList is somewhat simpler, but I think it would be nice if it still did type coercion. In that case, I guess we are reliant on whatever ES-allowed Array extending is possible, and I haven't followed that for a bit. Is this actually possible now?
Re: [whatwg] Canvas: dash list API
On 23/12/12 1:01 AM, Tobie Langel wrote: Array-like objects which don't inherit from the Array object and are thus missing methods one would expect to find on them (forEach, join, etc.) is one of the biggest WTF of the Web platform. We should be doing whatever it takes to fix this. I agree that that would be confusing. I think there is some tension between having an Array subclass so that assignments to array elements can be type checked (and so they an be notice by the owning object) and being able to assign a new Array object. For example it seems reasonable to be able to do: ctx.dashList = [5, 10]; but then after this assignment is dashList a NumberArray (or whatever we would call the subclass), and thus not the same object that you assigned? var a = [5, 10]; ctx.dashList = a; a.push(20); If the Array object were converted into a NumberArray, then the a.push() call wouldn't affect the dashList. If we don't have the type checking of array elements, and also don't need any noticing of individual element assignments, then we can just have a reference to a plain Array object and look at its elements at the time the dash array is needed. That could preserve the author expectation that after assigning a new Array object to the property you would get the same object back when getting the property.
Re: [whatwg] Make the files attribute of the input element writable
On 16/12/12 2:05 PM, Boris Zbarsky wrote: There's no way to express that in WebIDL, but I think that's a bug we should fix in WebIDL. We should allow getters and setters for attributes to accept different IDL types... Yeah, that has come up a couple of times now. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20407.
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On 4/12/12 6:31 AM, Boris Zbarsky wrote: It's a similar situation, yes. But in this case I don't see why you'd need an IDL annotation of any sort at all. If you want the behavior to be the same, just don't define onscroll on Bar at all and define the one on Foo to special case the two Foo subclasses you care about here. If you don't want it to be the same, the IDL annotation doesn't help you. I agree. But if you we really do need a separate namedItem (for bug 17201) on HTMLPropertiesCollection, then there is no harm in having it too, but I would have it not work on other HTMLCollection objects. So I think my suggested solution for that bug is: * Have the definition of HTMLCollection.namedItem include a hook that other specifications can override for descendant classes like HTMLPropertiesCollection. * Do that overriding for HTMLPropertiesCollection. * Not define a distinct namedItem on HTMLPropertiesCollection. I can see that if you did still include a namedItem on HTMLPropertiesCollection with its special behaviour, then you could save yourself effort by putting an extended attribute on HTMLCollection's one (which means delegate to the subclass) but I don't think it's really necessary. (I will put the above in the bug.)
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On 4/12/12 11:33 AM, Ian Hickson wrote: Per our IRC discussion just now, I think I would propose that when a method/setter/getter from a prototype of interface A is called against an object that is of an interface B (or one of B's descendants), where B is a subclass of A, and B defines its own method/getter/setter with the same name, then it should throw. I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20225 for that.
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On 4/12/12 12:11 PM, Boris Zbarsky wrote: Hmm. That, as phrased, is pretty complicated to implement in a performant way, if the two methods/getters/setters have the same signatures... Since I'm not terribly familiar with our generated bindings code, I'm not really sure what that would be. Is there a phrasing that would not be so complicated but does the same thing? :)
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
Boris Zbarsky: I guess from my point of view, extending the existing member [Unforgeable] to a wider class of members without changing anything else about it seems simpler than having two separate meanings to [Unforgeable] depending on what it's decorating... But maybe we're thinking about simplicity in different contexts? (Note we'll still need single-readonly-attribute [Unforgeable] for several properties on Window and Document, no matter what we do with Location.) I did forget this. My simplicity involved getting rid of [Unforgeable] interface members, so obviously we can't do that then. But I don't like having to add a valueOf operation to the IDL. So maybe we can a separately named extended attribute on the interface that results in valueOf being unforgeable. What about other functions from Object.prototype, by the way? toLocaleString, watch, hasOwnProperty, etc.? If there are a bunch of properties (that don't correspond to IDL members) that need protecting, maybe handling it in [DefineOwnProperty] is the simplest thing to do.
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
Boris Zbarsky: So we have indications that making everything on this interface unforgeable is sufficiently web-compatible. OK. I propose then that we allow [Unforgeable] on the interface, which means: * attributes get own, non-configurable accessor properties (with setters if they are not readonly attributes), and no property on the prototype * operations get own, non-configurable, non-writable properties, and no property on the prototype * the stringifier gets an own, non-configurable, non-writable toString property, and no property on the prototype * there is an own, non-configurable, non-writable valueOf property that just returns this I think that's the least amount of crazy. This would make Location.prototype empty. Is that OK?
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
Boris Zbarsky: I can live with this, but why is this better than just allowing [Unforgeable] on all operations and attributes and defining an object valueOf(); /* returns self */ on Location? If we really do want to make all Location interface members be unforgeable, then moving the [Unforgeable] up to the interface seems like a nicer way to indicate that. It also means we don't have to pretend we really are defining a useful valueOf operation.
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
Boris Zbarsky: I guess the question is whether we're more likely to need [Unforgeable] on some other entire interface or whether were more likely to need [Unforgeable] on a single member that's not a readonly attribute. Of course we might never need either one... I'm inclined to simplify now (by moving [Unforgeable] to the interface) and worry about it later if we need to.
Re: [whatwg] WebIDL nested interfaces
Tobie Langel: No. It sounds like I should be fast asleep instead of making a fool of myself and wasting everybody's time. It is however the kind of thing that Tab wants to do for CSS (have a window.CSS object that is like a namespace object for some CSS interfaces -- the concept for which used to exist in Web IDL a while ago, but which I removed due to disuse). So it might well make sense to add something to Web IDL to handle this again.
Re: [whatwg] classList should perhaps move from HTMLElement to Element
Rik Cabanier: There was a discussion in the SVG WG about dropping the SVGAnimatedxxx objects and have replace them with regular values. We would need some tricks so we can change the DOM, but make it backward compatible at the same time. We have discussed this a few times, and I would desparately love for it to work, but I am unconvinced it will. I can an imagine an author writing code like: if (!elt.className) ... to test if a class has been set. Even if we made the SVGElement.className SVGAnimatedString object one that stringifies to the class, add a [PutForwards] on to it so that assigning a string works, it would still break the above code, since the ! operator always returns false for an object.
Re: [whatwg] classList should perhaps move from HTMLElement to Element
Rik Cabanier: Who would do this in the current SVG world? As you say, (!elt.className) would always return false... Are you worried that new content won't work with an old viewer? No that would actually continue to behave the same. So I misspoke when I said things will break -- author expectations will break instead if they assume that that code which works on HTML elements would also work on SVG elements. But maybe that's OK?
Re: [whatwg] Changing the type of event.dataTransfer.types
Daniel Cheng: We've reverted it back to an Array in WebKit. Should the live requirement remain if it's an Array rather than a DOMStringList? I would think so. Note that if the spec is changed to readonly attribute DOMString[] types; it means that the object returned from that property is a platform array object, not a JS Array object.
Re: [whatwg] link.sizes and [PutForwards=value]
Cameron McCormack: The two Location objects stringify to the same thing, but are not ==. I think this can be confusing. Ian Hickson: Can we overload equality for objects? No, not within the confines of ECMAScript.
[whatwg] API design restrictions due to barewords in onxxx= attributes
This problem of using bare variables names rather than window.variableName in event handler attributes (which Boris mentions in https://developer.mozilla.org/Writing_Forward_Compatible_Websites) seems annoying. Is there any way we can avoid it by codifying current property lookup behaviour for all existing properties on elements/Document/Window while allowing newly introduced properties not to be found when using bare identifiers? I think we could have an object on the scope chain (when onxxx=s are run) that will, instead of having names resolved in this order: 1. look on element 2. look on element's form (if it has one) 3. look on document 4. look on window (which I assume is achieved by simply having those four objects on the scope chain in that order) does this instead: 1. if property name is in set S, then: a. look on element b. look on element's form (if it has one) c. look on document otherwise: a. look at element's named properties (if it has any) b. look at element's form's named properties (if it has a form) 2. look on window where S is the set of property names corresponding to * the IDL attributes, operations and constants on element's interface, * those on HTMLFormElement (if the element has a form), and * those on Document for the current set of APIs we have deployed. Would this work? Does it sound too brittle or hacky?
Re: [whatwg] Declarative Inert DOM (e.g. the template element)
On 18/11/11 8:21 AM, Adam Barth wrote: Another option is to tokenize the elements as usual, but put them into a new document created for thetemplate element (presumably using the usual tree-building rules). Because this document won't have a browsing context, all the elements would be inert, like they are for documents created by XMLHttpRequest. The site could access this document via a templateDocument (or whatever) property on HTMLTemplateElement. This would introduce a pretty big difference between text/html and XML parsing of HTML documents.
Re: [whatwg] link.sizes and [PutForwards=value]
On 2/08/11 6:29 AM, Tab Atkins Jr. wrote:
It's a confusion shared by all objects, though:
var x = [1,2];
var y = [1,2];
alert([x,y,x==y).join(' ');
This alerts 1,2 1,2 false.
That is true, but I get the impression that some authors don't know that
the Location object is actually an object rather than a string.
I don't feel like [PutForwards] is a particularly obvious API design
pattern for authors, and I don't think we should be adding new uses of it.
Re: [whatwg] link.sizes and [PutForwards=value]
Jumping in the middle of this thread to pick up on one aspect...
On 28/07/11 6:15 PM, Ian Hickson wrote:
Are we really concerned about objects stringifying to [Object Foo]?
It seems that the usefulness of such stringification is far outweighed by
the usefulness of being able to treat the attribute as a string attribute
like any other reflecting attribute while also being able to use methods
on it. In fact, it is consistent with every DOMString attribute: they
don't stringify to [Object String], yet you can call methods on them.
What's the difference?
There is a disadvantage. In JS, doing a comparison between two objects,
regardless of whether they have custom stringification behaviour, will
compare based on object identity and not the string.
!DOCTYPE html
iframe id=x src=b.html/iframe
iframe id=y src=b.html/iframe
script
window.onload = function() {
var xw = document.getElementById(x).contentWindow;
var yw = document.getElementById(y).contentWindow;
alert([xw.location, yw.location,
xw.location == yw.location].join(\n));
};
/script
The two Location objects stringify to the same thing, but are not ==. I
think this can be confusing.
Re: [whatwg] on* attributes on DOM elements
On 28/07/11 6:59 PM, Boris Zbarsky wrote: Why, exactly? I thought for SVG the evt thing was only relevant for content attributes, not IDL attributes. That's right. (Maybe Anne meant the Function used internally for the content attribute?)
Re: [whatwg] Nullable types and MediaStreams
Per-Erik Brodin: Maybe the null-check in step 3 under When the PeerConnection() constructor is invoked .. should not be there anymore since signalingCallback is not nullable. Yes, that step’s not necessary any more. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Nullable types and MediaStreams
Per-Erik Brodin: The DOMString arguments 'options' and 'configuration' are never referred to as being null, and thus I think it is safe to assume that they will not be null and that the default conversion rules apply (http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString). The callback arguments are all referred to as being null so I think it is safe to assume that they can be null. Interface types now *do not* include null as one of their values unless you make the type nullable explicitly. The HTML spec hasn’t been updated for this yet, though I have written a patch to do so: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640 -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Media Stream API: What is the intended behaviour for undefined mandatory arguments?
Tommy Widenflycht (ᛏᚮᛘᛘᚤ): Could we have some clarification for the below cases, please: var u; var n = null; // Should throw since u is undefined or just abort? navigator.webkitGetUserMedia(audio, u); I don’t think Ian has made changes to the spec yet regarding interface types not including null unless explicit made nullable. So let me assume for now that the spec says void getUserMedia (in DOMString options, in NavigatorUserMediaSuccessCallback? successCallback, in optional NavigatorUserMediaErrorCallback? errorCallback); which I think is supported by the prose describing the method. null therefore is a value that can be passed to the two callback methods. Per Web IDL at the moment, when there is no overloading, the types of values passed to a method do not determine whether the call is to that one unoverloaded method or not; it is assumed that you are calling that method. Therefore, each argument will just get converted according to the rules in http://dev.w3.org/2006/webapi/WebIDL/#es-types. This is a nullable type, so we look at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/WebIDL/Overview.html?rev=1.292;content-type=text%2Fhtml#es-nullable-type (as the spec looked earlier today). Here, any value other than null is converted according to the inner type. There is a bug here: those rules should also explicitly consider undefined as a JS value that is converted to an IDL null value. Otherwise you would end up with a TypeError being thrown here, and I don’t think that’s what you want. It’s also inconsistent with what the spec used to say before I made the recent change where null was removed from interface types. I’ve just fixed this bug now: http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type So if you pass undefined for successCallback it will be treated as null. // Will not throw but will abort. navigator.webkitGetUserMedia(audio, n); Right. // Should throw because we are expecting at least two arguments. navigator.webkitGetUserMedia(audio); Actually this should behave as if you called getUserMedia(audio, undefined). This is because of the different behaviour for overloading I mentioned above; when there is overloading, you will get a TypeError thrown if the number of actual arguments doesn’t match the expected number of formal arguments for one of the overloads. This difference in behaviour is sucky, and I’ll be looking at improving this in Web IDL soon. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Media Stream API: What is the intended behaviour for undefined mandatory arguments?
Aryeh Gregor: But there's an open issue that says Need to test how implementations actually behave when passed too few or too many arguments. So I wouldn't assume the standard is right. Maybe data would be useful on how different browsers behave here -- although I suspect that it will vary greatly from method to method. I can tell you from experience that Gecko throws if you pass fewer than three arguments to document.execCommand(). It makes sense to me -- if we want the API to not throw if the argument is omitted, why isn't the argument optional? It could be that the default coercion from undefined is acceptable, be that throwing a TypeError, or being converted to false, etc. Some months ago, after meeting with the TC39 folks, we came out with the proposal to make Web IDL be relaxed, i.e. assume undefined for missing arguments and allow additional arguments to be ignored, which I mailed to public-script-coord, but I didn’t see any pushback on that. Since this is something that I want to resolve soon, it might be worth my bringing it up on the list again. At the very least, though, I want the behaviour of non-overloaded and overloaded operations to be the same. The current behaviour is confusing. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] [Bug 12287] Restrict sequenceT to operation argument types and return types
and...@ado.is-a-geek.net: Can MessagePortArray be changed to be some kind of collection like many of the other places in DOM when we want a list of children? This would probably be easiest for me, but perhaps there is a better way. I suggest just changing the typedef to `typedef MessagePort[] MessagePortArray;`, and define MessageEvent.ports to be a read only array. http://dev.w3.org/2006/webapi/WebIDL/#dfn-read-only-array An alternative would be to define a new collection interface for the attribute, as you suggest. But for the arguments to MessageEvent.initMessageEvent() and MessagePort.postMessage() these would need to be sequence or array types so that you could pass in a JS Array object. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] ArrayBuffer and the structured clone algorithm
Anne van Kesteren: ImageData.data you mean? I wonder if we can still remove CanvasPixelArray. Tab Atkins Jr.: Only if the out-of-bounds behavior for entries in Typed Arrays matches the current clamping behavior for CanvasPixelArray. I don't see any explicit indication of what should be done in the Typed Array spec, which I suppose means that they're relying on WebIDL's coercion algos to keep things in-range for the given view. WebIDL has the wrong behavior here right now (it wraps), though I think heycan is receptive to changing it. This is http://www.w3.org/Bugs/Public/show_bug.cgi?id=10930. Kenneth Russell: For this reason I think we need to keep CanvasPixelArray distinct. I certainly hope that Web IDL does not change its conversion rules to mimic the clamping behavior in CanvasPixelArray. Right now Web IDL delegates to the ECMA-262 specification for primitive conversions, which have the wrapping behavior of C-style casts rather than clamping behavior. Forcing clamping for out-of-range integer values would impose a significant negative performance constraint on typed arrays. So it seems at this stage CanvasPixelArray definitely needs to have the clamping behaviour. If people have opinions on whether all JS Number → IDL integer type conversions should clamp or wrap, or whether Web IDL should just have an annotation to indicate what kind of conversion is used, please comment in the bug. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable
Charles Pritchard: The content within an editable area is already exposed: xhr is available. That is data that the user has explicitly typed in, though. I understand that a 'custom' system dictionary could expose private data ... Just as 'suggestions' on form elements do. Suggestions on form elements can’t be accessed by script on the page. They only expose information that the user selects. What breach is enabled by using a limited spell check? (What does “limited” mean?) If script can programmaticaly get at the spell check results, then it exposes whether particular words are in the user’s dictionary to that page. The assertion is that it is a violation of the user’s privacy for a web page to know whether a word is in the user’s dictionary or not. An API to perform spelling checks and return their results would expose this information. As currently handled, spelling checks are done purely at the UI level, and information about the dictionary is not exposed to script. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
Boris Zbarsky: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. Would classList provide access to the SVG element’s base or animated value of class=? Base probably makes more sense. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Orientation event in Firefox
Simon Fraser: What you're talking about here is getting data from the accelerometer to describe arbitrary positions, so I think it would be clearer if these were called accelerometer events, or something else that distinguishes them from the usage that only applies to the cardinal angles. What about “attitude”? -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] question about Web Storage setItem()'s behavior
Boris Zbarsky: Given the actual example code (and not its description, which doesn't match the code), the relevant section is http://dev.w3.org/2006/webapi/WebIDL/#es-operations steps 1 through 3 in the third bullet point. It looks to me like per the current spec text that will throw a TypeError for the above call, unless the second argument to setItem is marked [optional]. Yeah I think that’s right. I’ll just note though that behaviour when passing too many or too few arguments is still an open issue (although it’s more likely that the ‘too many’ case will change than the ‘too few’ case). OTOH, passing in undefined explicitly as the second argument would have it converted to the string undefined. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] New HTML5 spec GIT collaboration repository
Manu Sporny: 3. Running the Anolis post-processor on the newly modified spec. Geoffrey Sneddon: Is there any reason you use --allow-duplicate-dfns? I think it’s because the source file includes the source for multiple specs (HTML 5, Web Sockets, etc.) which, when taken all together, have duplicate definition. Manu’s Makefile will need to split out the HTML 5 specific parts (between the !--START html5-- and !--END html5-- markers). The ‘source-html5 : source’ rule in http://dev.w3.org/html5/spec-template/Makefile will handle that. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Codecs for audio and video
Matthew Gregan: The reason for not selecting a video codec doesn't seem to have much weight when considering Ogg Vorbis as a required audio codec. Apple's submarine patent argument doesn't seem to hold, as many deep-pocketed companies (including Microsoft) have shipped products with Vorbis support. It might also be worth pointing out that the existing working draft of SVG 1.2 includes a requirement for Vorbis support (http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#audio-format). That’s an old draft of a specification that never got to completion, but the audio element was lifted from that and put in SVG Tiny 1.2: http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioElement which says: This specification does not mandate support for any particular audio format. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Overriding functions in DOM Storage
(and a corresponding indexed property 0) // is created on window.sessionStorage. // This evaluates to 123. window.sessionStorage.removeItem; // This calls // window.sessionStorage.removeItem.[[Delete]](removeItem), which // invokes the name deleter behaviour because removeItem is the name // of a corresponding named property. delete window.sessionStorage.removeItem; -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Overriding functions in DOM Storage
Cameron McCormack: Another edge case: … // Just a normal property deletion... delete Storage.prototype.removeItem; Actually I just realised that this won’t work, since properties that correspond to operations are DontDelete. But this and the other example can still demonstrate when corresponding named properties get created and removed if you use Storage.prototype.blah, for example (which when created wouldn’t be DontDelete). -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
Ojan Vafai: 2) Add a css or xpath expression to fragment identifiers. Tthe iframe src can be set to http://foo.com#css(.foo #bar). Same as above applies. If there's no match, it's a noop. If there is a match, it scrolls the first one into view. Sounds like XPointer: http://www.w3.org/TR/xptr-framework/ -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] WebIDL vs HTML5 storage changes - delete behavior
Ian Hickson:
For DOMStringMap, my intention was to not provide methods at all, and
only provide the JS-native mechanisms.
Maciej Stachowiak:
A bold choice, but I would not recommend it as the sole available
mechanism.
Ian Hickson:
See above for UndoManager, but for DOMStringMap I don't want to add any
other mechanisms, because they introduce name clashes. Right now the IDL
for DOMStringMap is:
[NameCreator, NameDeleter, NameGetter, NameSetter]
interface DOMStringMap {};
It basically emulates a JS Object. It's intended only for JS. I don't see
why this is a bad idea.
At the moment, the interface is useful only for JS (and other languages
that support this kind of indexing). For other languages, a
DOMStringMap object would appear to be a completely opaque object
without any means of interacting with it. Given that this is basically
meant to be a shorthand for getting/setting attributes with particular
names, I would be happy with it not existing in other language bindings.
Web IDL doesn’t have a mechanism to state that an interface member or a
definition should only be included if the target language binding is a
particular one, though.
An alternative would be to put operations on the interface to act as the
getters/setters/etc., and use the [NoIndexingOperations] extended
attribute to indicate that these operations won’t correspond to
properties in language bindings such as ECMAScript. That would then at
least make the interface useful for other languages.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] DOM Storage feedback
Jonas Sicking: I talked with Cameron a while ago about what the default behavior should be for null. We couldn't find any functions that required that null be treated as null, but there are several examples of functions that require that null be treated as the empty string. I began testing all attributes and operations with DOMString arguments from a selection of specs for their behaviour wrt null and undefined: http://mcc.id.au/2009/01/string-handling/string-handling Each pair of characters in the column for a browser is the behaviour for null and undefined, respectively. It’s nowhere near complete, though you can see that there are some operations arguments and attributes that stringify null to null (“S” in the column). -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] DOM Storage feedback
Jonas Sicking: So in the null column an S means that it's treated as null, an E as , but what does N mean? N means that I was able to determine that null was treated as the actual null value, rather than converted to a string. Yes, there are definitely a lot of Ss in the null column for non-firefox browsers. The question to me is if this is really needed for webcompat though. Looking though our bug database I see no indication of that, but that's not necessarily a proof. If we were able to use as the default behavior for null then we would be able to get away with much fewer exceptions (so far alert() and and possibly write() has been found). OK. So what is more important for choosing the default: fewer exceptions (and thus fewer [Null=…] things polluting the IDL), consistency with the default stringification behaviour of ECMAScript, or avoiding the somewhat counterintuitive default behaviour of converting a valid value of the type to a different value of that type? -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] DOM Storage feedback
Jonas Sicking: So it behaves different from passing in an empty string? For some functions this surprises me, such as for the namespace parameter for getAttributeNS, I would think that we there treat the same as null. Not necessarily, but I agree that would be a better thing to report. I’ll rejig the tests to get that information. Cameron McCormack: OK. So what is more important for choosing the default: fewer exceptions (and thus fewer [Null=…] things polluting the IDL), consistency with the default stringification behaviour of ECMAScript, or avoiding the somewhat counterintuitive default behaviour of converting a valid value of the type to a different value of that type? converting a valid value of the type to a different value of that type, which values exactly? null. It feels slightly strange to me to treat null as a “second class value” by default. But I’ll get over it. :-) It may actually be indicative of a need for two distinct types: strings (i.e., possibly empty sequences of characters) and strings-or-null. But I don’t know if it’s worth rewriting everything in this way. I think another factor, that you haven't mentioned, that is very important is web compatibility. But beyond that I think I would rate fewer exceptions highest. Well, I assume that writers of specs that document already-implemented interfaces will choose the appropriate [Null] annotation (or lack of it) for web compatibility. Which to choose as the default is orthogonal, I think. -- Cameron McCormack ≝ http://mcc.id.au/
[whatwg] Misnamed attribute on HTMLFormElement
The IDL currently says:
interface HTMLFormElement … {
attribute DOMString accept-charset;
…
};
I assume that should be acceptCharset? If you are actually wanting a
property on an ES host object named “accept-charset”, then some
additional functionality in Web IDL to define that will be needed.
--
Cameron McCormack ≝ http://mcc.id.au/
[whatwg] Window::showModalDialog() missing [Variadic]
The 1 argument version of Window::showModalDialog() is missing a
[Variadic] on the second argument:
interface Window {
…
any showModalDialog(in DOMString url);
any showModalDialog(in DOMString url, in any arguments);
…
};
Since no arguments need be passed for those designated with [Variadic],
the two operations could just be combined into one:
interface Window {
…
any showModalDialog(in DOMString url, [Variadic] in any arguments);
…
};
--
Cameron McCormack ≝ http://mcc.id.au/
[whatwg] Window::applicationCache missing
The applicationCache attribute on the Window interface seems to be missing. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] number-related feedback
Hi Ian, Jonas.
Ian Hickson:
The UA would set a limit on the value it accepts for maxlength=, and
then cap the result at that, preventing someone from entering more than
4GB (or 2GB, or 4TB, or whatever limit the UA has). Does that answer your
question? In practice I would expect other limitations to come into play
long before a test for this limit could be triggered.
I don’t think it does answer the question, since you need to know what
happens if you do:
e.setAttribute('maxlength', '50');
alert(e.maxlength)
The text currently in the spec isn’t clear:
If a reflecting DOM attribute is an unsigned integer type (unsigned
long) then, on getting, the content attribute must be parsed according
to rules for parsing non-negative integers, and if that is successful,
the resulting value must be returned. If, on the other hand, it fails,
or if the attribute is absent, the default value must be returned
instead, or 0 if there is no default value.
The “rules for parsing non-negative integers” algorithm can return any
non-negative integer. Web IDL doesn’t define what to do if a spec
defines an operation to return a value that is not a member of its
return type. I’d classify that as a bug in the description of
reflecting DOM attributes.
I suggest to reword that paragraph to something like the following:
If a reflecting DOM attribute is an unsigned integer type (unsigned
long) then, on getting, the content attribute must be parsed according
to rules for parsing non-negative integers, and if that successfully
returns a value in the range of an unsigned long, that resulting value
must be returned. If, on the other hand, it fails, returns an out of
range value, or if the attribute is absent, the default value must be
returned instead, or 0 if there is no default value.
Similar wording would be needed for other paragraphs in this section.
--
Cameron McCormack ≝ http://mcc.id.au/
[whatwg] DOMStringMap named properties
Continuing a conversation from IRC
(http://krijnhoetmer.nl/irc-logs/whatwg/20081217#l-187):
Cameron McCormack:
heycam Hixie, i think it would be better if DOMStringMap still
had operations annotated with [NameGetter] etc., and then for me to
introduce something in Web IDL to indicate that the operations don't
correspond to functions, and then for you to use that functionality
heycam Hixie, so something like http://paste.lisp.org/display/72289
heycam it'd have the advantage of both making the description of the
named property accessors simpler (since you'd just do your usual
description of operations) and also makes the interfaces suitable
for languages that don't support object indexing
heycam s/makes/making/
…
heycam Hixie,
http://dev.w3.org/2006/webapi/WebIDL/#NoIndexingOperations
Ian Hickson:
Hixie heycam: i'm scared that that's like giving implementors a
loaded gun and telling them to point it at their foot and set the
safety and then pull the trigger -- implementors who aren't paying
attention will shoot themselves
Hixie heycam: i.e. they'll think what's NoIndexingOperations? oh
well let's ignore it for now and we'll get the functions exposed
Is that a valid concern? There are many requirements that Web IDL makes
that aren’t immediately obvious just by looking at an IDL fragment.
Such a concern could easily be mitigated with a small note.
[19:38] Hixie heycam: i'd much rather have the idl look like the js
object and have [IndexSetter] etc take arguments to provide names
for the other languages
But would you add those names? :) You’d need to specify the type of
the values, too, so that the implicit name getter operation can have a
return type (and to give the type of the name setter/creator operation’s
second argument).
This is how I would recommend the section read:
The DOMStringMap interface represents a set of name-value pairs. When
a DOMStringMap object is instantiated, it is associated with three
algorithms: one for getting the list of name-value pairs, one for
setting names to certain values, and one for deleting names.
[NoIndexingOperations]
interface DOMStringMap {
[NameGetter] DOMString get(in DOMString name);
[NameSetter, NameCreator] void put(in DOMString name,
in DOMString value);
[NameDeleter] void delete(in DOMString name);
};
!-- green note --
Note that due to the use of the [NoIndexingOperations] extended
attribute, the interface prototype object for DOMStringMap will not
have properties named get, set and remove; the only way to access
the strings stored in a DOMStringMap is by accessing them via
properties directly on the object.
The names of the supported named properties on a DOMStringMap object
are the names of each pair returned by the algorithm for getting the
list of name-value pairs.
The get(name) method must run the following algorithm:
1. Let /pairs/ be the list returned from the algorithm for getting
the list of name-value pairs.
2. Let /pair/ be the entry in /pairs/ whose name component is equal
to /name/.
3. Return the value component of /pair/.
The set(name, value) method must run the algorithm for setting names
to certain values, passing /name/ as the name and /value/ as the
value.
The delete(name) method must run the algorithm for deleting names,
passing /name/ as the name.
If you definitely don’t want to use [NoIndexingOperations], then the
section should look like the following:
The DOMStringMap interface represents a set of name-value pairs. When
a DOMStringMap object is instantiated, it is associated with three
algorithms: one for getting the list of name-value pairs, one for
setting names to certain values, and one for deleting names.
[NameGetter, NameSetter, NameCreator, NameDeleter]
interface DOMStringMap {
};
The names of the supported named properties on a DOMStringMap object
are the names of each pair returned by the algorithm for getting the
list of name-value pairs.
When a DOMStringMap object is indexed to retrieve a named property
/name/, the following algorithm must be run:
1. Let /pairs/ be the list returned from the algorithm for getting
the list of name-value pairs.
2. Let /pair/ be the entry in /pairs/ whose name component is equal
to /name/.
3. Return the value component of /pair/.
When a DOMStringMap object is indexed to create or modify a named
property /name/ with value /value/, the algorithm for setting names to
certain values must be run, passing /name/ as the name and the
result of converting /value/ to a DOMString as the value.
When a DOMStringMap object is indexed to delete a named property named
/name/, the algorithm for deleting names must be run, passing /name/
as the name.
If you go without [NoIndexingOperations], then I suggest specifying
somehow
Re: [whatwg] Stability of tokenizing/dom algorithms
Edward Z. Yang: Sounds good, since HTML4 is a strict subset of HTML5 (correct me if I'm wrong?) Ian Hickson: Mostly, yes. (There are exceptions, but they're not things you'd really want to be using anyway, e.g. obscure SGML features.) Note though that it’s not possible to write a document that is both valid HTML 4 and HTML 5, since they both require a different DOCTYPE to be used. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] A slightly different use-case for shared workers
Robert O'Callahan: Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Why shouldn’t that throw a WRONG_DOCUMENT_ERR? -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Disabled attribute for iframes
Ian Hickson: This seems like a bug. It seems like we would want to address this directly rather than requiring authors to disable iframes when doing drags (especially since that wouldn't help with things like plugins or whatever). Wouldn't the better solution be to provide some sort of mechanism to say that while the mouse button is down, all the mouse move events should go to the element that got the mousedown event? The old SVG 1.2 Full draft had a pair of methods (which are implemented in Batik), startMouseCapture()/ stopMouseCapture(), that could be used to do this kind of thing. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] HTML 5 : Misconceptions Documented
bindings for some interface written in Web IDL, then you could consider the [IndexGetter] to be a good guide to do that sort of thing. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] WebIDL vs HTML5 storage changes
Hi Brady.
Brady Eidson:
A little while ago, this change -
http://html5.org/tools/web-apps-tracker?from=1429to=1430 - was meant to
update the spec for consistency with WebIDL
In this change, the following passage was removed from the Storage
section:
In the ECMAScript DOM binding, enumerating a Storage object must
enumerate through the currently stored keys in the list the object is
associated with. (It must not enumerate the values or the actual members
of the interface). In the ECMAScript DOM binding, Storage objects must
support dereferencing such that getting a property that is not a member
of the object (i.e. is neither a member of the Storage interface nor of
Object) must invoke the getItem() method with the property's name as the
argument, and setting such a property must invoke the setItem() method
with the property's name as the first argument and the given value as the
second argument.
Shorty thereafter, the declaration of the Storage interface was changed
to the following:
interface Storage {
readonly attribute unsigned long length;
[IndexGetter] DOMString key(in unsigned long index);
[NameGetter] DOMString getItem(in DOMString key);
[NameSetter] void setItem(in DOMString key, in DOMString data);
[XXX] void removeItem(in DOMString key);
void clear();
};
I assumed that the WebIDL descriptions of [IndexGetter], [NameGetter],
and [NameSetter] would keep the specified functionality in tact, but it
appears this is *not* the case.
Or by reading http://dev.w3.org/2006/webapi/Binding4DOM/ I can't find
where it is the case...
Does someone know what is up with this?
Yeah, Web IDL doesn’t currently have a way to make a property DontEnum,
so the IDL there isn’t strictly equivalent to the prose that used to be
there.
While I'm on the topic, I'm also curious about that [XXX] placeholder.
There's a bug in WebKit's bugzilla pointing out that the IE8 beta and
Firefox 2 both support `delete storage.keyName` syntax as an alias for
`storage.removeItem(keyName)`
I'm taking a guess here and assuming supporting the `delete` syntax is
the implied concept behind [XXX]
Yes.
Not that this mailing list has direct impact on the WebIDL spec, but I
would suggest [NameDeleter] or [NameRemover] as a placeholder in the
HTML5 spec since it fits in with the NameGetter/Setter family of
operations quite nicely.
They’re sensible names. I’ll append() that on my TODO list.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] nextSiblingElement ?
Hi Garrett.
Garrett Smith:
nextSibling and previousSibling are useful, but not always what I want.
I usually want to get a siblingElement than a sibling, which might be
a text node.
Dom.findNextSiblingElement = function(el) {
for(var ns = el.nextSibling; ns != null; ns = ns.nextSibling)
if(ns.nodeType == 1)
return ns;
return null;
};
There is http://www.w3.org/TR/ElementTraversal/, which specifies just
this.
--
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
Re: [whatwg] Web widgets
Ian Hickson: The W3C WebAPI working group is working on Widgets, so I'm going to punt on this as far as the HTML5 spec is concerned. Let me know if there's anything that you still think belongs in HTML5 about this. I think that’s the Web Application Formats WG who is working on Widgets. -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
