I've been auditing all of the configuration options, and there are a few key changes I'd like to sneak in while we're still in next. The goals are to simplify the number of configuration options, preserve backward compatibility for a time, communicate changes to users, and offering better documentation.
Change TidyShowMarkup
Propose changing this to an enum with values no, yes, force-output. This would allow us to eliminate TidyForceOutput.
Change TidyHtmlOut
Propose changing this to an emum with values html, xhtml, and xml, allowing us to retire TidyXhtmlOut and TidyXmlOut.
Aside from trimming options, this removes all doubt about which configuration option "wins" if someone sets multiple options.
Retire TidyShowMetaChange and TidyWarnPropAttrs
Consistent with #629, these wouldn't be needed any more. The question, then, would be whether or not we maintain these using the deprecation mechanism (good practice), or drop them completely because they've only ever been in the next branch.
Handle the above deprecations in a backward compatible way
There's now a mechanism in place to accept "legacy" options while eliminating them from Tidy, but allowing them to still work (with a notice to the user).
Updated: 2017-October-08
I've been auditing all of the configuration options, and there are a few key changes I'd like to sneak in while we're still in
next. The goals are to simplify the number of configuration options, preserve backward compatibility for a time, communicate changes to users, and offering better documentation.Change
TidyShowMarkupPropose changing this to an enum with values
no,yes,force-output. This would allow us to eliminateTidyForceOutput.Change
TidyHtmlOutPropose changing this to an emum with values
html,xhtml, andxml, allowing us to retireTidyXhtmlOutandTidyXmlOut.Aside from trimming options, this removes all doubt about which configuration option "wins" if someone sets multiple options.
Retire
TidyShowMetaChangeandTidyWarnPropAttrsConsistent with #629, these wouldn't be needed any more. The question, then, would be whether or not we maintain these using the deprecation mechanism (good practice), or drop them completely because they've only ever been in the
nextbranch.Handle the above deprecations in a backward compatible way
There's now a mechanism in place to accept "legacy" options while eliminating them from Tidy, but allowing them to still work (with a notice to the user).
Updated: 2017-October-08