352 2003-09-30 16:56:13 +0000 CSS Validator does not recognize FPIs when SI is present. 2007-05-28 06:09:28 +0000 1 1 1 Unclassified CSSValidator XHTML1.0 CSS Validator Other All RESOLVED FIXED http://www.neonchart.com/tiki/tiki-index.php P2 normal --- 1 jan.docekal ot link r_arigur www-validator-cvs oldest_to_newest 787 0 jan.docekal 2003-09-30 16:56:13 +0000 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> 810 1 r_arigur 2003-10-16 13:42:21 +0000 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. :-/ 1165 2 196 r_arigur 2004-01-16 00:33:21 +0000 Created attachment 196 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. 1169 3 link 2004-01-16 19:04:26 +0000 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. 1170 4 r_arigur 2004-01-16 21:46:05 +0000 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.) 1175 5 link 2004-01-20 02:00:17 +0000 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. 15219 6 470 ot 2007-05-28 06:07:33 +0000 Created attachment 470 same as attachment 196, with embedded <style> for testing purposes 15220 7 ot 2007-05-28 06:09:28 +0000 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. 196 2004-01-16 00:33:21 +0000 2007-05-28 06:07:33 +0000 Testcase. testcase-bad-system-identifier.html text/html 807 r_arigur PCFET0NUWVBFIGh0bWwNCiAgICAgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0 Ly9FTiINCiAgICAgIkRURC94aHRtbDEtc3RyaWN0LmR0ZCI+DQo8aHRtbD4NCiA8aGVhZD4NCiAg PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IENoYXJz ZXQ9dXMtYXNjaWkiIC8+DQogIDx0aXRsZT5UZXN0Y2FzZTwvdGl0bGU+DQogPC9oZWFkPg0KIDxi b2R5Pg0KICA8aDE+VGVzdGNhc2U8L2gxPg0KICA8cD4NCiAgIFRoaXMgcGFnZSBpcyBub3QgdmFs aWQgWE1MIChYSFRNTCksIGJlY2F1c2UgaXQgY2xhaW1zIHRoYXQgaXRzIERURCBpcyBmb3VuZA0K ICAgYXQgPGNvZGU+RFREL3hodG1sMS1zdHJpY3QuZHRkPC9jb2RlPiAod2hpY2ggaXQgZG9lcyBu b3QpLiBOb25ldGhlbGVzcywgDQogICA8YSBocmVmPSJodHRwOi8vdmFsaWRhdG9yLnczLm9yZy9j aGVjay9yZWZlcmVyIj50aGUgVzNDIE1hcmtVcCBWYWxpZGF0aW9uDQogICBTZXJ2aWNlIGFzc3Vy ZXMgbWUgdGhhdCBpdCBpcyB2YWxpZDwvYT4uIFRoZSBWYWxpZGF0aW9uIFNlcnZpY2Ugc2hvdWxk DQogICBhbHdheXMgY2hlY2sgdG8gbWFrZSBzdXJlIHRoZSBVUkkgZ2l2ZW4gaW4gdGhlIERPQ1RZ UEUgZGVjbGFyYXRpb24gaXMNCiAgIGNvcnJlY3QuDQogIDwvcD4NCiAgPHA+DQogICBGb3IgbW9y ZSBpbmZvcm1hdGlvbiwgc2VlDQogICA8YSBocmVmPSJodHRwOi8vd3d3LnczLm9yZy9CdWdzL1B1 YmxpYy9zaG93X2J1Zy5jZ2k/aWQ9MzUyIj5CdWcgIzM1MjwvYT4uDQogIDwvcD4NCiA8L2JvZHk+ DQo8L2h0bWw+ 470 2007-05-28 06:07:33 +0000 2007-05-28 06:07:33 +0000 same as attachment 196, with embedded <style> for testing purposes 352_withcss.html text/html 869 ot PCFET0NUWVBFIGh0bWwKICAgICBQVUJMSUMgIi0vL1czQy8vRFREIFhIVE1MIDEuMCBTdHJpY3Qv L0VOIgogICAgICJEVEQveGh0bWwxLXN0cmljdC5kdGQiPgo8aHRtbD4KIDxoZWFkPgogIDxtZXRh IGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBDaGFyc2V0PXVz LWFzY2lpIiAvPgogIDx0aXRsZT5UZXN0Y2FzZTwvdGl0bGU+CiAgPHN0eWxlIHR5cGU9InRleHQv Y3NzIj4KICAgIHAgewogICAgICBmb286IGJhcjsKICAgICAgY29sb3I6IHJlZDsKICAgIH0KICA8 L3N0eWxlPgogPC9oZWFkPgogPGJvZHk+CiAgPGgxPlRlc3RjYXNlPC9oMT4KICA8cD4KICAgVGhp cyBwYWdlIGlzIG5vdCB2YWxpZCBYTUwgKFhIVE1MKSwgYmVjYXVzZSBpdCBjbGFpbXMgdGhhdCBp dHMgRFREIGlzIGZvdW5kCiAgIGF0IDxjb2RlPkRURC94aHRtbDEtc3RyaWN0LmR0ZDwvY29kZT4g KHdoaWNoIGl0IGRvZXMgbm90KS4gTm9uZXRoZWxlc3MsIAogICA8YSBocmVmPSJodHRwOi8vdmFs aWRhdG9yLnczLm9yZy9jaGVjay9yZWZlcmVyIj50aGUgVzNDIE1hcmtVcCBWYWxpZGF0aW9uCiAg IFNlcnZpY2UgYXNzdXJlcyBtZSB0aGF0IGl0IGlzIHZhbGlkPC9hPi4gVGhlIFZhbGlkYXRpb24g U2VydmljZSBzaG91bGQKICAgYWx3YXlzIGNoZWNrIHRvIG1ha2Ugc3VyZSB0aGUgVVJJIGdpdmVu IGluIHRoZSBET0NUWVBFIGRlY2xhcmF0aW9uIGlzCiAgIGNvcnJlY3QuCiAgPC9wPgogIDxwPgog ICBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgc2VlCiAgIDxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3Jn L0J1Z3MvUHVibGljL3Nob3dfYnVnLmNnaT9pZD0zNTIiPkJ1ZyAjMzUyPC9hPi4KICA8L3A+CiA8 L2JvZHk+CjwvaHRtbD4=