Re: Moving XBL et al. forward
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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?
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?
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?
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
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?
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
