- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 22 Mar 2007 22:52:50 +0000 (UTC)
- To: Sebastian Schnitzenbaumer <sebastian@dreamlab.net>
- Cc: public-html@w3.org
On Thu, 22 Mar 2007, Sebastian Schnitzenbaumer wrote: > > Yes. I wasn't suggesting WHATWG was vs. XHTML 2 or XForms. I was > suggesting that the technologies were designed in absence of a liaison > and consistency check between W3C technologies. Well, again, I don't know how the XForms and XHTML2 technologies have been developed, but the WHATWG specs are definitely built with XForms and XHTML2 in mind. I (and other WHATWG contributors) regularly read the archives of the XHTML2 and XForms working groups (as well as a lot of other working groups), and take development that affects those specs into account. For example, when issues are raised on www-html-editor on XHTML2, if the same issue affects HTML5 then I make a note of it and in due course resolve it (even if the XHTML2 WG rejects the issue, as often happens). When drafts (even internal drafts) of these working groups are produced, they are carefully examined, and where appropriate the WHATWG drafts are aligned appropriately. For example, WHATWG's spec dropped <acronym> much like XHTML2. The WHATWG specs similarly track the whole gamut of W3C technologies, including the Web API group's interfaces, the SVG group's development, the CSS group's features, as well as looking at feature requests from authors on the public lists of all these groups (I, and others in the WHATWG community, are subscribed to www-html, www-talk, www-svg, www-style, public-webapi, public-appformats, etc). So I again disagree with your characterisation that the WHATWG specs were built in the absence of consistency checks between the WHATWG specs and W3C technologies. > Currently XHTML2 and HTML5 are drifting apart, for example. Well, HTML5 is constrained by having to be backwards-compatible with legacy content and user agents. I'm not sure why this is automatically a problem. Do you have any concrete examples that you are concerned about? > I think this is a problem, and I think its a reasonable thing to ask, do > we want this? Can't we make them grow together at some point? I don't think the WHATWG community has any objection to making these specs closer by design; the WHATWG and the HTML WG are open environments, and the XHTML2 working group is always welcome to make suggestions and work with us in trying to find ways to avoid unnecessary differences. To my knowledge, however, we (the WHATWG contributors) have already gone to extreme lengths to avoid such differences; the ones that remain are in areas where we could not line up without sacrificing core goals of the WHATWG effort (such as backwards compatibility). > This is more than just incorporating some suitable aspects where > possible, its more of a goal, or vision, and something that I think is > the right thing to ask at brainstorming time of a new WG. I'm not really good with abstract goals and visions, I'm afraid. However, if you have concrete suggestions that would be really helpful for moving forward. > > Some people have suggested some features, like declarative > > calculations, but it isn't clear how those features would work (the > > XForms Transitional draft, as previously discussed, doesn't actually > > define how they would work for all cases -- according to the current > > definition, in fact, one would have to solve the halting problem to > > implement the spec). In the case of declarative calculations it is > > also not clear how the feature could be made to degrade gracefully > > without breaking full implementations. > > There is tendency that anything new doesn't work. Well, its not new, > XForms Transitional is just a simplification of XForms, and XForms has > been around for a while, and there a bunch of good ideas in there that > have been widely validated. With respect, the XForms Transitional specification has more in common with Web Forms 2 than XForms. The calculate="" feature specifically, as defined right now, is impossible to implement. It isn't impossible to implement in XForms, because XForms using XPath instead of JavaScript, and it is possible in XForms to statically analyse the references. However, in the XForms Transitional proposal this has been lost and the result is not implementable. There are a number of others features in XForms Transitional that work fine. Most are already in Web Forms 2 in some form or another (and have been carefully designed and tweaked in response to three and a half years of feedback and implementation experience), some of the others have already been noted for inclusion in a future revision of Web Forms 2. If there is one thing that the WHATWG does not suffer from, it's "not invented here" syndrome. We will take good features from anywhere we see them, so long as they are good and work well with our core principles. :-) > Now taking some these ideas and making them compatible with SGML-based > HTML is what XForms Transitional is about, and brings me to the core of > my message, trying to bring these technologies together over the long > run. >From the perspective of the WHATWG and its contributors and proponents, what might be more useful than a proposal replacement would be a careful review of the Web Forms 2.0 specification and a discussion of which features you think should be improved or added to bring the technologies closer together. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 22 March 2007 22:53:04 UTC