This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The text area form uses GET for submission. This causes the form to fail on various browsers since they limit the length of URIs to a fixed value which style sheets often exceed.
The beauty of the GET HTTP request method is that we can construct test cases that are URIs. I refuse to abandon this utility. Does using the POST method violate Web architecture or the HTTP 1.1 specification (<urn:ietf:rfc:2616>)? After all, testing for CSS validity of a string is a safe operation. Time to slog through the Web-architecture specification... Both methods can be options of the validator service. How to arrange this dual offering in a usable manner is yet another discussion, I think.
You could use JavaScript to insert a set of radio buttons that sets the method of the form (POST or GET), and then use a <noscript> element to display a link to the POST version for non-JS users. If you don't like <noscript>s, you could simply use the DOM to remove the paragraph with the link to the POST version.
Why not allow the values to be sent with either GET or POST, and change the front-end textarea to use POST? Then, the test cases will still work as URLs. To construct the test case URLs, you could just save the form locally, change the 'method' from POST to GET, and change the 'target' to point at the live server.
An argument mentioned by Jukka on the mailing-list, in favor of POST: [[ Quoting the HTML 4.01 spec: "Note. The "get" method restricts form data set values to ASCII characters. Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire [ISO10646] character set." http://www.w3.org/TR/html4/interact/forms.html#h-17.13.1 ]] http://lists.w3.org/Archives/Public/www-validator-css/2007Jul/0020.html
patched the validator to allow handling of direct input via POST. http://dev.w3.org/cvsweb/2002/css-validator/org/w3c/css/servlet/CssValidator.java.diff?r1=1.31&r2=1.28&f=h Yves, could you give it a glance? (we need to install tagsoup and java 1.6 on qa-dev, our testing ground is non functional until we do).
Could the above fix be deployed in production? Thanks. I'm currently stuck with this CSS validator, because testing CSS files of an internal enterprise application (thus unavailable on the internet) and my stylesheets are a little bigger than the HTTP max URL length. I have to send each of my CSS's through the file input to validate them one by one instead of just copy/paste the content of them.
(In reply to comment #6) > Could the above fix be deployed in production? We're waiting for translations to be completed before we can put the latest validator in production. http://qa-dev.w3.org:8001/css-validator/translations.html
in production now.