Re: Moving XBL et al. forward
On Mar 10, 2011, at 22:51 , Daniel Glazman 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. I would except that a binding document in HTML serialisation would use HTML in the shadow tree. If your UA doesn't understand that, it's unlikely to be able to do all that much with the binding in the first place (it could style it, but since bindings are mostly for behaviour I'm not sure how far that'd get you). -- Robin Berjon - http://berjon.com/
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: 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: 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.
Moving XBL et al. forward
Ian, Leigh, Dimitri, All, On March 11, the agenda of the so-called Hypertext Coordination Group [HCG] will include XBL [XBL] to continue related discussions they had during their Feb 11 call [Feb-11-Mins]. I wasn't present at that call but based on those meeting minutes and what Leigh said last month [Leigh], I think the gist of the March 11 discussion will revolve around: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? Please send comments on the above as soon as possible (preferably before 10:00am Boston time on March 11). -Art Barstow [XBL] http://www.w3.org/2008/webapps/wiki/XBL [HCG] http://www.w3.org/MarkUp/CoordGroup/ [Feb-11-Mins] http://lists.w3.org/Archives/Public/public-hypertext-cg/2011JanMar/0007.html [Leigh] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0243.html [XBL2-CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [XBL2-ED] http://dev.w3.org/2006/xbl2/ [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
Re: Moving XBL et al. forward
On 03/09/2011 04:14 PM, Arthur Barstow wrote: Ian, Leigh, Dimitri, All, On March 11, the agenda of the so-called Hypertext Coordination Group [HCG] will include XBL [XBL] to continue related discussions they had during their Feb 11 call [Feb-11-Mins]. I wasn't present at that call but based on those meeting minutes and what Leigh said last month [Leigh], I think the gist of the March 11 discussion will revolve around: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? I'd like us to continue in this path. If you are groupin this , what firm commitments can you make to push the spec along the REC track? Not sure. Would you object to the Forms WG taking over this spec? Yes. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? What is the proposal? The linked document is about use cases, or more like requirements to XBL2 If yes, who is willing to commit to work on that spec? Please send comments on the above as soon as possible (preferably before 10:00am Boston time on March 11). -Art Barstow [XBL] http://www.w3.org/2008/webapps/wiki/XBL [HCG] http://www.w3.org/MarkUp/CoordGroup/ [Feb-11-Mins] http://lists.w3.org/Archives/Public/public-hypertext-cg/2011JanMar/0007.html [Leigh] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0243.html [XBL2-CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [XBL2-ED] http://dev.w3.org/2006/xbl2/ [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
Re: Moving XBL et al. forward
This email is written as the position of several Chrome engineers working in this problem area at Google, though not Google's official position. On Wed, Mar 9, 2011 at 6:14 AM, Arthur Barstow art.bars...@nokia.com wrote: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? Chrome does not implement either form of XBL2. * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? We object to continuing with XBL2. The original XBL2 was flawed, and the cutdown version of XBL2 is incomplete and still too complex. I'm not sure if we would object, per se, to the Forms WG taking over XBL2, but we would consider it wasted effort that would not result in us implementing it in Chrome/Webkit. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? We do not wish to work on either version of XBL2. * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? We believe that the Component Model proposal should be pursued. Dimitri Glazkov volunteers to edit the spec. ~TJ
Re: Moving XBL et al. forward
On Wed, Mar 9, 2011 at 9:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: This email is written as the position of several Chrome engineers working in this problem area at Google, though not Google's official position. On Wed, Mar 9, 2011 at 6:14 AM, Arthur Barstow art.bars...@nokia.com wrote: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? Chrome does not implement either form of XBL2. * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? We object to continuing with XBL2. The original XBL2 was flawed, and the cutdown version of XBL2 is incomplete and still too complex. I'm not sure if we would object, per se, to the Forms WG taking over XBL2, but we would consider it wasted effort that would not result in us implementing it in Chrome/Webkit. To be fair, most of the event retargeting, CSS property inheritance and the plumbing for custom pseudo element capability (XBL2's pseudo attribute) is now implemented in WebKit. So there is _some_ overlap in the mechanical (i.e. non-user-facing) parts of the spec. I view [XBL2-ED] spec as an excellent starting point for the Web Components spec, but we should go much further toward untangling orthogonal concerns and simplifying, as well as relying more on existing (and well-understood) concepts in the Web platform. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? We do not wish to work on either version of XBL2. * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? We believe that the Component Model proposal should be pursued. Dimitri Glazkov volunteers to edit the spec. I certainly do, although the link mentioned is not really a proposal, more like a clean-slate examination of the concrete use cases that a Web Component model should satisfy. ~TJ
Re: Moving XBL et al. forward
On Wed, 09 Mar 2011 15:14:48 +0100, Arthur Barstow art.bars...@nokia.com wrote: * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? I do not think the XML-based version makes sense anymore. It's too complex and has always felt a bit awkward. A set of extensions to HTML or CSS would make more sense. I really quite liked the idea of using CSS and having some way of writing markup in CSS for this. Hopefully we can explore that somewhat. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? So far that is just a bunch of use cases, not really a proposal, but I really like how they are targeted at addressing issues such as form control styling. That is something authors want to see addressed, and was initially deferred to XBL3 or some such. [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases -- Anne van Kesteren http://annevankesteren.nl/
Re: Moving XBL et al. forward
On Wed, 9 Mar 2011, Arthur Barstow wrote: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? I'm not aware of any new developments on either front. * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? I have no objections to anyone continuing down such a path (the spec is under a Creative Commons license to allow anyone to do just that). I would ask that people use another name if they did, though, to avoid confusion. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? I expect XBL and Dimitri's work will evolve together and eventually end up being features specified in the HTML spec. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Moving XBL et al. forward
Here's my best understanding of the ansers to these questions from the Forms WG perspective: We continue to cheer for the development of a component system for the HTML5 stack, as it will make things easier for end-user authors and for framework developers, whether they choose to express their ideas in markup, JavaScript, or a mix. We do not feel it is necessary for the desktop and mobile browser implementations of a new component language to handle namespaced XML. However, as XForms is, and will continue to be, a markup-based layer to other W3C technologies, many of which will, going forward, be specified as JavaScript interfaces (XHR, DOM, etc.), we want to ensure that an extension or optional feature can be used to accept namespaced XML markup and produce output including namespaced XML markup. We expect to see XForms implemented in popular mobile and desktop browsers (as it currently is) in JavaScript, XSLT, and in server-side systems. Thus, a syntax that can cleanly be extended to bind to (and to produce) namespaced markup is important to us. Our hope is that the extensions necessary to express this will be minimal. While our preference would be to have this syntax described in the main component language recommendation, we can live it with being expressed in another recommendation which merely adds on the syntax. As for re-casting XBL as a series of CSS extensions, itself not expressed in markup, we have not discussed that issue yet, but if the proposal moves further forward we will. Leigh. On 03/09/2011 06:14 AM, Arthur Barstow wrote: Ian, Leigh, Dimitri, All, On March 11, the agenda of the so-called Hypertext Coordination Group [HCG] will include XBL [XBL] to continue related discussions they had during their Feb 11 call [Feb-11-Mins]. I wasn't present at that call but based on those meeting minutes and what Leigh said last month [Leigh], I think the gist of the March 11 discussion will revolve around: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? Please send comments on the above as soon as possible (preferably before 10:00am Boston time on March 11). -Art Barstow [XBL] http://www.w3.org/2008/webapps/wiki/XBL [HCG] http://www.w3.org/MarkUp/CoordGroup/ [Feb-11-Mins] http://lists.w3.org/Archives/Public/public-hypertext-cg/2011JanMar/0007.html [Leigh] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0243.html [XBL2-CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [XBL2-ED] http://dev.w3.org/2006/xbl2/ [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
Re: Moving XBL et al. forward
On 3/9/11 1:56 PM, Anne van Kesteren wrote: I do not think the XML-based version makes sense anymore. It's too complex and has always felt a bit awkward. A set of extensions to HTML or CSS would make more sense. I really quite liked the idea of using CSS and having some way of writing markup in CSS for this. Hopefully we can explore that somewhat. I think there's an important point being missed here. CSS application to nodes that are not in documents is not defined. I'm not sure it's possible or desirable to define in good ways, even. If we want to use something XBL-like that persists across nodes being moved in a document, it needs to not be bound via CSS. If we want it to work for nodes that you created via createElement it needs to not be bound via CSS. This has been the #1 lesson we have learned with Mozilla's XBL1 implementation: the CSS binding mechanism has been the biggest problem with it, leading to weird behavior, gross timing-dependent hacks, and years and years of other problems. Whatever we do needs to NOT use CSS as the binding mechanism. -Boris
Re: Moving XBL et al. forward
Arthur Barstow: * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? I promised Dmitri some use cases from the SVG WG’s perspective, but haven’t managed to get to working on these yet. Whatever solution we have in the end – and I personally am not really fussed about whether it is XBL2 as it was, or is now, or something new based on Dmitri’s requirements document – I would like it to be able to work without an HTML document present. I want to be able to write a document like svg … star cx=100 cy=100 points=5/ /svg or svg … my:star xmlns:star=… cx=100 cy=100 points=5/ /svg or svg … g class=star cx=100 cy=100 points=5/ /svg or svg … g binding=star cx=100 cy=100 points=5/ /svg (choosing g here because it’s kind of similar to a div), one of those. Sorry for not having more concrete comments yet. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Moving XBL et al. forward
(off-list) On Wed, Mar 9, 2011 at 1:25 PM, Cameron McCormack c...@mcc.id.au wrote: svg … star cx=100 cy=100 points=5/ /svg svg x-star cx=100 cy=100 points=5/ /svg ~TJ
Re: Moving XBL et al. forward
Cameron McCormack: svg … star cx=100 cy=100 points=5/ /svg Tab Atkins Jr.: svg x-star cx=100 cy=100 points=5/ /svg Or that. :) I have the feeling that we don’t have agreed upon rules on how authors are allowed to extend the platform. Whatever we deem is the “proper” way for them to do so would be how I’d like it to happen in SVG. -- Cameron McCormack ≝ http://mcc.id.au/
