Comment #83 questioned whether that keyword was sincere and was never adequately answered in the thread.
Comment #83 was a rude philippic, and it didn't merit a response. If you think my time, or that of anyone else associated with mozilla.org, is owned even fractionally by anyone who mouths off in a bug, you are very confused. BTW, there is no "thread"ing in bugzilla.
You still haven't read http://bugzilla.mozilla.org/show_bug.cgi?id=XForms#c26 (mentioned in http://slashdot.org/comments.pl?sid=105421&cid=9025093), apparently.
For someone who called me a blowhard on /. based on my six comments in the XForms bug, totaling 22 paragraphs, you sure do post a lot of opinion-advancing words yourself.
Maybe you'll take the honorific you bestowed on me back now, since I have confined my replies to you in /. and now here to arguments in favor of factual claims about which we can reason, not unprovable assertions, arguments from authority, misconceptions of how mozilla.org and browser markets work, etc. etc.
Trying to forge you own standard and rejecting ones like XPath seems neither "author friendly"
XPath is not used by web content authors enough to speak of, let alone assert that it's friendly to them to support it.
nor "likely to succeed" to me.
On the contrary, if the three top minority market share browsers support a simpler standard, and that spec can be implemented on IE using HTCs, then such a standard is infinitely more likely to succeed than XForms, which is not going to be supported in browsers, except possibly in Mozilla.
Doesn't the IE monopoly make incremental extensions to HTML vitually impossible?
Again, _au contraire_. Incremental extensions to HTML are the easiest for browser vendors to implement, and for volunteers to emulate on top of IE's HTML support using CSS, HTCs, scripting, and whatever else works (Active X or COM native extensions, if necessary).
/be _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
