>Not until supporting a "no-sugar" diet is "required", not "optional"; >you seem to have ignored that (distinct) point. Both modes are "requried" by some applications. Both modes are available, at the application's election. I don't think that provides particularly clear guidance re which should be the default, either way; setting a flag before parsing isn't exactly a major hardship or performance impact, and a convenience routine to yield a parser configured as you need it is fairly trivial. For that reason, I'm not really dogmatic about which way this should go. I do think that having the DOM default to building as complete a DOM as possible and filtering down from there is a touch cleaner, architecturally... but I grant that this is a matter of taste. >"property" (in explanatory text) and "feature" (in the API) are both used. If they're both used to refer to the same things, we should certainly fix it. If it's a matter of "If this feature is supported by the DOM, it can be disabled by setting that property" (where the feature is the behavior/API and the property is the flag), we should consider whether our intent is clear and make sure that "property", like "feature", goes into the glossary. >(Why not call them "optional modules"? :) A bit late to change it now, especially given the hasFeature() method. ______________________________________ Joe Kesselman / IBM ResearchReceived on Friday, 6 July 2001 13:17:08 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:49 GMT