This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We're unconditionally setting HTML::Parser into xml_mode() in preparse(). Seemingly this means that the doctype declaration isn't recognized in this mode if it's in lowercase. I don't think this is a HTML::Parser bug; the whole doctype declaration *is* case sensitive in XML, whereas in SGML eg. the "DOCTYPE" and "PUBLIC" words are perfectly legal in lowercase. AFAICT, this won't affect the validation, but the "valid" response page doesn't know the document type, hence reporting only "This page is Valid!". Perhaps preparse() should take the already available information (Content-Type, possibly the XML declaration) into account when setting the mode of HTML::Parser. Oh, and this is with HTML::Parser 3.26. And see the URL for a test case.
I see no easy way to achieve this right now. Switching xml_mode() on and off based on available information at that point involves too much guesswork. I think is a perfect case for documenting it as a known limitation and moving on.
Reset target to 1.0 (aka. "Blue Sky" ;D) and reassigning to Ville. I see no sane way to do it, but perhaps you do? If not, either leave the bug open in the hopes that we'll find a way later, or close it.
I can't come up with a robust way to do it either at the moment. But I haven't quite given up yet, leaving open...
*** Bug 904 has been marked as a duplicate of this bug. ***
*** Bug 1280 has been marked as a duplicate of this bug. ***
Why was this closed as "INVALID"? The bug is still not solved and there was no explanation, why the reported bug was considered "invalid".
(In reply to comment #6) > Why was this closed as "INVALID"? Because someone is having a lot of fun today messing up the state of bugs in this database.
Discussions on Bug #1500 and others seem to point to one solution: - if the content-type is text/html, then set HTML::Parser in html without xml_mode() - if the content-type is anything else (as far as I can tell, all other document types supported by the validator are xml-based), then set HTML::Parser The current code for check goes: 1) set temporary parse mode to SGML, XML or TBD based on content-type ( check v 1.432.2.11; lines 188-193 ) 2) run $File = &preparse_doctype($File); in systematic XML mode. ( check v 1.432.2.11; line 526 ) 3) if parse mode is still TBD, based on doctype found, set parse mode to SGML or XML ( check v 1.432.2.11; lines 530-560 ) If I understand the proposal of Bug #1500, the new behavior would be 1) set parse mode to SGML, XML based on content-type. text/html systematically means SGML mode 2) run $File = &preparse_doctype($File); using detected parse mode as mode for HTML::Parser and subsequent doctype detection. If the above is correct, then it seems fixing this bug (Bug #24) is almost immediate once Bug #1500 is resolved. Am I missing something?
I guess relying on Content-Type alone for the SGML/XML mode decision may not work too well with uploaded documents and/or markup submitted through a textarea. Maybe require the user to set the mode in those cases? This would however have an effect on the CGI "API" (think 3rd party tools submitting docs to the validator).
(In reply to comment #9) > I guess relying on Content-Type alone for the SGML/XML mode decision may not > work too well with uploaded documents and/or markup submitted through a > textarea. > Maybe require the user to set the mode in those cases? Upload should not be much of a problem, should it? Only for .html documents which would probably be treated as html even if they are XHTML 1.0, but it may just push more people to use .xhtml and serve as application/xhtml+xml. Direct input is an issue indeed, however, and I suppose we could have a "treat as HTML | treat as XML" radio choice. Similar in a way to what valet does, but probably more accessible to the layman than a choice of parsers. > This would however have > an effect on the CGI "API" (think 3rd party tools > submitting docs to the validator). True. That means we need a default for the direct input mode.
Hm, if .xhtml uploads as application/xhtml+xml with recent browsers, then the situation is better than I thought. I guess not a lot of people use the .xhtml extension at the moment, FWIW. Regarding the API change, I generally tend to think that prominently breaking things is better than subtle, hidden, incompatible behaviour changes. This change would fall into a grayish area though, maybe having a documented default would be acceptable, even if it could cause different results for the same submission before and after the change. Just thinking aloud, no strong opinions.
(In reply to comment #11) > Hm, if .xhtml uploads as application/xhtml+xml with recent browsers, then the > situation is better than I thought. I guess not a lot of people use the .xhtml > extension at the moment, FWIW. I assumed so, but it is worth testing. > Regarding the API change, I generally tend to think that prominently breaking > things is better than subtle, hidden, incompatible behaviour changes. Good point. Whatever we do, we should try and talk directly to a number of known users of the direct input (opera, mozilla's web developer extension, etc).
(In reply to comment #10) > > This would however have > > an effect on the CGI "API" (think 3rd party tools > > submitting docs to the validator). > > True. That means we need a default for the direct input mode. I think in the absence of media type information, the validator should either (1) force the user to choose one before performing validation, or (2) first issue a warning about lack of media type information and then check if the character stream begins with (ignoring BOM) "<?xml", and, if so, use XML mode, otherwise SGML mode. In case of (2) the user should be able to change the mode and revalidate. In either case it should not just say "This is valid X!" without warnings in the case of absent media type information, because it might not be true.
I think this precise bug was fixed by changing the behavior to the following: * read content type, if any * if content type gives parse mode of TBD, or no content type, use HTML::Parser as SGML mode else, preparse as XML. (that is, switch the default to SGML mode, and use XML mode only when we are sure) This new default will probably cause some issues with direct input ( but that's a question for Bug #1391 ) and some custom DTDs, but over all this behavior is more sane.