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

On Feb 14, 2006, at 2:48 AM, Mark Birbeck wrote:

>
> Hi Maciej,
>
> Why a 'window' object? Many of these features are independent of a  
> 'window',
> and would be better placed on another object...perhaps an application
> object, or something. Also, many classes of applications that could  
> use a
> DOM and the features mentioned here, don't need a 'window'.

That's what web browsers historically call the object that acts as  
the global scope for scripts. It doesn't necessarily represent a  
window, even in current web browsers, it is actually the global scope  
for a particular document, so in case of CDR there is more than one  
in a window. Or if you have a tabbed UI with multiple documents in  
the same window.

I am trying to propose existing interoperable features for  
specification here, not invent new ones. If some classes of  
applications aren't interested in this, then they don't have to  
implement it, that is why it will be separate from DOM core.

Cheers,
Maciej


>
> Regards,
>
> Mark
>
>
> Mark Birbeck
> CEO
> x-port.net Ltd.
>
> e: Mark.Birbeck@x-port.net
> t: +44 (0) 20 7689 9232
> b: http://internet-apps.blogspot.com/
> w: http://www.formsPlayer.com/
>
> Download our XForms processor from
> http://www.formsPlayer.com/
>
>> -----Original Message-----
>> From: public-webapi-request@w3.org
>> [mailto:public-webapi-request@w3.org] On Behalf Of Maciej Stachowiak
>> Sent: 14 February 2006 10:30
>> To: public-webapi@w3.org
>> Subject: Window object, very rough cut of proposed content
>> for first version of spec
>>
>>
>>
>> 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 10:55:40 UTC