In one paragraph
IE conditional comments in HTML means the raw source contains a marker matching this legacy pattern. Review where the markup is consumed before deleting it: ordinary modern browser pages, legacy enterprise environments, and email rendering can have different needs. Preserve content in revealed blocks and retain justified email-specific code. The warning is a source clue, not proof every enclosed resource is universally unused.
Why it matters
Microsoft documented downlevel-hidden and downlevel-revealed conditional forms for older Internet Explorer. In clients that do not implement that feature, hidden blocks are ordinary comments while revealed content can remain part of the page. Deleting the entire surrounding region indiscriminately can therefore remove current content.
MSO conditions also appear in HTML email, particularly workflows targeting Outlook's Word-based rendering. Not every product called Outlook uses the same engine, and a web version of a newsletter may share code with its email version. A browser cleanup should not silently break a different intended consumer.
A legacy marker can suggest maintenance work, but it does not prove old libraries are insecure or that removing comments delivers a measurable performance gain. Evaluate real dependencies and support commitments rather than making categorical assumptions.
How WebAuditOS evaluates this finding
The supplied rule matches documented conditional-marker prefixes anywhere in eligible raw HTML, case-insensitively. A match warns informationally; no match passes; error or unavailable content can remain ungraded.
It does not distinguish hidden from revealed behaviour, validate conditions, count complete blocks, or determine whether the same source is sent as email. Strings inside scripts or examples can also match. The stable internal ID compat.viewport-units is historical and must not be renamed during content import.
How to fix it
- Find the exact source region and all templates that reuse it. Determine whether it is an ordinary webpage, an email archive, a shared email source, or a deliberately supported legacy application.
- Classify the conditional syntax rather than deleting between arbitrary markers. A hidden block and a revealed block have different content-preservation needs in current non-supporting clients.
- For genuinely unused browser-only shims or styles, remove the loader and then verify nothing else references the asset before deleting the file. Do not assume a familiar old filename proves safe removal in every deployment.
- Preserve ordinary modern content inside revealed structures while simplifying only the wrapper where appropriate. Test actual script and stylesheet loading afterwards.
- Retain or deliberately redesign justified email-specific conditions with email-client testing. A browser scan's marker warning is not an instruction to erase Outlook compatibility code.
- When consolidating conditional root-element patterns, preserve needed language, direction, class, and other attributes on the final valid root element. A cleanup should not introduce a missing-language or parsing problem.
- Test supported browsers, actual email consumers where relevant, responsive layout, and the tasks depending on the affected assets. Review legacy-support exceptions with their owners instead of making them disappear silently.
- Rescan and document justified retained matches. A source-pattern pass is not proof all legacy dependencies have been modernised or every script still works.
What the fix can break
A broad regular-expression deletion can remove rendered content or cross incorrectly nested comment boundaries. Use a reviewed transformation with backups and representative tests.
Removing a stylesheet can expose rules that depended on a legacy class or a shared conditional branch. Verify the final resource graph.
Do not describe comments as always cost-free or always a ranking problem. Their actual maintenance and transfer impact depends on the content; this detector does not measure it.
Questions
Can I delete every conditional block wholesale?
No. Revealed content or shared email markup can still be needed. Classify and test first.
Does an MSO marker necessarily mean an IE-only webpage bug?
No. It can be part of a valid email-compatibility workflow.
Should the internal viewport-units ID be fixed here?
No. Preserve the supplied stable identifier; changing a product registry is not part of this text rewrite.
Which related checks help?
Review obsolete elements, doctype, and the website audit checklist.