Bugzilla – Bug 1019
incorrectly validates uppercase predefined attribute values
Last modified: 2015-02-15 04:15:20 CET
This document validates <!DOCTYPE html> <html> <head><title>foo</title></head> <body> <form action="/charge" method="POST"> <script src="https://checkout.stripe.com/checkout.js" class="stripe-button" data-key="pk_test_2NwXWNYn4X732fdOEumVlz57" data-image="/square-image.png" data-name="Demo Site" data-description="2 widgets ($20.00)" data-amount="2000"> </script> </form> </body> </html> It shouldn't, per section 4.11. Attributes with pre-defined value sets of page http://www.w3.org/TR/xhtml1/diffs.html#h-4.11 method="POST" should be method="post" This bug is related to https://github.com/SWI-Prolog/packages-http/issues/1
Hi, Thanks for the report. While what you point out in your description is true for XHTML 1.1, it's not true for the current HTML spec. The validator conforms to the requirements in the current HTML spec and behaving as expected for this case. Please see the following: http://www.w3.org/TR/html/forms.html#attr-fs-method http://www.w3.org/TR/html/infrastructure.html#enumerated-attribute Those spec sections indicate that the value of form[method] is an enumerated value, with one of the possible values being an ASCII case-insensitive match for "POST". (BTW, the XHTML1 spec is obsolete and superseded by the current HTML spec at http://www.w3.org/TR/html And in the current HTML spec, most attributes are defined as being case-insensitive. Browsers never restricted their behavior to any requirements in the XHTML1 spec on case sensitivity; for example, browsers have always handled <form method="POST"> and <form method="post"> in exactly the same way. So the requirements in the current HTML spec align more closely with actual browser behavior.) So I'm going to go ahead can mark this bug resolved. But if you have further comments or questions about it, please post them here and re-open the bug if needed.
Ah, thanks. I had it backwards. So the bug's on SWI-Prolog's end only - this code is valid for html5. (SWI-Prolog's quasiquoter syntax checker was incorrectly rejecting POST in u/c - this has been corrected in a patch this afternoon as well)
(In reply to Anne Ogborn from comment #2) > Ah, thanks. > > I had it backwards. > > So the bug's on SWI-Prolog's end only - this code is valid for html5. > > (SWI-Prolog's quasiquoter syntax checker was incorrectly rejecting POST in > u/c - this has been corrected in a patch this afternoon as well) Ah, OK. Well I'm glad then if the validator helped to catch a bug in other code :-)