Re: Window object, very rough cut of proposed content for first version of spec

Hello everyone,

One question about the overall charter raised by this particular piece, 
why choosing the DOM interface for this workgroup rather than E4X which 
IMO would have allowed for much more flexibility?

Is there any particular reason for not pushing towards E4X in this context?

The charter says:

"Other language interfaces, such as Java, Python, C# and Ruby, should be 
developed in cooperation with the organization responsible for the 
language."

Which might be one reason. But to be fair most languages today offer 
alternatives to DOM which are closer to what E4X is all about.

Another reason might be that DOM is already implemented in the vast 
majority of browsers but then what is the use for E4X?

Thanks for any feedback :)
- Sylvain


Maciej Stachowiak a écrit :
> 
> 
> Hello people interested in Web APIs,
> 
> Here's my proposal for what to put in the first version of the window 
> object spec, as IDL with comments. This is a small subset of what the 
> window interface provides in popular implementations. These features 
> were selected as follows:
> 
> - Already widely interoparably implemented by mainstream HTML UAs
> - Likely to be helpful for SVG or CDR requirements
> - Simple (nothing that implies the existence of other interfaces with 
> their own complex semantics; no events; but timers and location are 
> included)
> - Likely to be uncontroversial (nothing that would spawn debates over 
> its moral values, like window.open)
> - no networking or XML parsing, that will be in other specs
> 
> More complex features would likely be addressed in a follow-on version 
> of the spec.
> 
> Please review this rough proposal to see if there's anything in here 
> that you wildly object to, or anything you think desperately needs 
> adding. Keep in mind that this is not the last word on specifying the 
> window object, I would expect work on a follow-on to start immediately 
> once this spec is done, covering a much broader range of features.
> 
> 
> I propose one of the following for the title:
> 
> DOM Global Object (Level 3? or 1.0?)
> DOM Window Object (Level 3? or 1.0?)
> DOM Level 3 Views (especially if we incorporate AbstractView and 
> DocumentView interfaces into this spec instead of just referencing views)
> 
> // or global or window or views?
> module window
> {
>     // based on Mozilla and Safari interfaces, Internet Explorer docs, 
> WHATWG draft
>     interface Location {
>         // the current URI
>         readonly attribute DOMString href;
> 
>         // pieces of the URI, per the generic URI syntax
>         readonly attribute DOMString hash; // (fragment)
>         readonly attribute DOMString host; // hostname:port if port 
> specified,
>         readonly attribute DOMString hostname; // just the hostname, no 
> port
>         readonly attribute DOMString pathname;
>         readonly attribute DOMString port;
>         readonly attribute DOMString protocol; // scheme
>         readonly attribute DOMString search;  // query
> 
>         void assign(in DOMString url); // go to the requested URL
>         // does it make sense to spec reload and replace without 
> specifying history behavior at all?
>         void replace(in DOMString url);
>         void reload();
> 
>         // same value as href; not all implementations have this 
> explicitly but toString is always available
>         // in ECMAScript, and probably this should be explicit for the 
> sake of Java. Or we could skip it since
>         // it matches href.
>         DOMString toString();
>     };
> 
>     // for ECMAScript there is a special case for this type, it can be 
> either a string or a function.
>     // In the string case, the string is eval'd in global scope when the 
> timer fires.
>     // in the function case JS allows extra arguments after the 
> milliseconds argument; the function
>     // is called with extra arguments if any when the timer fires
>     interface TimerListener {
>         // who knows - what interface would work for non-JS languages? 
> this could just be an EventListener
>         // but then we would have to define TimerEvent; it might also be 
> handy to expose that to JS, in which
>         // case this spec would incorporate one new feature for HTML UAs 
> to implement. But I would expect it
>         // to be a simple one.
>     };
> 
>     // should this interface be called something else - Global, 
> DOMWindow, DOMGlobal?
>     // should specify that for ECMAScript execution this provides the 
> global scope
>     // based on Mozilla and Safari implementations, Win IE docs, Web 
> Apps 1.0 draft (some also in SVG Tiny 1.2 draft)
>     interface Window : views::AbstractView {
>         // AbstractView has a document attribute of type DocumentView, 
> should we drop the charade and admit it is a
>         // Document?
> 
>         // self-reference
>         readonly attribute Window window;
> 
>         // self-reference - why both? because both are used
>         readonly attribute Window self;
> 
>         // name attribute of referencing frame/iframe/object, or name 
> passed to window.open,
>         // does it make sense to spec this without being html-specific 
> or defining open?
>         attribute DOMString name;
> 
>         // global object of containing document
>         readonly attribute Window parent;
> 
>         // global object of outermost containing document
>         readonly attribute Window top;
> 
>         // referencing <html:frame>, <html:iframe>, <html:object>, 
> <svg:foreignObject>, <svg:animation> or other
>     // embedding point, or null if none
>         readonly attribute core::Element frameElement;
> 
>         // Location object representing the current location
>         // assigning this has special behavior in ECMAScript, but it is 
> otherwise read only
>         // specifically, in ES a string URI can be assigned to location, 
> having the same effect as location.assign(URI)
>         readonly attribute Location location;
> 
>         // should timers allow more than long, maybe a floating point 
> type? don't think anyone's timers have more precision
>         // one-shot timer
>         long setTimeout(in TimerListener listener, in long milliseconds);
>         void clearTimeout(in long timerID);
> 
>         // repeating timer
>         long setInterval(in TimerListener listener, in long milliseconds);
>         void clearInterval(in long timerID);
>     };
> };
> 
> 
> Other possible things to add (potentially more controversial):
> 
> - SVG uDOM style timers - way less convenient in JS but maybe better for 
> Java
> - Web Apps 1.0 proposed version of setTimeout / clearTimeout that take a 
> language name as third parameter(*)
> - SVG uDOM window.gotoLocation(in URI) - same effect as 
> window.location.assign(URI)
> - IE extension window.navigate(in URI) - same effect as 
> window.location.assign(URI)
> - an interface that adds contentWindow property to DOM elements that 
> have contentDocument; perhaps an issue for individual language specs
> - due to the dependence on AbstractViews, Document is required to have a 
> defaultView attribute that points to the window, perhaps it is desirable 
> to add aliases for it, e.g. "window" as in Web Apps 1.0 draft or 
> "global" as in SVG uDOM
> - yet another alias for the window object's self-reference named "global"
> 
> (*) - I think this is unneeded, because there's no need to enable one 
> language to set a timer that will eval code in another language. I think 
> the string parameter versions of these should instead be defined as an 
> ECMAScript binding feature and not in the IDL.
> 
>

Received on Tuesday, 14 February 2006 11:21:49 UTC