Member Avatar for somjit{}

chrome , firefox.. these are great browsers , and even if i write utter crappy html code, it still makes sense out of it , and tries to display it the way a proper code would have made it display.

thats great stuff unless i want to know/see the errors when i make them.

any such place i can do that ?

Edited by somjit{}
  • 5 Contributors
  • 5 Replies
  • 287 Views
  • 9 Months Discussion Span
  • Latest Post Latest Post by almostbob

Dani AI

Generated

Short practical guide for and anyone who wants the browser to stop “fixing” broken markup.

Browsers try to be helpful, so visual rendering rarely shows the underlying parse problems. Combine three kinds of tools instead of relying on a single browser: (1) live linting in an editor for immediate feedback, (2) a standards validator for conformance and line/column errors (as pointed out), and (3) a strict parser that refuses to recover so problems become obvious.

Editors and linters: follow ’s advice — use an editor that highlights syntax and runs an HTML linter while typing. Popular editors can run HTMLHint or an HTML language server, show line errors, and be wired into pre-commit hooks. Command-line checkers (HTML Tidy or an html5 parser) will list errors and offer auto-fixes that show what’s really wrong.

Force strict browser behavior: serve the page as XHTML (MIME type application/xhtml+xml). Browsers that honor that MIME type will use an XML parser and show a parse error for malformed documents instead of correcting them. Example — valid XHTML header:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
  <head><title>Test</title></head>
  <body><p>Hello</p></body>
</html>

If a required closing tag is missing and the file is served as application/xhtml+xml, the document will fail to parse (visible as an XML parse error). Note the caveats: serving XHTML affects script handling (inline scripts often need CDATA or external files) and some old browsers historically don’t support that MIME type.

A simple, actionable workflow: fix problems while editing (editor + linter), run a standards validator for conformance, run a strict parser or Tidy for well-formedness, then test rendering and raw output (compare “view‑source” to the DOM inspector and try device/emulator checks as suggested). Add linter + validator to CI so bad markup never reaches production.

Recommended Answers

All 5 Replies

Member Avatar for somjit{}

thanks a lot :)

Member Avatar for Dani

Use an editor that syntax highlights to help you catch yourself.

Member Avatar for frankjames018

go to w3school there you can find the best way to test the code...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.