Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
User Journal

Journal einhverfr's Journal: Why Firefox 3 is Bad for Developers 2

One of the major problems I have run into with Firefox three is that XHTML which passes the W3C's valiators is not rendered at all. The problem has to do with the fact that the W3C and the Firefox team apparently have different views as to what the XHTML spec actually means.

See the discussion in the following bugzilla entries:

The following XHTML document renders on Seamonkey but not on FF3. Furthermore, it passes the W3C's validators with no problems:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <title>LedgerSMB 1.2.99</title>
    <meta http-equiv="Pragma" content="no-cache" />
    <meta http-equiv="Expires" content="-1" />
        <link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
    <link rel="stylesheet" href="css/ledgersmb.css" type="text/css" title="LedgerSMB stylesheet" />
    <link rel="stylesheet" href="UI/login.css" type="text/css" title="LedgerSMB stylesheet" />
    <link rel="stylesheet" href="css/ledgersmb.css" type="text/css" title="LedgerSMB stylesheet" />
    <script type="text/javascript" language="JavaScript" src="UI/login.js" />
    <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
    <meta name="robots" content="noindex,nofollow" />
<body class="login" onload="setup_page('Name:',
    <br /><br />
        <form method="post" action="login.pl" name="login"
            onsubmit="return submit_form()">
        <input id="menubar" type="hidden" name="menubar" value="" />
        <input id="blacklisted" type="hidden" name="blacklisted" value="" />
        <div class="login">
            <div class="login" align="center">
                <a href="http://www.ledgersmb.org/" target="_top"><img src="images/ledgersmb.png" class="logo" alt="LedgerSMB Logo" /></a>
                <h1 class="login" align="center">Version SVN Trunk</h1>
                <div align="center">
                    <div id="credentials"></div>
                    <div id="company_div">
                      <div class="labelledinput">
                        <div class="label">
                            <label for="company">
                        <div class="input">
                            <input class="login"
                            accesskey="c" />
                <button type="submit" name="action" value="login" accesskey="l">Login</button>
        <p><a href="admin.pl">Administrative login</a></p>

The problem lies with the tag in the document head. Firefox 3 sees it as unterminated while the W3C validator sees it as properly terminated. The Firefox team argues that the W3C validator is wrong and that they won't support content that the W3C's tools say are valid.

The Firefox Team's Rationale:

The new behavior in Firefox, as it turns out is behavior by design. The issue has to do with a security fix which had to do with unterminated tags in earlier versions, where the tag would be ignored and the rest of the document would be processed as HTML. Obviously this is a problem because it leads to ambiguity as to the nature of content, whether it is executable, and what it does. I support their efforts to fix it, but I also think that the fix is as flawed from developers' perspective as User Access Control is in Vista from a power user's perspective. Basically a self-terminating tag is differentiable from an unterminated one and since the W3C's validators show this as valid, it should be handled.


Why this is a bad thing:

Now, arguably the W3C's validators are wrong. According to the spec and the DTD, the script tag really *should* have an end tag. However, expecting that all developers are going to be spec lawyers is a serious mistake. Many developers *do* rely on the W3C validators as being the ultimate arbitrator of what is valid HTML and XHTML. Failing to handle this case in the same way will:

1) Needlessly flood bugzilla with repetative bugs.
2) Drive developers away from Firefox to those who are more inline with existing validation tools
3) Create support headaches for everyone.

This is a trivial fix without the dire security issues the Firefox team has invoked.

A second option would be to engage with the W3C to help ensure that such discrepancies are resolved bidirectionally. A little effort now will save a lot of headache for everyone down the road. I would hate to see Firefox 3 become more or less the Windows Vista of Open Source, but this may happen if the FF team decides to go it alone in their interpretation of the specs. That would be a real shame.

This discussion has been archived. No new comments can be posted.

Why Firefox 3 is Bad for Developers

Comments Filter:
  • There's another thing that's working against this bug. XHTML is no longer the focal point for browser developers, and web developers are moving towards HTML 4.01 strict, see Ian Hickson's famous http://www.hixie.ch/advocacy/xhtml [hixie.ch]
  • The problem is that you're asking the validator whether this document is valid XHTML. It is. If you send it as application/xhtml+xml, there is no problem.

    Unfortunately, it sounds like you're sending it as text/html, not the proper XHTML MIME type. XHTML may only be sent as text/html if:

    1) It satisfies all the normal constraints of XHTML.
    2) It _also_ satisfies the additional constraints of Appendix C
    of the XHTML 1.0 specification.

    So sending this document as text/html is a vi

I'd rather just believe that it's done by little elves running around.