Does this include inline blocks?

No — this check only looks at on* attributes on HTML elements (onclick, onload, etc.), not tags. Inline blocks have their own CSP considerations (nonces/hashes) but aren't what this check reports.

Info Inline event handler attributes

Why onclick and other inline event handler attributes are discouraged, and how they interact with Content-Security-Policy.

The validator flags attributes like onclick, onload, onmouseover, and any other on* attribute used directly in markup.

Example

<!-- Discouraged -->
<button onclick="submitForm()">Submit</button>

<!-- Preferred -->
<button id="submit-btn">Submit</button>
<script>
  document.getElementById("submit-btn").addEventListener("click", submitForm);
</script>

Why it matters

Inline event handlers mix behavior directly into markup, which makes it harder to see everywhere a piece of behavior is wired up, and harder to remove or replace a listener cleanly (there's no direct inline equivalent of removeEventListener). More concretely, a strict Content-Security-Policy without unsafe-inline in its script-src directive blocks inline event handlers outright — the attribute is simply never executed, with no error beyond a CSP violation report. Attaching the same behavior with addEventListener from an external or nonce'd script works under a strict CSP.

Frequently asked questions

Will removing inline handlers break my site?

Not if you replace each one with an equivalent addEventListener call — the behavior is identical, just attached from script instead of markup. It only becomes urgent if you're adopting a Content-Security-Policy that blocks unsafe-inline.

Does this include inline <script> blocks?

No — this check only looks at on* attributes on HTML elements (onclick, onload, etc.), not <script> tags. Inline <script> blocks have their own CSP considerations (nonces/hashes) but aren't what this check reports.