This is a compromise -
1. Keep insertion of a blank title tag, if none.
2. Add new warn if title tag is blank, in html5
modified: include/tidyenum.h
modified: src/language_en.h
modified: src/message.c
modified: src/parser.c
option every time we might want to allow or disallow new output. Adds two new
options:
- `squelch-id` (default **no**) will provide tags during Tidy's output that
can be used to silence warnings. For example, `MISSING_ENDTAG_OPTIONAL`
will be shown after warnings of that type. Then in the future, the user can
use...
- `squelch` (default NULL) takes a list of message identification tags.
Messages of this tag type will then be muted from output.
This gives the user great control over hiding things that he or she doesn't care
about seeing. However, muted errors/warnings still count toward error summaries.
If we merge this, then TidyShowMetaChange and TidyWarnPropAttrs are candidates
for removal (using the deprecation mechanism Tidy now has, these will continue
to work, though).
- Prevent the message filter from missing possible messages due to dispered
control.
- Single decision point for the types of messages to be output given current
conditions and options settings.
- Change default value of `--fix-bad-comments` to `no`.
- Ensure that when _not_ fixing, nothing is actually fixed.
- Ensure that when fixing, initial adjacent hyphens actually are fixed.
- Issue tidyinfo for all fixes made.
- Issue tidywarning when when not making fixes for non-HTML5 doctypes.
output, classify and organize all of the dialogue type of messages. This paves
the way towards formalizing (and expanding!) the footnotes system with much
greater explanatory text, as well as providing much better fine-grained control
over which types of output that Tidy will produce.
Moved STRING_DOCTYPE_GIVEN, STRING_CONTENT_LOOKS, and STRING_NO_SYSID to the
Report paradigm from the Dialogue paradigm, as these are items that are
traditionally TidyInfo and included in the Report table, rather than any type
of dialogue.
At this point, we are exactly passing all tests.
Note that there are several regressions in the accessibility test suit that
are not related to output messages. These are a result of previous work, and
these results should be updated in the test suite when this item is merged.
