Re: Moving XBL et al. forward

2011-03-10 Thread Daniel Glazman

Le 10/03/11 16:26, Dimitri Glazkov a écrit :

Ok, this is interesting. Which proposal by Google is ghost of Daniel
referring to? I don't think there is one yet?


This kind of things for instance?

http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Reacting_to_bound_element_state_change

/Daniel



Re: Moving XBL et al. forward

2011-03-10 Thread Dimitri Glazkov
That's just use cases. I used the latest draft of XBL2 for syntax --
might as well be pseudocode at this point.

:DG

On Thu, Mar 10, 2011 at 1:35 PM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:
 Le 10/03/11 16:26, Dimitri Glazkov a écrit :

 Ok, this is interesting. Which proposal by Google is ghost of Daniel
 referring to? I don't think there is one yet?

 This kind of things for instance?

 http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Reacting_to_bound_element_state_change

 /Daniel




Re: Moving XBL et al. forward

2011-03-10 Thread Dimitri Glazkov
Cameron++

Also, this is a public wiki. If you feel like the use cases aren't
covering the problem domain to your satisfaction, please feel
encouraged to make additions.

:DG

On Thu, Mar 10, 2011 at 1:46 PM, Cameron McCormack c...@mcc.id.au wrote:
 Daniel Glazman:
 Ok, so don't focus on the proposal word in my message. My comment
 still stands : keeping XBL as an XML-based thing is good for user
 agents that don't need to have knowledge of a given dialect, HTML
 for instance.

 We should think of XBL as being a DOM-based thing, rather than an XML-
 based thing.  Then we can have HTML syntax for the cases where
 everything is within a text/html document, and XML syntax for the cases
 like the ones I brought up, where you might be purely within an SVG
 document.

 --
 Cameron McCormack ≝ http://mcc.id.au/




Re: Moving XBL et al. forward

2011-03-10 Thread Daniel Glazman

Le 10/03/11 16:46, Cameron McCormack a écrit :


We should think of XBL as being a DOM-based thing, rather than an XML-
based thing.  Then we can have HTML syntax for the cases where
everything is within a text/html document, and XML syntax for the cases
like the ones I brought up, where you might be purely within an SVG
document.


I disagree. If you do that, the HTML serialization of a binding won't
be usable in a user agent having no knowledge of HTML.

/Daniel



Re: Moving XBL et al. forward

2011-03-10 Thread Tab Atkins Jr.
On Thu, Mar 10, 2011 at 1:51 PM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:
 Le 10/03/11 16:46, Cameron McCormack a écrit :

 We should think of XBL as being a DOM-based thing, rather than an XML-
 based thing.  Then we can have HTML syntax for the cases where
 everything is within a text/html document, and XML syntax for the cases
 like the ones I brought up, where you might be purely within an SVG
 document.

 I disagree. If you do that, the HTML serialization of a binding won't
 be usable in a user agent having no knowledge of HTML.

The HTML serialization of an ordinary web page isn't usable in a user
agent having no knowledge of HTML, either.  Why is this different?

~TJ



Re: Component Model is not an Isolation Model

2011-03-10 Thread Robert O'Callahan
On Fri, Mar 11, 2011 at 8:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 CDNs of various sorts, dedicated hostnames for different sorts of content
 (a la existing images.something.com setups), that sort of thing.

 If we want to not allow cross-site loading at all, those cases break. If we
 want to allow it, we should try to make it hard to shoot yourself in the
 foot by doing it, imo.


OK, but those are all generally loading from trusted sites, like script
does.

I understand that it would be nice to improve on script by protecting
against potential compromise of the other site. However, if document authors
and component API authors don't think hard about the possibility of their
component turning hostile (and I am very confident that they won't!), I fear
that the component will be able to wreak havoc in the container via the APIs
exposed by the component. For example, if we try to enforce protection via a
capability model, it's easy to accidentally leak capabilities through a
carelessly designed API.

So I'm worried that protecting containers from components will be a burden
on the component model that doesn't lead to much practical benefit. But
maybe I worry too much :-).

Rob
-- 
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true. [Acts 17:11]


Re: Component Model is not an Isolation Model

2011-03-10 Thread Dimitri Glazkov
On Wed, Mar 9, 2011 at 7:17 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 3/9/11 7:30 PM, Dimitri Glazkov wrote:

 From the perspective of the component, the isolation is unfairly

 punishing -- you can't use the outside DOM or even DOM element on
 which you're hoisted, you can't add methods to it, and you have to
 always imagine the membrane in order to build a proper mental model of
 what the heck you're trying to accomplish.

 This is sort of a requirement for being able to use components that you
 don't trust to arbitrarily mess with your DOM though, no?

Yes, you're exactly right. Having an isolation boundary is a
requirement for the components that don't trust the document or the
document that doesn't trust the component.

However, many use cases for components simply don't have this
requirement. Most complex apps today build or reuse their own
component frameworks just for the sake of encapsulation
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Custom_Widget_System).
Isolation for them is not a concern, because the components are its
own source. We want to be useful and not in the way for this use case.

For the cases where isolation is necessary, be that mashups or
browser's implementation of HTML elements
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Built-in_HTML_Elements),
we should provide the capability.

This, in essence, is what triggered realization that components and
isolation are complementary, but different things.

 Also, the component wants to keep the document from poking at its internals
 except via the APIs the component exposes, I would think.

 From the perspective of the document, the isolation is too fiddly:

 it's rare that the level of isolation at the _individual_ component
 level is what's actually necessary.

 I'm not sure what the fiddly issue is here...  From the perspective of the
 document isolation should mean two things:

 1)  Cross-site components are safe to use.
 2)  You can't screw up and depend on implementation details of a
    component, because if you're calling something the component
    provides then you're using APIs the component explicitly exposed.

 Is there something I'm missing?

 Or are those things that fall under modularity or encapsulation in your
 message?  If so, what are you thinking of in terms of isolation?

Ah, great question. I've been only recently enlightened by Mark
Miller's Caja crew on this subject, apologies for perhaps crude
explanations.

Isolation is an abstraction that provides a boundary (a membrane from
the Caja world http://en.wikipedia.org/wiki/Object-capability_model)
around untrusted code. The untrusted code could be any chunk of DOM or
Javascript, including the document itself (this case would be a
component defending itself from the untrusted document,
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Parent_trusts_component_but_not_vice_versa).

The Isolation model (whatever it turns out to be), should provide
ability to create this boundary at will, not tied to a component spec
in itself.

Does this make a bit more sense now?

:DG



Re: Component Model is not an Isolation Model

2011-03-10 Thread Dimitri Glazkov
On Thu, Mar 10, 2011 at 1:59 AM, Robert O'Callahan rob...@ocallahan.org wrote:
 On Thu, Mar 10, 2011 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 1)  Cross-site components are safe to use.
 2)  You can't screw up and depend on implementation details of a
    component, because if you're calling something the component
    provides then you're using APIs the component explicitly exposed.


 #2 --- protecting components from the enclosing document --- should
 definitely be supported by the component model IMHO. Without that, it's more
 difficult to update components over time.

Yes indeed. The component model must provide a uniform way to declare
component APIs.

 I'm less enthusiastic about #1. In many situations, perhaps most, developers
 can choose to trust a component and host it themselves, and there's no
 problem. Some widget use cases can be solved with IFRAMEs instead. What
 use cases for cross-site component loading are left?

 Rob
 --
 Now the Bereans were of more noble character than the Thessalonians, for
 they received the message with great eagerness and examined the Scriptures
 every day to see if what Paul said was true. [Acts 17:11]




Re: Component Model is not an Isolation Model

2011-03-10 Thread Dimitri Glazkov
On Thu, Mar 10, 2011 at 1:57 PM, Robert O'Callahan rob...@ocallahan.org wrote:
 On Fri, Mar 11, 2011 at 8:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 CDNs of various sorts, dedicated hostnames for different sorts of content
 (a la existing images.something.com setups), that sort of thing.

 If we want to not allow cross-site loading at all, those cases break. If
 we want to allow it, we should try to make it hard to shoot yourself in the
 foot by doing it, imo.

 OK, but those are all generally loading from trusted sites, like script
 does.

 I understand that it would be nice to improve on script by protecting
 against potential compromise of the other site. However, if document authors
 and component API authors don't think hard about the possibility of their
 component turning hostile (and I am very confident that they won't!), I fear
 that the component will be able to wreak havoc in the container via the APIs
 exposed by the component. For example, if we try to enforce protection via a
 capability model, it's easy to accidentally leak capabilities through a
 carelessly designed API.

 So I'm worried that protecting containers from components will be a burden
 on the component model that doesn't lead to much practical benefit. But
 maybe I worry too much :-).

No, I agree that this is a real concern. You are right, we must do
better than just tell authors to use object capabilities.

I am hoping to be able to use component encapsulation as enough of the
separation to be able to just have a big lever (FRIEND--ENEMY)  to
_slide_ a membrane between the component and its host. This is still
thinking in progress :)

 Rob
 --
 Now the Bereans were of more noble character than the Thessalonians, for
 they received the message with great eagerness and examined the Scriptures
 every day to see if what Paul said was true. [Acts 17:11]




Re: Component Model is not an Isolation Model

2011-03-10 Thread Dimitri Glazkov
On Thu, Mar 10, 2011 at 2:07 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 3/10/11 4:58 PM, Dimitri Glazkov wrote:
 We want to be useful and not in the way for this use case.

 Agreed-ish.

 For the cases where isolation is necessary, be that mashups or
 browser's implementation of HTML elements

 (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Built-in_HTML_Elements),
 we should provide the capability.

 Yes.

 I think we agree that isolation should be optional.

 I'm not sure I agree that we need a broad far-reaching general isolation
 model before we can provide isolation for the special case of
 widgets/components (just like we already provide isolation for frames).

 This, in essence, is what triggered realization that components and
 isolation are complementary, but different things.

 I agree, but I think that isolation for components is a much more
 tractable specification and interoperable implementation problem than
 isolation in general.  Now clearly each UA already has some sort of
 isolation infrastructure that it would use to implement this, but I see no
 reason to expect that these will match in all particulars for other use
 cases.

 1)  Cross-site components are safe to use.
 2)  You can't screw up and depend on implementation details of a
    component, because if you're calling something the component
    provides then you're using APIs the component explicitly exposed.

 Is there something I'm missing?

 Or are those things that fall under modularity or encapsulation in
 your
 message?  If so, what are you thinking of in terms of isolation?

 ...

 Isolation is an abstraction that provides a boundary (a membrane from
 the Caja world http://en.wikipedia.org/wiki/Object-capability_model)

 OK, so this is the part that makes #1 above OK-ish (in the sense of not
 allowing the component to run code as you immediately).

 Is #2 above what you put under encapsulation then?

Yes.


 The Isolation model (whatever it turns out to be), should provide
 ability to create this boundary at will, not tied to a component spec
 in itself.

 It's not clear that we need to solve this problem in generality to create
 something usable for components.

 Past that, I have no problem with separate specs here, as long as we don't
 end up with the the overreach problem and end up with no isolation for
 components because we couldn't agree on how all the rest of the isolation
 model should work.

That is certainly a concern. Perhaps the right approach is to
recognize the need to address the isolation before we consider
component model spec done (done TBD).

Also, maybe Caja folks could lend their skillful hand in crafting a
simple DOM-centric isolation spec?


 -Boris




Re: Moving XBL et al. forward

2011-03-10 Thread Daniel Glazman

Le 10/03/11 16:55, Tab Atkins Jr. a écrit :


The HTML serialization of an ordinary web page isn't usable in a user
agent having no knowledge of HTML, either.  Why is this different?


Do you have different serializations for another helper technology
called CSS ? No. Why should it be different here?

/Daniel



Re: Moving XBL et al. forward

2011-03-10 Thread Tab Atkins Jr.
On Thu, Mar 10, 2011 at 2:39 PM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:
 Le 10/03/11 16:55, Tab Atkins Jr. a écrit :
 The HTML serialization of an ordinary web page isn't usable in a user
 agent having no knowledge of HTML, either.  Why is this different?

 Do you have different serializations for another helper technology
 called CSS ? No. Why should it be different here?

Languages whose syntax is *significantly* different from HTML/XML,
like CSS or WebVTT, don't run into the dual representation issue
because, well, attempting to represent them in HTML would be a ton of
work and would result in something fairly unrecognizable.

As Cameron noted, however, it seems to be useful and accepted to
expose XML/HTML languages in both an XML and an HTML serialization, as
the two languages are very close to each other and the differences are
relatively minor.  Those minor differences, unfortunately, tend to
cause authors quite a lot of problems when they're currently using one
and try to use the other, so allowing an author to use whichever they
prefer is a good thing.

We now expose an HTML serialization of SVG and MathML embedded in
HTML.  Similarly, Component Model in HTML will have an HTML
serialization, but it's easy to imagine it also having an XML
serialization for use directly in SVG or similar.

~TJ



Re: [FileAPI] Why is FileList a sequence?

2011-03-10 Thread Ian Hickson
On Fri, 11 Mar 2011, Cameron McCormack wrote:
 Anne van Kesteren:
Lets at least remove sequenceT from the draft then.
 
 Cameron McCormack:
   Other specifications use it, and it really serves a different
   purpose from things like NodeList, like passing in native Array
   objects to DOM methods.  So I don’t think we should remove it.
 
 Anne van Kesteren:
  Which specifications use it then?
 
 The ones I could find were: Web Applications 1.0, RDFa API and The
 System Information API (admittedly fewer than I thought!).

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.

(Are the other two implemented by any browsers?)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Moving XBL et al. forward

2011-03-10 Thread Leigh L Klotz Jr

On 03/10/2011 02:56 PM, Tab Atkins Jr. wrote:


serialization, but it's easy to imagine it also having an XML
serialization for use directly in SVG or similar.

~TJ


Certainly, we'd prefer to have an XML representation of the component 
language for use with XForms for similar reasons.  XForms is not a host 
language, but works together with other XML applications such as XHTML 
and SVG.


We've explored an HTML representation for use with HTML serializations, 
but not made any efforts in that direction due to lack of interest from 
users.  But it would certainly be possible; the data binding to XML (or 
JSON, in XForms 1.2) data is unrelated to the syntax used to express the 
bindings.


Leigh.



RfC: Last Call Working Draft of Progress Events; deadline June 1

2011-03-10 Thread Arthur Barstow
This is a Request for Comments for the March 10 Last Call Working Draft 
of Progress Events:


http://www.w3.org/TR/2011/WD-progress-events-20110310/

If you have any comments, please send them to the following list by 1 
June 2011 at the latest:


public-webapps@w3.org

-Art Barstow



RfC: Last Call Working Draft of Server-sent Events; deadline April 21

2011-03-10 Thread Arthur Barstow
This is a Request for Comments for the March 10 Last Call Working Draft 
of Server-sent Events:


http://www.w3.org/TR/2011/WD-eventsource-20110310/

If you have any comments, please send them to the following list by 21 
April 2011 at the latest:


public-webapps@w3.org

-Art Barstow



RfC: Last Call Working Draft of Web Workers; deadline April 21

2011-03-10 Thread Arthur Barstow
This is a Request for Comments for the March 10 Last Call Working Draft 
of Web Workers:


http://www.w3.org/TR/2011/WD-workers-20110310/

If you have any comments, please send them to the following list by 21 
April 2011 at the latest:


public-webapps@w3.org

-Art Barstow




Re: [FileAPI] Why is FileList a sequence?

2011-03-10 Thread Cameron McCormack
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?

2011-03-10 Thread Ian Hickson
On Fri, 11 Mar 2011, Cameron McCormack wrote:
 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.

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


 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?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [FileAPI] Why is FileList a sequence?

2011-03-10 Thread Cameron McCormack
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/



Component Model Should Use DOM Object Inheritance

2011-03-10 Thread Dimitri Glazkov
Summary: There is no need to build another type of inheritance into
the component model, since all DOM already has an inheritance
mechanism.

Another set of thoughts around use cases
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases)

A large part of complexity of the current XBL2 draft comes from
dealing with inheritance: from implicit/explicit inheritance chain
(http://dev.w3.org/2006/xbl2/Overview.html#binding-inheritance), to
the final flattened tree
(http://dev.w3.org/2006/xbl2/Overview.html#the-final-flattened-tree),
to multi-step matching of scoped stylesheets
(http://dev.w3.org/2006/xbl2/Overview.html#binding-style-sheets).

I think that we can jettison the entire concept of binding inheritance
from the spec and instead rely on ye good olde DOM object inheritance
to do the dirty work. Consider this strawman:

1) Each component inherits from a DOM object, directly or indirectly.
This of course means that a component is-a DOM object.

2) Whenever the shadow tree needs to be constructed, the component's
createShadowSubtree method is called. This method constructs a
shadow DOM subtree (details omitted for simplicity).

So, for the imperative API, if a component wants to build a shadow DOM
that's different than its prototype/superclass, it overrides the
method.

function MyButton() {
}

MyButton.prototype = {
__proto__: HTMLDivElement,
createShadowSubtree: function(DOMScope)
{
// where DOMScope is a bit made-up, please accept as pseudocode.
DOMScope.appendChild(document.createElement(img)).src = foo.png;
}
}

Similarly, a declaratively-defined component is wired to use the
createShadowSubtree method to clone the contents of the template
element. Thus the equivalent to above definition would be:

!-- rough pseudocode --
element name=MyButton extends=HTMLDivElement
template
img src=foo.png
/template
/element

This of course means that we must rely on composition to emulate
functionality, provided by the inherited element from the current
XBL2 draft, but I believe this is an acceptable feature/simplicity
compromise. In fact, composition seems like a nice path from status
quo, where the frameworks
(http://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases#Custom_Widget_System)
are doing just that with HTML elements.

:DG



Re: [FileAPI] Why is FileList a sequence?

2011-03-10 Thread Simon Pieters

On Fri, 11 Mar 2011 01:02:25 +0100, Ian Hickson i...@hixie.ch wrote:


On Fri, 11 Mar 2011, Cameron McCormack wrote:

Anne van Kesteren:
   Lets at least remove sequenceT from the draft then.

Cameron McCormack:
  Other specifications use it, and it really serves a different
  purpose from things like NodeList, like passing in native Array
  objects to DOM methods.  So I don’t think we should remove it.

Anne van Kesteren:
 Which specifications use it then?

The ones I could find were: Web Applications 1.0, RDFa API and The
System Information API (admittedly fewer than I thought!).


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.


Opera has implemented typedef sequenceMessagePort MessagePortArray for  
cross-document messaging and shared workers. As far as I know, our impl is  
spec compliant, and I see little point in changing it.


--
Simon Pieters
Opera Software