Re: CfC: publish new WDs of Sever-sent Events, Workers and Storage
On Sun, 23 Jan 2011 14:16:42 +0100, Arthur Barstow art.bars...@nokia.com wrote: As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with this proposal to publish. Lets do it! -- Anne van Kesteren http://annevankesteren.nl/
What is happening with XBL?
[ Bcc: set to: public-fo...@w3.org ; please set Reply-To: to just public-webapps@w3.org ] XBL Fans, In case you missed it, about a week ago, Anne van Kesteren wrote a nice blog about some of the recent activities with XBL including pointers to some related work by Dimitri Glazkov (e.g. Use Cases). Given AvK's blog is short-ish, I'll quote it here: [[ http://annevankesteren.nl/2011/01/xbl What is happening with XBL? 15th January 2011 What is happening with XBL? http://annevankesteren.nl/2011/ Despite quite a bit of interest when XBL 2.0 http://www.w3.org/TR/2007/CR-xbl-20070316/ was developed it has not made it into browsers thus far. Perhaps because Jonas Sicking is too occupied, or perhaps it simply is too complex. The drive for XBL started moving again late last year when Ian Hickson simplified http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0675.html the specification. Instead of a new language XBL would become a set of extensions to HTML. In parallel, Dimitry Glazkov started drafting Component Model Use Cases http://wiki.whatwg.org/wiki/Component_Model_Use_Cases, a WHATWG Wiki document anyone can contribute to. Effectively taking a fresh look at what we want nowadays from XBL. He also wrote a great post for anyone not familiar with the types of scenarios XBL will tackle: What the Heck is Shadow DOM? http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ It is a complex subject, but the way he conveys it makes it look easy. Now I have been hopeful for XBL happening pretty much since we started working on HTML5 in 2004 so I am not too excited yet. But for the first time in almost four years we are making progress again. ]] I think there are at least four different versions of XBL specs with various levels of implementations: 1. Mozilla XBL: original, Mozilla-specific; Blue Griffon. Perhaps some XForms implementations also implement Mozilla XBL? 2. sXBL: first attempt at a standard XBL, aimed mainly at SVG. Lots of interest at SVG Open three or four years ago but apparently interest has died? 3. XBL2 CR: - some XForms implementations reported; Jonas announced some work (last report May 2010) http://www.w3.org/TR/2007/CR-xbl-20070316/ http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/1008.html [from Leigh] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0485.html [from Jonas] 4. XBL2-cutdown: Hixie's September 2010 version. Not clear if there is any implementers support for this enough or if any prototyping/implementing has been done. http://dev.w3.org/2006/xbl2/ http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0675.html It would be useful to get updated implementation plans/data, especially for #3 and #4 above. As Anne implies, Dimitri's work raises questions about whether XBL2 CR or XBL2-cutdown are the right approach or is a different approach is needed? Additionally, given the broad set of constituencies here, and the requirement to preserve implementation investment, is it realistic to expect one spec to satisfy all of the use cases and requirements? -Art Barstow
[Bug 11847] New: hich you are submitting feedback, quoting the text that's wrong today if appropriate. If you're suggesting a new feature, it's really important to say what the problem you're trying
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11847 Summary: hich you are submitting feedback, quoting the text that's wrong today if appropriate. If you're suggesting a new feature, it's really important to say what the problem you're trying to solve is. That's more imp Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: hich you are submitting feedback, quoting the text that's wrong today if appropriate. If you're suggesting a new feature, it's really important to say what the problem you're trying to solve is. That's more imp Posted from: 58.33.113.75 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: What is happening with XBL?
Le 24 janv. 2011 à 08:24, Arthur Barstow a écrit : 1. Mozilla XBL: original, Mozilla-specific; Blue Griffon. Perhaps some XForms implementations also implement Mozilla XBL? just for the record ;) @karlpro BlueGriffon does not _implement_ xbl ; Gecko does ; BlueGriffon _uses_ it... – http://twitter.com/glazou/status/29535104942481409 -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
[Bug 11847] hich you are submitting feedback, quoting the text that's wrong today if appropriate. If you're suggesting a new feature, it's really important to say what the problem you're trying to s
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11847 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID --- Comment #1 from Art Barstow art.bars...@nokia.com 2011-01-24 15:28:40 UTC --- Invalid. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: What is happening with XBL?
We've discussed this on Forms WG and are preparing a reply, but in the interest of time I'll give a summary: The Forms WG members are pleased with the progress toward real-world XBL and shadow-DOM injection facilities in popular desktop browsers, and want to encourage that work. Additionally, a number of our members are using a cut-down version of XBL2 as a macro language for composing XForms and HTML components, usually in a transformation step that takes place before markup is delivered to popular desktop browsers. The use cases which public-webapps is currently studying for XBL also include component definitions, so we feel that is harmony between the goals, and *hope that we can work together to a common specification*, though perhaps with optional features. While there are non-browser implementations of XForms, most XForms implementations for popular desktop browsers are using JavaScipt and other in-browser facilities to provide a markup-based, declarative interface to the native facilities available in the browser, and we see progress in the shadow-DOM front as a great benefit. Our hope is that as HTML5 moves forward that it gets easier, rather than harder, to provide XForms declarative markup-based access to browser facilities, and we hope to leverage the eventual XBL-like shadow-DOM injection facility as part of this delivery, /as well as/ retain the ability to define and use components containing a mix of HTML and XForms markup. A number of XForms implementations make use of XBL or cut-down versions of XBL2 to develop widgets and composite controls: 1A: In Mozilla XForms the XForms markup is bound with full-blown XBL with shadow DOM, CSS bindings, JavaScript etc. 1B: In all others, a cut-down XBL2 is used as a simple macro-language for composing compound form controls out of HTML and XForms markup, without any participation in the underlying HTML4 browser shadow DOM. In these cases, XSLT is also used to provide a transformation step, providing the ability to use attribute-value templates to perform substitutions instead of simply copying of attribute values. * Being able to unify these two uses of XBL is our goal, and obviously if a better version of XBL is widely deployed in popular desktop browsers, that task becomes easier. * However, there is one area of concern, and that is that it the ability to bind to markup in the XForms namespace, or to produce output markup in the XForms namespace may be removed from XBL. Ian Hixson's proposal to eliminate namespaces and event support from XBL2 is the most troubling issue for us. To expand on this point, for case 1A, we feel that it's necessary to provide an ability to match markup with namespaced elements, and also to produced namespaced-elements (mostly XForms in both cases) as output. A clear idea of when XSLT PIs are processed and when XBL definitions are processed might go far toward helping resolve this issue.However, for case 1B, where the XBL implementation is not within the browser, optional namespace support in the Recommendation may be sufficient. It may be that if XSLT PI support is retained, in-browser implementations will be able to continue to use that to provide the namespace matching necessary to disambiguate XForms from underlying HTML4 or HTML5 elements, and then the shadow-DOM facility can operate at a separate level. Some implementations have had success in using in-browser XSLT or in-browser JavaScript re-parsing of the live DOM to bridge between the XForms markup and HTML+JavaScript implementation. However, a clear ability to do one of these two things from within XBL (interpose XSLT transformations, with namespace binding, or to use JavaScript to read the incoming DOM with un-munged namespaced elements) would be necessary to sure a path to success with an XForms+XHTML+XBL - HTML5+XBL in-browser conversion (i.e., to allow XBL to operate both to expand into XForms markup and to participate in the in-browser behavior). Additionally, some of our WG members feel that XPath selectors would be more useful for case 1B. However, I believe we are approaching a consensus that CSS selectors are OK for case 1A, so my personal belief is that we will most likely not be asking for XPath selectors. Leigh. On 01/24/2011 05:24 AM, Arthur Barstow wrote: [ Bcc: set to: public-fo...@w3.org ; please set Reply-To: to just public-webapps@w3.org ] XBL Fans, In case you missed it, about a week ago, Anne van Kesteren wrote a nice blog about some of the recent activities with XBL including pointers to some related work by Dimitri Glazkov (e.g. Use Cases). Given AvK's blog is short-ish, I'll quote it here: [[ http://annevankesteren.nl/2011/01/xbl What is happening with XBL? 15th January 2011 What is happening with XBL? Despite quite a bit of interest when XBL 2.0 http://www.w3.org/TR/2007/CR-xbl-20070316/ was developed it has not made it into browsers
