> If we talk about public web sites the goal > should be "absolute accessibility everywhere".
I think we can all agree on this fundamental goal. But making a player available freely and providing content which is not html-ized does not contravene this crucial principle. You cannot create xCard content with a plain old text editor (W3C's definition of accessibility) but no-cost versions of MC and RunRev are available via the web which allow you to do everything that HTML can do, with no limitations; & script the interactivity of your content with the 10-line and 25-line scripting-limits of MC and RunRev respectively. Much can be achieved within this constraint given that the script of buttons rarely exceed a few lines, for example. Full accessibility, in my view, should also take into consideration the ease with which the content and its interactivity can be maintained/modified by those who create the wares AND by those who USE them too. What would you rather work with? With an xCard that allows you to build your web solutions with a WYSIWYG GUI vs a traditional approach to web solutions which requires you to *textually* code the content, its structure and the appearance that its *likely* to have on the client side, plus your users cannot readily change it themselves. Do you prefer xTalk over JavaScript? > Unfortunately as long as somebody is going to > make a buck out of it, html will never evolve > and the public will be served only half. The HTML standard has been retired from the development cycle. IOW, W3C has officially declared that the HTML standard is "done". It won't evolve any further. W3C & others are now promoting XML (and kin) as the standards of the future. At best, HTML will live on as xHTML, IOW as a dialect of XML that can be handled by XML as XML. > The excuse that the backward compatibility > will suffer is false, people do upgrade > when they have a reason. Backward compatibility is important but in the ebullient and volatile climate of rapid technological changes that we live in these days, its not always feasible. To avoid this merry-go-round, we must endeavour to make our wares (and the underlying code) as OPEN as possible. Open to third-party enhancements, as well open to the subsequent changes that will inevitably be made to the ware/code. This, in turn, is mainly a question of good design and a bit of foresight. Backward compatibility is more viable (sustainable) with stacks than with HTML pages. A stack is equivalent to a complete site, yet far more flexible than the dozens or hundreds of corresponding web pages. A stack can/will be scripted to re-purpose the existing content, casting the content in several forms: HTML, XML, textfiles, database records, reports, CGI program; individually, or any mix that you wish. New formats can also be scripted as they become available, relevant, popular... without fussing with the content at all and without disrupting the other formats either. I agree with you that people do upgrade when they have a good reason and a reasonable of success. It's evolution! My conviction is that we have the upper-hand in terms of potential, but I suppose that we the xCard community has not made its case persuasively enough. Not yet that is! Ignorance of the superiority of our xCard approach must be countered with more communication, and hopefully my last 3 messages to this list have contributed to this, albeit in a very small way. You can quote my ramblings, if you wish, in other forums. As it is, I am preaching to the converted, eh! For those of you who know me better, I am endeavouring to persuade the university-based R&D center that I work for to switch over to an xCard approach from a PHP+SQL solution which mirrors what everyone else is doing. No thank you; conformity sucks!, particularly when one is being pressured to conform to something mediocre like HTML and JavasScript. We can, and will do, much better than this. Update : my colleagues and my superiors are taking my proposal very very seriously. They expect me to submit a detailed plan along these lines, in order to fetch some top-notch support, including some funding, to pursue this xCard approach *aggressively*. :-) I can't believe how much time I have blown on this post. I have to get back to work now. If I am boring you all, then please tell me eh! ;-) Editorially yours, Alain Farmer Laboratoire de Communautique Appliquée Université de Québec à Montréal (UQAM) [EMAIL PROTECTED] __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard