11

Since I learned to serve XHTML pages as XML, I have started noticing something odd: whenever I view an XHTML page in the Firefox source code viewer, the DOCTYPE is always marked as an error. According to the tooltip I get from mousing over it, the error in question is a "stray doctype". From what I understand, a "stray doctype" means that there is an extra DOCTYPE in the middle of the document where it doesn't belong, which is certainly not the case here.

Here's an example - this markup will pass validation, and display correctly in all modern browsers:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!--FF source viewer will mark the preceding two lines as an error.-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <meta http-equiv="content-type"
      content="application/xhtml+xml; charset=utf-8" />
    <title>Sample XHTML Page</title>
  </head>
  <body>
    <p>This is an example.</p>
  </body>
</html>

This error message is especially odd, considering that these pages pass validation perfectly, and that a single parsing error would normally break the page.

Slartibartfast
  • 338
  • 2
  • 9
  • 1
    Technically the DOCTYPE declaration is optional for the purpose of parsing and rendering the page in XML mode, but that doesn't mean one would be *unexpected* at that location as you correctly point out, and while it's optional for parsing, it's still required for validation (after all, how else is the validator going to know this is XHTML 1.0 Strict without making wild assumptions?). – BoltClock Nov 09 '13 at 08:12
  • I'd expect to see the error if the page is served up as HTML, but it's also there in a real XHTML page. I lean towards considering this a bug in FF, especially since this behaviour is the opposite of the output of the W3 validator. – Mr Lister Nov 10 '13 at 12:19
  • Actually, the bug _only_ appears when the page is served as `application/xhtml+xml`; when it is served as `text/html`, the error does _not_ appear. – Slartibartfast Nov 13 '13 at 02:12
  • 1
    It's the last day of 2016 and it also appears in SVGs with xml + DOCTYPE. – LGT Dec 31 '16 at 16:33

3 Answers3

9

I am the developer of this feature. You have found a bug. (Filed just now.) Thanks.

View Source syntax highlighting is based on the HTML parser, because our XML parser is not suited for the purpose and XML is rare enough that it doesn't make sense to put resources into implementing proper XML View Source. Hence, the XML View Source feature is a hack on the HTML parser and this aspect doesn't work quite right.

hsivonen
  • 7,908
  • 1
  • 30
  • 35
  • The same issue occurs for an XML document using an XSL to produce HTML. I commented the DOCTYPE which was flagged as "stray doctype" out, and then I got a console error for the XSL line: > InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable A consequence is that relative links don't work correctly for XML+XSL producing HTML output. When a link like http://.../file.xml#link is loaded, the link doesn't go to the right anchor. Click on the link address bar and hit Enter again, then it works. (I also updated this case in Bugzilla) – marius Jan 07 '14 at 10:14
  • I just tested Chrome and it has the same kind of issue. (FF 26, Chrome 31.0.1650.63 m) – marius Jan 07 '14 at 10:22
  • After 3 years this bug is still present in `Firefox ESR 45.4` (Debian GNU/Linux) and I'm experiencing it in a page with `DTD XHTML Basic 1.1`. –  Sep 29 '16 at 18:46
1

The error appears because the file is saved as UTF-8 BOM instead of UTF-8. Open the file in Notepad and change its encoding.

Public Sphere
  • 21
  • 1
0

In addition to @Public Sphere's answer.

This warning can also occur when using <!DOCTYPE html>. Probably the same warning is then also shown for the <html>, <head> and <body> tags (stray start tag "html").

To check if UTF-8 BOM is the problem:

  • Click the 'network' tab
  • Click the first request
  • On right details panel, click 'Response' tab and expand 'Response Payload'
  • You'll see the raw response now. A red dot is in front of the doctype line, and on hover it displays "\ufeff"

To easily find the files that could cause the problem, you can, in Linux, use this grep to find all files with BOM:

grep -rl $'\xEF\xBB\xBF' .
Piemol
  • 857
  • 8
  • 17