This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When validating CSS on my website (by entering http://jigsaw.w3.org/css-validator/validator/?uri=http%3A//www.neonchart.com/tiki/tiki-index.php ) the CSS validator claims that i should validate my XML first (output could be viewed at the bottom of this page). The page however validates OK using the following link http://validator.w3.org/check?uri=http%3A%2F%2Fwww.neonchart.com%2Ftiki%2Ftiki-index.php The bottom line is that no CSS validation is performed. I think that either the HTML validator should complain at the XHTML or that the CSS vaildator should atleast start to examine my CSS. (Another possiblity is that the error message is formulated in a way that i fail to see the problem inf there is one). The page displays as expected in most new browsers (which proves that they can find the CSS file from the XHTML page) I use Red Hat 9 and have entered actually entered the adresses above by using the Tools | Validate Web page | Validate HTML and Tools | Validate Web page | Validate CSS menu items in Konqueror (but my guess is that this has nothing to do with the problem). Best regards Jan (Please see output from CSS validator below) <!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang='en' xml:lang='en' xmlns='http://www.w3.org/1999/xhtml'> <head> <meta name="ROBOTS" content="NOINDEX, NOFOLLOW" /> <title>CSS Validator : Error</title> <link type="text/css" rel='stylesheet' href='http://jigsaw.w3.org/css-validator/style/error.css' /> </head> <body> <div> <a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="w3c" /></a> </div> <hr /> <div class="t1">CSS</div> <div class="t2">Validator</div> <div class="t3">Error</div> <h2>Target: http://www.neonchart.com/tiki/tiki-index.php</h2> <div class="error"> <p>Please, validate your XML document first!</p> <p>Line 1</p> <p>Column 3</p> <p>The markup declarations contained or pointed to by the document type declaration must be well-formed. </p></div> <hr /> <p><img src='images/mwcss.gif' alt='made with CSS' /></p> <address><a href='Email.html'>www-validator-css</a></address> </body></html>
The problem is that your DOCTYPE declaration reads thus: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd"> when it should read thus: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> (i.e., you need an absolute URI rather than a relative one, since the DTD is not located at http://www.neonchart.com/tiki/DTD/xhtml1-transitional.dtd). This is a common mistake, actually; the Markup Validator should pick up on it. Moving to the "Validator" product, though I'm not sure I'm putting it in the right component thereof. :-/
Created attachment 196 [details] Testcase. This is a testcase demonstrating the bug. The MarkUp Validator says that the page is valid, even though the system identifier in its DOCTYPE declaration is wrong.
This is not a validity error, and arguably isn't an "error" at all, as it is perfectly permissible to prefer the FPI over the System Identifier (if one is even provided). There is a standing feature request for the Markup Validator to detect various questionable SIs (e.g. that do not match the FPI, or that are ambigious or unresolveable) and issue a warning, but it is not a bug. The behaviour of a conformant system when presented with both a FPI (whose syntax and semantics are defined) and an SI (which is just a bag of bytes and whose interpretation is left to the implementors) is implementation dependant. Prefering the FPI in this case is IMO the more logical (and established) practice. IOW, not recognizing the FPI in this case is a CSS Validator bug.
If the purpose of the validator is to ensure a user that a document is valid (in this case) XHTML, then I respectfully disagree with Comment #3. According to the > An XML processor attempting to retrieve the entity's content may use any > combination of the public and system identifiers as well as additional > information outside the scope of this specification to try to generate an > alternative URI reference. (http://www.w3.org/XML/xml-V10-2e-errata#E25) This suggests that a conforming, validating processor could find the attached XHTML document to be invalid (since its system identifier produces a URI reference that doesn't correctly identify a DTD). Therefore, the markup validator should inform the user of this. (This seems like a problem with the XML spec - it describes validity as a property of the document, but it seems that in practice, different conforming, validating processors could disagree about whether a given document is valid.)
The issue here isn't really one of Valid vs. Invalid; it's a question of how an implementation of a SGML System chooses to attempt to resolve the External Subset. The CSS Validator is choosing to ignore the FPI when a SI is present -- despite the FPI beeing, in this case, assigned by the W3C; unlike the SI, which may be any arbitrary string -- while the Markup Validator prefers the FPI (and correctly looks it up in its Catalog). If you read the rationale for Erratum #25 you'll note it is trying to legitimize the use of a SI since it was felt that the original text might prohibit it in favour of the FPI. The new text suggests the FPI and SI be treated as beeing of equal weight, and says a Conformant Implementaton "MAY" use either of them, or even additional out-of-band data, to resolve the external subset. In that light it is, to me, exceedingly odd that the CSS Validator is choosing to ignore the perfectly good FPI in favour of the (in this case) broken SI. It is especially unfortunate that when the SI fails to resolve, the CSS Validator does not then make use of the FPI to look the external subset up in its catalog. The correct error to report here would be"Warning: Ignoring FPI since SI is present" and "Unable to locate External Subset" for the CSS Validator. The Markup Validator has a standing feature request to detect when a SI is unresolveable (as well as when the SI is not identical to the "well known" URL for a particular FPI and other odd cases). I would say it is a bug, and at the very least a feature request, for the CSS Validator to not honor the FPI in this case. In either case I find it unfortunate that the CSS Validator is second-guessing the Markup Validator. The former should certainly have the more permissive defaults as its purpose is to validate the associated CSS, not the document markup per se.
Created attachment 470 [details] same as attachment 196 [details], with embedded <style> for testing purposes
We now use TagSoup as an HTML/XML parser, and it doesn't really seem to care much about FPIs and SIs (that's the point, it's made to be really tolerant) so this bug is fixed. Tested with Attachment #470 [details].